Openclaw技术解析

Created time

Apr 6, 2026 05:15 AM

OpenClaw 的本质是什么

在深入架构之前，先把 OpenClaw 是什么、不是什么说清楚。

OpenClaw 不是聊天机器人。它是一个运行在你的机器（或 VPS）上的本地网关进程。这个网关连接到你已经在用的消息平台，把每一条传入消息路由给一个由 LLM 驱动的智能体。智能体不只是回复文字——更重要的是，它能在现实世界中采取实际行动。

你可以接入任何你想用的模型的 API Key：Claude、GPT、Gemini，或者通过 Ollama 运行的完全本地化模型。OpenClaw 与模型无关。

乍一看它像个智能消息助手，底层其实是一个用于 AI 智能体的本地编排平台。这个区别，正是我们接下来要拆解的核心。

网关：系统的控制平面

OpenClaw 中的一切都流经一个叫做 Gateway（网关） 的单一进程。官方文档将其描述为会话、路由和通道连接的"单一事实来源"——可以把它理解为整个系统的神经中枢。

网关通常以长期运行的后台进程形式存在（Linux 上通过 systemd，macOS 上通过 LaunchAgent）。客户端通过 WebSocket 连接到配置的绑定地址，默认为 ws://127.0.0.1:18789。

整体高层架构如下：

网关负责路由、连接、身份验证和会话管理；Agent Runtime（智能体运行时）负责推理和执行。这种关注点分离是有意为之的，也至关重要。

这是第一个值得深刻理解的架构概念：真正的 AI 智能体部署，始终在模型前端设有一个编排层。 你不能把原始的 LLM API 调用直接暴露给用户输入，而是在中间放一个受控进程来处理路由、排队和状态管理。OpenClaw 让这种模式变得具体可读。

第一步：标准化输入（通道适配器）

当你向 OpenClaw 发送一条 WhatsApp 消息时，第一件发生的事就是通道适配器（Channel Adapter） 对它进行标准化处理。

OpenClaw 支持十余种通道，使用各类适配器库（例如 WhatsApp 用 Baileys，Telegram 用 grammY），Slack、Discord、Signal、iMessage 和 WebChat 也有对应的适配器。这些平台各自使用不同协议，消息格式也大相径庭。来自 WhatsApp 的语音消息和来自 Slack 的文字消息，结构上完全不同。

通道适配器会把所有这些内容转换成一个统一的消息对象，包含发送者、正文、附件和通道元数据。如果你发送的是语音消息，它会在到达模型之前先被转录成文字。

这是所有生产级 AI Pipeline 都会用到的模式：在模型处理之前，先对输入进行标准化。 传给 LLM 的上下文就是一切——输入混乱，输出自然混乱。

第二步：路由与会话管理

网关拿到标准化消息后，需要决定两件事：由哪个智能体来处理，以及它属于哪个对话会话。

OpenClaw 支持多智能体路由。你可以为不同的渠道、联系人或群组配置不同的智能体：一个负责语气随意、能访问日历的个人私信，另一个负责风格正式、接入产品文档的团队支持频道——所有这些都跑在同一个网关进程里。

每个智能体维护自己的会话（Session），即对正在进行的对话的有状态表示。会话有 ID、跟踪历史记录，并对执行过程进行序列化处理。最后这一点值得特别关注。

OpenClaw 对同一会话中的消息逐条串行处理，而非并行。这由命令队列（Command Queue）负责实现，官方文档也明确说明了原因：按会话串行化可以防止工具冲突，保持会话历史的一致性。如果同一会话的两条消息同时跑，可能会破坏状态或产生相互冲突的工具输出。

这是一条真实的工程经验：智能体共享状态时，并发是危险的。 按会话串行执行是深思熟虑的设计选择，而不是局限。

第三步：智能体循环（Agentic Loop）

这是 OpenClaw 的核心，也是所有 AI 智能体背后的核心概念。官方文档是这样描述的：

智能体循环是智能体的完整运行过程：接收输入 → 组装上下文 → 模型推理 → 工具执行 → 流式回复 → 持久化。

让我们逐一拆解。

上下文组装

在模型看到你的消息之前，智能体运行时会先组装一个上下文包。根据文档，系统提示词由以下四部分构建：

OpenClaw 基础提示词：智能体始终遵循的核心指令

技能提示词：一份精简的可用技能列表（名称、描述、路径），告知模型当前有哪些技能可用

引导上下文文件：提供环境级上下文的工作区文件

单次运行覆盖项：为特定任务注入的额外指令

模型没有眼睛，它只能处理你放进上下文窗口里的内容。上下文组装不是一个可以略过的预处理步骤，它可能是整个智能体系统中最重要的工程决策。 模型所知、所信、所能做的一切，都流经这一阶段。

模型推理

组装好的上下文会作为标准 API 调用发送给你配置的提供商（Anthropic、OpenAI、Google、Ollama 等）。OpenClaw 在这里处理几个重要细节：强制执行模型特定的上下文长度限制，并维护一个压缩预留（Compaction Reserve）——即为模型回复预留的 token 缓冲区，确保模型始终有足够空间输出响应。

工具执行：智能体的"手"

有趣的部分来了。LLM 响应时，只会做两件事之一：

输出文字回复（本轮结束）

请求工具调用

工具调用是指模型以结构化格式输出类似这样的内容："我想用这些参数运行这个工具。"可以理解为模型在说：「我需要读这个文件」「我需要搜索网络」「我需要发这封邮件」。

OpenClaw 的智能体运行时会拦截该请求、执行工具、捕获结果，并将其作为新消息反馈回对话。模型看到结果后再决定下一步——可能继续调用工具，也可能最终给出回复。

