1. 微信 OpenClaw 接入 Agent 的真实痛点微信开放 Claw 接入端点之后底层 iLink 协议能跑通 OpenClaw但如果你想把自己写的 Agent 接进去会发现中间缺了一层。OpenClaw 本身更像一个消息通道它负责把微信消息收进来、把回复发出去可它并不管你的 Agent 部署在哪、用什么协议、怎么鉴权。我试过直接把 Agent 的 HTTP 地址填进配置结果消息格式对不上、目标端点要手动写/target、多个 Agent 之间切换全靠改配置折腾一晚上没跑通。weclaw-proxy就是为这个场景写的。它是一个用 Go 实现的极简 Agent 接入网关夹在微信 OpenClaw 和你的 Agent 之间做三件事统一转发、智能路由、统一鉴权。你不需要在每条消息里手动指定/target网关会根据消息内容自动判断该发给哪个 Agent你也不需要给每个 Agent 单独配一套 Key网关统一收口后端 Agent 只认网关的 Key 就行。这篇文章面向的是已经在本地跑 OpenClaw、想接自己 Agent 但被转发和鉴权卡住的人。我会给出可复制的config.toml骨架、TaoToken 统一 Key 的配置方式以及启动后怎么验证网关连通和 Agent 响应。Go 环境、Docker 基础操作会提到但不需要你精通 Go 源码。2. TaoToken 前置统一 Key 与 API 通道在配weclaw-proxy之前先把 Key 和 API 通道准备好。网关本身不产生模型能力它只负责把请求转发到你的 Agent而 Agent 背后调用的模型 API 需要一个统一的入口。TaoToken 在这里的角色就是统一 Key 和 API 通道你申请一个 Key网关和 Agent 都用它不用在多个服务之间来回同步密钥。先到官网注册并拿到 Keyhttps://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content登录之后进控制台创建 API Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentKey 的管理页面在https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 的基础地址是https://taotoken.net/api这个地址不加 UTM 参数直接写进配置里。如果你后面要接 Claude Code 这类编码工具可以看 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content接入文档在https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注意Key 只存在服务端配置文件里不要写进前端代码或提交到 Git 仓库。网关的config.toml建议加进.gitignore。拿到 Key 之后先别急着配网关用模型对话页面确认 Key 本身可用https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content在对话页面发一条测试消息能正常返回就说明 Key 和通道没问题。这一步能帮你排除掉后面网关报错时「到底是 Key 问题还是网关问题」的干扰。3. weclaw-proxy 的 config.toml 骨架与统一 Key 配置weclaw-proxy的配置核心是config.toml。下面这份骨架可以直接复制改掉注释里标了「改这里」的字段就能用。我把它分成三段网关自身监听、上游 OpenClaw 连接、下游 Agent 路由。# weclaw-proxy 配置骨架 # 网关自身监听 [server] # 网关监听地址OpenClaw 往这里发消息 listen 0.0.0.0:8787 # 网关对外暴露的访问 KeyOpenClaw 请求时带这个 gateway_key gw_换成你自己的随机串 # 日志级别debug / info / warn log_level info # 上游微信 OpenClaw 的接入端点 [upstream] # OpenClaw 的 iLink 端点地址按你本地实际端口改 endpoint http://127.0.0.1:9000/ilink # 连接超时单位秒 timeout 15 # 下游你的 Agent 列表支持多个 [[agents]] # Agent 名称路由时用 name assistant # Agent 的 HTTP 地址改这里 url http://127.0.0.1:8001/chat # 该 Agent 的触发关键词命中就走它 keywords [助手, assistant, 帮我] # 是否作为默认 Agent没命中关键词时走它 default true [[agents]] name coder url http://127.0.0.1:8002/chat keywords [代码, code, 报错] default false # 统一 Key所有 Agent 共用这一份由网关注入 [auth] # TaoToken 统一 Key改这里 api_key sk_换成你在 TaoToken 拿到的 Key # API 基础地址固定 base_url https://taotoken.net/api # 注入方式header 或 query inject header # 注入的 header 名 header_name Authorization # header 值前缀 header_prefix Bearer 几个关键点解释一下。gateway_key是网关自己的门禁OpenClaw 发消息时必须带上防止别人直接打你的网关端口。[auth]段是统一 Key 的核心网关在转发请求给下游 Agent 时会自动把api_key按Bearer格式塞进Authorization头你的 Agent 不需要自己再配一遍 Key只认网关转发过来的就行。[[agents]]是数组表可以写多个。keywords是智能路由的依据消息里出现这些词就路由到对应 Agent都没命中就走default true的那个。这样你就不用像以前那样在消息里手写/target coder了。如果你的 Agent 需要区分不同模型可以在 Agent 段里加一行覆盖[[agents]] name assistant url http://127.0.0.1:8001/chat keywords [助手] default true # 该 Agent 单独指定模型不写则用全局默认 model claude-sonnet配好之后把config.toml放到weclaw-proxy同级目录或者用-c参数指定路径。Docker 部署的话把配置文件挂载进去docker run -d \ --name weclaw-proxy \ -p 8787:8787 \ -v $(pwd)/config.toml:/app/config.toml \ amigoer/weclaw-proxy:latestWindows 下路径换成绝对路径比如-v D:\weclaw\config.toml:/app/config.toml。macOS 和 Linux 的 amd64、arm64 都有对应二进制直接跑也行./weclaw-proxy -c ./config.toml4. 启动后验证网关连通与 Agent 响应配置写完启动网关接下来是验证。分两步先确认网关本身活着再确认消息能穿过网关打到 Agent 并拿到回复。第一步检查网关监听端口curl -s http://127.0.0.1:8787/health正常会返回类似{status:ok,agents:2}的内容agents数量和你配置里的[[agents]]个数一致。如果返回连接拒绝说明网关没起来或者端口被占先看日志docker logs -f weclaw-proxy或者直接跑二进制时看终端输出。日志里会打印加载了几个 Agent、监听在哪个地址。第二步模拟 OpenClaw 发一条消息验证路由和统一 Key 注入。用 curl 带上网关 Keycurl -s -X POST http://127.0.0.1:8787/ilink \ -H Content-Type: application/json \ -H X-Gateway-Key: gw_换成你自己的随机串 \ -d {from:test_user,content:帮我写个快排}这条消息里带了「帮我」应该命中assistant这个 Agent。如果返回里能看到 Agent 的回复内容说明整条链路通了。想验证路由切换把content换成「这段代码报错了」应该命中coder。第三步确认统一 Key 真的注入到了下游。在你的 Agent 服务里打一行日志打印收到的Authorization头应该能看到Bearer sk_...的格式。如果 Agent 收到的是空头检查[auth]段的inject和header_name是否写对。第四步回到微信侧给 OpenClaw 发一条真实消息看是否能在微信里收到 Agent 的回复。这一步通了整个接入就算完成。如果微信侧没反应但 curl 能通问题多半在 OpenClaw 的端点配置检查[upstream]的endpoint是否指向了 OpenClaw 实际监听的地址和路径。5. 本篇常见错排查配weclaw-proxy时踩过的坑集中在几个地方我按报错现象列一下。网关启动报address already in use8787 端口被占。改[server]的listen端口或者先lsof -i:8787找到占用进程处理掉。Docker 部署时注意-p映射的宿主机端口别和别的服务冲突。curl 返回 401 或invalid gateway keyX-Gateway-Key和配置里的gateway_key不一致。注意这个 Key 是网关自己的不是 TaoToken 的api_key两者别搞混。网关 Key 你可以随便生成一个随机串TaoToken Key 是sk_开头的那串。消息发出去了但 Agent 没收到先看网关日志有没有转发记录。如果日志显示路由到了某个 Agent 但请求失败检查[[agents]]里的url是否可达用curl直接打一下 Agent 地址。如果日志显示没匹配到任何 Agent检查keywords是否写对以及有没有设default true。Agent 收到请求但报鉴权失败说明统一 Key 没注入成功。检查[auth]段的inject是不是headerheader_name是不是你 Agent 期望的头名。有些 Agent 框架期望X-Api-Key而不是Authorization按实际改。header_prefix如果是Bearer注意后面有个空格。微信侧收不到回复curl 能通但微信不通问题在 OpenClaw 到网关这一段。确认 OpenClaw 配置里的回调地址指向了网关的listen地址和/ilink路径并且带上了网关 Key。如果 OpenClaw 和网关不在同一台机器listen要设成0.0.0.0而不是127.0.0.1。Docker 里连不上宿主机的 Agent容器内的127.0.0.1是容器自己不是宿主机。把 Agent 的url改成宿主机的局域网 IP或者用host.docker.internalmacOS/Windows 支持。Linux 下可以加--add-hosthost.docker.internal:host-gateway。改了配置不生效weclaw-proxy启动时读一次配置改完要重启。Docker 的话docker restart weclaw-proxy二进制的话 CtrlC 再跑。6. 统一 Key 与网关的后续接入网关跑通之后统一 Key 的好处会慢慢体现出来。你新增一个 Agent只需要在config.toml里加一段[[agents]]不用再单独申请和配置 KeyKey 要轮换改[auth]一处所有 Agent 同时生效。对于本地跑 OpenClaw 接微信消息这种场景少一处配置就少一个出错点。如果你后面要把这套接到编码类 Agent 或者长期跑的自动化任务上可以看 Coding Plan 的配置方式它和网关的统一 Key 是同一套通道https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentClaude Code 相关的接入说明在https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content需要新建或轮换 Key 时回到 API Keys 页面操作https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content配置细节以接入文档为准https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content最后提醒一句config.toml里的gateway_key和api_key是两个不同层级的凭证前者管网关门禁后者管模型通道别互相替代。验证的时候先用 curl 打通网关到 Agent再回微信侧测真实消息这样出问题能快速定位是哪一段。