最近 OpenClaw 这么火，你知道它的原理吗？

参考答案

OpenClaw 本质上是一个开源的 多渠道 AI 网关（Multi-channel AI Gateway），它自己不做推理，只做调度和执行。你可以把它理解成一个中枢网关，把大模型的推理能力翻译成对操作系统、软件 API、硬件设备的实际控制权。

跟普通聊天机器人最大的区别在于，它能真正”动手干活”，不只是回复文字。

理解 OpenClaw，只需要抓住两个核心：架构和运行时机制（Agentic Loop + 工具生态）。

架构上分两层：

1）Gateway（网关层）：

不仅是消息入口也是整个系统的常驻基础设施。

它以守护进程方式 7×24 小时运行，负责六件核心事：

• 多平台接入，统一翻译各渠道消息格式为内部 MsgContext
• 会话隔离，为每个用户/群/Agent 维护独立的 Session Key
• 排队控制，并发消息的去重、限流、队列调度
• 心跳巡检，Heartbeat 周期性唤醒 Agent 主动做任务
• Cron 定时调度，支持 cron 表达式的精确定时任务系统）
• 记忆刷盘，在上下文压缩前把关键信息持久化到磁盘。

可以把它类比成 API Gateway + 进程管理器 + 任务调度器的结合体。

2）Agent Runtime（运行时层）：

真正干活的地方。

接收 Gateway 派发的消息，组装上下文、调用 LLM、执行工具、返回结果。

运行时机制的核心是 Agentic Loop（Agent 循环），也就是基于 ReAct 范式的推理循环：

这是 OpenClaw 的心脏。每当用户发一条消息，Agent 不是简单地丢给 LLM 拿回答案就完了，而是进入一个循环：

1）Load，组装上下文：加载会话历史、记忆文件、系统提示词

2）Call，调用 LLM：把上下文和工具列表一起发给 LLM，让它”想”

3）Parse，解析响应：LLM 要么直接回复文字（结束循环），要么返回一个 tool_call 指令，比如”我需要搜索一下网页”

4）Execute，执行工具：如果是 tool_call，那就执行对应的工具，拿到结果

5）Append，结果回填：把工具执行结果追加到上下文里

6）Loop，循环：回到第 2 步，这个循环会一直转，直到 LLM 认为任务完成、输出最终文本

除了这个循环，OpenClaw 还有个很重要的点在于它内置了一套丰富的工具生态，能直接操作操作系统：读写文件、执行终端命令、浏览网页、调用外部 API 等。

循环是引擎，工具才是手脚。普通聊天机器人就算有循环，没有这些执行器，也只能回复文字。

OpenClaw 能做到”搜网页 → 读取内容 → 整理摘要 → 写入文件 → 告诉用户搞定了”这种多步骤任务链，靠的是循环 + 工具的组合驱动。

技术栈上，OpenClaw 用 Node.js + TypeScript（ESM） 实现，HTTP 服务直接基于 Node 原生的 node:http 模块（没有用 Express/Koa），WebSocket 做控制面实时通信。底层的 Agent 会话管理构建在 pi-coding-agent SDK 之上。

扩展知识

为什么 OpenClaw 能火

时机对了。

2025 年 AI Agent 概念爆发，大家都在找”怎么让 AI 真正干活”，但 LangChain 门槛太高要写大量胶水代码，AutoGPT 容易失控烧 Token，各家 API 手搓又太累。

OpenClaw 正好卡在中间：开箱即用，不需要写代码就能跑起来。

它把自己定位成”AI 的操作系统”。不做推理，那是 LLM 的事，它只管调度和执行，模型完全可以随便换。

今天用 Claude，明天换 DeepSeek，后天跑本地 Llama，代码一行不用改，只需要改配置文件里的 API Key 和 Base URL。

再加上开箱即用地接入 15+ 聊天平台，部署非常方便。

