OpenClaw 最近的变化,不是更炫,而是更像一个能长期工作的系统

我最近看 OpenClaw 的主干变化，最大的感受不是“又出了一个大功能”。

真正值得注意的是另一件事：它正在从一个能调工具、能跑任务的 Agent 框架，往一个能长期在线、能处理异常、能留下证据、能跨通道协作的执行系统演进。

很多人看 AI 产品，习惯盯模型、盯效果、盯一次性的惊艳演示。但真正把 Agent 放到工作流里的人都知道：演示里的聪明，只是入场券；日常里的稳定，才是生产力。

我的判断很直接：OpenClaw 最近的重点，不是更炫，而是更可靠。

先看一个真实问题

一个人通过微信发指令，让 OpenClaw 去打开浏览器、查本地仓库、整理文章、写入公众号草稿、发送预览。

这个过程看起来像一句话。

但系统里面其实串着一整条链路：消息入口、任务调度、浏览器状态、文件生成、图片插入、公众号保存、预览发送、再回到微信通知。

任何一环不稳，最后都会变成一句很刺耳的话：

“你不是说已经完成了吗？为什么后台还是空的？”

我现在越来越觉得，Agent 真正进入工作流以后，最难的不是让它会做事，而是让它做完以后能被验证。

这也是 OpenClaw 最近这些变化值得写的原因。它们表面上是很多 bugfix，放在一起看，其实是在补四层骨架：执行入口、多通道交付、过程证据、权限边界。

第一层：执行入口更稳

最近主干里有一批和浏览器自动化、命令解析有关的修复：browser act 对嵌套 request 字段的兼容、managed Chrome CDP listener 从陈旧状态恢复、slash skill 多行参数保留等。

这些听上去不像发布会上会讲的东西。

但它们对真实使用非常关键。

因为 Agent 真正进入工作，不是只问一句“帮我总结一下”，而是要打开网页、点击按钮、填写表单、处理登录态、读页面状态、把多行参数传给技能，然后继续下一步。

任何一个字段丢失、连接陈旧、参数被截断，都会让一次自动化任务从“看起来很智能”变成“半路卡死”。

我对这类修复的评价很高：它们不是小修小补，而是在补 Agent 的手和脚。

工具调用不是魔法。它本质上是一个很长的执行链条。

链条越长，越不能只靠模型“聪明”。

第二层：多通道开始讲交付纪律

OpenClaw 最近还在持续修 Telegram、WhatsApp、Slack、Feishu、Discord、Mattermost 这些通道里的细节：Telegram 超时后的 handler 恢复、WhatsApp 已读回执 socket 卡死边界、Slack outbound reply 事件、Feishu 自己发出的 receive event 去重、Discord guildId 解析、Mattermost 线程证据不被覆盖。

这些变化背后是一件事：多通道 Agent 最难的不是接入平台，而是处理平台的脾气。

微信、飞书、Slack、Telegram、Discord，每个通道都有自己的消息顺序、回执、线程、重投、权限和异常。

人类聊天时这些只是“小问题”，但 Agent 一旦成为执行层，这些就是交付事故。

比如重复处理一条消息，可能会重复发通知；线程证据丢了，任务就无法追溯；通道自己回环触发，系统就可能把自己的话当成用户指令。

老板真正担心的不是“这个 Agent 会不会接 Slack”，而是“我交代出去的事，会不会跑错地方、漏掉结果、或者把错误当成完成”。

这就是为什么我更愿意把 OpenClaw 看成一个执行系统，而不是一个聊天机器人。

聊天机器人回答问题就结束了。

执行系统要对交付负责。

第三层：记忆和用量变成证据链

另一条很明显的线，是 memory、usage、history 相关能力在增强。

比如 memory_search 在临时模式下的行为修复，gateway sessions.usage 改为全量聚合，session history repair 清理 partialJson 流式残留，失败的 agent turn 写入聊天历史，prompt 释放后还能保住并发 transcript 更新。

这说明 OpenClaw 对“过程证据”的重视在上升。

一个长期工作的 Agent，不能只给最终答案。它必须能回答：

• 我刚才为什么这么判断？
• 我调用了哪个工具？
• 哪一步失败了？
• 失败有没有记录？
• 用量是不是算准了？
• 历史是不是被半截流式 JSON 污染了？

人可以凭感觉说“我记得我做过”，系统不行。

系统必须能留下证据，能恢复现场，能让下一轮执行接得上。

我踩过的坑是：只要一个自动化系统不能复盘，它迟早会退化成人工盯日志。

表面上是 AI 提效，最后变成“人盯 AI 有没有出错”。

这就失去意义了。

第四层：权限边界重新收紧

最近还有几类变化值得注意：无 key Web Search provider 默认 opt-in 的修正，open DM 工具进入安全审计，插件 CLI backend 的 provider policy 解析修复，ClawHub skill 来源 provenance 信任链修正，proxy capture 与 SQLite rollback journal 的私有/安全路径补齐。

这条线很关键。

Agent 越强，权限就越危险。

它能读消息、能开网页、能跑命令、能发通知、能调用外部 provider、能安装 skill，也就意味着它必须知道什么能做、什么不能做、什么必须显式授权、什么必须留痕。

能力越强，边界越要清楚。

我不太喜欢只讲“AI Agent 能帮你省多少时间”的文章，因为那只讲了一半。

另一半是：如果权限、审计、确认关口、外部搜索策略没有设计好，省下来的时间很可能会变成更大的风险。

过去很多 AI 工具的问题，是先追求能力扩张，再回头补安全边界。

OpenClaw 最近这些动作更像是在提前做一件事：让能力增长时，权限系统和审计系统也一起长。

这才是能放进个人工作台、企业环境、自动化流程里的基础。

可以直接复用的四层检查法

如果你也在把 Agent 接进日常工作流，我建议先别急着问“它能不能更智能”。

先问四个更朴素的问题。

第一，执行入口是否稳定。

浏览器、命令、文件、剪贴板、表单、登录态，这些看起来不高级，但它们决定任务能不能跑到最后。

第二，交付通道是否可追。

一条消息从哪里来，发给了谁，线程有没有保存，失败有没有回执，这些必须说得清。

第三，过程证据是否完整。

不要只看最终答案。要看工具调用、失败轮次、用量、历史、截图、保存后回读。

第四，权限边界是否收紧。

默认能做什么，必须确认什么，外部搜索是否显式启用，插件来源是否可信，敏感文件是否进入审计范围。

我会用一个很简单的模板判断一个 Agent 系统有没有进入可托付阶段：

能执行，只是第一步。 能交付，是第二步。 能复盘，是第三步。 能守边界，才敢长期运行。 

这篇文章不是说 OpenClaw 已经完美。

恰恰相反，我更看重的是它开始认真处理那些“不性感”的问题：超时、回执、线程、历史、权限、策略、恢复、审计。

这些问题不适合做 demo，却决定系统能不能每天用。

真正的 Agent 竞争，最后不会只看谁的模型更会说话。

会看谁能在真实工作里少出错、能追溯、能恢复、能协作、能被信任。

一句话总结我对 OpenClaw 最近动态的判断：

表面是修 bug，实质是在给 Agent 补工业化骨架。

下一步我会继续看三件事：

1. 多通道交付能不能继续减少串线和重复；

2. memory / wiki / session history 能不能成为更稳定的第二大脑；

3. 浏览器、文件、消息、权限这些执行边界，能不能进一步产品化。

如果这些都继续往前走，OpenClaw 的意义就不只是一个工具。

它会更像一个可以长期驻场的个人执行层。