万字拆解 OpenClaw，为什么很多同学玩不起来？因为他不是软件是Runtime 啊

有同学反馈偏工程侧的解读看不懂，所以我们出一篇偏产品视角的解读。

最近关于 OpenClaw 的讨论，已经越来越不像一个普通开源项目了。

有人把它当成数字员工框架，有人把它当成 Agent 时代的操作系统，也有人把它理解成一套 Skills 容器、或者一个介于消息系统、工作流引擎和 LLM runtime 之间的混合体。

其实这些说法都不算错。

但如果你真的站在生产落地、实际使用的视角去看，OpenClaw 最值得研究的，反而不是它到底能不能帮你发消息、跑浏览器，而是：

OpenClaw 到底是什么，以及它为什么会在 Demo 里那么惊艳，到了真实环境里却总是暴露各种问题

这件事如果不讲清楚，我们就很容易被两种声音带偏：

一种是神化。觉得它已经是数字员工、AI 军团、Agent OS，仿佛装上以后就能一人成军。

另一种是贬低。觉得它不过就是个会调工具的聊天机器人，没什么了不起，甚至连个稳定的浏览器自动化都做不好。

这两种看法，其实都不准确。它真正有价值的地方，在于它把一件以前大家只在 PPT 和演讲里说的事情，第一次以一个可运行系统的形式摆在了所有人面前：

如果我们想让 AI 不只是答一句话，而是真的去接消息、用工具、记状态、拆任务、跨渠道工作，那么这个系统到底该怎么长。

而它的问题，也恰恰暴露在这里。很多用户最常见的抱怨，比如：

1. 聊几轮就失忆
2. 长任务跑到一半突然崩
3. 浏览器控制时灵时不灵
4. 飞书、QQ、外部 API 偶发报错，而且报错经常不准
5. 明明在线，却像死了一样没有回音
6. 一个看起来不复杂的任务，成本却高得离谱
7. 一听要给它本地文件权限、网络权限、消息权限，马上开始紧张
8. …

如果你只把这些当成体验问题，那就有点低估这件事了。因为这些抱怨背后，并不是几个零散 bug，而是 OpenClaw 作为一个 Agent Runtime，在上下文治理、运行时可靠性、成本模型、安全边界、控制面设计上的真实情况。

所以这篇文章，我想回答三个更重要的问题：

• 第一，OpenClaw 从产品本质上到底是什么。
• 第二，一条消息进入系统后，整个运行时到底发生了什么。
• 第三，为什么这些设计在 Demo 很惊艳，但一进入真实环境就会暴露出一整套架构性问题。

OpenClaw 到底是什么

很多人第一次接触 OpenClaw，会被表层体验带偏。

你在 Telegram、飞书 等 IM 里发一句话，它开始思考、开始调用工具、开始写东西、开始回你，于是很多人会下意识把它理解为：

1. 一个更强的聊天机器人。
2. 或者一个装了很多工具的 AI 助手。
3. 或者一个 Workflow 加外壳。
4. 或者一个数字员工。

但如果站在产品架构的视角，你会更愿意把 OpenClaw 定义为：一个常驻的 Agent Runtime + Gateway。

这个定义非常关键，因为它决定了你后面理解 OpenClaw 的方式。

它不是聊天机器人

聊天机器人主要优化的是问答质量、对话体验、人格表现。但 OpenClaw 的核心责任不是把一句话答漂亮，而是：

1. 接消息
2. 做路由
3. 管会话
4. 调工具
5. 写状态
6. 做持久化
7. 失败后继续恢复
8. 下次还能接着跑

也就是说，它面对的问题不是会不会说，而是能不能持续干活。

它不是传统工作流引擎

工作流引擎强调的是预先编排、确定性强、路径可控。你先把节点画好，把条件写好，把流程排好，然后它按你的图跑。

但 OpenClaw 更像是一个装满 Skills 和 Tools 的执行体。你给它一句目标，它自己去判断：

1. 这是不是普通问答
2. 这是不是执行型任务
3. 需不需要调用工具
4. 调哪个工具
5. 要不要拆任务
6. 要不要生成子 Agent
7. 什么时候收口

它不是把每一步预先写死，而是让模型在运行时做判断。

