OpenClaw 架构拆解：开源 AI 助手如何做到 7×24 小时替你干活

OpenClaw 是目前 GitHub 上热度最高的开源项目之一：一个跑在自己机器上的常驻 AI 助手，通过 Telegram、WhatsApp 这些聊天软件接收指令，自己动手完成查邮件、盯代码仓库、整理文件这类实际操作。截至本文发稿，它的 GitHub 仓库已经积累了超过 38 万 star。项目由开发者 Peter Steinberger 发起，前身是 2025 年底走红的 Clawdbot，中途短暂改名 Moltbot 后定名 OpenClaw。

System Design Newsletter 近期发布了一篇架构拆解《The Anatomy of OpenClaw》，把这套系统的内部构造讲得相当清楚。本文基于该文的公开部分，把 OpenClaw 的几个核心模块——Gateway 网关、渠道层、LLM 层、插件系统、记忆系统——逐一讲透，并补充国内使用的实际条件和几个上手前必须想清楚的问题。

OpenClaw 是什么

用 ChatGPT 写邮件时，AI 负责起草，但复制文本、粘贴进 Gmail、点击发送这些动作仍然要人来完成。OpenClaw 补的就是这一段：它本身不产生智能，智能来自接入的大模型（Large Language Model，大语言模型），它负责把模型的决策落实到文件、聊天软件、shell 和各种 API 上。原文的比喻是”LLM 是大脑，OpenClaw 是手”。

整套系统拆开看有六个组成部分：

Gateway 网关：跑在 Mac 或 Linux 上的常驻服务，协调消息、模型、工具和记忆，是整个系统的地基。
多渠道消息接口：WhatsApp、Telegram、Slack 等平台上对接的是同一个助手，共享上下文和记忆，不需要每个平台单独维护一个 bot。
技能平台 ClawHub：收录了 5400 多个模块化技能。技能（skill）就是普通的 Markdown 文件，写清楚某件事怎么做，比如检查 GitHub PR 或发送 Slack 消息。
持久记忆系统：知识、偏好、日志全部以 Markdown 文件形式存在本地磁盘上，可以直接查看、编辑，甚至纳入版本管理。
主动调度引擎：Heartbeat（心跳）机制加 cron 定时任务，让它可以按计划自己醒来检查服务器、分拣邮件、发送摘要，而不是干等指令。
模型无关：Claude、GPT、DeepSeek、Gemini、Grok 或者通过 Ollama 跑的本地模型都能接入，还可以把不同任务路由给不同模型，用低价模型处理例行任务、旗舰模型处理复杂任务。

原文给了一个很能说明问题的使用场景：晚上 9 点在 Telegram 发一句”检查我的 PR，看今晚有没有需要回复的”，然后锁屏睡觉。第二天早上收到回复——三个 PR 处于打开状态，其中一个有同事留下的关于错误处理的评审意见，OpenClaw 已经起草好回复并标记等待批准；另外两个还在跑 CI，没有动；涉及鉴权模块的那个它没碰，因为记得上周用户说过鉴权相关的评审要亲自处理。全程不需要打开 GitHub，也不需要在窗口之间搬运任何内容。

与常见 AI 工具的区别

原文把市面上的工具分成四类做了对照：

ChatGPT、Claude、Gemini 网页版：提问、回答，仅此而已。它们访问不了邮箱，跑不了脚本，标签页一关记忆就没了。
Siri、Google Assistant：成熟但封闭，不能添加自定义技能，不能接任意 API，也不能自托管。
LangChain、CrewAI、AutoGen：面向开发者的框架，链路要自己写 Python，界面要从零搭。OpenClaw 把这些都做成了开箱即用。
Claude Code、Codex CLI：面向编码会话的终端工具，人发起、它响应，会话结束就停。OpenClaw 全天候在线，管的也不只是代码。

图：网页版 AI 与 OpenClaw 常驻网关的能力对比（根据原文示意图重绘）

Gateway：常驻本机的控制中枢

