乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > OpenClaw 的工作原理:通过真实架构理解 AI 智能体

OpenClaw 的工作原理:通过真实架构理解 AI 智能体

当前时间： 2026-03-19 11:08:53 分类：办公文件 评论(0)
OpenClaw 的工作原理:通过真实架构理解 AI 智能体

OpenClaw 是一个开源的个人 AI 智能体，在 2026 年初迅速获得了超过 10 万的 GitHub 星标。通过观察它的构建方式，包括其网关、智能体循环、技能、MCP 和记忆系统，我们可以学习到驱动当今每一个严肃 AI 智能体的核心概念。

你可能已经在 X、Reddit 或 Hacker News 上看到过它。OpenClaw（前身为 Clawdbot，然后是 Moltbot）是目前讨论度最高的开源 AI 项目之一，原因显而易见。

它在你本地机器上运行，连接到 WhatsApp、Telegram 和 Slack 等消息应用，并能代表你执行实际操作：读写文件、运行 Shell 命令、发送电子邮件、浏览网页、管理你的日历。用户报告称，让它完全代表自己处理谈判、保险纠纷和安排任务。

人们称它为"有手的 Claude"。这是一种有趣的描述方式。但从工程角度来看，这里到底发生了什么？

这就是本文要讲的内容。与其再写一篇安装指南，我想把 OpenClaw 作为一个教学工具。它的架构是一个清晰的开源实现，体现了当今驱动每个严肃 AI 智能体的精确模式：智能体循环、工具使用、上下文注入和持久化记忆。一旦你理解了 OpenClaw 的工作原理，你就能理解智能体的一般工作方式。

让我们一层一层地分析。

OpenClaw 到底是什么
在深入架构之前，先搞清楚 OpenClaw 是什么、不是什么，会很有帮助。

OpenClaw 不是一个聊天机器人。它是一个在你机器（或 VPS）上运行的本地网关进程。该网关连接到你已使用的消息平台，并将每一条传入的消息通过一个由大语言模型驱动的智能体进行路由。智能体可以用文本回复，但更重要的是，它也能在现实世界中采取行动。

你需要自带想要使用的任何模型的 API 密钥：Claude、GPT、Gemini，或者通过 Ollama 运行的完全本地模型。OpenClaw 与模型无关。

乍一看，它像一个智能的消息助手。在底层，它是一个用于 AI 智能体的本地编排平台。这个区别正是我们将要深入探讨的。

网关：控制平面
OpenClaw 中的所有一切都流经一个称为网关的单一进程。官方文档将其描述为会话、路由和频道连接的"单一可信来源"。可以把它想象成整个系统的神经系统。

网关通常作为一个长期运行的后台进程运行（在 Linux 上通常通过 systemd，在 macOS 上通过 LaunchAgent）。客户端通过 WebSocket 连接到配置的绑定主机，默认为 ws://127.0.0.1:18789。

这是高层架构的样子：

网关架构
网关处理路由、连接、认证和会话管理。智能体运行时处理推理和执行。这种关注点分离是刻意的，也很重要。

这是第一个值得内化的架构概念：一个真正的 AI 智能体部署总是在模型之前有一个编排层。你不会将原始的 LLM API 调用直接暴露给用户输入。你会在中间放一个受控的进程来处理路由、排队和状态管理。OpenClaw 使这种模式具体化且易于理解。

第 1 步：标准化输入（频道适配器）
当你向 OpenClaw 发送 WhatsApp 消息时，首先发生的事情是频道适配器将其标准化。

OpenClaw 支持十多个频道。频道集成使用适配器库（例如，常见设置中的 WhatsApp 的 Baileys 和 Telegram 的 grammY），并为 Slack、Discord、Signal、iMessage 和 WebChat 提供类似的适配器。每种协议都使用不同的协议，并以不同的格式传递消息。来自 WhatsApp 的语音笔记看起来与来自 Slack 的文本消息完全不同。