我们知道 Workflow 强在可控。Agent 强在灵活。而 OpenClaw 显然是后者，所以他就会带着 Agent 显著的特性。

它也不是操作系统

很多人喜欢把 OpenClaw 说成 Agent 时代的操作系统。这个说法在传播上当然很爽，但如果严格一点，它离操作系统还差得很远。

它确实具备一些像操作系统的观感：

1. 长期在线
2. 多入口接入
3. 多工具调用
4. 会话与状态管理
5. 权限和控制面
6. 子任务分发

但它缺的恰恰是操作系统最贵的那部分：

1. 强隔离
2. 强一致性
3. 强权限边界
4. 进程/容器级安全域
5. 系统调用级审计
6. 完整的回滚与恢复语义

所以更准确的叫法，可以把它理解成：

一个以消息接入、工具执行、会话管理和状态沉淀为核心的智能运行时控制层

这也是为什么 OpenClaw 官方文档里会出现很多看起来不像聊天产品的概念：session management、compaction、memory flush、token use、gateway auth、device pairing、security audit。

因为它干的本来就不是替你答一句话的活，而是在试图承担一部分智能控制层的职责。

OpenClaw 是数字员工？

现在最常见的说法是 OpenClaw 是一套数字员工框架，因为他最强大的特征就是可以装载各种 Skills，而 Skills 的本质却是员工们的 SOP。

以前如果你要做一个能干活的 AI 员工，往往要拼很多层：

1. 前面是消息入口，比如飞书、钉钉、Web Chat
2. 中间是规则和调度，比如 Workflow、脚本、RPA、定时器
3. 后面是执行能力，比如浏览器自动化、API 调用、文件处理、代码执行
4. 再加一层 LLM，让整个系统看起来更聪明一点

而 OpenClaw 想做的，就是把这几层尽量收进一个统一的运行时里。也就是：

消息入口、会话管理、上下文系统、技能系统、工具系统、多 Agent 协作、结果分发和状态持久化，全部放到一个底座里统一处理。

从产品视角看，以前的大模型更像一个会说话的人。而 OpenClaw 想做的是一个会接活、会调用资源、会记进度、会继续跑的执行系统。

所以它才会让那么多人第一次真正产生一种感觉：这东西不像聊天，像员工了。

但也正因为它做的是这件事，它面对的问题天然就不是聊天产品级别的，而是运行时系统级别的。

而运行时系统，最大的难点是稳定性治理。

OpenClaw 的整体结构，

从工程角度出发，我会把 OpenClaw 理解成五层：

第一层，用户入口层

这是大家最容易看到的一层。包括：

1. Telegram
2. Slack
3. Discord
4. QQ
5. 飞书
6. 钉钉
7. CLI
8. …

这些入口本质上只是你从哪里跟它说话。这也许也是 OpenClaw 能火的关键，他让 AI 离我们更近了，解决了最后一公里问题。

只不过，最为关键的微信生态，现在阶段依旧难以直接打通

第二层，Gateway 控制面

这是 OpenClaw 的真正骨架之一。它负责：

1. 鉴权
2. 配对
3. 连接管理
4. 路由
5. 队列
6. 会话归属
7. 设备与客户端范围
8. 控制面诊断

很多人以为 OpenClaw 最大的问题会出在 AI 本身，比如回答不准、不会用工具。

但真实情况是很多用户还没来得及验证它聪不聪明，就已经先被安装、配置、认证、配对、升级这些事情折腾崩了。

因为它背后不是一个单机聊天程序，而是一整套控制系统。这也是之前大家能500元安装小龙虾赚大几十万的原因。

第三层，消息处理层

这一层负责把所有异构入口统一成系统能处理的内部对象，并完成：

1. 标准化
2. 去重
3. 防抖
4. 排队
5. 会话键生成
6. 出站分发

这是 OpenClaw 能同时接 飞书、钉钉、Telegram、Web Chat 等通道的原因。

第四层，Agent Runtime 层

这一层是 OpenClaw 最核心的部分。

它负责：

1. 系统提示词组装
2. 工作区注入
3. 上下文装配
4. 技能与工具选择
5. agent loop
6. 子 Agent 生成
7. 记忆与压缩
8. 执行过程管理

