背景：2026 年 10 月 12 日

那天我想让 AI 能直接收发微信消息——不是网页版那种半吊子，是正经的双向通道。调研了一圈，腾讯官方的 iLink Bot API 是正道：微信 App 里"设置→插件→ClawBot"扫码配对，走官方通道。

打通：比想象中顺利

配对流程：扫码 → 绑定 → AI 就能收微信消息了。收发能力实测：

• 收：文本（含引用回复）、语音（自动转文字）、图片/视频/文件都能收
• 发：文本（超长自动分段）、图片/视频/文件都能发
• 不支持：发语音条（试过 TTS 转 Opus 推流，服务端返回成功但客户端不渲染——官方插件也只做了收语音）

语音转文字走的是声纹+ASR 的 pipeline，实测准确率够用。

最大的坑："24 小时过期"是个误会

网上很多文章说"iLink 每天要重新扫码"，我一开始也信了。实际测下来发现，这是把两种凭证搞混了：

bot_token（扫码配对凭证）：扫码一次获得，本地持久化。不会自动过期。我实测存活数天没问题。失效的唯一信号是 errcode = -14，意思是"token 被作废"——比如你在别处重新扫码绑定，把旧的顶掉了。这时候才需要重扫。

context_token（会话上下文）：每条用户消息携带，发消息时要回传。约 24 小时 TTL，从用户最后一条消息起算的滑动窗口（不是自然日）。过期后只影响"AI 主动推送"，用户再发一条消息就刷新了，不需要重新扫码。

腾讯官方协议文档全文没有写"24 小时过期"这几个字。"24h/10条"的数字来自社区实测和第三方文档的转述。DSH 等项目做的"24 小时回到待扫码状态"，是它们的保守本地策略，不是服务端行为。

几个实测结论

• 保活没用：长轮询在线、定时收发，都不能延长 context_token。只有用户主动发消息能开启新周期。
• 没有续期接口：协议里就那几个接口（扫码、收消息、发消息等），没有 refresh_token，没有申请延长有效期的公开渠道。
• 一个微信号同时只能保一个机器人绑定：我在别处扫了新的，旧的直接被顶掉作废（-14）。实测确认的。
• 看门狗：收消息的服务是后台进程，VM 重启会掉。我加了个每 5 分钟检查的看门狗，掉了自动拉起。

一点体会

这次最大的价值不是"接通了微信"，而是用实测纠正了一个流传很广的错误认知。网上说"每天重扫"的人，可能都没分清两种 token 的区别。

做技术调研，官方文档 + 自己实测 > 网上转述。这个结论我以后会反复用。