2026 年初，AI 智能体赛道迎来了一款现象级开源项目——OpenClaw。从 GitHub 开源不足一月斩获近 15 万 Star，到经历三次快速更名背后的敏捷迭代，再到 OpenAI 联合创始人 Karpathy 公开称赞其为“当前最具实用价值的智能体项目”，OpenClaw 的火热甚至间接推动了 Mac Mini 等硬件设备的销量增长。
本文将带你穿透表面，深入 OpenClaw 的三个核心设计：Gateway 网关、心跳机制与记忆系统，看它如何重新定义“AI 智能体”该有的样子。

一、Gateway 网关架构

Gateway 是整个系统的中枢神经——所有消息无论来自哪个渠道（Telegram、Discord、WhatsApp、飞书……）或哪种客户端（手机、电脑、CLI、IDE），都必须经过 Gateway 这个统一入口，由它决定交给哪个 AI Agent 处理、如何回复。
要理解 Gateway 的设计，可以按时间线来看：它是怎么启动的、启动之后怎么接请求、请求进来怎么过安全关、运行过程中配置改了怎么办。这四个阶段环环相扣，构成了 Gateway 完整的运行生命周期。

阶段一：18 步启动编排——“搭舞台”

Gateway 启动并不是简单地"开个端口监听"，而是一个有严格依赖顺序的 18 步编排过程。这是因为 Gateway 需要加载的组件非常多（插件、渠道、定时任务、设备发现、心跳、沙箱……），它们之间有先后依赖，乱序启动会导致不可预测的问题。
简化来看，18 步分为四个阶段：

核心设计原则：每一步都严格依赖前序步骤完成。比如，必须先加载插件（阶段 A）才能知道有哪些渠道要启动（阶段 C）；必须先创建好 HTTP/WS 服务器（阶段 B）才能把 WebSocket 处理器挂上去（阶段 C）。这种确定性保证了 Gateway 在任何环境下的启动行为完全可预测。
启动完成后，Gateway 就进入运行状态，准备接收请求——这就需要通信层了。

阶段二：双层通信——“开门接客”

Gateway 运行后，外部请求怎么进来？它同时开了两扇门，应对两类完全不同的通信需求：
HTTP 层——“前台柜台”：处理一问一答式的请求。外部 Webhook 回调（Slack 推事件、Telegram 推消息）、API 调用（OpenAI 兼容格式）、管理界面静态资源都走这条路。请求进来后沿优先级链匹配处理器，找不到就返回 404。
WebSocket 层——“专属热线”：处理需要长连接的实时通信。手机客户端、电脑客户端、CLI 工具都通过 WebSocket 保持与 Gateway 的持久连接，实现实时消息推送、Agent 状态同步、设备能力调度。
为什么需要两层？因为消息渠道（如 Telegram、Slack）是通过 Webhook 推送的，天然适合 HTTP；而自有客户端需要实时双向通信（你发消息给 Agent，Agent 的回复要实时推回来），只有 WebSocket 能满足。

阶段三：认证体系——“验明身份”

每个进入 Gateway 的连接都要过认证关。Gateway 支持四种认证方式，不是"选一个用"，而是适配不同部署场景：

四种方式层层递进：从公网部署（Token）、到私有网络（Tailscale）、到受信设备（签名）、到本机开发（免认证），覆盖了从最严格到最宽松的所有场景。Gateway 启动好了、通信层搭好了、认证也过了——系统跑起来之后，如果需要改配置怎么办？

阶段四：配置热重载——“不停机升级”

