OpenClaw 飞书 ↔ 微信桥接调试报告 时间2026-08-10环境Windows / OpenClaw 2026.7.1-2 / Claude Sonnet 5Alluse 中转 Qwen3-8Bfallback/ openclaw-weixin(iLink) feishu 插件一、目标实现飞书发【微信】xxx→ OpenClaw 调本地 Node 脚本 → 经 iLink 协议主动推送至手机微信反向微信→飞书走被动同步。二、已闭环的部分技术链路 100% 通模型层anthropic/openai/claude-sonnet-5经 Alluse OpenAI 兼容中转调通504 时 fallback 到siliconflow/Qwen/Qwen3-8B。权限层tools.allow含exec/bashexec.securityfullchannel_send按通道 deny/allow 分离飞书禁、微信开。命令执行层放弃让 LLM 直接拼node C:\...\wx-send.cjs base64曾出现node 、~路径、PowerShell 转码导致Exec failed改为中间文件 静态 batC:\openclaw\msg.txt写明文C:\openclaw\send.bat固定调用 OpenClaw 便携 NodeC:\Users\Administrator\AppData\Local\OpenClaw\deps\portable-node\node.exe C:\Users\Administrator\.openclaw\wx-send.cjs %MSG%Claude 只负责写文件 执行C:\openclaw\send.bat不再接触动态参数。脚本层wx-send.cjs走ilinkai.weixin.qq.com/ilink/bot/sendmessage带bot_tokencontext_tokenHTTPS 请求能发出Node/路径/编码全通。被动方向手机微信给 bot 发/ping→ bot 回pong证明 iLink 收消息、OpenClaw 插件存活。三、未闭环的部分平台规则层现象飞书侧 Claude 回“已发微信xxx”但手机微信收不到手工 CMD 跑send.bat脚本打到 iLink 服务端返回{ret:-2,errmsg:prepare failed}早期日志曾误打HTTP 200 {message_id:...}属脚本未打印真值。根因iLink 协议限制非配置问题iLink bot只能被动回复不能对“未建立活跃会话”的用户主动推送context_token来自用户侧近 24h 内向 bot 发消息超时失效即ret:-2单 token 下行配额约 10 条超量也回ret:-2因此“飞书静默喊一声 → 微信主动弹出”在当前架构下不可靠。四、排障关键节点时间线Claude 经 Alluse 504 → fallback Qwen → Qwen 幻觉“已发微信” → 定位到中转超时 fallback 嘴硬。Claude 接管后 exec 出现node /~截断 → 定位 OpenClaw exec 宿主对动态命令重写失败。改send.bat中间文件法 → 手工跑报“系统找不到路径” → 发现 Node 不在Program Files\nodejs而在 OpenClaw 便携目录。路径修正后脚本运行 → 打印假HTTP 200→ 改脚本打印原始响应 → 确认服务端ret:-2。手机发/pingbot 回pong→ 印证被动通、主动被平台拒。五、最终结论飞书→Claude→exec→Node→iLink 请求全链路技术成功。iLink→手机微信主动推送被平台会话规则阻断ret:-2无法靠改配置/改脚本/换模型解决。稳定可用架构应为反向为主微信用户 → bot → Claude 处理 → 被动回微信 ✅微信 → 飞书同步channel_send✅飞书 → 本地任务/写文件/分析 ✅但不承诺飞书指令让微信主动响。六、遗留与建议AGENTS.md 已改为“exec 失败/ret:-2 不许谎报已发微信”。若未来要真主动推送需用户侧定时发心跳消息刷新context_token或弃用 iLink 改走企业微信/公众号模板消息/短信网关。本次不再死磕ret:-2桥接以“微信触发为主、飞书协同”收工。要不要我把这份报告整理成C:\Users\Administrator\.openclaw\workspace\BRIDGE_REPORT.md直接落盘