这一层决定了它像不像一个会干活的系统。

第五层，基础设施层

包括：

1. 会话转录 JSONL
2. memory 文件
3. 索引 SQLite
4. 结构化日志
5. 诊断与监控
6. 沙箱与权限策略

这一层平时最不显眼，但真正影响生产可用性。你可以把它理解成：

表面上，OpenClaw 是一个能在聊天软件里跟你对话的 AI。

实际上，它底下是一个在持续处理消息、组织状态、调度执行的运行时系统。

消息来了，到底发生了什么

一旦你接受了这个视角，后面很多问题就都容易理解了。

为了把系统讲清楚，我们还是沿用一个简单例子，小钗在 钉钉 里发了一句：

调研一下最近火爆的 AI Agent 框架，整理成报告
重点关注 LangChain、AutoGen 和 Dify

表面上，这只是一次用户输入。但站在运行时视角，这句话其实意味着一个完整系统开始工作。

第一站：消息进门

—— OpenClaw 首先解决的不是智能，而是入口问题。

从产品设计角度看，OpenClaw 最先要解决的问题，不是怎么生成答案，而是怎么把来自不同世界的消息，先变成同一种东西。

Telegram 的 webhook、Slack 的事件、钉钉/飞书 的消息推送、Web Chat 的 websocket，它们天然就是不同协议、不同字段、不同认证方式……

如果直接把这些方言喂给后面的 Agent，系统一定会越来越复杂。所以 OpenClaw 做的第一件事，就是标准化。

不管消息从哪个入口来，都会先被统一包装成一个内部消息对象。这里面会包含：

消息正文
给 Agent 的正文
会话键
来源渠道
账户 ID
线程 ID
回复引用信息
媒体路径
是否有命令权限
网关 scope 等元数据

你不用记这些字段名，但你要理解一件事：OpenClaw 不是在直接处理聊天内容，而是在处理消息该去哪。

也就是说，OpenClaw 关注的不是 用户说了什么，而是 系统要如何接收、路由和执行的一个工程对象。

这是它能多渠道工作的根本原因。但问题也从这里开始。因为你越想统一，越容易把不同渠道的特殊性漏掉。

比如某个渠道独有的线程语义、某个渠道的权限系统、某个渠道的错误码，在统一过程中可能被抽象得太粗。

于是用户最后看到的现象就会很奇怪：

1. 明明是飞书的权限报错，系统给出的却像 timeout；
2. 明明是引用上下文没带进来，结果表现成 它怎么突然理解错了。

这也是平台抽象的天然代价：统一输入，带来了效率；也带来了信息折损。

第二站：工程队列

在 OpenClaw 里，一条消息进来以后，并不是马上丢给模型，而是先要经过好几道非常工程化的关卡：

1. 规范化

系统会先做一轮清洗和补全。目的是两点：安全与可用性。

比如用户文本里如果故意伪造某些系统标记，系统要把它们降成不可信内容；再比如命令权限，如果没有明确授权，默认就不让它执行高风险命令。

这一步很容易被忽略，但它其实非常重要。因为 IM 世界里，prompt injection、引用伪造、上下文污染，本来就是常态。

2. 去重

IM、Webhook、网络重连，都可能让同一条消息被重复投递。如果没有去重机制。最轻的是多花钱；严重一点，是重复发消息、重复执行工具、重复写文件、重复触发外部动作。

所以 OpenClaw 会为每条入站消息生成一个幂等键，短时间内如果发现是一条重复消息，就直接拦住。

你可以把这一步理解成：可以看出，这些就是些很常规的工程稳定性处理，对主干逻辑其实没意义，但实际运行时候又都离不开，后面也是如此。

3. 排队

OpenClaw 不会让同一个会话里的多条消息同时乱跑。它会给会话分车道，相同 sessionKey 的消息必须串行执行。

这看上去有点笨，但这是在用效率换一致性，因为如果同一个会话并发跑两件事，会发生很多问题：

1. 转录文件同时写
2. 上下文互相覆盖
3. 工具状态串线
4. 历史和结果错位

所以 OpenClaw 策略是排队，以求避免上下文撕裂。这也解释了为什么很多人会觉得 OpenClaw 有时“慢半拍”。

