理解 OpenClaw，不能只看它有哪些模块。 更重要的是先问一句：一个可用的 Agent，到底最少需要解决什么问题。

先从第一性原理看 Agent

如果把 Agent 还原到最基础，实际上只需要回答 4 个问题：

1. 它是谁。
2. 它现在要做什么。
3. 它可以调用什么能力。
4. 它做过什么，之后还记不记得。

OpenClaw 的很多设计，本质上都在回答这 4 个问题。

• System Prompt 解决“它是谁”
• 当前输入 解决“它现在要做什么”
• Tools 解决“它可以做什么”
• Memory 解决“它记不记得过去”

所以不要把 OpenClaw 看成一堆配置文件。

它本质上是在给大模型补齐执行任务时最缺的上下文。

System Prompt 不是装饰，而是操作系统

很多人第一次看 OpenClaw，会觉得 AGENTS.md、SOUL.md、USER.md 这些文件有点碎。

但如果从第一性原理看，这些内容其实都在做同一件事：

让模型在开始做事之前，先知道自己应该以什么身份、什么边界、什么偏好行动。

可以这样理解：

• AGENTS.md 是规则层，定义什么能做，什么不能做
• SOUL.md 是行为层，定义说话方式、做事风格、决策倾向
• USER.md 是关系层，定义当前用户是谁、偏好是什么、长期目标是什么
• TOOLS.md 是能力层，定义手和脚能碰到哪里

这些内容拼起来，才是一个真正可工作的 Agent。

如果没有这一层，模型虽然“会说话”，但不会稳定做事。

OpenClaw 的核心，不是更聪明，而是更可控

很多人误以为 Agent 系统的重点是“让模型变强”。

其实不是。

模型本身已经很强，真正难的是让它在复杂任务里保持稳定、少跑偏、能重复。

所以 OpenClaw 的重点不是继续堆能力，而是做 3 件事：

• 把上下文组织好
• 把能力边界说清楚
• 把执行路径拆清楚

这也是为什么很多 Agent 框架最后拼的不是“谁会更多工具”，而是谁更会做 context engineering。

sub-agent 的本质，是把大任务拆成小闭环

spawn sub-agent 看起来很高级，但本质很简单：

一个大 Agent 不可能同时在一个上下文里高质量处理所有细节。

上下文一长，噪音就会变多。 任务一杂，判断就会变形。

所以需要把任务拆出去，让小 Agent 在更小、更干净的上下文里只做一件事。

这件事的价值不在“多开几个模型”，而在于：

• 降低主 Agent 的上下文负担
• 把问题切成更容易判断的小块
• 让每个子任务都有更清晰的输入和输出

如果把主 Agent 比作项目经理，那 sub-agent 更像外包给不同岗位的小执行单元。

主 Agent 不需要知道所有细节，但必须知道每个子任务的目标和结果。

sub-agent 真正节省的是注意力，不只是 token

很多介绍会说 sub-agent 可以节省 token。

这没错，但不是最关键的点。

更关键的是，它节省了“注意力预算”。

因为大模型在长上下文里最容易出现的问题，不是不能回答，而是：

• 抓错重点
• 忘掉限制条件
• 在枝节里打转
• 把前后阶段混在一起

sub-agent 的意义，就是强行把任务隔离。

每个小 Agent 只拿到完成任务所需的最小上下文，然后把结果摘要返回给主 Agent。

这样主 Agent 看到的是“处理后的结果”，不是“整个过程的噪音”。

不能让 sub-agent 无限 spawn

如果放任 sub-agent 继续无上限地生成 sub-agent，系统很快就会失控。

原因也很简单：

Agent 会天然倾向于继续拆任务，因为“再拆一步”总显得更安全。

但拆到最后，常见问题会出现：

• 层级越来越深
• 成本越来越高
• 调试越来越难
• 责任边界越来越模糊

所以一个实用系统必须控制 spawn。

常见做法有两种：

1. 限制最大深度或最大数量。
2. 直接不给子 Agent spawn 权限。

第二种更干脆。

因为从系统设计上说，spawn 本质也是一种工具。 不给它，就是从能力层面切断无限递归。

Skill 不是工具，而是工具的用法模板

Skill 很容易被误解成“另一个 tool”。

其实两者不是一层东西。

Tool 解决的是：

我能做什么动作。

比如搜索、读文件、发请求、执行命令。

Skill 解决的是：

面对某类任务，我应该按什么步骤、什么顺序、什么标准去用这些工具。

所以更准确地说：

• Tool 是原子能力
• Skill 是能力编排
• Workflow 是更大范围的任务路径

从这个角度看，Skill 很像 SOP。

它把零散能力变成可复用的方法。

为什么 Skill 很重要

因为模型最大的波动，不在“会不会调用工具”，而在“会不会按稳定方法做事”。

今天它可能会先搜资料再总结。 明天它也可能直接跳到结论。

这就是纯模型驱动的不稳定性。

Skill 的价值，就是把“经验”固化下来。

一旦某类任务被沉淀成 Skill，系统就不再依赖模型临场发挥，而是优先复用已经验证过的方法。

这会直接带来两个结果：

• 输出更稳定
• 调试更容易

因为出问题时，你知道是工具坏了，还是流程写错了，而不是只能怀疑“模型今天状态不好”。

Memory 解决的不是存档，而是连续性

如果没有记忆，每一轮对话对模型来说几乎都是新的开始。

它只能依赖当前窗口里看得到的内容行动。

这会导致两个直接问题：

1. 它不知道你长期想要什么。
2. 它不知道之前已经做过什么。

于是系统会不断重复解释、重复试错、重复确认。

所以 Memory 的作用不是单纯存资料，而是维持任务连续性。

一个可用的 Agent，至少要有两类记忆：

• 短期记忆：当前任务上下文
• 长期记忆：用户偏好、历史决策、稳定规则

没有短期记忆，任务接不上。 没有长期记忆，关系建不起来。

OpenClaw 本质上在做 context engineering

如果只用一句话总结 OpenClaw：

它不是单纯在“包装大模型”，而是在系统化地做 context engineering。

也就是：

• 该给模型什么上下文
• 什么时候给
• 给多少
• 给到哪一层
• 哪些内容应该长期保留
• 哪些内容应该临时隔离

这件事决定了 Agent 最终是不是像一个稳定的执行系统，而不是一个偶尔灵、偶尔飘的聊天机器人。

可以这样理解 OpenClaw 的整体结构

OpenClaw 可以压缩成下面这个思路：

1. 用 System Prompt 定义身份、规则、风格。
2. 用 Tools 提供外部行动能力。
3. 用 Skill 固化任务方法。
4. 用 sub-agent 做任务拆分和上下文隔离。
5. 用 Memory 维持长期连续性。

这五个东西加起来，才构成一个真正能做事的 Agent 系统。

少了其中任何一个，系统都还能跑。

但要么不稳定，要么不高效，要么不可维护。

最后只记住一句话就够了

OpenClaw 不是在造一个“更会聊天”的模型外壳。

它是在造一个：

有身份、有边界、有方法、有记忆、还能分工做事的执行系统。

这样看，很多概念就不会再散。

它们都不是零件堆砌，而是在共同回答一个问题：

怎样把一个大模型，变成一个真正可工作的 Agent。

贡献者: paiad