问ClawBot iLink 下行静默丢弃，同机双微信号对照实验定位到账号级：特定微信号 sendmessage 返回 ret:0 但 100% 不投递？

问题概述

一个微信 ClawBot（iLink）机器人，上行正常、下行 100% 静默丢弃：ilink/bot/sendmessage 稳定返回 HTTP 200 {"ret":0}，但消息永远不出现在手机微信里。同一台机器上换成另一个微信号接入，同样的代码、同样的参数，下行立即完全正常。

环境

代码块

iLink 服务器:        https://ilinkai.weixin.qq.com/
协议版本:            WEIXIN_PROTOCOL_VERSION = 2.4.6
客户端:              DeepSeek Harness (DSH) 的微信通道插件（自建 iLink bot 客户端，非 OpenClaw）
操作系统:            Windows

故障账号

代码块

iLink user_id:       o9cq801JehOTa8tb3S1D4tbX2uuk@im.wechat
bot accountId:       5d384e5eecd0@im.bot
botId:               wx_1e95ca30978c2d572f484e23
绑定时间:            2026-10-12T13:46:01.475Z
历史情况:            该微信号此前绑定过 OpenClaw / ClawBot 连接，旧连接已停用
累计已发出未送达:    7 条（全部丢失，无一条到达）

对照账号（同一台机器、同一个客户端进程、同一时刻）

代码块

iLink user_id:       o9cq80wjo2nSlac43VwofrS9GGm0@im.wechat
bot accountId:       290a1f4f0546@im.bot
botId:               wx_cd637cb25865c1cb49ca9c37
绑定时间:            2026-10-12T13:55:08.369Z
投递结果:            正常，首条下行 21:55:27 立即出现在手机微信

核心对照实验（本次最有价值的部分）

两个微信号同时绑定在同一个 DSH 进程中，唯一变量是微信号本身，结果完全相反：

两个账号的 sendmessage 服务端响应完全一致（都是 {"ret":0}），但只有故障账号的消息在投递环节消失。

关键设计点：新增第二个微信号时，该客户端的扫码流程会把已有账号的 token 一并上报给 ilink/bot/get_bot_qrcode（local_token_list 参数）。也就是说，这次扫码恰恰携带了故障账号的 token，按"旧 token 污染新绑定"的假设本应继承故障 —— 但新号下行完全正常。这同时证伪了"携带旧 token 导致腾讯侧复用旧绑定"。

已排除的可能性

1. 不是客户端参数问题。已穷举测试：message_state (0/1/2)、message_type (1/2)、from_user_id 有无、client_id 有无、context_token 有无、run_id / msg_id、GENERATING→FINISH 流式配对、重新 notifystart。全部返回 {"ret":0}，全部不投递。服务端确实会校验参数（GENERATING + 空 item_list → {"ret":-2,"errmsg":"invalid arguments"}；多传未知字段 → {"ret":-1,"errmsg":"invalid request"}），说明报文格式正确。
2. 不是 bot 实例问题。删掉旧 bot、清理本地凭据后，用全新 bot 实例重新扫码，故障逐条完全复现（sendmessage 仍 {"ret":0}，手机仍不显示，typing 仍正常显示）。
3. 不是本地凭据残留。本地 token 文件中旧 token 已彻底清除，只剩当前实例。
4. 不是 context_token 过期。故障账号每次都是用户刚发言后秒级回复，context_token 必然是新鲜的，依然不投递。
5. 不是客户端架构缺陷。该客户端每个 bot 实例有独立的 runtime 和独立的长轮询循环，HTTP 走全局 fetch 连接池，不存在"同一 token 被两个 session 争抢"的结构（这一点已对照若干第三方实现核实）。

第三方项目的同源证据（供参考）

同样的"HTTP 200 假成功 + 静默丢弃"故障模式在其他 iLink/ClawBot 客户端上已被独立报告并定位：

1. hermes-agent PR #10091《fix(weixin): split poll/send sessions and reuse live adapter to prevent message loss》 https://github.com/NousResearch/hermes-agent/pull/10091 其 Root Cause 明确写道：当网关运行时，cron 任务与 send_message 会用一个 bot token 创建竞争的 iLink session，iLink 后端有时返回 HTTP 200，但消息被静默丢弃或严重延迟，原因是 long-poll session 与 standalone session 冲突。 → 这说明 iLink 后端确实存在"下行路由指向错误/冲突的 session 时，返回成功码但丢弃消息"的行为。本次故障账号的现象与此同源，只是"竞争方"是历史 OpenClaw 连接留下的失效路由。
2. zeroclaw issue #8967《[Bug]: WeChat sendmessage ignores in-body errors and reports failed deliveries as successful》 https://github.com/zeroclaw-labs/zeroclaw/issues/8967 指出 iLink 的 sendmessage 失败时返回 HTTP 200 + body 内非零 ret/errcode，与微信 API 家族一致；客户端若只看 HTTP 状态就会把失败当成功。 → 本次故障的返回码是 {"ret":0}，即服务端主动"承认成功"后才丢弃，属于投递链路环节而非接口拒绝环节。

我的判断

丢弃发生在 iLink 服务端针对该特定微信号的下行投递链路上：该微信号的下行路由仍指向历史 OpenClaw 连接留下的残留 session（或失效路由目标），新绑定的 bot 虽然鉴权、上行、typing 全部正常，但下行消息被投递到已不存在的目标后丢弃，且服务端不报错。

诉求

1. 请协助解除微信号 o9cq801JehOTa8tb3S1D4tbX2uuk@im.wechat 在 iLink / ClawBot 侧指向历史 OpenClaw 连接的残留绑定/缓存，使其新绑定的 bot 能正常下行投递。
2. 如果属于已知问题，请告知预计修复时间；如果是策略性限制，请明确说明该微信号违反了哪一条策略。
3. 如需要，我可以提供任意时间点的完整请求/响应报文、sendmessage 的原始 HTTP 抓包，以及同账号 getupdates 的正常上行记录。

附：复现原始记录

代码块

# 故障账号（2026-10-12 21:48）
账号 wx_1e95ca30978c2d572f484e23 -> o9cq801JehOTa8tb3S1D4tbX2uuk@im.wechat
getconfig      <- 200 {"ret":0,"typing_ticket":"<长度 472>"}
sendtyping(1)  <- 200 {"ret":0}      # 手机确实显示「对方正在输入」
sendtyping(2)  <- 200 {"ret":0}
sendmessage    <- 200 {"ret":0}      # 手机永远不显示
本地 state.json recentOutboundMessages 累计 7 条已发送记录（含 providerMessageIds），全部未送达

# 对照账号（2026-10-12 21:55，同一 DSH 进程内，同一时刻）
账号 wx_cd637cb25865c1cb49ca9c37 -> o9cq80wjo2nSlac43VwofrS9GGm0@im.wechat
contextToken receivedAt = 21:55:25
recentOutboundMessages:
  [21:55:27] -> o9cq80wjo2nSlac43VwofrS9GGm0@im.wechat   # 用户确认手机上立即收到