不是它没收到，而是它在排队。它首先在做的，是保护会话的一致性。

第三站：路由

我们之前说过，对于 Agent 产品，路由系统一定是其重中之重，对于 OpenClaw 也是如此。

消息进入系统后，马上要回答一个问题：这句话该交给谁处理？也就是路由。

如果 OpenClaw 只有一个 Agent，这件事很简单；但 OpenClaw 天生支持多 Agent、多通道、多会话。这加剧了复杂度：

你可以有客服 Agent、编程 Agent、日程 Agent，它们共享同一个底座，但职责不同。

所以路由本质上不是找一个机器人回复，而是在做两件事：

• 第一，确定归属。
• 第二，确定隔离。

说得更通俗一点，就是：谁负责这件事，谁对这段上下文负责。

找到目标 Agent 后，系统会生成一个 sessionKey。它决定了三件大事：

1. 哪些历史会被带进来
2. 哪些记忆会被复用
3. 哪些消息必须串行执行

你可以理解成，sessionKey 决定的是“语境边界”。而这一步，也是 OpenClaw 为什么既强大又脆弱的源头之一。

因为一旦你把很多持续交互压在一个 session 里，你就必须长期保存、长期压缩、长期恢复这段上下文。

这已经不是聊天机器人会面对的问题了。这是一个长期运行系统才会面对的问题。

很多用户以为所谓失忆，只是模型忘了。但很大一部分时候，问题不是模型忘了，而是：

1. 会话键不一致
2. 历史没读到正确位置
3. 转录缺了关键轮次
4. 会话边界被搞乱了

所以会话管理在 OpenClaw 里是核心底座。其实我们在之前的文章里就说过 多 Agent 出现的原因是为了降低工程复杂度，但多 Agent 的会话问题，本身就足够复杂了，所以如果不是必须，还是单 Agent 好了，多数人玩不明白的。

第四站：上下文组装

这里接着前面说，如果说 OpenClaw 有一个最核心又最容易出问题的能力，那一定是上下文组装。

因为它不是普通问答。它不可能只把用户当前这句话发给模型。它要塞进去的东西非常多：

系统提示词
Agent 角色和规则
bootstrap 文件
Skills 描述
Tools schema
历史对话
工具调用记录
工具返回结果
压缩摘要
长期记忆
当前用户消息
入站元数据

为什么要塞这么多？因为 OpenClaw 必须让模型知道：

你是谁。
我是谁。
我能用什么工具。
我之前做过什么。
哪些规则必须遵守。
哪些文件和记忆要参考。
哪些结果已经拿到。
当前这句话和前面是什么关系。

如果没有这些，Agent 根本跑不起来，但问题也恰恰在这里：

Agent 能运行，靠的是长上下文；Agent 容易崩，也恰恰因为长上下文

Bootstrap 文件系统

OpenClaw 会把一些工作区文件直接注入上下文，比如：

1. AGENTS.md
2. SOUL.md
3. TOOLS.md
4. IDENTITY.md
5. USER.md
6. MEMORY.md
7. 以及一些初始化或心跳相关文件

这套机制的好处很明显：它让人格、规则、工具说明、长期记忆，变成一种工程对象，而不是你每次都要手打 prompt。

但它的问题也很明显：这些文件一多、一长，system prompt 就会非常胖。

再加上 tools schema、skills 描述、历史消息、工具返回结果，首轮上下文就可能已经大得离谱了。

所以很多人会觉得 OpenClaw还没开始干活，token 就先烧掉一大半。这不是错觉，而是它的系统结构本来就容易这样。

上下文爆了

为了不让上下文被打爆，OpenClaw 会做两件事：

• 第一，压缩历史，也就是 compaction。
• 第二，把重要内容提前写入 durable memory，也就是 memory flush。

这套思路本身没问题，甚至可以说是 Agent Runtime 的标准动作。问题在于：

1. 历史不是只有聊天记录。
2. 还有工具结果。
3. 而工具结果往往比聊天记录多得多。

一段 JSON、一个网页内容、一整份文件、一次浏览器抓下来的结构化数据，都可能比几轮聊天大得多。所以 OpenClaw 最核心的矛盾，其实就是一句话：

它要靠长上下文活，太长了又不行…