并且它能 7×24 小时常驻运行，支持心跳巡检（定期主动检查待办事项）和 Cron 定时调度（标准 cron 表达式的定时任务）。这让 AI 从一个”你问它才答”的被动工具，变成了一个”能主动干活”的基础设施。

还有一点开源 + 本地优先击中了隐私焦虑。

同期很多 AI 产品都是云服务，数据在别人服务器上，而 OpenClaw 数据全在本地，这对企业和注重隐私的开发者吸引力很大。

除此之外，龙虾不仅击中开发者的需求，很多其他行业的打工人听到有个可以自动帮你干活的“龙虾”，就被疯狂安利了。

这个项目能火，其实和创始人也有很大的关系，他自带光环。

Peter Steinberger 是 PSPDFKit（PDF 组件库）的创始人，在 iOS/macOS 开发圈有很高知名度，靠 PSPDFKit 实现了财务自由。

他做的东西开发者天然信任。

项目最初叫 Clawdbot，有点像 Claude 的谐音，吉祥物是只龙虾。2026 年 1 月 Anthropic 以名字相似为由要求改名，先改成 Moltbot 只撑了 72 小时，最终定名 OpenClaw。

GitHub star 数增长速度创了历史纪录，2 天破 10 万（Linux 花了 12 年，React 花了 8 年），到 2026 年 3 月已经超过 30 万 star，登顶 GitHub 历史第一。

2026 年 2 月 Steinberger 加入了 OpenAI，项目转为独立基金会运营，继续保持开源。

国内腾讯云、阿里云、百度智能云、火山引擎、京东云、美团都上线了 OpenClaw 云端部署服务，深圳龙岗区甚至发布了”龙虾十条”专项支持政策。

Gateway 网关

Gateway 是一个 HTTP + WebSocket 服务器，默认只绑定 127.0.0.1:18789，不对外暴露。

作为网关，它具备传统 API Gateway 的基础能力：鉴权、路由分发（按优先级将消息派发到对应 Agent）、限流（并发控制 + 队列调度）、幂等去重（防止平台重复推送导致 Agent 重复执行）。

但其实 Agent Loop 和 Tools 并不是 OpenClaw 独有的，比如Claude Code、Codex 都有自己的实现。

Gateway 才是 OpenClaw 区别于其他 AI 编程工具的核心独有模块，除了上述基础网关能力，它还承担了六大进阶职责：

1）常驻在线（Always-on）

Gateway 的主循环是一个 while (true) 永不退出的进程。配合操作系统级的守护进程管理：macOS 用 launchd、Linux 用 systemd、Windows 用 Scheduled Task，从而实现了崩溃自动拉起。

Gateway 重启时，因为会话状态已经以 JSONL 格式持久化在磁盘上，所以能恢复之前的对话上下文，继续处理没完成的任务。

重启过程也不是直接杀掉：收到 SIGUSR1 信号后，先进入 drain 阶段等待所有正在执行的 Agent turn 完成（最多等 90 秒），然后才优雅关闭并 spawn 新进程或让 supervisor 拉起。

每个渠道连接也有独立的指数退避重连策略（5 秒起步、2 倍增长、最大 5 分钟、最多重试 10 次），单个渠道掉线不影响其他渠道。

2）多平台接入（Channel Plugins）

每个聊天平台都有一个专门的渠道适配器（Channel Plugin），比如 Telegram 用 Bot Token 鉴权，WhatsApp 用 QR 码配对，iMessage 需要跑在真正的 Mac 上。

适配器负责把各平台千差万别的消息格式统一成 OpenClaw 内部的 MsgContext，顺带处理 Markdown 转换、长消息切分、媒体上传这些脏活。

对于 Agent 运行时来说，不管消息来自哪个平台，看到的都是同一种数据结构。

3）会话隔离（Session Isolation）

Gateway 为每个用户、每个群、每个 Agent 维护独立的 Session Key，格式为 agent:{agentId}:{channel}:{peerKind}:{peerId}。

群聊一个群一个会话。

