Qclaw bug反馈

核心问题诊断：

我刚分析了 wechat-access 插件的源代码，发现真相：

1. 消息确实发出去了——message 工具调用 sendText 函数，返回 {ok: true}，没有任何错误
2. 但消息被标记为 msg_type: "cron_job"（系统定时任务事件），通过 WebSocket 推送给腾讯 AGP（AI Gateway Protocol）
3. AGP 把消息路由到了你的 QClaw 小程序——你截图里那个"股票投资专家"聊天界面就是消息的去向
4. 小程序把它当成了"新的用户请求"——所以它会"重新做分析"，而不是显示我推送的内容

所以你看到的现象完全合理：

• 小程序里说"没收到你电脑发来的 A 股周期分析"——因为它把我的推送误判为新任务
• “正在重新做 A 股周期分析”——因为它把推送当成新指令了
• 但它的工作区里有我保存的报告文件 A股周期分析报告_2015_2025.md

解决方案：

请你在微信小程序里直接告诉它：

“你的工作区有文件 A股周期分析报告_2015_2025.md，直接读取并显示给我，不要重新分析”

这样小程序就会读我的文件并把内容展示给你看。

长期方案： 我建议你去 QClaw 社区反馈：wechat-access 插件的 cron_job 消息类型应该被 Mini Program 识别为"已推送结果"而不是"新请求"。这是产品 bug，不是我能修的。

问题描述：微信小程序双向通信失效

环境：QClaw 2026.6.5，wechat-access 已正确配置且能推送文字消息

复现步骤：

1. 在微信小程序"股票投资专家"发一条消息给 Agent
2. PC 端 Agent 收到消息并正常回复
3. 小程序页面显示"没收到"，PC 端日志显示消息已通过 wechat-access 成功推送

根因：小程序的 WebSocket 入口和 wechat-access 的客服号推送入口是两个独立通道。Agent 响应小程序消息时，回复被路由到客服号通道（msg_type: “cron_job”），小程序无法将其识别为用户可见回复。

建议修复：响应小程序消息时，回复应通过小程序的 WebSocket 通道回推，而非 wechat-access 客服号通道。

第二个问题：

我觉得你陷入了某种逻辑陷阱的死循环。换个角度，假设没有surface，你是不是就不能建立一个微信clawbot? 如果答案是不能，那我理解这个Qclaw是专门给surface设计，作为初次安装必须用surface，然后才能用电脑。如果是这样，那我就理解当前的问题，链接不能改变，必须一直依赖surface才能决定微信clawbot的在线。如果答案是可以，那么有和没有surface不重要，重要的是顺序，谁第一个建立，谁拥有微信clawbot，不能更改。这也可以理解，可能也是bug。技术性地讲。微信clawbot应该和同一账号下的Qclaw保持联系，并且依据激活建立优先顺序，简言，就是谁下线，谁就被移除，在线的成为primary node

这个思路是对的。我重新想了一下。

先回答你的核心问题：没有 Surface，PC 上的 QClaw 能不能建立微信 ClawBot？

从配置看——可以。guid 是设备绑定的，但 userId（1409517995）是你这个微信账号，PC 上配置同样的 userId + 对应的 token 和 guid，理论上可以连接。

但这指向了一个真正的设计缺陷：

微信 ClawBot 的连接是"独占式"的——同一时间只能有一个 QClaw 实例连上去。不是"多设备共享同一通道"，而是"先到先得，后来者抢占"。Surface 先建立了连接 → PC 上的 QClaw 就连不上去。

这不是 bug，这更像是一个架构设计选择：一个微信账号 + 一个 ClawBot = 一对一关系，天然就是独占的。

但你的"primary node"思路是对的：

合理的逻辑应该是——谁在线谁就是 active node，离线的自动释放连接，再上线时重新竞争。但 QClaw 没有实现这个逻辑，所以：

• Surface 关机 → 连接没释放 → ClawBot 显示离线
• PC 上的 QClaw 想接管 → 没有机制让它接管

结论：你的理解是对的，Surface 不是"可选配件"，而是微信通道的唯一锚点。 这解释了为什么 ClawBot 显示离线——不是 Surface 离线，是整个微信通道因为 Surface 关机而中断了，而且 PC 没有被授权接管。

这不是配置问题，是 QClaw 产品设计层面的"单点故障"——微信通道强依赖某一台特定设备的在线状态。

你发的社区帖子其实应该加上这一点：微信通道应该支持多设备竞争接入，或至少实现 primary node 自动切换机制，而不是一旦设备离线就连带所有通道失效。