这也是为什么“失忆”在架构层面至少有四层含义：

• 第一层，历史没带进来。
• 第二层，历史带进来了，但在 compaction 时把关键约束压缩丢了。
• 第三层，关键内容本来应该进入 durable memory，但 memory flush 没跑好。
• 第四层，tool result 太大，直接把 prompt 预算挤爆，系统进入异常恢复路径。

所以失忆不是单点 bug。它是整个上下文爆炸后的外部表现。

第五站：模型决策

当上下文准备好之后，模型才真正开始干活。

但 OpenClaw 里的模型更像是一个运行时里的调度者。它要判断：

这是普通问答还是执行任务
是否需要工具
用哪个工具
要不要继续追问
要不要拆成子任务
要不要创建子 Agent
什么时候收口
什么时候把结果返回给用户

这就是 Agent 和普通聊天模型最大的差别：模型更像是会说话的人、Agent 模型更像是会做决策的人。

好处当然很明显：

1. 流程更灵活。
2. 能力更开放。
3. 任务不需要预先写死。
4. 系统可以在运行时根据情况选择动作。

但我们之前就说过，这是一种Token 换 架构的策略，他的缺点也明显，就是不稳定：

1. 每一次灵活，都会带来额外的不确定性。
2. 每一次决策，都会多一条分支。
3. 每一次分支，都会多一点上下文、多一点成本、多一点错误可能。

这种不稳定性，只在效果演示里看不到（我也会删除…），在生产里会立刻感受到。

第六站：工具调用

在群里讨论时，粉丝抱怨 OpenClaw 最多的几个地方，基本都集中在这里：

1. 浏览器控制不稳定
2. IM 偶发报错
3. 明明授权了却提示没权限
4. 外部 API 报错经常不准
5. …

如果你从单点功能看，会觉得这些是具体 bug。但如果你从系统设计看，就会发现它们更像同一个问题在不同地方的投影。

因为 OpenClaw 调用的不是一个本地函数，而是一整条桥接链。

以浏览器为例，很多人以为就是一句 browser.click()。但实际上发生的是：

这条链只要有一段状态没同步好，用户看到的就是：

1. 浏览器怎么没反应。
2. 一直 timeout。
3. 明明装了扩展却连不上。
4. 授权了却说没权限。

所以这些问题的本质，不是某个 SDK 写得烂，而是：

当一个 Agent Runtime 想统一管理多外部系统时，真正难的不是调通，而是把每个系统的状态语义、错误语义、重试语义，都准确地翻译回来

这也是为什么工具桥接这一层真正要补的，不只是更多适配器，而是四个更底层的能力：

1. 连接状态管理
2. 错误分类
3. 重试策略
4. 跨桥接层状态一致性

如果这四件事不稳，工具再多都只是增加不确定性。

第七站：多 Agent

其实非常令我诧异的一点是：OpenClaw 支持多 Agent。

因为，过往我在实践的时候，发现多 Agent 维护成本比较高，其次单 Agent 多数情况下够用了。

但随后想想，对于 OpenClaw 这种复杂场景的 Agent 来说，不用多 Agent 好像也说不过去，这里的核心就是：当主 Agent 接到一个复杂任务时，它不一定自己全干，而是可以拆给子 Agent。

比如一个调研任务，主 Agent 可以把 LangChain、AutoGen、Dify 分给三个子 Agent，最后再自己汇总。

这套模式看上去很强？因为它把一个模型能做什么，升级成了一个 Agent 组织能做什么。你可以把它理解成：

1. 主 Agent 是总负责人。
2. 子 Agent 是专项小组。
3. 会话隔离是项目隔离。
4. 任务回写是周报机制。

听起来是不是很像一个真实组织？这也是为什么很多人第一次接触时会被它震撼。因为它第一次让数字员工组织化协作这件事，有了具体可运行的样子。

但这里也有很大的问题。多 Agent 一旦进入真实环境，立刻会暴露出新的治理难题：

1. 谁来控制子 Agent 数量
2. 谁来限制递归深度
3. 谁来限制并发
4. 谁来隔离权限
5. 谁来处理子 Agent 失败
6. 谁来观测到底是哪一层挂了
7. 谁来决定何时删除、何时保留子会话

