开篇

在第一次接触 OpenClaw 时，会下意识地把它和 Claude Code 放在一起比较。🧐 它们确实有很多相似点：都会调用模型、都会使用工具、都会进入多轮 agent loop、都会处理上下文、记忆和权限问题。

但如果继续往下拆，会发现：

Claude Code 更像一个面向开发者的 coding agent runtime；而 OpenClaw 则是一个面向多入口、多设备、多权限场景的通用 Agent ，它真正走进了用户的现实世界。

OpenClaw 构建了一套极具工程美学的 Harness ，用四层边界清晰的架构，解决了能力开放与行为可控之间的核心矛盾。

这篇文章会根据 OpenClaw 的这四层核心技术架构，分为以下四个部分～

• Channel（通道层）：多端入口的万能转接头

• Gateway（网关层）：最核心的总调度

• Node（节点层）：安全手脚与沙箱

• Agent Runtime（运行时）：核心大脑

Channel 层：接入世界的「万能转接头」

OpenClaw 就像是我们的一个私人助理，平时可以在微信里和它闲聊，在飞书里给它派发工作文档，偶尔还可以在 Slack 或者终端里给它发指令。

但是，不同渠道过来的信息格式是五花八门的。就像如果我们周围的人都是来自不同的国家，每个人说着不同的语言，每和一个人对话，就要切换一种语言，长时间下来我们的大脑可能就会要爆炸了。🤯

为了解决不同渠道消息格式不同的问题，OpenClaw 设计了Channel（通道适配层）。👇

Channel 就像是出国旅行时带的「万能转接头」。

无论国外的插座是英标、美标还是欧标（微信、飞书、Discord），只需要带一个核心的排插，然后在前面加一个特定国家的转换插头就好了。

在代码层面，Channel 将所有的接入方式分为了三类：

Bot API：走官方正规军路线。像飞书、Slack、Telegram 等平台自身就开放了完善的 Webhook 服务。Channel 只需要调用官方 SDK，把飞书的消息格式翻译成 OpenClaw 内部格式。

Bridge（桥接）：针对那些没有官方开放接口的平台，通过第三方协议或客户端进行桥接注入（本方法有风险，了解即可～）。

Native：本地原生的 Webchat 或 CLI 终端，遵循系统最原生的内部协议。

Channel 层的存在，就是将外部世界与内部处理进行了一个完美隔离：Agent Runtime（Agent运行时，是第四层技术，之前的文章也有详细拆解过～给 Claude Code 一个任务，它的内部发生了什么？） 永远不需要知道这条消息是来自张三的微信，还是李四的飞书。它只负责接收标准化的信封，处理完毕后，再塞回信封丢出去。

👉 这种可插拔的设计，极大降低了 OpenClaw 拓展渠道的边际成本。

Gateway 层：维持秩序的「中央前台」

如果把上面的 Channel 比作一家公司大门的安检员，那 Gateway 就是这家公司的中央前台。👇

它是 OpenClaw 整个系统的总控中枢。（最核心的部分）

无论是外部客户端发来的消息，还是内部节点执行完工具的反馈，都必须经过 Gateway 来进行统筹调度。

要理解 Gateway，首先要理解它底层使用的通讯协议：WebSocket。

👉 传统的 HTTP 协议就像写信。

客户端发一封信（请求），服务器回一封信（响应）。如果客户端不发问，服务器永远不能主动搭话。😶

但 Agent 的工作流往往是长周期的。比如你让它“去爬取知乎的最新大模型文章”，这可能需要跑 5 分钟。如果用写信的模式，你要么一直干等，要么不停写信去问：“好了没？”。

👉 而 WebSocket 就像是打电话。

信道一旦建立，双方随时可以开口说话。模型流式输出的每一个 Token（SSE 推送）、系统后台定时触发的任务进度（Event），都可以通过这个双向通道随时广播给前端。

基于这种双向奔赴的通道，Gateway 负责了以下最核心的四件事情：

1. 路由：今天上午在微信上让它帮忙装了个环境，下午在飞书上让它查个文档。

Gateway 需要精准知道，这条消息应该丢进哪个上下文（Session）里，跨渠道绝不能串台。

2. 鉴权：不是谁来了都能改写本地文件的。

Gateway 通过 Loopback（仅本机访问）或 SSH Tunnel（临时授权）等暴露层级，严格把控着每一位访客的通行证。🪪

3. 广播：Agent 在后台吭哧吭哧干活时，执行到哪一步了？是正在规划，还是在调用浏览器？

Gateway 负责将这些状态同步分发给对应的前端，缓解用户的等待焦虑。

4. 状态与断线重连：如果你在地铁上拿手机跟它聊天，信号断了怎么办呢？

Gateway 维护了消息的队列与版本状态，网络恢复后，它能自动把断档期间的消息一条不落地补发过去。

