编者按： 当我们惊叹于OpenClaw仿佛"活过来"般的自主行为时，我们究竟在惊叹什么------是模型真的拥有了某种意识，还是我们被某种精妙的工程机制"欺骗"了？
今天为大家带来的这篇文章，作者给出了一个清晰而坚定的答案：OpenClaw 的"自主性"并非源于神秘的涌现能力，而是一套严谨、可解释的事件驱动架构所带来的工程成果。
本文深入技术底层，为读者抽丝剥茧地解析了 OpenClaw 的核心架构。文章首先厘清了 OpenClaw 的本质 ------ 一个围绕集中式控制平面构建的事件驱动状态机，而非具备感知能力的后台大脑。随后，作者详细拆解了网关作为"中央路由器"如何通过会话键实现隔离，利用 lane-aware FIFO 队列避免并发冲突，以及如何通过统一的 WebSocket 协议协调多端通信。最为关键的是，文章揭示了让智能体产生"活着"这一错觉的真实原因：心跳、Webhooks 等多种输入类型触发的事件循环，而非某种灵光一现。最后，作者还从安全角度出发，针对这一高权限系统的潜在风险提供了务实的加固建议。
作者 | Vinoth Govindarajan
编译 | 岳扬
大多数 AI 智能体的演示看起来神奇无比，就像魔法一样。
而 OpenClaw 给人的感觉是真正的"自主运行"。
但在技术底层，它并非依靠魔法 ------ 而是一套严谨的事件驱动机制。
OpenClaw 是一款可自托管、开源的个人 AI 助手，与典型的聊天应用相比，它更贴近你的操作系统。它不在浏览器标签页里与你对话，而是直接接入你正在使用的通讯渠道（WhatsApp、Telegram、Slack、Discord、iMessage、WebChat 等），并能通过工具执行实际的操作。
很多人把 OpenClaw 描述为"自主的"或"始终在线的"。最简单的理解方式是：
OpenClaw 的"主动行为"并不是因为它有"自我意识"或像人一样会"睡醒然后开始思考"。它之所以给人主动感，是因为它能接收的输入类型远不止你的消息 ------ 并且通过一个持续的循环对所有这些输入进行处理。
这便是其架构设计的奥秘所在。
01 OpenClaw 是什么（以及不是什么）
它是什么：
- 网关（控制平面），负责接收来自四面八方的各类事件并进行路由分发。
- 智能体运行时（agent runtime），能够执行"轮次操作"：调用大语言模型、使用工具、写入状态，并回复。
OpenClaw 的官方文档将网关 WebSocket 协议描述为统一的控制平面，所有客户端（命令行界面、网页界面、macOS 应用、iOS/Android 节点等）都通过它连接。
它不是什么：
- 一个有感知能力的系统。
- 一个在后台持续运转的推理大脑。
如果它看起来像是"在凌晨 3 点灵光一闪"，通常只是因为某个定时器、计划任务、网络钩子（webhook）或系统钩子（hook）在凌晨 3 点触发了一个事件，然后智能体执行了一轮正常的处理流程。
02 整体架构：以网关为中心的星型拓扑
如果你更喜欢可视化内容，下面这张图展示了整个架构：
OpenClaw 本质上是一个围绕集中式控制平面构建的、事件驱动的、会话隔离的单写入状态机。
核心思想：网关（Gateway）是流量调度器和唯一事实来源。智能体运行时（agent runtime）是负责"思考与执行"的工作单元。
03 网关：中央路由器（以及事实来源）
OpenClaw 运行着一个持续在线的网关守护进程，负责维持所有连接并协调整个系统。文档中明确指出：
- 所有会话状态均由网关管理
- UI 客户端应通过查询网关来获取信息，而不是直接读取本地的会话文件
3.1 会话（Sessions）：隔离是刻意的（并且是可配置的）
当你从不同的场景（私信与群聊、Telegram 与 Slack 等）与 OpenClaw 对话时，你肯定不希望发生意外的上下文泄露。OpenClaw 通过会话键（session keys）来建模这一需求。
会话模型（session model）非常灵活，但其默认逻辑是：
- 每个智能体实例，默认会拥有一个"类似于私信"的主会话，这个会话通常被命名为 main。
- 针对群组/频道/话题则有独立的会话
- 可选的"安全私信模式"，按发送者/频道/账号隔离私聊会话，避免不同用户间的上下文泄露
一个简单的思维模型：
如果你部署 OpenClaw 不只是给自己用，那么安全私信模式就很重要 ------ 因为默认情况下，私信的作用域会让所有私信共享同一个会话上下文以保持连续性，除非你另行配置。
3.2 会话状态的实际存储位置
OpenClaw 将会话记录以 JSONL 格式存储在磁盘上，并维护一个存储文件，用于将会话键（session keys）映射到具体的会话 ID 和元数据。文档中显示的路径如下：
- 存储文件：~/.openclaw/agents//sessions/sessions.json
- 会话记录：~/.openclaw/agents//sessions/.jsonl
这部分内容很重要，原因有二：
1）持久性：会话在系统重启后依然存在
2）安全性：这些文件可能包含敏感内容
04 队列：OpenClaw 如何防止"两种想法同时碰撞"
如果多个输入几乎同时到达（一条 Slack 私信 + 一个心跳信号 + 一个 webhook），你肯定不希望并发运行导致同一会话文件或工具状态被破坏。
OpenClaw 通过 lane-aware FIFO 队列来解决这个问题：
- 它保证每个会话只有一个活跃运行
- 它仍然允许跨不同会话的并行处理，直到达到配置上限
以下是该队列工作原理的简化示意图：
OpenClaw 还支持不同的队列行为（"模式"），例如：
- collect（默认） ：将多条消息聚合起来，合并成一次后续的执行轮次来处理。
- followup：始终等待当前正在执行的"思考 - 行动"循环结束
- steer：注入到当前正在进行的任务流中（在工具调用的边界点）
"顺序状态机"的体验在每个会话内部是真实存在的 ------ 但整个系统仍可根据配置，并发运行其他会话。
05 协议：所有组件都通过同一套带类型的 WebSocket 语言进行通信
OpenClaw 能够支持多种界面（CLI、Web UI、桌面应用、移动节点）的一个重要原因是，它将网关视为一个真正的控制平面。
5.1 三种帧类型：req / res / event
OpenClaw 定义了一个简单的 WebSocket 消息模型：
- Request（请求） : { type: "req", id, method, params }
- Response（响应） : { type: "res", id, ok, payload | error }
- Event（事件） : { type: "event", event, payload, ... }
且第一帧必须是 connect（连接）请求。
5.2 TypeBox：通过模式定义（Schema）来驱动数据校验和代码生成
OpenClaw 将 TypeBox 定义的模式（Schema）作为其通信协议的唯一事实来源。这使得以下操作成为可能：
- 系统在运行过程中实时检查数据，如果发现不符合规则的数据包，直接拒绝处理。
- 系统能够将内部定义的数据结构，导出为标准的 JSON Schema 格式文件。
- 系统能够根据协议定义，自动为客户端生成所需的数据模型（类型定义）和代码（如 SDK 函数）。
以下是最简单的"hello world"连接流程：
文档还提到了协议版本控制和连接时的身份验证，包括如果你设置了网关令牌（Gateway token），可以使用基于令牌（token）的认证。
06 Agent 运行时循环："聊天"变成"工作"的地方
一旦网关决定了由哪个 agent 和哪个会话来处理输入，智能体运行时（agent runtime）就会执行这样一个常规循环：
1）加载上下文（会话历史 + 工作区上下文）
2）调用模型
3）执行工具调用（浏览器、文件系统、shell、节点、插件）
4）持久化更新
5）响应（或故意保持沉默）
此处提供一个紧凑的循环示意图：
6.1 "记忆"并非学习 ------ 而是文件
这是最重要的思维转变之一：
OpenClaw 不会通过改变模型权重来"学习"。
它通过读写磁盘上的状态数据，并在每轮执行时重新注入上下文，来维持连续性。
OpenClaw 的"Agent Workspace"文档将工作区描述为 agent 的家，一个你应当视作记忆载体的地方。
另外有一点值得注意：工作区是默认的工作目录，而非严格的沙箱 ------ 相对路径会在工作区内解析，但除非你启用沙盒，绝对路径仍可访问外部。
07 让人产生"OpenClaw 具有自主性"幻觉的五种输入类型
大多数聊天机器人只有在你打字时才会唤醒。OpenClaw 在多种触发条件下都会唤醒，这正是它给人"仿佛活着"的感觉的原因。
以下是五种核心输入类型（外加一个补充项）：
一些出人意料但至关重要的细节：
- Heartbeats 默认间隔为 30 分钟（某些认证模式除外），推荐的做法是：如果无需处理任何事务，就回复 HEARTBEAT_OK。
- Webhooks 可配置为立即触发或等待下一次 heartbeat 再处理，且投递功能可随时启用/禁用。
- Hooks 是一个事件驱动的自动化系统，会从多个目录（workspace、managed、bundled）中自动发现。
08 "凌晨 3 点来电"示例：本质就是一条 pipeline
让我们揭开这个经典"灵异时刻"的神秘面纱：
"为什么我的 AI 助手会在我睡觉时去决定做某事？"
这并不需要什么涌现能力。仅仅是：
- 到达指定时间而触发了一个事件
- 网关将其加入队列
- 智能体执行了一个处理轮次
- 某个工具执行了该操作
09 安全性：强大的智能体天生"带刺"
OpenClaw 的官方安全文档几乎说出了所有人的顾虑：运行具有 shell/文件访问权限的 agent 是有风险的，不存在绝对安全的配置 ------ 你的目标是审慎地控制谁可以与它对话、它可以在哪里行动、它能接触哪些资源。
9.1 为什么攻击面很大
OpenClaw 能够：
- 从多个渠道接收不受信任的文本
- 读取文件、浏览网页、运行工具
- 安装/运行"skills"或扩展
上述能力的组合，使得那些已知的智能体安全风险不再是理论上的担忧，而是切实存在的威胁。
- Prompt 注入（直接或通过网页/文档/邮件的间接注入）
- Skill 供应链风险（所谓 "有用的" skill 实际上是恶意软件）
- 凭证泄露（token、API key、cookies）
- 命令误触发（模型试图帮忙但执行了破坏性的 shell 命令）
Cisco 的 AI 威胁与安全研究团队强调了"skills"的风险，并引用研究指出，在他们分析的 31,000 个 agent skills 中，有 26% 包含至少一个漏洞，为此他们推出了一款开源扫描工具。
9.2 你真正应该用起来的内置防护机制
一份实用的加固清单：
1）配对 + 私信策略
配对码一小时后过期，且待处理请求有数量上限，因此未知用户无法随意私聊你的智能体并获得完全访问权限。
2）非本地访问的 Gateway token
如果你将网关暴露到 localhost 之外，务必要求连接在握手时通过 token 认证。
3）多人可私信时启用安全私信模式
按发送者/频道隔离会话，避免上下文泄露。
4）沙箱/最小权限原则
记住：工作区默认并非沙箱。如果你允许智能体运行代码或接触敏感路径，请启用沙箱机制。
5）审计你的配置
文档建议运行 openclaw security audit 来识别危险配置和潜在暴露点。
6）将社区 skills 视为不受信任的代码
扫描、审查、固定版本，避免"每天随机使用 skill"的行为。
9.3 部署建议（简单且务实）
如果你想要有所获益，又不想陷入噩梦：
- 在专用机器或 VM 上运行 OpenClaw（这样"agent 被攻破"不意味着"你的整台笔记本被攻破"）。
- 为 email、Slack、GitHub 等使用独立账号/限定范围的 token。
- 在让它执行动作之前，先从"只读"工作流开始（如生成摘要、起草内容）。
10 一份"代码/文档快速查阅指南"
如果你想深入了解，以下是与架构最相关的关键入口点：
- 网关协议与握手流程（模式定义、版本控制、身份认证机制）（docs.openclaw.ai/gateway/pro...
- TypeBox 帧模型（req/res/event + 首帧必须为 connect 的规则）（docs.openclaw.ai/concepts/ty...
- 会话管理（dmScope、安全私信模式、文件存储路径）（docs.openclaw.ai/concepts/se...
- 命令队列（能够识别会话通道的 FIFO、每个会话内部，事件的执行顺序是严格有序的，且同一时刻只有一个事件在被处理、任务入队列或执行有多种行为模式）（docs.openclaw.ai/concepts/qu...
- 心跳机制（默认频率、HEARTBEAT_OK 的行为模式）（docs.openclaw.ai/gateway/hea...
- Hooks + Webhooks（内部 vs 外部事件触发源）（docs.openclaw.ai/automation/...
- 插件系统（OpenClaw 如何通过命令/工具/RPC 进行扩展）（docs.openclaw.ai/tools/plugi...
11 最终结论：OpenClaw 的"自主性"本质上是一种工程模式
如果把所有内容提炼到最简，OpenClaw 的架构基本由四部分组成：
- 时间 Time（心跳 + 定时任务）
- 事件 Events（消息 + Hooks + Webhooks）
- 状态 State（会话 + 磁盘上的 workspace 记忆）
- 循环 Loop（智能体处理轮次：读取 → 决策 → 执行 → 写入）
当人们问"智能体是否有生命"时，他们问错了问题。
真正应该问的是：
- 什么事件会唤醒它们？
- 它们拥有什么状态？
- 它们强制遵守哪些 invariants？
- 它们能执行哪些工具？
OpenClaw 用清晰的架构回答了这些问题。
而正是这种清晰，赋予了它强大的能力。
END
本期互动内容 🍻
❓OpenClaw 默认工作区不是沙箱。在你实际部署中，更倾向「先跑起来再加固」，还是「一开始就最小权限」？有没有踩过相关的坑？
本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。
原文链接：