频道适配器将所有这一切转换为一个单一的、一致的消息对象，其中包含发送者、正文、任何附件和频道元数据。如果你发送语音笔记，它会在到达模型之前被转录为文本。

这是你在每个生产级 AI 管道中都会看到的模式：在模型看到输入之前，先对其进行标准化。你传递给 LLM 的上下文就是一切。混乱或不一致的输入会产生混乱的输出。

第 2 步：路由和会话
一旦网关有了标准化的消息，它需要决定由哪个智能体处理它，以及它属于哪个对话会话。

OpenClaw 支持多智能体路由。你可以为不同的频道、联系人或群组配置不同的智能体。一个智能体可能用随意的语气处理个人私信，并可访问你的日历。另一个智能体可能用更正式的风格管理团队支持频道，并可访问产品文档。所有这些都通过一个单一的网关进程运行。

每个智能体维护自己的会话：一个持续对话的状态化表示。会话有 ID，它们跟踪历史，并序列化执行。最后一部分值得注意。

OpenClaw 在一个会话中一次处理一条消息，而不是并行处理。这是由命令队列处理的，文档明确说明了原因：按会话通道序列化可以防止工具冲突，并保持会话历史一致。如果来自同一会话的两条消息同时运行，它们可能会破坏状态或产生冲突的工具输出。

这是一个真实的工程教训。当智能体共享状态时，并发是危险的。按会话序列化执行是一个刻意的设计选择，而不是限制。

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

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

让我们逐一分析每个部分。

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

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

  • 技能提示：一个紧凑的合格技能列表（名称、描述、路径），告诉模型有哪些技能可用

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

  • 每次运行的覆盖：为特定运行注入的任何附加指令

模型没有眼睛。它只能处理你放入其上下文窗口的内容。上下文组装不是你可以跳过的预处理步骤。它可以说是任何智能体系统中最关键的工程决策。模型所知、所信、所能为的一切都流经这个阶段。

模型推理
组装好的上下文作为标准的 API 调用发送给你配置的提供商（Anthropic、OpenAI、Google、Ollama 等）。OpenClaw 在这里处理几个重要的细节：强制执行特定模型的上下文限制，并保持一个压缩预留（为模型的响应保留的令牌缓冲区），这样模型就永远不会没有空间来回复。

工具执行：智能体如何获得"手"
这里变得有趣了。当 LLM 响应时，它会做两件事之一：

  • 生成文本回复（此轮结束）

  • 请求工具调用

工具调用是指模型以结构化格式输出类似这样的内容："我想用这些特定的参数运行这个特定的工具。"可以把它想象成模型在说"我需要读取这个文件"或"我需要搜索网络"或"我需要发送这封邮件"。

OpenClaw 的智能体运行时拦截该请求，执行工具，捕获结果，并将其作为新消息反馈回对话中。模型看到结果并决定下一步做什么，这可能意味着调用另一个工具或最终写出回复。

这个循环被称为 ReAct 循环（Reason + Act 的缩写）。它是智能体 AI 的定义模式，也是将智能体与聊天机器人区分开来的东西。

以下是代码中简化版本的样子：

python

whileTrue:    response = llm.call(context)if response.is_text():        send_reply(response.text)breakif response.is_tool_call():        result = execute_tool(response.tool_name, response.tool_params)        context.add_message("tool_result", result)# 循环继续

OpenClaw 实现了相同的循环模式，实时将部分响应流式传回给你。你可以观察工具被调用，看到结果返回，并观察模型在回复之前对其进行推理。

第 4 步：技能（按需指令加载）
技能是 OpenClaw 中最优雅的特性之一，它们也清晰地展示了一种真正的提示工程技术。

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

以下是技能文件简化后的示例：

markdown

---name: github-pr-reviewerdescription: 审查 GitHub 拉取请求并发布反馈---# GitHub 拉取请求审查员当被要求审查拉取请求时：1. 使用 web_fetch 工具从 GitHub URL 检索 PR diff2. 分析 diff 的正确性、安全问题和代码风格3. 将你的审查结构化为：摘要、发现的问题、建议4. 如果被要求发布审查，使用 GitHub API 工具提交始终保持建设性。将阻塞性问题与建议分开标记。

