微信官方小龙虾插件协议拆解
今天微信发布了官方龙虾插件 微信ClawBot，支持 OpenClaw 接入个人微信。 第一时间尝试之后，深入源代码，分析其协议实现。废话不多说，直接开始。 一张图先看全局 整套协议的结构其实非常规整：控制面走 Bot 网关，��据面走 CDN，插件本地负责把两者接起来。 控制面接口主要有 5 个： getupdates sendmessage getuploadurl getconfig sendtyping 数据面则只有一件事：媒体文件通过 CDN 上传/下载，本地做 AES-128-ECB 加解密。 这就是理解整套协议的入口。 1. 登录链路：二维码授权 -> bot_token 先看登录。 插件登录阶段只依赖两个接口： GET /ilink/bot/get_bot_qrcode?bot_type=3 GET /ilink/bot/get_qrcode_status?qrcode=... 第一步拿二维码，第二步轮询二维码状态。它的状态机大致如下： 确认授权后，服务端会返回： { "status": "confirmed", "bot_token": "<bot_token>", "ilink_bot_id": "xxxxxxxx@im.bot", "ilink_user_id": "xxxxxxxx@im.wechat", "baseurl": "https://ilinkai.weixin.qq.com" } 这里真正关键的是 4 个字段： bot_token：后续所有业务请求的 Bearer 凭证 ilink_bot_id：Bot 身份 ilink_user_id：绑定的微信用户 baseurl：服务端下发的 API 基址 插件会把这些值保存到本地账号文件，后续 gateway 启动时直接复用。 一句话概括登录阶段：二维码只是授权入口，真正建立会话能力的是 bot_token。 2. 统一请求头：协议外壳非常稳定 除了扫码登录用 GET 之外，后续业务接口基本都是 JSON POST。统一请求头如下： Content-Type: application/json AuthorizationType: ilink_bot_token Authorization: Bearer <bot_token> X-WECHAT-UIN: <base64(random uint32 decimal string)> SKRouteTag: <optional> 这里可以顺手记住 3 个实现细节。 ...