把 Agent 放进生活：OpenClaw 的四个核心技术

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

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

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

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

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

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

为了解决这个问题，OpenClaw 设计了 Channel（通道适配层）。它就像是出国旅行时带的万能转接头——无论国外的插座是英标、美标还是欧标，只需要带一个核心的排插，然后在前面加一个特定国家的转换插头就好了。

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

• Bot API：走官方正规军路线。飞书、Slack、Telegram 等平台自身就开放了完善的 Webhook 服务，Channel 只需要调用官方 SDK，把消息格式翻译成 OpenClaw 内部格式。
• Bridge（桥接）：针对那些没有官方开放接口的平台，通过第三方协议或客户端进行桥接注入（这个方法有风险，了解即可）。
• Native：本地原生的 Webchat 或 CLI 终端，遵循系统最原生的内部协议。

Channel 层的存在，就是将外部世界与内部处理进行了一个完美隔离：Agent Runtime 永远不需要知道这条消息是来自张三的微信，还是李四的飞书。它只负责接收标准化的信封，处理完毕后再塞回信封丢出去。

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

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

如果把 Channel 比作一家公司大门的安检员，那 Gateway 就是这家公司的中央前台，它是整个系统的总控中枢。无论是外部客户端发来的消息，还是内部节点执行完工具的反馈，都必须经过 Gateway 来统筹调度。

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

传统的 HTTP 协议就像写信——客户端发一封信，服务器回一封信，如果客户端不发问，服务器永远不能主动搭话。但 Agent 的工作流往往是长周期的，比如你让它去爬取某个网站的最新文章，这可能需要跑 5 分钟。用写信的模式，你要么一直干等，要么不停写信去问「好了没？」。

而 WebSocket 就像打电话——信道一旦建立，双方随时可以开口说话。模型流式输出的每一个 Token、系统后台定时触发的任务进度，都可以通过这个双向通道随时广播给前端。

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

1、路由：今天上午在微信上让它帮忙装了个环境，下午在飞书上让它查个文档。Gateway 需要精准知道这条消息应该丢进哪个 Session 里，跨渠道绝不能串台。

2、鉴权：不是谁来了都能改写本地文件的。Gateway 通过 Loopback（仅本机访问）或 SSH Tunnel（临时授权）等暴露层级，严格把控着每一位访客的通行证。

3、广播：Agent 在后台干活时执行到哪一步了？是正在规划，还是在调用浏览器？Gateway 负责将这些状态同步分发给对应的前端，缓解用户的等待焦虑。

4、状态与断线重连：如果你在地铁上拿手机跟它聊天，信号断了怎么办？Gateway 维护了消息的队列与版本状态，网络恢复后能自动把断档期间的消息一条不落地补发过去。

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

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

如果问「把 OpenClaw 运行在本地，你最大的担忧是什么？」，大概率答案会是失控——比如一觉醒来，发现它为了清理硬盘空间，把电脑里的重要文件全删掉了。

Node 就是执行这些命令的员工（能力节点）。为了防止员工捅出大篓子，OpenClaw 引入了沙箱执行机制。可以用一个通俗的例子来理解隔离级别：

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

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

而且这里的 Node 不仅仅是简单地跑几行 Python 脚本。以浏览器工具为例：以前让 AI 看网页，通常是截图加 OCR，但多模态模型对像素坐标的理解往往是模糊的，这很像让一个盲人看红绿灯。

OpenClaw 的做法是提取浏览器运行时的 A11y Tree（无障碍访问树），把网页解析成一个个带有标记的按钮（比如 [按钮 A1: 写邮件]、[按钮 A2: 发送]）。模型不再看像素坐标，而是直接阅读这些结构化的树状节点，然后下达指令「点击 A1 按钮」。这很像给盲人看的专用书籍，可以让盲人摸着凸起阅读。

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

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

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

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

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

它本质上就是一个不断自我驱动的 While Loop 循环：

1. 组装上下文：把用户的要求、历史记录、可用工具列表揉碎了拼进 Prompt。
2. 调用模型：问大模型「下一步该干嘛？」
3. 判断走向：模型说「我要调用浏览器搜一下」，Runtime 就去触发 Node 层的工具，拿到结果后把 tool_result 追加进上下文，回到第一步继续循环；模型说「我已经做完了」，就结束循环，把结果通过 Gateway 推给前端。

随着工具调用的增加，比如报错日志、几万行的 JSON 文件，上下文窗口很快就会逼近极限。Agent Runtime 中有两个子机制来应对：

Compaction（压缩）：当当前会话的长度达到最大容量的 70% 时，Runtime 会自动触发一次紧急救援。它并不是简单地砍掉前半部分，而是基于结构化策略进行压缩——比如对于冗长的工具返回结果，只保留工具名和状态；对于用户的核心诉求，则一字不落。

SubAgent（子代理隔离）：当主 Agent 发现任务过于繁杂时，会派生出一个子代理。子代理在一个全新的、干净的上下文里去处理脏活累活（比如查几十篇论文），处理完后只把提炼后的核心结论交还给主 Agent，随之销毁。这种物理级别的隔离，极大地降低了跨步骤通信的噪音。

最后

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

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

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