私聊可通过 dmScope 配置粒度（共享主会话 / 按用户 / 按渠道+用户 / 按账号+渠道+用户）。Cron 定时任务和子 Agent 也有各自隔离的会话空间，互不干扰。

4）排队控制（Queue Control）

当 Agent 正在处理一条消息时，新消息进来怎么办？

Gateway 实现了一套完整的队列系统，支持 6 种模式：

• steer：新消息直接注入到当前运行中的 Agent 上下文（”插嘴”）
• followup：排队等当前 turn 结束后再处理
• collect：收集多条消息合并为一个 turn 处理
• interrupt：打断当前任务立即响应
• queue：标准 FIFO 先进先出
• steer-backlog：steer + backlog 混合

配套有去重机制（按 message-id 或 prompt 去重）、容量上限（cap）、溢出策略（丢旧消息 / 丢新消息 / 用 LLM 摘要合并），防止消息洪水冲垮 Agent。

5）心跳巡检 + Cron 定时调度（Heartbeat + Cron）

这是 OpenClaw 能主动做任务的核心机制，也是它与纯被动聊天机器人最大的区别。

Heartbeat（心跳巡检） 负责周期性唤醒 Agent。每隔一段时间（可配置，如每 10 分钟），Gateway 触发一次心跳，唤醒 Agent 检查 HEARTBEAT.md 文件中定义的待办事项。

心跳触发有 7 种原因：

• 定时到期（interval）
• 手动触发（manual）
• 命令执行完成（exec-event）
• 外部唤醒（wake）
• 定时任务回调（cron）
• 钩子触发（hook）
• 重试（retry）

每个 Agent 可以有不同的心跳间隔和提示词，Gateway 统一调度。

Cron（定时调度） 是一个完整的定时任务系统，支持标准 cron 表达式。用户可以通过 openclaw cron add 添加定时任务（如”每天早上 9 点总结昨天的邮件”），CronService 在后台管理 Job 的增删改查、调度执行、失败告警。

Cron 任务运行在独立的 Agent 会话中，不会污染用户的主对话。

Heartbeat 负责”巡逻式”的周期检查，Cron 负责”闹钟式”的精确定时，两者配合，让 OpenClaw 从一个被动应答器变成了一个主动工作的 AI Agent。

5）记忆刷盘（Memory Flush）

当会话接近 token 上限即将触发 Compaction（压缩）时，Gateway 先让 Agent 执行一次 Memory Flush：模型会把当前对话中的关键信息（决策、待办、偏好等）主动写到磁盘文件 memory/YYYY-MM-DD.md 中，然后再做压缩。

这确保了压缩不会丢失重要信息。触发有两个阈值：软阈值（剩余 4000 tokens 时）和硬阈值（会话文件超过 2MB 时强制执行）。

Agent 运行时

当 Gateway 把消息派发到 Agent Runtime 后，会经历以下阶段：

第一步：路由匹配

一个 OpenClaw 实例可以配置多个 Agent（比如”客服 Agent”、”运维 Agent”），消息进来后要先决定交给谁。resolveAgentRoute() 会按优先级逐层匹配：

精确 peer 绑定 → 父 peer → guild + 角色 → guild → team → account → channel → 默认 Agent

匹配成功后同时生成一个 Session Key 用于会话隔离（具体格式和粒度见上面 Gateway 章节的「会话隔离」部分）。

第二步：组装上下文（System Prompt + 历史 + 工具）

OpenClaw 的系统提示词不是写死的，而是每轮对话由 buildAgentSystemPrompt() 动态拼装。数据来源包括：

• 工作空间的 Markdown 配置文件：AGENTS.md（行为规则）、SOUL.md（人格语气）、TOOLS.md（工具使用备注）、USER.md（用户偏好）、IDENTITY.md（身份配置）
• 自动注入的运行时信息：可用工具列表及说明、当前时区、渠道能力、沙箱状态
• 按需加载的技能指令（Skills）和语义搜索召回的记忆片段

插件还可以通过 before_prompt_build 钩子在构建阶段注入自己的上下文。改 Agent 行为只需编辑 Markdown 文件，完全不用动代码。