现在，这里有一个容易出错的部分。OpenClaw 并不会将每个技能的完整文本注入系统提示。相反，上下文组装步骤注入一个紧凑的合格技能列表，基本上只有它们的名称、描述和文件路径。模型阅读这个列表，当它决定某个特定技能与当前任务相关时，它会按需读取该技能的 SKILL.md。

这是一个重要的架构区别。模型不是被动地接收指令。它主动决定查阅哪些技能，并根据需要加载它们。上下文窗口是有限的，这种设计使得无论安装了多少技能，基础提示都能保持精简。

技能可以从 OpenClaw 的社区仓库 ClawHub 安装，也可以从头编写。值得注意的一点是：Cisco 的研究人员警告说，社区技能可能导致静默数据泄露和提示注入类滥用。Snyk 的安全审计扫描了数千个社区技能，发现有相当一部分存在严重问题，包括提示注入、恶意软件和凭证窃取。在安装技能之前，尤其是那些与敏感工具（如电子邮件或浏览器自动化）交互的技能，务必先进行审查。

第 5 步：MCP（集成外部工具）
如果你读过我之前关于 MCP 的文章，你会认出这里发生了什么。

一些 OpenClaw 部署集成了 MCP 服务器作为标准化的工具层，将智能体连接到外部服务，如 Google 日历、Notion、Home Assistant 或自定义 API。项目中原生的 MCP 支持正在积极发展中，社区适配器如今已经使其成为可能。

基本思路很简单。无需硬编码每一个外部集成，MCP 服务器暴露一组具有定义模式（schema）的工具。智能体发现有哪些工具可用，使用标准请求格式调用它们，并收到结构化的结果返回。

MCP 工具层
智能体从不直接接触底层服务。它调用一个标准接口，MCP 服务器处理其余部分。这带来了工具的可移植性：为一个兼容 MCP 的智能体构建的工具可以在其他使用相同协议的系统上重用。

第 6 步：记忆
问任何一位 AI 工程师，智能体系统中最困难的问题是什么，记忆肯定会排在前列。LLM 本质上是无状态的。每一个新的对话都从白板开始。那么，你如何构建一个能记住你的偏好、进行中的项目以及沟通风格，并且能跨越数天和数周的智能体呢？

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

记忆存在于智能体工作区内的纯文本 Markdown 文件中，默认位置是 ~/.openclaw/workspace。OpenClaw 的配置和状态（凭证、会话、日志、已安装的技能）位于 ~/.openclaw/ 下。

text

~/.openclaw/workspace/+-- AGENTS.md         <-- 智能体配置和指令+-- SOUL.md           <-- 个性、偏好、语气+-- MEMORY.md         <-- 长期事实和摘要+-- HEARTBEAT.md      <-- 主动任务检查清单+-- memory/    +-- 2026-02-15.md <-- 每日临时日志    +-- 2026-02-16.md <-- 每日临时日志

每日日志（memory/YYYY-MM-DD.md）是持久的、只可追加的文件，记录每天发生的事情。重要的是，这些日志不会在每个轮次自动注入上下文。智能体通过记忆工具按需检索它们，仅在它们与当前任务相关时才这样做。这使得日常对话保持精简，避免了不必要的上下文膨胀。

MEMORY.md 存储智能体了解到的关于你的长期事实，比如"用户偏好简洁回复"、"用户的技术栈是 Next.js 和 Supabase"或"永远不要在周五安排会议"。

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

当加载所有这些历史记录会超出上下文窗口时，OpenClaw 会运行一个压缩过程。它将较旧的对话轮次总结为压缩条目，在减少令牌数量的同时保留语义内容。这是对基于 LLM 的系统中长上下文问题的一个实用解决方案。

对于记忆检索，OpenClaw 支持基于嵌入的搜索，可选择由 sqlite-vec SQLite 扩展加速。根据配置，一些部署将其与基于关键字的搜索结合使用，为你提供概念匹配和精确令牌匹配。

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

