OpenClaw 飞书 ↔ 微信桥接调试报告

MindWeave

354人浏览 · 2026-08-10 16:04:54

MindWeave · 2026-08-10 16:04:54 发布

时间：2026-08-10

环境：Windows / OpenClaw 2026.7.1-2 / Claude Sonnet 5（Alluse 中转）+ Qwen3-8B（fallback）/ 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/bash，exec.security=full，channel_send 按通道 deny/allow 分离（飞书禁、微信开）。
命令执行层：放弃让 LLM 直接拼 node "C:\...\wx-send.cjs" <base64>（曾出现 node &、~ 路径、PowerShell 转码导致 Exec failed），改为中间文件 + 静态 bat：
- C:\openclaw\msg.txt 写明文
- C:\openclaw\send.bat 固定调用 OpenClaw 便携 Node：
  
  "C:\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_token + context_token，HTTPS 请求能发出，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。
手机发 /ping bot 回 pong → 印证被动通、主动被平台拒。

五、最终结论

飞书→Claude→exec→Node→iLink 请求：全链路技术成功。
iLink→手机微信（主动推送）：被平台会话规则阻断，ret:-2 无法靠改配置/改脚本/换模型解决。
稳定可用架构应为反向为主：
- 微信用户 → bot → Claude 处理 → 被动回微信 ✅
- 微信 → 飞书同步（channel_send）✅
- 飞书 → 本地任务/写文件/分析 ✅，但不承诺飞书指令让微信主动响。