所以多 Agent 的问题从来都不是能不能做，而是：它原本是为了解决复杂任务，结果自己很快又变成了一个新的复杂系统。

多 Agent 就不是生产力，而是放大器：尤其是架构复杂性，但是决定会话如何传递就很令人头疼。

第八站：半死不活

很多系统的稳定性问题，不在于会不会错，而在于错了之后有没有人知道。

OpenClaw 现在最典型的生产问题之一，就是这种隐形死亡：

1. 它看起来没挂，实际上已经卡死。
2. 还在线，但不说话。
3. 没有明确报错，但也不继续执行。
4. 前端还在等，用户还以为它在思考。

这类问题为什么烦？因为它不是立刻失败，而是进入一种很尴尬的半死亡状态：

1. 用户会误判。
2. 重试会叠加错误。
3. 同一任务可能被重复执行。
4. token 可能继续烧。
5. 系统表面活着，实际上已经没有价值。

这就是典型的可观测性和恢复问题，一个成熟运行时，至少应该让人知道：

1. 消息收到了没有
2. 是在调工具，还是在压缩上下文
3. 是已经失败，还是在恢复
4. 这次 run 到底停在了哪一步
5. …

如果这些都没有，用户就只能靠猜，而一个靠猜才能使用的系统，是很难进入生产的。

第九站：烧钱

其实，关于 OpenClaw 为什么费 Token 我们前面大概也聊到了，只不过很多同学确实也会疑惑：为什么简单问题也那么贵？

1. 明明是个不复杂的任务，结果 token 消耗很夸张。
2. 明明只是整理几封邮件，结果成本像在跑一个重型系统。

很多人因此得出一个简单结论：模型太贵了。但如果从架构上看，这肯定是错的。

与其说 OpenClaw 贵，不如说 Agent 这种模式就是贵，OpenClaw 又是当前 Agent 的代表

当前 OpenClaw 每次执行，带上的东西太多了：

system prompt
bootstrap 文件
工具说明
skills 描述
历史对话
工具结果
记忆内容
当前消息
再加上工具重试、多轮循环和压缩恢复

所以它的成本不是“问一次多少钱”，而是“这整条执行链要花多少钱”。还是那句话：

Agent 成本不是模型问题，而是架构问题。

真正决定你烧多少钱的，很多时候不是你买了什么模型，而是你的 runtime 让模型看了多少无效东西、重复做了多少无效动作。

这也是为什么很多看起来很酷的 Agent 系统，最后难以大规模落地，费钱啊！

第十站：安全问题

实话实说，OpenClaw 并不比 Manus 高明，但他最近风头就是大，其价值，就建立在高权限之上：

1. 它能看本地文件。
2. 能调用脚本。
3. 能连外部网络。
4. 能接消息渠道。
5. 能做浏览器自动化。
6. 能触达很多真实世界的资源。

这当然很强,但问题也恰恰在这里：能力越强，安全边界就越重要。

如果权限隔离、工具沙箱、文件校验 这些地方没做好，它带来的就不只是效率提升，还可能是真正的安全风险。比如：

1. 会不会读到不该读的文件。
2. 会不会把内部数据发出去。
3. 会不会被 prompt injection 利用去执行危险操作。
4. 会不会在下载、写文件、调用外部 API 的过程中出问题。
5. 会不会因为一个恶意 skill，把整个环境变成供应链入口。

所以很多人一谈 OpenClaw 安全，就容易走向两个极端：

• 一种是轻视，觉得这不就是个本地工具。
• 另一种是夸张，觉得这东西绝对不能碰。

当前的情况是，轻视的人是足够的轻视，但他们并不在自己电脑上玩；夸张的是绝对的夸张，但并不影响他们发文说真叼…

严格来说，贾维斯类 AI 权限大是必然，只不过关于这里的安全问题，我们确实没准备好，必定 Agent 才火多久…

第十一站：部署得蛋疼

当前，很多人还没来得及验证 OpenClaw 聪不聪明，就已经先被安装、配置、认证、代理、配对、升级这些事折腾崩了。

因为 OpenClaw 不是那种装完就跑的单机小工具。它背后还有一套控制系统在支撑：Gateway、认证、插件系统……