第 7 步：心跳（主动智能体行为）
OpenClaw 更有趣的一点是，它不仅仅坐着等待你给它发消息。它运行一个心跳：一个默认每 30 分钟触发一次的定时触发器。

每次心跳时，智能体读取 HEARTBEAT.md，这是一个它应该主动检查的任务清单。它判断现在是否有任何需要关注的事情。如果有，它就采取行动，并可能向你发送一条消息。如果无事可做，它回复 HEARTBEAT_OK，网关会抑制此回复，不会发送给你。

这就是让 OpenClaw 感觉积极主动而非被动响应的模式。其架构概念是一个由 cron 触发的智能体循环：智能体不是只对人类输入做出响应，而是定期被唤醒并评估其任务列表。你可以用它向自己发送每日简报，监控网站变化，或者在你自己注意到之前就发现日历冲突。

整合所有部分
以下是单条消息流经 OpenClaw 的完整画面：

完整消息流

这能教你关于智能体的一般知识
大多数现代智能体框架在它们不同的 API 和抽象之下，共享相同的核心模式。观察 OpenClaw，你可以清楚地看到它们：

  • 一个处理路由和会话管理的网关或编排层

  • 一个在推理前打包历史、记忆和指令的上下文组装步骤

  • 一个模型进行推理、调用工具并整合结果的 ReAct 循环

  • 一个赋予智能体现实世界能力的工具层

  • 一个赋予智能体领域特定专业知识、按需加载的技能或提示系统

  • 一个提供跨会话连续性的记忆系统

  • 一个实现主动行为的调度机制

OpenClaw 并非因为使用这些模式而独特。它的价值在于使这些模式变得具体、基于文件且易于理解。你可以打开 SOUL.md，确切地看到智能体遵循什么指令。你可以阅读任何 SKILL.md，准确理解一项能力是如何添加的。你可以检查 MEMORY.md，审计智能体了解到的关于你的一切信息。

这种透明度既是其最大的工程优点，也是其最大的安全攻击面。一个能访问你的文件、浏览器、电子邮件和消息应用的智能体是强大的。一个恶意的技能或通过智能体访问的网页进行的提示注入攻击，理论上可能危及所有这一切。在将你的网关暴露给网络之前，务必运行安全审计工具，并在安装每个第三方技能之前进行审查。

开始使用
如果你想亲自尝试：

bash

# 全局安装（需要 Node.js 22+）npminstall-g openclaw@latest# 运行引导式入门向导openclaw onboard --install-daemon# 在暴露任何东西之前运行安全审计openclaw security audit --deep

入门向导会引导你完成网关设置、频道配置和技能安装。命令可能随着版本发布而演变，如果发现任何不对的地方，请查看 docs.openclaw.ai 上的官方 CLI 文档。

最后的想法
OpenClaw 在 2026 年初成为 GitHub 上增长最快的仓库之一。开发者社区不仅仅是在认可一个有用的工具。他们是在认可一种架构模式。本地网关 + 智能体循环 + 技能 + 持久化记忆模型将在很长一段时间内成为个人 AI 智能体的蓝图。

如果你曾经想了解 AI 智能体在底层是如何工作的，OpenClaw 是你所能研究的最佳真实世界范例之一。代码采用 MIT 许可，架构清晰易读，它所实现的概念与严肃的 AI 公司生产级智能体系统所使用的概念相同。

去阅读源码吧。打开一个 SKILL.md。编辑你的 SOUL.md。去尝试，去"破坏"。这才是你真正学习的方式。

参考资料：

  • OpenClaw GitHub：https：//github.com/openclaw/openclaw

  • OpenClaw 文档：https：//docs.openclaw.ai

  • 智能体循环：https：//docs.openclaw.ai/concepts/agent-loop

  • 网关架构：https：//docs.openclaw.ai/concepts/architecture

  • 记忆：https：//docs.openclaw.ai/concepts/memory