第三步：进入 Agentic Loop

上下文组装好后，进入前面说的核心循环。Agent 底层使用 pi-coding-agent SDK 管理会话状态，配合流式输出把模型的回复实时推送给用户。

在循环过程中，系统对上下文大小有严格的管控：

• Context Guard：单条工具结果最多占 context 的 50%，超出自动截断
• Token Budget：整体上下文有 token 预算，超出触发自动 Compaction（压缩）
• Overflow Recovery：如果遇到 context overflow 错误，系统会自动 compaction → 截断 tool result → 重试，最多重试数十次

第四步：保存状态

对话结束后，所有消息和工具调用结果以 JSONL 格式落盘到 ~/.openclaw/sessions/ 目录，下次对话时加载恢复。

所以整体的架构图（网关仅画出基本功能）如下：

技能系统（Skills）和渐进式披露

如果把所有工具的完整说明都塞进 System Prompt，几十个工具就能吃掉大量 Token，模型面对太多选择还容易选错。

OpenClaw 的 Skills 系统用按需加载来解决这个问题。

每个技能是一个带 SKILL.md 的文件夹，SKILL.md 的 YAML frontmatter 声明元数据（名称、描述、触发条件），正文是完整的执行指令。

加载分三层：

1. 元数据层（始终加载）：只解析 frontmatter，几十 tokens 的开销
2. 指令层（条件加载）：根据用户查询做相关性评估，只有命中的少数技能才展开完整内容
3. 资源层（按需加载）：脚本、模板等只有技能被激活且确实需要时才拉进来

打个比方：传统做法是把整本操作手册塞给你让你自己翻，OpenClaw 是先给你看目录，你说”我要搜网页”，再翻到那一章给你看。

社区技能通过 ClawHub 分发，一行 clawhub install <skill-slug> 即可安装。

记忆系统：短期 + 长期的双层设计

OpenClaw 的记忆系统解决的核心问题是：LLM 只能看到当前 context window 里的内容，怎么让它记住更多？

短期记忆就是当前会话的对话历史。

当对话太长快撑爆 context window 时，会触发 Compaction（压缩）：用 LLM 对早期对话生成结构化摘要，替换掉原始消息。摘要中严格保留标识符（UUID、URL、文件名等）和关键结构（决策、待办等）。

压缩前还有一个 Memory Flush 机制：先让模型把关键信息主动写到 memory/ 目录的文件里，确保压缩不会丢关键信息。

长期记忆存储在本地磁盘的 memory/ 目录里，通过 QmdMemoryManager 管理。

长期记忆检索用的是混合搜索策略：

• 关键词匹配（精确命中）
• 向量余弦相似度（语义理解）

两路结果加权融合。

搜”投资目标”也能命中”财务目标””资金规划”这种同义表达，同时支持 CJK 分词。

检索结果还经过 时间衰减（越旧的记忆权重越低）和 MMR 多样性重排（避免结果太雷同）。

Agent 通过两个工具接口使用记忆：memory_search 做语义召回，memory_get 按路径读取具体内容。

数据全部存在本地，不出设备。

面试官追问

提问：OpenClaw 的 Agentic Loop 如果某一步工具调用失败了，怎么处理？

回答：工具执行失败时，错误信息和详情会作为 tool_result 回填到上下文里，然后继续下一轮循环。LLM 看到错误后自己决定下一步，可能换参数重试，换一个工具绕过去，或者直接告诉用户”这个搞不定”。所以错误处理逻辑不是硬编码的 if-else，而是交给 LLM 的推理能力来判断。

不过系统层面提供兜底保护：用户发新消息可以直接中断当前循环（abort 机制），防止 Agent 卡死烧 Token；如果遇到 context overflow，系统会按优先级自动恢复：先触发 Compaction 压缩历史 → 再截断过大的 tool result → 最后报错建议 /reset。整个重试循环有迭代次数上限（默认 32~160 次，取决于配置的 auth profile 数量），防止无限重试。

