拆解微信 ClawBot 是如何接入 OpenClaw 的

微信 ClawBot 接入 OpenClaw 的底层逻辑与其他 app 方案本质一致。 核心链路为：微信用户 ⇌ 腾讯 iLink 云服务 (ilinkai.weixin.qq.com) ⇌ openclaw-weixin 插件 ⇌ OpenClaw Gateway ⇌ AI 模型。 插件并不直接直连微信服务器，而是将腾讯提供的 iLink 云服务作为全局的消息中转枢纽。 扫码鉴权与注册流程： 设备的注册与鉴权通过标准的扫码流程完成。 插件首先调用 iLink API 获取二维码 URL 及临时 Token；用户微信扫码后，插件通过轮询接口状态（等待/已扫描/已确认）。确认授权后，插件获取最终的 bot_token 与 ilink_bot_id，并将这些核心凭证保存至本地目录。 在通信设计上，方案舍弃了对网络环境要求较高的 Webhook 模式，转而采用 HTTP 长轮询（Long-Polling）。 @指令下行（收消息）： monitorWeixinProvider 模块持续对 iLink 服务发起长轮询，拉取增量消息并转交 OpenClaw Gateway。运行环境无需配置公网 IP，仅需具备外网访问权限即可正常运转。 @结果上行（发消息）： Agent Runtime 处理完任务后，通过 iLink API 将结果下发。其中，文本内容直接投递，图片等媒体文件则通过专用的微信 CDN上传处理。 OpenClaw 宿主环境中的数据存储采用了配置与凭证分离的策略：openclaw.json 仅负责记录渠道的启用状态及绑定的账号列表。openclaw-weixin/accounts.json 维护已注册的 Account ID 数组。 此外，敏感信息不写入主配置，而是按 ID 独立存储于 accounts/{id}.json 文件中。消息的同步游标单独保存在 accounts/{id}.sync.json，确保消息不被重复拉取执行。 该架构原生支持多账号，单次扫码即生成独立的 Account 实例及对应的配置文件。实现了配置的热重载机制。 当新的登录凭证写入本地文件后，OpenClaw Gateway 会自动监听文件系统变化，并动态加载新Channel，全程无需重启主服务进程。 #openclaw #qclaw