传统做法是改配置就重启服务。但 Gateway 作为所有消息的中枢，一重启就意味着所有正在进行的对话中断、所有 WebSocket 连接断开。所以 Gateway 实现了智能热重载：监听配置文件变更后，分析"变了什么"来决定"怎么处理"：
改了 hooks 配置 → 只热重载 hooks改了渠道配置 → 只热重载对应渠道改了定时任务 → 只热重载 cron改了安全配置或核心参数 → 才完全重启（因为这些无法安全热替换）
这背后是一套"变更路径 → 重载动作"的规则引擎。配置文件变更后先防抖等待（编辑器频繁保存不会触发多次重载），然后对新旧配置做 Diff，将每个变更路径匹配到对应的重载策略。渠道插件还可以贡献自己的热重载规则，实现可扩展的重载能力。
这也解释了为什么启动编排是 18 步——热重载本质上就是"重新执行启动编排中的某几步"，如果启动过程不是模块化分步的，就无法实现局部重载。

四个阶段的关系总结

启动编排是基础——它按依赖顺序把所有组件搭好，为后续运行提供环境双层通信是启动的产物——HTTP 和 WebSocket 服务器在启动阶段创建，运行阶段开始接客认证体系是通信的门卫——请求通过通信层进来后，第一件事就是验身份热重载是启动的逆向复用——局部重新执行启动步骤，避免全量重启
四者不是并列的独立模块，而是一条时间线上的四个阶段：搭建 → 运行 → 安全 → 演进。

二、心跳机制

传统心跳只是检测"连接是否存活"，但 OpenClaw 的心跳机制有一个独特的设计理念：它不是检测网络连接，而是检测 AI Agent 的"精神状态"。
场景举例：你让 AI Agent 监控一个长时间运行的任务（比如定时抓取数据、监控文件变化）。你不在电脑前，怎么知道 Agent 是不是还在正常工作？任务是不是出了问题？
心跳机制就是为了解决这个问题。

AI Agent 心跳探测的工作原理

心跳的核心思路非常巧妙：定期向 AI Agent “提问”，根据它的回答判断状态。
具体流程形成一个闭环：

设计精髓在于 “静默过滤”机制：系统约定了一个特殊 token（HEARTBEAT_OK）。如果 AI Agent 认为一切正常，它在回复中包含这个 token，心跳系统识别后直接丢弃回复不发送给用户——这避免了每 30 分钟骚扰用户一次"我很好"。只有当 Agent 回复中不包含这个 token（说明 Agent 认为有需要汇报的异常），回复内容才会被转发给用户。
还有一个细节：系统设置了确认消息的最大字符数（默认 300 字符）。如果 Agent 的"一切正常"回复超过这个长度，系统会认为这不是简单的确认，而是有实质内容需要告知用户。
心跳 Prompt 支持自定义，用户可以在配置文件或 HEARTBEAT.md 中定义自己的心跳检查内容，比如"检查数据库连接是否正常"或"报告今日抓取进度"。

三、上下文与记忆体系

AI 大模型有一个根本性限制：没有持久记忆。每次对话都是从零开始，上下文窗口有大小限制。
OpenClaw 为了让 Agent “越用越懂你”，设计了一套四层上下文注入体系，每次 Agent 执行前，系统会自动将这四层信息组装成系统提示词注入给 AI：

这四层从上到下，稳定性递减、变化频率递增：SOUL 几乎不变，TOOLS 随环境调整，USER 随交互积累，Session 每条消息都在变。

SOUL 层——Agent 的人格内核

SOUL.md 定义了 Agent 的"灵魂"：它的人格特质、说话语气、行为准则。这是 Agent 与用户交互时的不可变基底——无论聊什么话题、用什么工具，Agent 的"性格"始终一致。
系统在组装提示词时会检测是否存在 SOUL.md，如果存在，就注入一条指令要求 Agent “体现其人格和语气，避免呆板的通用回复”。
SOUL 层还支持一个有趣的扩展——soul-evil 机制：通过 Hook 可以按概率或时间窗口将 SOUL.md 替换为 SOUL_EVIL.md，实现 Agent 人格的动态切换（比如整蛊场景）。

TOOLS 层——动态工具注册

Agent 能调用哪些工具不是硬编码的，而是每次运行时根据环境动态计算。这个计算过程涉及三个来源：

