① 一个很容易掉进去的错觉

很多人第一次接触 OpenClaw，会把它当成：

一个「帮你写 Agent 的框架」

于是注意力很快变成：

• Agent 怎么写？
• Tool 怎么接？
• LLM 怎么换？

但这恰恰是理解 OpenClaw 时，最危险的起点。

---

② 一个反直觉的事实

只盯着 Agent / Skill / Tool 这一层，很难看出 OpenClaw 的价值。

把视角拉高到工程系统，结论会变得清晰：

OpenClaw 解决的不是“怎么写 Agent”，而是“怎么运行、约束、调度、治理 Agent”。

---

③ 本文要解决的唯一问题

这篇文章不讲用法细节，只回答一个问题：

OpenClaw 由哪些工程部件组成？每一层负责什么，又刻意不负责什么？

下面从一张完整链路图开始。

---

一、OpenClaw 的完整工程链路

这不是“画得复杂”，而是“原本就复杂”。

接下来我们只做一件事：

👉 一层一层，讲清楚“这一层存在的工程理由”。

---

二、Messaging Surfaces / Clients（消息入口不是对话入口）

这一层包括：

• WhatsApp / Telegram / Slack / Discord
• WebChat / Web UI / mac app / CLI
• automations / cron / 非人工触发

工程关键点只有一句话：

消息 ≠ 会话 ≠ Agent 执行

OpenClaw 在最上层就做了一个强约束：

任何输入，都只是“触发信号”，不是执行指令。

这一步，直接避免了：

• 聊天即执行
• 人类输入和自动任务混在一起
• 多入口状态污染

---

三、Gateway：控制平面（整套系统的大脑）

这是OpenClaw 最不像“Agent 框架”的地方。

从工程视角看，Gateway 更像：

API Gateway + Session Router + Scheduler 的组合体

它只做三类决定：

1. 这个请求能不能进来？
2. 应该进到哪个 session / workspace？
3. 现在要不要真的启动一次 Agent Run？

⚠️ 注意：

Gateway 不运行 Agent，它只决定“要不要运行”。

---

四、Agent Runtime：执行面，而不是“Agent 本体”

很多人把这里当成 Agent，但这是个误解。

在 OpenClaw 里：

Agent Runtime ≈ Agent 的操作系统

它负责：

• 把 Memory / Workspace / Skill 注入执行环境
• 控制 LLM → Tool → LLM 的循环
• 管理 token、步数、生命周期

而 Agent 自己，并没有执行权。

---

五、Workspace / Memory：持久化骨架

这一层解决一个非常现实的问题：

如果 Agent 每次都是“失忆的”，那它永远只能是 Demo。

Workspace / Memory 不是简单聊天记录，而是：

• 执行状态
• 中间产物
• 工具输出
• Skill 绑定信息
• 可审计痕迹

你可以把它理解为：

Agent 的工程工作目录 + 状态快照

---

六、Skills：能力包，而不是“函数集合”

Skill 在 OpenClaw 里有一个非常明确的定位：

能力声明 > 能力实现

一个 Skill 至少包含：

• 它“允许做什么”
• 它“明确不允许做什么”
• 它调用哪些 Tool

Skill 的存在，本质是把“权力”从 LLM 手里收回来。

---

七、Tools：唯一接触真实世界的地方

Tool 是全链路里最危险的一层，因为它能：

• 操作文件系统
• 发网络请求
• 执行命令
• 影响真实世界

也正因为如此，它被：

• 放在最底部
• 必须经由 Skill
• 必须受 Policy 约束

---

八、Tool Policy & Sandbox：工程兜底，不讲智能

这两层只解决一件事：

当 LLM 判断错误时，系统还能不能稳住？

答案是：

• Policy 给确定性
• Sandbox 给隔离
• Elevated 明确提权边界

这里不追求聪明，只追求可控。

---

九、选项解释表：为什么要“拆这么细”？

如果你用的是	通常会遇到的问题
单脚本 / cron	功能膨胀、不可回退
Agent Demo	能跑，但不敢上线
LLM + Tool 直连	一次失误就是事故
OpenClaw 这种结构	前期复杂，长期可控

---

十、边界说明：这篇文章刻意没讲什么

为了保证总览清晰度，本文刻意没有展开：

• Gateway 的具体路由机制
• Agent Runtime 的执行时序
• Skill / Tool 的设计规范
• Policy 的配置策略

这些内容，每一项都值得单独一篇精讲，后续我将逐个拆解。

---

十一、判断路径式 FAQ

Q：这一套是不是太重了？

A：对 Demo 来说，是；对长期运行的 Agent 来说，刚刚好。

Q：能不能只用其中一部分？

A：可以，但你要清楚自己放弃了哪一层的“安全网”。

Q：什么时候你一定需要这种结构？

A：当 Agent 开始

• 自动运行
• 长期存在
• 接触真实系统
• 不再只服务你一个人

---

如果你读到这里，能在脑中清晰地回答：

“一次消息，是如何一步步变成一次受控执行的？”

那你已经跨过了 Agent 工程化 的第一道门槛。

从下一篇开始，我会逐层下钻，

不是讲“怎么用”，而是讲：

这一层，为什么必须这样设计。