这个循环叫做 ReAct 循环（Reason + Act 的缩写）。它是智能体 AI 的核心定义模式，也是智能体与聊天机器人的本质区别。

代码层面的简化版本大概是这样的：

OpenClaw 实现了同样的循环模式，并将部分响应实时流式传输给你——你可以亲眼看到工具被调用、结果返回，以及模型在给出回复前对这些信息进行推理的全过程。

第四步：技能（按需加载指令）

技能是 OpenClaw 最优雅的功能之一，也是一个真实提示词工程技巧的清晰示范。

技能（Skill） 是一个包含 SKILL.md 文件的文件夹。这个 Markdown 文件里有自然语言指令、示例，有时还有工具配置，告诉智能体如何处理特定领域——比如管理 GitHub 仓库、审查 PR，或与某个特定 API 交互。

一个技能文件的简化示例大概是这样的：

这里有个容易搞错的关键点：OpenClaw 并不会把所有技能的全文都注入到系统提示词里。 上下文组装阶段只会注入一份精简的技能列表，本质上就是名称、描述和文件路径。模型读取这份列表后，当它判断某个技能与当前任务相关时，才会按需加载那个 SKILL.md 的全文内容。

这是一个重要的架构区分：模型不是在被动接收指令，而是主动决定去查阅哪些技能并按需加载。上下文窗口是有限资源，这种设计让基础提示词始终保持精简，无论安装了多少技能。

技能可以从 OpenClaw 的社区注册中心 ClawHub 安装，也可以自己从头编写。需要注意的是：Cisco 研究人员曾警告，社区技能可能导致静默数据泄露和提示词注入式滥用。Snyk 安全审计在扫描数千个社区技能后发现，其中有相当一部分存在严重问题，包括提示词注入、恶意软件和凭据窃取。安装任何技能前请务必审查，尤其是会接触邮件或浏览器自动化等敏感工具的技能。

第五步：MCP（集成外部工具）

如果你读过关于 MCP（模型上下文协议）的文章，这部分会很熟悉。

一些 OpenClaw 部署会将 MCP 服务器 作为标准化工具层接入，将智能体连接到 Google 日历、Notion、Home Assistant 或自定义 API 等外部服务。项目对 MCP 的原生支持正在积极演进，社区适配器目前已经可以使用。

基本思路很直接：与其把每个外部集成都硬编码进去，不如让 MCP 服务器通过定义好的 Schema 暴露一组工具。智能体发现哪些工具可用，用标准请求格式调用它们，再接收结构化的返回结果。

智能体永远不直接接触底层服务，它只调用标准接口，MCP 服务器处理其余的一切。这带来了工具可移植性：为某个兼容 MCP 的智能体构建的工具，可以复用于其他说同一种协议的系统。

第六步：记忆系统

问任何一位 AI 工程师，智能体系统中最难解决的问题是什么——记忆，一定名列前茅。LLM 本质上是无状态的，每段新对话都从一张白纸开始。那么，如何让智能体跨越数天乃至数周，记住你的偏好、正在进行的项目和沟通风格？

OpenClaw 的答案刻意保持简单，我认为这是整个项目最好的设计决策之一。

记忆存储在纯 Markdown 文件里，位于智能体工作区，默认路径为 ~/.openclaw/workspace。OpenClaw 的配置与状态（凭据、会话、日志、已安装的技能）存储在 ~/.openclaw/ 下。

每日日志（memory/YYYY-MM-DD.md）是持久的、只能追加的文件，记录每天发生的事情。重要的是，这些内容不会在每轮对话中自动注入到上下文，而是由智能体在需要时通过记忆工具按需检索。这让日常对话保持轻量，避免不必要的上下文膨胀。

MEMORY.md 存储智能体从你这里了解到的长期事实：比如"用户偏好简洁的回复"、"用户的技术栈是 Next.js 和 Supabase"、"周五不安排会议"。

SOUL.md 定义智能体的个性、名字和沟通风格，让它感觉像是你的专属助手，而不是一个通用机器人。

当加载所有历史记录即将超出上下文窗口时，OpenClaw 会运行压缩（Compaction）流程：将较早的对话轮次总结成压缩条目，在保留语义的同时减少 token 占用。这是解决 LLM 长上下文问题的一种实用方案。

在记忆检索方面，OpenClaw 支持基于嵌入（Embedding）的语义搜索，可选择通过 sqlite-vec SQLite 扩展加速。部分部署方案会同时结合关键字搜索，兼顾语义匹配和精确 token 匹配。

没有外部数据库，没有 Redis，没有 Pinecone。只有 SQLite 和 Markdown 文件。 这很好地提醒了我们：在工程中，能真正解决问题的最简单方案，通常就是最好的方案。

第七步：心跳（主动行为机制）

OpenClaw 有一个有趣的地方：它不只是坐等你的消息。它会运行一个心跳（Heartbeat）——一个默认每 30 分钟触发一次的定时任务。

每次心跳触发时，智能体会读取 HEARTBEAT.md，这是一份它需要主动检查的任务清单。它判断当前是否有事项需要处理：如果有，就采取行动并可能给你发消息；如果没有，就回复 HEARTBEAT_OK，网关会将其拦截，不会推送给你。

这正是让 OpenClaw 显得主动而非被动的模式。其架构概念是基于 cron 触发的智能体循环：智能体不再只响应人类输入，而是被定期唤醒，主动评估自己的任务列表。你可以用它来给自己发送每日简报、监控某个网站的变化，或者在你自己注意到之前就发现日程冲突。

全貌：一条消息在 OpenClaw 中的完整旅程

这对理解通用智能体意味着什么

大多数现代智能体框架，在不同的 API 和抽象之下，共享着相同的核心模式。通过观察 OpenClaw，这些模式清晰可见：