技术支持 wechatapi.net最近我一直在做一个比较实际的方向把微信接成 OpenClaw 的一个真实入口。不是做一个简单的“消息转发脚本”而是希望做到下面这种完整链路用户在微信里发消息本地网关接收回调根据私聊 / 群聊 / 会话类型做路由调用 OpenClaw再把结果发回微信这个项目做到后面我越来越觉得真正有价值的不是“机器人脚本”而是“入口层”。一、为什么我会做这个方向现在很多 AI Agent、工作流、自动化平台能力已经很强了大模型调用工具执行工作流编排任务状态管理但这些东西最后经常卡在一个问题上用户到底从哪里进入如果只是网页入口那适合部分场景。但对于很多国内真实业务来说微信仍然是最高频、最自然的入口之一。所以我想验证一件事能不能把微信变成 OpenClaw 的一个可用入口而不是单纯做个演示脚本我手里本身就有微信接口能力所以这次的底层接入是基于wechatapi.net这类接口能力来完成的。对我来说这个项目一方面是技术验证另一方面也在反过来检验微信接口在真实 Agent 场景里的可用性。二、整体架构是怎么设计的我最后没有把它继续写成一个“收到消息就直接调用 AI”的短脚本而是拆成了几层微信回调 ↓ FastAPI 接口层 ↓ 回调解析层 ↓ 消息标准化 ↓ Session 路由 ↓ Worker 队列 ↓ OpenClaw 调用层 ↓ 微信发送层这样设计的原因很简单回调层只负责接和拆路由层负责区分私聊 / 群聊 / 会话执行层负责真正调用 OpenClaw发送层统一做文本 / 图片回发如果把这些全堆在一个函数里项目一旦变复杂基本就很难继续维护。三、先说一个最容易踩的坑微信回调不能按想当然来解析一开始我以为只要拿到Content.string就够了后来发现不是这样。根据真实回调结构至少要关心这些字段TypeNameWxidData.MsgTypeData.FromUserName.stringData.ToUserName.stringData.Content.string而且有几个逻辑一定要做对。1. 是否自己发送不能只看FromUserName而要结合Wxid判断is_selfbool(wxidandfrom_userwxid)2. 是否群消息群消息不能只看一个字段要结合发送人和接收人判断is_groupfrom_user.endswith(chatroom)orto_user.endswith(chatroom)3. 群内真实发送人群消息里真实发送人可能在Content.string前半段ifis_groupandraw_contentand:\ninraw_content:possible_sender,possible_textraw_content.split(:\n,1)ifpossible_sender.startswith(wxid_):sender_wxidpossible_sender actual_textpossible_text.strip()如果这些解析不做严谨后面上下文一定会乱。四、我为什么没有把它继续做成“简单聊天脚本”如果只是最小 demo其实一段逻辑就能跑app.post(/wechat/callback)asyncdefhandle_wechat(request:Request):dataawaitrequest.json()textextract_text(data)resultcall_openclaw(text)send_back(result)return{ok:True}但这种写法有几个明显问题群聊和私聊混在一起没有会话层没有去重没有排队没有白名单后续很难扩展到企微、TG 或别的入口所以我后来改成了网关思维而不是脚本思维。五、我最终保留了哪些关键能力1. 首次命令行初始化第一次运行时直接输入WX_API_TOKENPUBLIC_URL群触发词地区 ID并自动生成config.ini。这里我故意把初始化做得更像“产品入口”因为我越来越觉得如果连接入体验都很糟糕别人根本不会认真评估这套方案。2. 配置自动生成配置文件自动写出并保留中文注释后续可调。3. 白名单私聊不做白名单限制的话很快就会失控。4. 群触发词群里不是所有消息都应该触发机器人至少先用触发词收口。5. 同会话串行不同会话并行这是入口层最关键的一点之一defshard_index_for_session(session_id:str,worker_count:int)-int:hint(hashlib.md5(session_id.encode(utf-8)).hexdigest(),16)returnh%worker_count这样不同用户不会互相阻塞但同一个会话也不会乱序。六、这套东西最核心的瓶颈其实不在微信这一点我一开始判断错了。我最开始以为慢主要是微信回调慢。但后来打日志后发现真正慢的是这一段cmd[openclaw,agent,--session-id,sid,--message,message.strip()]ressubprocess.run(cmd,...)也就是说每来一条微信消息我实际上都在重新起一次 OpenClaw CLI 进程。这意味着每次都要启动进程读取配置恢复上下文初始化 provider再请求模型再退出所以体感上一定比前端慢。这一点后来也让我更明确地认识到微信入口层是值得做的但要想做到真正流畅后面还是要考虑 OpenClaw 常驻化而不是长期依赖 CLI 单次调用。七、这个项目对我最大的价值是什么说实话一开始我以为它最大的价值是“做出一个机器人”。但做到后面我的判断变了。我现在觉得它真正的价值是1. 验证微信是不是一个值得投入的 Agent 入口答案是是。2. 验证微信 API 在真实场景里能不能承接 AI 工作流答案也是可以但前提是入口层要认真做。3. 验证接口能力是不是应该只卖“API”我现在越来越觉得单卖接口太抽象。相比之下把接口能力做成一个可见、可跑、可理解的入口方案更容易让别人看懂价值。这也是为什么我这次做下来对wechatapi.net这种底层能力的看法更明确了底层接口当然重要但真正放大价值的往往是入口方案和场景包装。八、这套方案适合哪些场景目前我觉得比较适合这些微信 AI 助手私域群聊问答知识库入口指令型机器人自动客服业务流程触发器尤其适合已经有模型能力OpenClaw 工作流私有知识库但缺“用户入口”的团队。九、我现在的结论如果只是做一个 demo把微信接上 OpenClaw 并不难。但如果想让它变成真实可用的入口层需要做的事情会比想象中多很多解析回调做好群聊判断过滤自己消息做会话路由控制上下文做并发与顺序处理 CLI 延迟问题不过这件事依然值得做。因为在很多真实业务里用户不会先问你用了什么模型、什么框架。他们先问的是能不能在微信里直接用而这恰恰就是入口层的价值。十、最后这篇文章更多是我当前阶段的技术总结。如果后面我把这套东西再往前推一步我更想继续做两件事把微信入口层做得更稳定把微信 / 企微这类入口能力逐渐抽象成可复用网关如果你也在做类似方向欢迎交流。我这次的底层接入验证主要基于wechatapi.net这类能力做的后面如果我继续往下打磨应该也会围绕“入口层 场景方案”这个方向继续展开。
通过wechatapi对接openclaw终于接好了
技术支持 wechatapi.net最近我一直在做一个比较实际的方向把微信接成 OpenClaw 的一个真实入口。不是做一个简单的“消息转发脚本”而是希望做到下面这种完整链路用户在微信里发消息本地网关接收回调根据私聊 / 群聊 / 会话类型做路由调用 OpenClaw再把结果发回微信这个项目做到后面我越来越觉得真正有价值的不是“机器人脚本”而是“入口层”。一、为什么我会做这个方向现在很多 AI Agent、工作流、自动化平台能力已经很强了大模型调用工具执行工作流编排任务状态管理但这些东西最后经常卡在一个问题上用户到底从哪里进入如果只是网页入口那适合部分场景。但对于很多国内真实业务来说微信仍然是最高频、最自然的入口之一。所以我想验证一件事能不能把微信变成 OpenClaw 的一个可用入口而不是单纯做个演示脚本我手里本身就有微信接口能力所以这次的底层接入是基于wechatapi.net这类接口能力来完成的。对我来说这个项目一方面是技术验证另一方面也在反过来检验微信接口在真实 Agent 场景里的可用性。二、整体架构是怎么设计的我最后没有把它继续写成一个“收到消息就直接调用 AI”的短脚本而是拆成了几层微信回调 ↓ FastAPI 接口层 ↓ 回调解析层 ↓ 消息标准化 ↓ Session 路由 ↓ Worker 队列 ↓ OpenClaw 调用层 ↓ 微信发送层这样设计的原因很简单回调层只负责接和拆路由层负责区分私聊 / 群聊 / 会话执行层负责真正调用 OpenClaw发送层统一做文本 / 图片回发如果把这些全堆在一个函数里项目一旦变复杂基本就很难继续维护。三、先说一个最容易踩的坑微信回调不能按想当然来解析一开始我以为只要拿到Content.string就够了后来发现不是这样。根据真实回调结构至少要关心这些字段TypeNameWxidData.MsgTypeData.FromUserName.stringData.ToUserName.stringData.Content.string而且有几个逻辑一定要做对。1. 是否自己发送不能只看FromUserName而要结合Wxid判断is_selfbool(wxidandfrom_userwxid)2. 是否群消息群消息不能只看一个字段要结合发送人和接收人判断is_groupfrom_user.endswith(chatroom)orto_user.endswith(chatroom)3. 群内真实发送人群消息里真实发送人可能在Content.string前半段ifis_groupandraw_contentand:\ninraw_content:possible_sender,possible_textraw_content.split(:\n,1)ifpossible_sender.startswith(wxid_):sender_wxidpossible_sender actual_textpossible_text.strip()如果这些解析不做严谨后面上下文一定会乱。四、我为什么没有把它继续做成“简单聊天脚本”如果只是最小 demo其实一段逻辑就能跑app.post(/wechat/callback)asyncdefhandle_wechat(request:Request):dataawaitrequest.json()textextract_text(data)resultcall_openclaw(text)send_back(result)return{ok:True}但这种写法有几个明显问题群聊和私聊混在一起没有会话层没有去重没有排队没有白名单后续很难扩展到企微、TG 或别的入口所以我后来改成了网关思维而不是脚本思维。五、我最终保留了哪些关键能力1. 首次命令行初始化第一次运行时直接输入WX_API_TOKENPUBLIC_URL群触发词地区 ID并自动生成config.ini。这里我故意把初始化做得更像“产品入口”因为我越来越觉得如果连接入体验都很糟糕别人根本不会认真评估这套方案。2. 配置自动生成配置文件自动写出并保留中文注释后续可调。3. 白名单私聊不做白名单限制的话很快就会失控。4. 群触发词群里不是所有消息都应该触发机器人至少先用触发词收口。5. 同会话串行不同会话并行这是入口层最关键的一点之一defshard_index_for_session(session_id:str,worker_count:int)-int:hint(hashlib.md5(session_id.encode(utf-8)).hexdigest(),16)returnh%worker_count这样不同用户不会互相阻塞但同一个会话也不会乱序。六、这套东西最核心的瓶颈其实不在微信这一点我一开始判断错了。我最开始以为慢主要是微信回调慢。但后来打日志后发现真正慢的是这一段cmd[openclaw,agent,--session-id,sid,--message,message.strip()]ressubprocess.run(cmd,...)也就是说每来一条微信消息我实际上都在重新起一次 OpenClaw CLI 进程。这意味着每次都要启动进程读取配置恢复上下文初始化 provider再请求模型再退出所以体感上一定比前端慢。这一点后来也让我更明确地认识到微信入口层是值得做的但要想做到真正流畅后面还是要考虑 OpenClaw 常驻化而不是长期依赖 CLI 单次调用。七、这个项目对我最大的价值是什么说实话一开始我以为它最大的价值是“做出一个机器人”。但做到后面我的判断变了。我现在觉得它真正的价值是1. 验证微信是不是一个值得投入的 Agent 入口答案是是。2. 验证微信 API 在真实场景里能不能承接 AI 工作流答案也是可以但前提是入口层要认真做。3. 验证接口能力是不是应该只卖“API”我现在越来越觉得单卖接口太抽象。相比之下把接口能力做成一个可见、可跑、可理解的入口方案更容易让别人看懂价值。这也是为什么我这次做下来对wechatapi.net这种底层能力的看法更明确了底层接口当然重要但真正放大价值的往往是入口方案和场景包装。八、这套方案适合哪些场景目前我觉得比较适合这些微信 AI 助手私域群聊问答知识库入口指令型机器人自动客服业务流程触发器尤其适合已经有模型能力OpenClaw 工作流私有知识库但缺“用户入口”的团队。九、我现在的结论如果只是做一个 demo把微信接上 OpenClaw 并不难。但如果想让它变成真实可用的入口层需要做的事情会比想象中多很多解析回调做好群聊判断过滤自己消息做会话路由控制上下文做并发与顺序处理 CLI 延迟问题不过这件事依然值得做。因为在很多真实业务里用户不会先问你用了什么模型、什么框架。他们先问的是能不能在微信里直接用而这恰恰就是入口层的价值。十、最后这篇文章更多是我当前阶段的技术总结。如果后面我把这套东西再往前推一步我更想继续做两件事把微信入口层做得更稳定把微信 / 企微这类入口能力逐渐抽象成可复用网关如果你也在做类似方向欢迎交流。我这次的底层接入验证主要基于wechatapi.net这类能力做的后面如果我继续往下打磨应该也会围绕“入口层 场景方案”这个方向继续展开。