👉 Gateway 解决了异步长周期任务在产品体验上的割裂感。它不仅仅是一个网关，更是用户体验的稳定器。

Node 层：物理世界的「安全手脚与沙箱」

如果问：“把 OpenClaw 运行在本地，你最大的担忧是什么？”

大概率答案会是失控。比如一觉醒来，发现它为了清理硬盘空间，把电脑里的重要文件全删掉了。😨

这第三层 Node 就是执行这些命令的员工（能力节点）。为了防止员工捅出大篓子，OpenClaw 引入了沙箱执行机制。👇

可以用一个通俗的例子来理解沙箱的隔离级别：

• 同进程（如同在一个大开间办公）：大家共用一套上下文，效率高，但一个人感冒（崩溃），全公司遭殃；任何人都能偷看别人的屏幕。
• Docker 容器（如同隔音会议室）：我们把需要执行危险命令的 AI 关进一个密闭的会议室。它在这个房间里怎么删东西、怎么改文件，都只能在指定的挂载目录里发生，不会影响到外面的宿主机系统。
• 虚拟机 VM（如同完全不同的大楼）：这是最底层的隔离，连操作系统内核都换了。

OpenClaw 的 Node 层通常是通过第二层 Docker 容器级别的隔离，为外部提供各种 Tools（工具调用能力）。

并且这里的 Node 不仅仅是简单地跑几行 Python 脚本，还包括比如浏览器工具（Playwright）：

以前让 AI 看网页，通常是截图+OCR。但多模态模型对像素坐标的理解往往是模糊的，这就很像让一个盲人看红绿灯。

那 OpenClaw 的 Node 是怎么做的呢？

它提取了浏览器运行时的A11y Tree（无障碍访问树/节点树）：

把网页解析成一个个带有标记的按钮（比如：[按钮 A1: 写邮件]、[按钮 A2: 发送]）。模型不再看像素坐标，而是直接阅读这些结构化的树状节点，然后下达指令：“点击 A1 按钮”。（这很像是给盲人看的专用书籍，可以让盲人摸着凸起阅读。）

除此之外，还有文件读写工具，它从白名单校验，到操作留痕，再到超大文件的分页截断返回（防止把上下文撑爆）。

Node 层的设计，是对之前文章从 Claude Code 看 Anthropic 的 Managed Agents 中提到的「脑手分离」的最佳实践：模型只负责出指令，Node 拿着鉴权通过的 Token 在沙盒里执行。

👉 不越权、不搞破坏，是 AI 走向实用的底线。

Agent Runtime：驱动一切的「思考大脑」

经过了 Channel 通道、Gateway 前台、Node 员工，现在来到了 OpenClaw 的心脏：Agent Runtime（运行时）。

这和上一篇文章给 Claude Code 一个任务，它的内部发生了什么？中拆解的 Claude Code 的 Agent Runtime 本质上是相同的，它就是一个不断自我驱动的 While Loop 循环：

1. 组装上下文：把用户的要求、历史记录、可用工具列表揉碎了拼进 Prompt。

2. 调用模型：问大模型“下一步该干嘛？”

3. 判断走向：

• 模型说：“我要调用浏览器搜一下。” -> Runtime 就去触发 Node 层的工具。

• 拿到浏览器结果后，将 tool_result 追加进上下文，回到第一步继续循环。

• 模型说：“我已经做完了，答案是 XXX。” -> 结束循环，把结果通过 Gateway 推给前端。

随着工具调用的增加，比如报错日志、几万行的 JSON 文件，上下文窗口很快就会逼近极限。

Agent Runtime 中会有两个子机制：Memory（记忆系统）与Compaction（上下文压缩）。

Compaction（压缩）：当当前会话的长度达到最大容量的 70% 时，Runtime 会自动触发一次紧急救援。它并不是简单地砍掉前半部分，而是基于结构化策略进行压缩。

👉 比如，对于冗长的工具返回结果，它只保留工具名和状态（成功/报错）；对于用户的核心诉求，则一字不落。

SubAgent（子代理隔离）：当主 Agent 发现任务过于繁杂时，它会派生出一个子代理。子代理在一个全新的、干净的上下文里去处理脏活累活（比如查几十篇论文），处理完后，只把提炼后的核心结论交还给主 Agent，子代理随之销毁。

👉 这种物理级别的隔离，极大地降低了跨步骤通信的噪音。

最后

总结一下～

Channel 负责拉客入场，Gateway 负责居中调度，Node 负责撸起袖子干活，最后 Agent Runtime 负责深度思考。

OpenClaw 让我们看到了一个真正的 Harness Engineer：不要假设模型不犯错，而是去建立 Gateway 来鉴权，用 Node 沙箱来阻断，用 Runtime 压缩来抵抗遗忘。

它让 AI 真正走出聊天框，安全地接入用户的现实世界。🥰