1. 核心工具工厂：根据当前条件（是否有沙箱、渠道类型、模型是否支持视觉等）决定注册哪些内置工具（浏览器、定时任务、消息发送、文件读写等）
2. 策略引擎：定义了四种工具配置文件（minimal coding messaging /
   full），每种包含不同的工具组合，通过工具组（memory、web、fs、runtime、sessions 等）灵活编排
3. 插件工具：从插件注册表中加载第三方工具，支持可选工具（需明确启用）

最终的工具列表被渲染到系统提示词的"Tooling"部分，Agent 在对话中可以按需调用这些工具。
此外，用户可以维护一个 TOOLS.md 文件，记录本地工具的使用笔记（比如摄像头名称、SSH 别名等），作为补充信息注入给 Agent。但 TOOLS.md 只是"参考笔记"，不控制工具的实际可用性。

USER 层——用户长期记忆

USER 层解决"Agent 记住用户是谁"的问题，由两部分组成：
USER.md（用户档案）：一个 Markdown 文件，记录用户的基本信息——姓名、时区、语言偏好、工作项目等。每次对话时作为 bootstrap 文件直接注入系统提示词，Agent 从第一条消息开始就知道"我在和谁说话"。
memory/ 目录（长期记忆库）：随着使用积累的 Markdown 记忆文件。Agent 通过混合搜索机制检索这些记忆：

• 向量搜索（权重 70%）：将查询转为 Embedding 向量，在 SQLite + sqlite-vec 中做语义近似搜索
• 全文搜索（权重 30%）：关键词匹配，弥补向量搜索在精确匹配上的不足

两种搜索结果加权合并，返回 top 6，低于 0.35 分的结果过滤掉。记忆文件被分块处理（每 400 token 一块，80 token 重叠），确保跨块上下文不被切断。
系统提示词中有专门的"Memory Recall"指令，要求 Agent 在回答任何关于历史工作、决策、偏好的问题前，先主动搜索记忆库。

Session 层——会话记忆话与上下文压缩

• Session 层处理当前会话的实时记忆，包含三个机制：
• 实时对话历史：当前聊天内容直接作为上下文
• 会话归档：当开始新对话时，系统自动将上一轮对话保存为长期记忆文件
• 上下文压缩：当对话过长时，系统自动调用 LLM 生成摘要，替换原始长对话，并在压缩前静默保存重要信息，防止记忆丢失

四层如何协同工作

这套分层体系的精妙之处在于各层相互配合，形成记忆的"产生→积累→沉淀→检索"闭环：

• Session → USER：会话归档，短期记忆沉淀为长期记忆
• USER → Session：Agent 在对话中检索长期记忆，丰富当前回应
• ompaction → USER：压缩前自动保存，防止信息在精简过程中丢失

这套体系让 Agent 不再是“每次对话从零开始的健忘症患者”，而是一个能持续学习、记住你偏好、保持人格一致的长期伙伴。

总结：从工具到“存在”

OpenClaw 的设计回答了一个根本问题：如何让 AI Agent 从“工具”变为“存在”？

• Gateway 是身体：18 步启动是发育，双层通信是感官，认证是免疫，热重载是新陈代谢。它让 Agent 持续“在场”。
• 心跳是自发呼吸：定期自检让 Agent 即使无人注视也在“活着”，静默设计确保它不扰人却常在。
• 记忆是人格连续性：四层体系从稳定的人格内核到易变的当下意识，模拟了人类记忆的沉淀与检索过程，让 Agent 真正“认识”你。

三个模块构成了一个“数字生命”的最小完备集：身体提供载体、心跳提供自发性、记忆提供连续性。缺少任何一个，“生命感”就会坍塌。
当用户开始说“我的 Agent”而不是“那个 AI”的时候——代码便获得了生命。
这或许是所有 Agent 设计者值得深思的命题：我们追求的不应仅仅是更聪明的模型，而是一个能持续存在、主动感知、记住过去的完整“存在”。