从 OpenClaw 这只“龙虾”出发,拆解 AI Agent 的系统设计

今天关于 Agent 的文章很多，但多数内容还停留在几类话题上：

这些当然重要，但它们还不是真正的工程主战场。

当你想把 Agent 放进真实系统里，问题很快就会变成另外三种：

1. 入口怎么统一？用户不只会从一个聊天框里来，还可能从 Telegram、Slack、Discord、WebChat，甚至命令行进入系统。

2. 上下文怎么隔离？私聊、群聊、线程、并发消息混在一起时，怎样切清 session 边界，避免上下文串线？

3. 执行边界怎么守？当 Agent 开始调用终端、浏览器、文件系统和设备能力时，权限、审批、隔离和恢复机制该怎么设计？

所以，一个真实的 Agent 项目，难点早就不只是“模型回什么”，而是：

这个系统能不能稳稳地接住输入、组织状态、调用能力，并安全地把结果送回去。

这也是我们想拆源码的原因。

因为我们需要的，不是一个“看起来很聪明”的样品，而是一个链路完整、边界清楚、能观察到真实工程问题的样品。

OpenClaw 恰好符合这个条件。

它不是一个典型的多租户 SaaS，而是一套偏 Local-First 的个人 AI 助手系统。你可以把它运行在自己的电脑上，也可以部署在自己掌控的主机上。它负责接入多个聊天和设备入口，把消息整理成统一的内部事件，路由到对应的 agent/session，再把结果送回原来的通道。

如果把它压缩成最核心的一条链路，大致就是这样：

聊天渠道 / 设备入口
        ↓
Gateway 接住消息并统一事件
        ↓
Agent Runtime 按 session 执行推理
        ↓
Tools / Plugins / Nodes 提供外部能力
        ↓
结果回到原消息通道

这里强调一下：上面只是帮助理解的概念流程，不是 OpenClaw 的真实 API。

但只看这条链路，你已经能明白它为什么值得拆。

因为它不是单纯的“模型外壳”，而是一套完整系统，至少包含四个值得研究的部分：

也就是说，OpenClaw 不是拿来“崇拜”的，而是拿来“解剖”的。

这一系列不会停留在“它支持哪些功能”，而会顺着一套真实系统的骨架，往里一层层拆。

我们大致会分成四个部分：

1. 感官层：入口如何被统一

重点看它怎样把 20 多种异构聊天平台和设备入口，收敛成统一的消息模型和入口抽象。

2. 脊髓层：控制平面如何组织

重点看 Gateway 为什么采用 WebSocket 控制平面，以及事件、路由、RPC 和会话状态如何协同。

3. 大脑层：运行时如何思考与行动

重点看 Agent Runtime 怎样做上下文注入、会话裁剪、工具调用，以及插件能力如何接入。

4. 肢体层：系统如何触达真实设备

重点看 Nodes 怎样把 macOS、iOS、Android 或其他主机上的本地能力接进来，形成可执行闭环。

读完之后，你至少会更清楚AI Agent的四件事：

1. 一条消息是怎样从聊天入口进入系统，再回到原通道的。
2. 为什么控制平面、会话状态和推理执行最好分层，而不是揉成一个“大一统进程”。
3. 为什么工具调用真正难的不是“能不能调”，而是“边界怎么守、出了事怎么收”。
4. 当你要给系统新增一个通道、一种工具或一个设备能力时，应该改哪一层，不该碰哪一层。

这不是一套“教你怎么调用模型”的文章，而是一套“帮你理解 Agent 为什么能成为系统”的文章。

AI Agent 正在从一个“模型应用话题”，慢慢变成一个“系统工程话题”。

谁能把消息接好、把状态管好、把工具边界守好，谁才更有可能把 Agent 真正带进现实世界。

这也是为什么，我们不满足于再看一个会说话的 龙虾，而是想拆开一个真实项目，看看里面的骨架到底长什么样。

欢迎关注 《Agent 全解：基于 OpenClaw 的工程实践》。

下一讲，我们从最关键的一步开始：

OpenClaw 的整体架构，到底是怎样搭起来的？