微信联通精简版 OpenClaw后秒变龙虾神器

当我们决定让 AI 直接在微信里对话时，面前有两条路：要么通过企业微信插件，可以移步之前文章持证上岗！如何在微信里驯养一只 OpenClaw 龙虾，要么站在巨人肩膀上。这次我们选后者 -- 微信官方WeixinClawBot插件(微信官方连龙虾插件)，结合 OpenClaw 这个开源 AI Agent 框架，但只取其中最核心的微信通道模块，在一个云端沙盒里跑起来。

这篇文章记录了整个搭建过程、踩过的每一个坑，以及最终形成的架构方法论。如果你也想让 AI 住进微信，让它真正成为你生产力的助手，这份避坑指南或许能帮你少走几天弯路。

一、为什么选择 OpenClaw

OpenClaw 是一个 TypeScript 编写的 AI Agent 框架，它的核心价值在于把「AI 大脑」和「通信管道」彻底解耦：

关键优势：安装一个 npm 包 + 扫个码，微信就通了。不需要你去逆向微信协议，不需要企业微信的复杂审批。

二、整体架构设计

最终跑通的架构是这样的：

这个架构有一个关键设计：翻译代理层。因为 OpenClaw 的 Anthropic Provider 使用 Anthropic Messages API 格式，而我们的 AI Gateway 是 OpenAI Chat Completions 兼容格式，中间需要一层协议翻译。

三、搭建步骤（精简版）

第一步：安装 OpenClaw

npm install -g openclaw

OpenClaw 安装后，配置文件位于 ~/.openclaw/openclaw.json，这是整个系统的神经中枢。为了后续提升响应速度，将不相关的文件及代码删除，从原始 10,200 文件精简到 4 个文件, 千余行代码, 1 个 npm 依赖，只保留微信相关的模块即可。

第二步：安装微信插件

npx -y @tencent-weixin/openclaw-weixin-cli@latest install

这条命令会把 @tencent-weixin/openclaw-weixin@2.0.1 安装到 ~/.openclaw/extensions/openclaw-weixin/。

第三步：配置 openclaw.json

{"agents":{"defaults":{"model":{"primary":"anthropic/claude-sonnet-4-6"}}},"models":{"providers":{"anthropic":{"baseUrl":"http://127.0.0.1:18800","apiKey":"proxy-key","models":[]}}},"gateway":{"mode":"local","auth":{"mode":"token","token":"your-token-here"}},"plugins":{"entries":{"openclaw-weixin":{"enabled":true}}}}

注意 models 数组必须存在（即使为空），否则启动会报验证错误。

第四步：编写翻译代理

这是整个项目最核心的创造性工作。翻译代理需要完成：

关键代码片段 -- 模型名映射：

functionmapModel(model) {   return"anthropic/" + model     .replace("claude-sonnet-4-6", "claude-sonnet-4.6")     .replace("claude-opus-4-6", "claude-opus-4.6"); }

OpenClaw 用连字符格式 (claude-sonnet-4-6)，而 AI Gateway 用点号格式 (claude-sonnet-4.6)，这个细节会让你调试半天。

第五步：扫码登录

npx openclaw channels login openclaw-weixin

会弹出一个腾讯 iLink Bot 的二维码，用微信扫描即可。二维码有效期约 60 秒，动作要快。

第六步：启动 Gateway

npx openclaw gateway run

看到 [weixin] config cached for xxx@im.wechat 就说明微信通道已连接成功。点击后扫码后就可以使用openclaw。

四、七个必踩的坑和解决方案

坑 1：models 字段缺失导致启动失败

现象：Gateway 启动报 models.providers.anthropic.models: expected array

原因：OpenClaw 的配置校验严格要求 models 字段为数组类型

解法：加上 "models": []，即使你不需要声明任何模型

坑 2：Provider Base URL 可能不被识别

现象：配置了 "baseUrl": "http://127.0.0.1:18800"，但请求仍然打到了真正的 Anthropic API

原因：OpenClaw 某些 Provider 的 Base URL 可能是硬编码的（OpenRouter Provider 就是如此）

解法：同时设置环境变量 ANTHROPIC_BASE_URL=http://127.0.0.1:18800，配置和环境变量双保险

坑 3：流式响应格式不匹配

现象：Gateway 报 LLM request timed out 或 request ended without sending any chunks

原因：OpenClaw 默认发送流式请求（stream: true），但代理只处理了非流式场景

解法：代理必须实现完整的 Anthropic SSE 协议，包括 message_start、content_block_start、content_block_delta、content_block_stop、message_delta、message_stop 六种事件类型

坑 4：QR 码 60 秒超时

现象：CLI 输出 QR 码太慢，还没来得及扫就过期了

原因：在云端沙盒中，CLI 的 stdout 可能有缓冲延迟

解法：写一个 Web Server 包装登录流程，把 QR URL 实时暴露为 HTTP 接口，用浏览器访问扫码

坑 5：auth-profiles.json 格式

现象：401 invalid x-api-key 或 Missing Authentication header

原因：OpenClaw 的认证解析顺序是 auth-profiles.json > 环境变量 > openclaw.json，格式必须严格匹配

正确格式：

{"version":1,"profiles":{"anthropic:default":{"type":"api_key","provider":"anthropic","key":"your-key-here"}}}

坑 6：进程在沙盒中被杀

现象：Gateway 和代理过一段时间就静默退出，微信机器人无响应

原因：后台进程在沙盒环境中不稳定，bash 级别的 supervisor 脚本自身也可能被杀

解法：将服务注册到系统级 supervisord，利用 autorestart=true + startretries=999 实现真正的进程保活

[program:openclaw_gateway]command=bash -c "sleep 5 && exec npx openclaw gateway run"autorestart=truestartretries=999

坑 7：LLM 调用了不存在的工具

现象：代理日志出现 unknown tool: message_user

原因：LLM 会「创造性地」调用它认为应该存在的工具，比如 message_user、send_message 等

解法：在工具调用循环中过滤只处理已知工具，未知工具返回错误提示而不是崩溃

constKNOWN_TOOLS = ["generate_image", "generate_video", "publish_wechat_article"]; const knownTools = toolCalls.filter(tc =>KNOWN_TOOLS.includes(tc.function.name));

五、翻译代理的设计哲学

翻译代理是这个项目最有价值的部分。它的设计原则是：

不只是翻译，更是增强。

原始的 OpenClaw + Anthropic 组合只能做纯文本对话。通过翻译代理层，我们注入了三个工具：

代理内部实现了完整的工具调用循环：LLM 请求 → 检测工具调用 → 执行工具 → 将结果喂回 LLM → 再次请求（最多 5 轮），直到 LLM 给出最终文本回复。

媒体内容通过 MEDIA:url 指令嵌入到文本回复中，OpenClaw Gateway 会识别这个指令，自动将图片/视频作为富媒体消息发送到微信。

六、方法论总结

核心原则：最小化依赖，最大化控制

架构决策树

最终成果

这个项目证明了一件事：站在开源框架的肩膀上，加上一层翻译代理，就能把 AI 的能力无缝注入到任何 IM 平台中。 关键不是写多少代码，而是理解每一层的协议边界，然后在正确的位置做正确的事。