启动 OpenClaw 网关，得到的是一个绑定 18789 端口的 Node.js 服务，作为后台守护进程一直运行。这是它和浏览器型 AI 工具最根本的区别：主流 AI 助手只在标签页打开期间存在，DeepResearch 这类模式能跑一个长会话，但跑完也就停了。OpenClaw 的定时任务、主动提醒、多渠道消息、长期记忆，全部建立在”进程一直活着”这个前提之上。

消息从 Telegram、WhatsApp 或 Slack 进来后，Gateway 依次做这几件事：验证发送者身份，创建或恢复对应会话，组装完整上下文交给模型，处理模型返回的工具调用，最后把回复送回消息来源的渠道。

图：一条消息在 OpenClaw 内部的完整处理流程（根据原文示意图重绘）

危险操作有审批机制。比如让它清理旧日志，Gateway 会先把 shell 命令拦下来，通过 Telegram 发一条确认请求：”即将执行 rm -rf ~/logs/*.log，是否批准？”不点头就不执行，不回复就一直等着。

Gateway 还在 http://localhost:18789 提供一个浏览器控制台（Control UI），可以实时观看 agent 的推理过程、批准待执行的命令、查看活跃会话，每一次工具调用和模型响应都会实时显示。由于 Gateway 通常跑在 Mac Mini 或 VPS 上，同一局域网内任何设备的浏览器都能访问这个控制台；配合 Tailscale（一款异地组网工具），在外面用手机也能直接连上。

配置支持热加载：换模型、改权限、新增消息渠道都不需要重启进程，运行中的服务会直接应用变更。

渠道层：一套适配器接入所有聊天软件

各聊天平台在协议层面完全是四套东西：Telegram 用 bot token，消息通过轮询或 webhook 送达；WhatsApp 走的是逆向工程出来的网页协议，需要扫二维码登录，会话状态存在本地；Slack 用 Socket Mode，要管理两种不同的 token；Discord 是网关 WebSocket 连接，自带心跳保活要求。

如果没有专门的抽象层，每接入一个新平台都要改动路由逻辑、会话管理和消息管道。OpenClaw 的解法是渠道层（Channel Layer）：每个平台是一个独立插件，充当翻译适配器，把进来的消息统一转换成内部标准格式——稳定的身份标识、内容、元数据、附件——然后才交给 Gateway。过了这道边界，后面所有环节都不关心消息来自哪个平台。

图：渠道层把四种平台协议统一成一种内部格式（根据原文示意图重绘）

这个设计还有一个安全上的好处：白名单、设备配对、@提及门控这些安全策略只需要实现一份，就能在所有平台上统一生效，不用每个渠道重做一遍。

LLM 层：可替换的大脑与工具调用循环

原文把这一层称为 brain socket（大脑插座）：用户提供 API key 接入智能，OpenClaw 提供其余全部基础设施。Claude、GPT-4、Gemini、DeepSeek 或 Ollama 本地模型随时可换，不需要重新配置。

消息到达这一层后，OpenClaw 会组装系统提示词，内容包括四块：配置好的 agent 人设、可用技能列表、从历史会话中检索出的相关记忆，以及当前对话记录，然后带着完整上下文调用模型。模型如果决定采取行动——跑 shell 命令、搜网页、读文件、调 API——就返回一个工具调用；OpenClaw 执行工具、捕获输出、把结果喂回对话，模型阅读结果后决定下一步是继续调用工具还是给出最终回答。这个循环一直转到模型不再请求工具为止，全过程在 Control UI 里逐步可见。

当对话逼近模型的上下文长度上限时，压缩机制（compaction）自动触发：agent 把此前的对话总结成摘要，用摘要替换原始消息记录。连续性保住了，又不用每次回复都加载几千 token 的历史。

插件系统与生命周期钩子

核心引擎之外，OpenClaw 里几乎所有东西都是插件：Telegram 接入是插件，GitHub 访问是插件，记忆系统本身也是插件。启动时它读取配置，只加载启用了的插件；关闭一项能力只需改一行配置，安装社区插件只需把文件放进指定目录，自己开发插件则只要实现规定的接口，完全不碰核心引擎。

插件可以在所有关键节点挂上生命周期钩子：工具调用前后、消息处理前后、会话开始和结束。审计日志、请求限流、自定义审批流程，都是通过钩子加进去的，核心 agent 代码一行不动。

记忆系统的三层设计

最朴素的记忆方案——把全部聊天历史塞进每个提示词——很快就会失效：一周的活跃对话足以撑爆任何上下文窗口；就算塞得下，每次回复都加载全量历史，既贵又慢。OpenClaw 把”短期连续性”和”长期回忆”当成两个问题分开解决，外加一层人工维护的固定层：

短期记忆负责当前对话不断线。每个会话保存为磁盘文件，回复时只加载该会话最近的部分。
长期记忆负责跨天、跨周的回忆。所有历史会话在本地数据库中建立索引，每次回答前记忆索引器先检索一遍，相关内容自动带入上下文——五天前聊过的事项，不需要用户再提醒一次。
固定笔记是第三层：用户自己手写的 Markdown 文件，存放在 ~/.openclaw/workspace/memory/，相当于一份长期有效的简报，记录偏好、项目和背景信息。SOUL.md、USER.md、MEMORY.md 这几个文件每次会话开始都会被读取。

图：记忆系统的三层结构（根据原文示意图重绘）

长任务的三种处理模式

多数交互几秒钟就结束，但爬几百个页面、跑完整测试套件、跨多个 API 的多步骤流程可能要几个小时。OpenClaw 对这类任务有三种处理方式：

一是发完即走。任务耗时长时，agent 不会占着对话让人干等，而是先确认收到、转入后台执行、完成后主动发消息汇报，手机锁屏走人完全没有影响。

二是断点续传。跨越多个会话、或中途需要人工输入的任务，agent 会先完成能做的部分，把当前状态写入 MEMORY.md 或工作区文件后暂停；用户回来继续对话时，它从存档状态接着干。关键状态写在磁盘上而不是驻留内存，会话之间不会丢失上下文。

三是 cron 隔离会话。真正的常驻后台作业适合用隔离会话模式的定时任务：每次运行获得独立会话，完成工作、把结果投递到消息渠道、干净退出，下一次运行从零开始。长期跑的自动化任务不会越积越多陈旧上下文。

原文还点了一个实际限制：单个工具调用耗时过长，Gateway 会等待超时。大规模网页抓取、响应慢的 API 这类工作要拆成小块，让 agent 分批处理、批与批之间汇报进度，不要指望一次工具调用全部干完。

上手前的现实问题：安全、成本与国内条件

以下几点是原文之外的补充判断。

权限边界比功能更值得先想清楚。一个能执行 shell 命令、能读邮箱的常驻 agent，读到的任何内容——邮件正文、网页、群消息——都可能包含诱导性指令，这类提示词注入攻击对所有工具型 agent 都成立，OpenClaw 因为权限大，后果也更重。稳妥的做法是把它部署在独立的小主机或 VPS 上，只授予确实需要的账号权限，Gateway 的命令审批机制不要图省事关掉。原文把安全风险列为专门章节，官方文档中也有对应的安全说明，动手前有必要通读。

常驻等于持续花钱。心跳唤醒、定时任务、记忆检索都在消耗 API token，全天候挂一个旗舰模型，月底账单会相当可观。合理的配置是把例行心跳和轻量任务路由给便宜模型或本地 Ollama 模型，复杂任务再交给 Claude 这类高端模型——模型路由本来就是它的内置能力，用起来不费事。

国内部署存在现实约束。消息渠道 Telegram、WhatsApp、Slack、Discord 在国内均无法直连，需要相应的网络环境，这基本决定了国内用户要么部署在海外 VPS 上，要么自行解决网络问题。模型一侧反而顺畅：DeepSeek 的 API 国内直连可用且价格低，Ollama 本地模型完全不依赖外部网络。国内暂时没有生态体量相当的开源对标品，定位最接近的做法是自己把 Claude Code 一类 CLI 工具挂到聊天软件上，但调度、记忆、多渠道、审批这些 OpenClaw 已经打包好了。

硬件门槛不高，人的门槛不低。推理发生在模型 API 一侧，本机只负责调度和工具执行，一台闲置 Mac Mini 或低配 VPS 足够。它更适合有服务器运维经验、清楚 shell 权限风险的工程师；只想要一个现成 AI 助手的用户，托管型服务更省心，代价是数据不在自己手里。