提问：你说技能是注入到 System Prompt 里的，技能特别多的时候上下文窗口不够用怎么办？

回答：渐进式披露就是专门解决这个问题的。元数据层每个技能只占很少 tokens（解析 YAML frontmatter），完整执行指令只有命中的少数几个才会加载。会话历史也有压缩机制，接近窗口上限时自动把早期对话做摘要。在摘要之前还有 Memory Flush 机制，先让模型把关键信息写到磁盘的 memory 文件里，确保压缩不会丢失重要信息。再加上 tool result 的 Context Guard（单条结果最多占 context 的 50%，超出自动截断），多套机制配合控制上下文长度。

提问：OpenClaw 的安全模型经历过什么重大事件？它后来做了哪些改进？

回答：最严重的一次是 Shodan 暴露事件。2026 年 1 月底，安全研究人员发现几百个 OpenClaw 控制面板直接裸露在公网上，入侵者能看对话记录、偷 API Key，甚至以用户身份执行命令。Axios、Bitdefender、1Password 都报道了这个事。核心原因是早期版本支持 auth: none 无认证模式，很多用户图方便就这么配了。v2026.1.29 版本加强了安全审计和警告，要求配置 Token 或密码认证。后来又加了 7 层工具策略管道（从 profile 到 group 级别逐层收窄），加上 owner-only 工具隔离和子 Agent 工具限制。中国工信部也专门发了安全提示，国家互联网应急中心列了四大风险点建议审慎使用。

提问：OpenClaw 说自己是”模型无关”的，切换模型会不会出现行为不一致？

回答：一定会。不同模型对 System Prompt 的理解能力、工具调用的格式遵循度、推理深度都不一样。Claude 对复杂工具链的编排能力就比 7B 的小模型强很多，换成本地 Ollama 跑的量化模型，一个多步骤任务可能就搞砸了。OpenClaw 在工程层面做了不少适配：normalizeToolParameters() 会根据 Provider 自动清洗 Tool Schema（Gemini 不支持 additionalProperties、xAI 不支持 minLength/maxLength、OpenAI 要求顶层必须是 type: "object"），还有 fallback profile 机制（主模型失败自动切备用模型），但模型能力差异是框架层解决不了的。实际生产里常见的做法是按任务复杂度做路由，简单任务走便宜的小模型，复杂任务走旗舰模型。

提问：OpenClaw 的记忆系统是怎么做语义搜索的？纯向量检索还是有别的方案？

回答：不是纯向量检索，用的混合搜索策略，BM25 关键词匹配加向量余弦相似度一起跑，实现在 QmdMemoryManager 里。这样既能精确匹配关键词，又能捕捉语义相关性。搜”投资目标”也能命中”财务目标”这种同义表达。还支持 CJK 分词处理中日韩文本，有时间衰减机制（Temporal Decay）让旧记忆相关性自动降低，还有 MMR（最大边际相关性）做多样性重排。对外暴露两个工具：memory_search 做语义召回返回摘要片段，memory_get 按路径和行号读取完整内容。记忆数据默认存在本地，不出设备，这也是 OpenClaw 隐私优先设计的一部分。

提问：Gateway 和 Agent Loop 哪个更重要？OpenClaw 的核心竞争力到底在哪？

回答：Agent Loop + Tools 是 ReAct 范式的标准实现，Claude Code 和 Codex 都有，这不是 OpenClaw 独有的。Gateway 才是 OpenClaw 真正的护城河。没有 Gateway，Agent Loop 只能在终端里跑一次性对话；有了 Gateway，它就变成了一个 7×24 常驻运行、能接入 15+ 聊天平台、支持定时任务和主动巡检的 AI 基础设施。
具体来说，Gateway 做了六件 Agent Loop 做不到的事：常驻在线（守护进程 + 崩溃自动拉起 + 上下文恢复）、多平台接入、会话隔离、排队控制、心跳巡检、Cron 定时调度。