这件事最开始其实没有想得那么复杂。
前两天我看到 OpenClaw 已经可以接微信，我第一反应是：既然它能接，那我们现在这一套 ChatGPT、LMN516、Control Tower，是不是也可以放进微信里？我平时本来就一直在微信里，很多时候手机也在手边。如果我突然想到一个问题，或者想让 AI 帮我做一件事，最自然的入口其实不是重新打开一个后台，也不一定非得打开 ChatGPT，而可能就是发一条微信。
我之前口述的时候有时会把它说成 OpenCloud，实际这次接的是 OpenClaw。它在这条链路里更像一个 Agent Runtime：负责把微信里的消息接进来，维持会话，再把后面的模型、工具和系统能力接上去。
一开始的目标很简单：先让它能回。
但真正做下来，我发现“微信里能出现一句 AI 回复”和“我真的愿意把它当成日常入口”，中间还有不少东西。
第一步：先把微信这条路跑通
最开始我们做的事情，本质上还是一个聊天链路：
我
↓
微信
↓
OpenClaw
↓
模型
↓
OpenClaw
↓
微信先不谈 Agent，也不谈执行。只看最基本的一件事：我在微信里发一句话，后面能不能收到这句话，模型能不能理解，然后回复能不能再回到微信。
这一步做通的时候其实已经挺有意思。因为以前我对“AI 在哪里”这件事还是会有一点 App 思维：ChatGPT 在 ChatGPT 里，微信在微信里，LMN516 在网站里。接通以后，这几个边界就没有原来那么硬了。
AI 不一定非得有一个自己的聊天界面。
微信也可以只是一个入口。
这跟我之前把 Gmail、快捷指令、Mac 剪贴板这些东西接进 LMN516 的感觉很像。只要中间能力开放出来，入口本身就可以换。
不过能回以后，问题很快就开始出现。
第二步：真正麻烦的是反复测试
刚接通的时候，我最关心的是“它有没有回复”。但测试几轮以后，标准马上就变了。
我开始关心：
- 为什么有时很快，有时明显慢；
- 为什么同样一句话，有时很顺，有时像卡住；
- 为什么系统明明完成了一个 turn，微信里却没有可见回复；
- 如果连续聊几轮，上下文能不能保持；
- 如果开始调用工具，整体还会不会稳定。
今天我就遇到过一条很典型的提示：
I finished the turn, but it did not produce a visible reply.
它其实非常能说明问题。
从模型或者 Agent 的内部来看，这一轮可能“完成”了；但对我来说，没有看到回复，就等于没有完成。
这两个“完成”不是一回事。
以前做 LMN516 的 Control Tower 时，我们就一直在解决这个问题：代码写了不等于上线，上线不等于我看到了，我看到了也不一定等于我验收。现在把 AI 放进微信，类似的问题又出现了一次。
模型完成
≠
Agent 完成
≠
消息成功返回
≠
我在微信里真的看到所以后来我们不再只盯着模型有没有正常结束，而是开始看完整链路。
第三步：我开始很在意响应时间
把 AI 放在网页里时，慢几秒有时候还能忍。但放进微信以后，体感会变得很敏感。
因为微信本来就是一个即时通讯工具。
我发一句话以后，下意识会期待它像一个人在聊天一样，很快有反应。哪怕最后答案质量一样，4 秒和 12 秒的感觉也完全不一样。
所以有一段时间我们一直在压响应时间。我当时希望尽量把普通对话压到大约四秒左右，不是说每一次都必须精确四秒，而是希望它进入一种“聊天时不会明显打断节奏”的范围。
后来我越来越清楚，响应时间也不能只看模型。
一次微信里的回复，中间至少可能经过：
微信收消息
↓
OpenClaw 收到并整理会话
↓
模型推理
↓
必要时调用工具 / MCP
↓
拿到结果
↓
组织最终回复
↓
OpenClaw 发回
↓
微信变成可见消息任何一段慢，最后都会变成我的“怎么还没回”。
这件事后来也改变了我们看性能的方式。以前容易问“模型快不快”，后来会问“整条链路里到底是哪一段在花时间”。
如果只是模型慢，那是模型问题；如果是工具调用慢，就要看工具；如果回复已经生成但没有成功显示，那又是消息回传的问题。
第四步：额度第一次变成了产品体验
再往后，另一个问题开始明显起来：额度。
一开始我可能会把额度理解成一个后台数字，或者某个 API 的限制。但当微信成为日常入口以后，额度会直接变成体验的一部分。
比如连续测试、上下文变长、Agent 需要做更多判断，都会增加消耗。额度不足或者触发限制以后，表现出来的可能不是一个很漂亮的“额度不足”页面，而是回复变慢、失败、重试，甚至某一轮没有正常返回。
这时候我才觉得，额度不是一个财务问题，它也是架构问题。
如果只是偶尔玩一下，额度不够最多就是今天先不用。
但如果我希望微信真的成为一个长期入口，那就要开始考虑：
- 普通聊天和重任务是不是要走不同模型；
- 哪些东西应该直接读 LMN516，而不是每次重新推理；
- 哪些上下文应该压缩；
- 工具结果能不能复用；
- 失败以后怎么重试，什么时候不该重试；
- 最终要不要给不同类型的请求设不同预算。
这些问题现在都还没有完全做完，但它们已经从“以后再说”变成了真实的问题。
第五步：我后来发现，只能聊天其实还不够
真正让这件事发生变化的，是我们开始问：既然已经在微信里了，它为什么只能回答我？
比如我在微信里说：
“帮我看一下现在还有哪些任务没完成。”
如果它只是根据聊天上下文猜一遍，那它仍然只是一个 Bot。
我更希望它真的去读 Control Tower。
我再说：
“这个问题你继续做。”
它不应该只回复“好的，我来处理”，而应该真正建立一次执行，把任务交给 Worker，然后把状态再回来告诉我。
这时候目标就从“微信聊天机器人”变成了“微信里的 AI Agent”。
这两者最明显的差别，不是后者更会说话，而是后者有一个真实世界。
Bot 的世界基本在当前对话里。
Agent 的世界里还应该有：
任务
状态
工具
权限
执行
证据
失败
重试
结果于是我们开始把 OpenClaw 接到 LMN516 已经存在的 Control Tower MCP。
第六步：微信开始接进 LMN516 的任务系统
这部分是这次接入里我觉得最关键的一步。
因为 LMN516 本来就已经有一套 Q、RUN、Control Tower、Worker 的结构。
一个需求先变成 Q，一次真实执行有自己的 RUN。Worker 做了什么，做到哪一步，有没有阻塞，有什么证据，最后有没有完成，都可以围绕同一个任务继续追踪。
所以我们没有再给微信单独造一套“微信任务系统”，而是让 OpenClaw 去接已经存在的那套能力。
现在这条链路更接近：
我
↓
微信
↓
OpenClaw
↓
LMN516 MCP
↓
Control Tower
↓
Q / RUN
↓
Heavy Worker
↓
真实执行（代码 / GitHub / LMN516）
↓
状态与证据回写
↓
微信8 月 21 日，我们先给 Control Tower MCP 增加了 list_open_items。
这件事看起来只是多了一个工具，但它很重要。因为从这一步开始，外部 Agent 不需要靠聊天记忆猜“我还有什么事没做”，而是可以直接读取 LMN516 当前未解决的事项、阻塞、需要用户做什么、关联了哪些 RUN。
之后又补了 report_run_status。
它解决的是另一半：Worker 不只是被派出去，还要把真实执行状态和证据写回来。
比如：
RUNNING
VERIFYING
WAITING_USER
BLOCKED_EXTERNAL
DONE
FAILED这些状态不是为了好看，而是为了避免微信里出现一种很假的体验：
“好的，我已经开始处理了。”
然后什么都没有发生。
我现在越来越不喜欢这种“语言上的执行”。
如果一个 Agent 说自己开始做，那系统里最好真的有一个 RUN；如果它说完成，那最好有证据；如果做不了，也应该告诉我卡在哪里。
到写这篇文章的时候，它还没有完全结束
这一点我觉得也应该写清楚。
现在并不是说整个 WeChat Agent 已经 100% 收口，然后我回来写一篇成功案例。
实际状态更像是：
- 微信和 OpenClaw 的基础聊天链已经跑起来；
- LMN516 的 MCP 已经可以让外部 Agent 查询未完成事项；
- RUN 状态回传能力已经写进实现；
- Q ↔ RUN 的归属、终态不能倒退、证据记录这些规则也已经补上；
- 但 Production 里的完整暴露和真正端到端的 WeChat → Worker → 状态回传 smoke，还在继续验证。
这其实更接近我们真实做东西的方式。
不是等所有事情都完美以后，再事后写一条非常顺的路线。
真正的过程里会有接通、失败、测试、误判、限额、响应时间、重新拆问题，然后目标也会变。
这件事对我真正有意思的地方
如果只从功能上说，这件事可以被总结成一句很普通的话：
“我把 AI 接入微信了。”
但我自己现在更在意的是另外一件事。
以前我把不同系统看成不同地方：
微信 = 聊天
ChatGPT = AI
GitHub = 代码
LMN516 = 网站
Control Tower = 任务现在它们开始慢慢变成：
微信 = 入口
OpenClaw = Agent Runtime
LMN516 = 我的系统
Control Tower = 任务与状态
Worker = 执行
GitHub / API / 数据库 = 能力这样以后，“我在哪儿”就没那么重要了。
我可以在微信里说一句话，但真正发生的事情可能在 LMN516、GitHub、数据库或者别的服务里。
对我来说，这跟之前把 Gmail 接进 LMN516、把快捷指令接进小泡泡，其实是一条线。
我开始越来越不把一个 App 当成一个封闭的地方，而是把它看成一个入口或者一种能力。
微信这次比较特殊，是因为它离我太近了。
如果以后我不用专门打开一个开发后台，也不用切换很多页面，只是在微信里说：
“看一下那个任务现在到哪儿了。”
“继续。”
“这个通过了。”
“把这个想法先记下来。”
然后后面的系统真的知道我在说哪一件事，并且能做、能回、能留下证据，那它就已经不是把一个聊天机器人塞进微信这么简单了。
它更像是：我自己的系统，终于长出了一个我每天都会使用的入口。
现在这条路还没有完全走完。
但至少已经从“能不能接进微信”走到了另一个问题：
接进去以后，它到底只是陪我聊天，还是能真正成为我系统里的一部分。