说实话，OpenClaw 更像个极客体验工具，他对一般同学来说，门槛还是过高了，只不过这里倒是不用怕，国产的各种龙虾已经在路上了，比如智谱、腾讯：

惊艳的 Demo

在与粉丝交流的过程中，其实发现了一些问题，比如：

1. 系统装得起来，却不一定稳得住。
2. 今天能跑，升级后又未必还跑得动。
3. 一个 1008 pairing required，能直接把一堆人拦在门外。

这类问题不够性感，也不适合拿来宣传，所以大家都看不见，或者多数人是不关注小龙虾的，比如我老婆从来不问 OpenClaw 的事，他依旧每天刷剧…

到这里，我们其实已经可以总结出一个核心判断了。

OpenClaw 在 Demo 里为什么惊艳？因为 Demo 的环境通常是：

干净的
短链路的
单任务的
短会话的
权限简单的
外部系统少的

而真实环境则完全相反：

脏数据多
链路长
会话长
工具多
权限复杂
外部系统多
升级频繁
成本敏感
稳定性要求高

换句话说：Demo 展示的是能力上限，真实环境考验的是系统下限。

而 OpenClaw 当前暴露出来的那些问题，本质上都不是“小 bug”，而是架构矛盾在真实环境里的自然放大。

可以把它收敛成六个核心问题：

1. 上下文治理问题

失忆、溢出、空回复、循环失败，本质上都是上下文预算失控。

2. 桥接一致性问题

浏览器不动、权限错判、外部调用偶发失败，本质上都是跨边界状态语义不一致。

3. 可观测性和恢复问题

最可怕的不是报错，而是半死不活。 没有明确错误，也没有明确恢复。

4. 成本模型问题

OpenClaw 贵，不是因为模型贵，而是因为运行时让模型看了太多无效东西。

5. 安全边界问题

它之所以强，是因为它触达了真实资产； 所以安全边界必须比聊天产品硬得多。

6. 控制面与长期维护问题

装得起来不等于稳得住。 升级、配对、路径差异，会不断制造可用性债务。

这六个问题，才是真正决定 OpenClaw 能不能从很火走向可交付的关键。而就我现在的判断：

OpenClaw 已经不是一个玩具级 Agent 了，但它距离成熟的生产级 Agent Runtime，还差的恰恰是最贵、最难的那部分工程稳定性，这需要时间打磨

什么时候用 OpenClaw

最近几个同学在群里讨论：OpenClaw 会不会淘汰 Coze、Dify、LangChain、AutoGen 这些东西？

我自己的判断是：它们不是同一品类，所以与其谈淘汰，不如谈分工。

如果你满足下面几条，OpenClaw 往往更有价值：

1. 你的入口在 IM 或多入口统一。你希望像给同事发消息一样发指令，而不是打开一个专门工作台。
2. 你需要触达本地或设备能力。比如文件、脚本、浏览器、本地服务、消息通道。
3. 你愿意为治理付费。你能做隔离、最小权限、审批、审计、监控、成本预算。

以及不适合的典型场景：

1. 你需要多租户、强审计、强 SLA 的企业应用平台
2. 你需要高度确定性的固定流程，而不是运行时决策
3. 你无法接受给 Agent 本地文件、网络、消息权限
4. 你的团队没有能力维护控制面和运行时

这时候你可能更适合 Dify、Coze 这类平台化产品，或者直接用 Workflow/RAG/服务编排去做。

其实最现实的不是替代，而是组合，实际上这件事也正在发生…

结语

—— OpenClaw 的价值，不只在于它展示了 Agent 可以怎么跑；更在于它把 Agent 真正难的地方，提前暴露给了所有人

OpenClaw 让我们第一次比较完整地看见：

一个能持续接消息、持续调用工具、持续管理会话、还能拆任务和组织子 Agent 的系统，到底长什么样。

它也让我们第一次比较残酷地看见，这个系统真正难的，不是模型够不够聪明，而是：

上下文怎么治理
工具状态怎么桥接
失败后怎么恢复
成本怎么收敛
权限怎么收口
控制面怎么做稳
长期维护怎么产品化

总而言之，OpenClaw 是很值得深入研究的，大家继续，我也再看源码去了…