Star数超越Linux！拆解OpenClaw的5层架构，看懂AI Agent的"操作系统"

发表于 更新于 分类于 阅读次数： 本文字数： 4.6k 阅读时长 ≈ 4 分钟

cover

React 用了 13 年积累 24 万 Star。Linux 内核用了 40 年。OpenClaw 只用了 3 个月。

很多人把 OpenClaw 的爆火归结为”赶上了风口”或者”龙虾 meme 太魔性”。但如果你去翻它的代码仓库——43 万行 TypeScript，40+ 消息平台集成，54 个内置技能，完整的事件驱动架构——你会发现，这东西绝不是一个”套壳聊天机器人”。

黄仁勋在 GTC 2026 上说它是”个人 AI 的操作系统”。这话并不夸张。

今天我们不聊怎么用 OpenClaw，聊一个更底层的问题：它的架构凭什么能撑住 24 万 Star 的期待？

先看全貌：5 个组件，各司其职

OpenClaw 的架构可以用一句话概括：Gateway 负责接入，Brain 负责思考，Skills 负责执行，Memory 负责记忆，Heartbeat 负责调度。

用一个比喻来理解：把 OpenClaw 想象成一个机场。

  • Gateway（塔台）：所有航班（消息）都经过这个中央调度中心，由它分配到正确的跑道
  • Brain（飞行员）：接到指令后，决定怎么飞、走哪条航线
  • Skills（机械臂）：在地面上真正搬运行李、加油、检修的执行单元
  • Memory（黑匣子）：记录所有飞行数据，下次起飞时作为参考
  • Heartbeat（值班表）：按时间表触发定时任务，比如凌晨 3 点自动检查航班状态

这 5 个组件的职责完全隔离。换消息平台不影响 Agent 逻辑，换大模型不影响消息路由，换工具不影响记忆系统。这种分层设计，是 OpenClaw 能从一个”周末项目”长成”操作系统”的根本原因。

第一层：Gateway——“只做路由，不做推理”

Gateway 是 OpenClaw 最核心的设计决策。

它是一个长期运行的 WebSocket 服务器，默认跑在 localhost:18789。所有消息——不管来自 WhatsApp、Telegram、Discord、钉钉还是飞书——都先经过 Gateway。

关键原则：Gateway 不做任何推理。 它只做三件事：

  1. 消息标准化：把不同平台的消息格式统一。Telegram 的 Markdown、Slack 的 Block Kit、WhatsApp 的富文本，全部转换成 OpenClaw 内部格式。
  2. 路由分发：根据 6 级优先级匹配规则，把消息分发给对应的 Agent。
  3. 安全拦截：在消息进入 Agent 之前，先过 Allowlist 白名单、Mention Gating、Command Gating 等多层访问控制。

为什么这个设计这么重要？

因为它实现了接入层和智能层的完全解耦。你在 Slack 里讨论工作、在 Telegram 里安排日程、在 WhatsApp 里聊个人事务——这些消息经过 Gateway 标准化后，Agent 看到的是统一格式。它不需要知道消息来自哪个平台。

反过来，如果你要接入一个新平台（比如飞书），只需要写一个 Channel 适配器插件，不用动 Agent 的任何代码。目前 OpenClaw 已经有 40+ 个 Channel 适配器，部分以插件形式存在，保持核心代码精简。

消息进入 Gateway 后的完整路径：

1
2
3
4
消息到达 → 频道元数据解析 → 路由匹配（6级优先级）
→ 访问控制检查 → 会话创建/激活
→ 消息入队（双车道：会话级串行 + 全局并发控制）
→ Agent 执行 → 响应格式转换 → 分块发送 → 会话持久化

这里有一个精妙的细节：双车道队列。sessionLane 保证同一会话内的消息严格串行处理（防止并发导致的上下文混乱），globalLane 控制全局并发数（防止多个会话同时跑爆资源）。

第二层：Brain——ReAct 循环，让 AI “会做事”

Brain 是 OpenClaw 区别于所有”套壳聊天机器人”的核心。

传统的 AI 聊天应用，处理逻辑是线性的：用户问 → 模型答 → 结束。OpenClaw 的 Brain 基于 ReAct（Reasoning + Acting）循环：

1
思考（Thought）→ 行动（Action）→ 观察（Observation）→ 思考 → 行动 → ...

每次 LLM 生成响应后，系统都会问一个关键问题：**”这个响应包含工具调用吗？”**

如果包含，就暂停输出，执行工具，把结果注入上下文，然后让 LLM 继续生成。这个循环一直持续到 LLM 生成一个”不包含工具调用”的最终响应。

举个例子：你说”帮我查一下明天北京的天气，然后加到日历里”。

  1. 思考：用户想查天气并添加日历事件
  2. 行动：调用天气 API 查询北京明天的天气
  3. 观察：明天北京晴，15-25°C
  4. 思考：天气信息拿到了，接下来添加日历事件
  5. 行动：调用日历 API 创建”明天北京，晴，15-25°C”的备注
  6. 观察：日历事件创建成功
  7. 最终响应：”明天北京晴，15-25°C，已经帮你加到日历里了。”

整个过程对用户来说是一条消息、一个回复。但背后经历了多轮”思考-行动-观察”的循环。

这就是 Agent 和 Chatbot 的本质区别——Chatbot 只有”思考”，Agent 有”思考+行动+观察”的完整闭环。

Brain 的底层引擎叫 Pi，一个通用的 Agent 执行运行时。它的设计哲学极度克制：

  • 事件驱动：系统内部的所有行为——模型推理、工具调用、人工介入——都通过统一的事件流推进。没有”偷偷发生”的动作。
  • 流式输出：支持块流式和增量流式，用户能实时看到 AI 在”思考什么”。
  • 故障容错：24×7 运行意味着不能因为一次异常就崩溃。完整的重试、超时、终止机制。

一个让人惊讶的数字：OpenClaw 的核心系统提示词只有约 1000 个 Token。包含工具定义、安全护栏、CLI 参考在内，总共 1000 Token。这证明了当大模型足够强时，不需要冗长的指令就能理解 Agent 上下文。

第三层：Skills——“用 Markdown 写接口”

这可能是 OpenClaw 最具创新性的设计。

传统的插件系统需要严格的 OpenAPI/Swagger 模式定义。写一个插件，你得定义 JSON Schema、参数类型、返回格式……光配置文件就上百行。

OpenClaw 的 Skills 用 Markdown 文件作为接口描述语言。

一个 Skill 就是一个 SKILL.md 文件，用自然语言告诉 Agent：这个工具是做什么的、什么时候该用、怎么用、有什么限制。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
---
name: weather-check
description: 查询指定城市的天气信息
---

# 天气查询

当用户询问天气信息时使用此技能。

## 使用方法
调用 weather API，参数为城市名称。

## 限制
- 只支持中国城市
- 数据延迟约 30 分钟

为什么用 Markdown 而不是 JSON Schema？

因为 LLM 本身就是一个概率性的自然语言处理器，不是确定性的逻辑编译器。用自然语言描述工具，比用结构化模式描述工具，对 LLM 更友好。 模型能更准确地理解”什么时候该调用这个工具”。

这个设计带来了一个巨大的副作用：任何人都能写 Skill。你不需要是程序员，不需要懂 API 设计。写一个 Markdown 文件，描述清楚”这个工具做什么、怎么用”，就能扩展 OpenClaw 的能力。

这就是为什么 OpenClaw 的社区能在短短几个月内贡献 5400+ 个 Skills。

更高级的玩法是 Skill 自我生成。OpenClaw 有一个内置的 skill-creator 工具，Agent 可以在运行过程中自主发现需求、生成新 Skill。你让它做一件它不会的事，它会自己写一个 Skill 来学会。

第四层：Memory——三级记忆，”越用越懂你”

传统 AI 助手最大的痛点是”健忘”。每次新对话都要从头介绍自己。OpenClaw 的记忆系统分三层：

短期记忆：对话上下文

就是当前会话的聊天记录。OpenClaw 有完整的上下文管理机制：当上下文接近模型的 Token 上限时，会触发自动压缩——先把关键信息写入长期记忆文件，再精简上下文窗口。

中期记忆：会话摘要

每个会话结束或中断时，Agent 会自动生成一份摘要，保存为 Markdown 文件。下次回来时，它能快速回忆”上次聊到哪了”。

长期记忆：向量化知识库

这是最精妙的部分。OpenClaw 把工作空间里的所有 Markdown 文件——你的笔记、偏好设置、历史摘要——切分成约 400 Token 的块，生成向量嵌入，存入 SQLite 数据库。

查询时同时使用两种匹配：

  • 向量相似度：语义匹配，”Mac Studio 网关主机”能匹配到”运行 Gateway 的那台机器”
  • 关键词搜索：精确匹配，确保专有名词不丢失

所有记忆数据存在本地，不上传云端。你可以用 Git 管理、用文本编辑器查看、随时删除。记忆的所有权完全属于你。

OpenClaw 社区有句话叫”记忆是神圣的”。Meta 超级智能实验室的对齐方向负责人 Summer Yue 实测发现，当上下文膨胀到数千条消息时，如果记忆管理不当，会导致严重的”遗忘”问题。正确的做法是定期整理——让 Agent 把重要信息固化到长期记忆文件中，而不是全靠上下文窗口硬扛。

第五层：Heartbeat——让 Agent”主动做事”

Heartbeat 是 OpenClaw 区别于所有聊天机器人的最后一块拼图。

传统 AI 是”踹一脚它动一下”。你不说话，它就永远沉默。OpenClaw 的 Heartbeat 机制让 Agent 有了时间感——它知道现在几点了，知道该做什么了。

1
2
3
4
5
6
7
8
9
# 每天早上 7 点发送晨间简报
openclaw cron add --name "morning-brief" \
  --schedule "0 7 * * *" \
  --prompt "生成今日晨间简报"

# 每 30 分钟检查一次邮箱
openclaw cron add --name "email-check" \
  --schedule "*/30 * * * *" \
  --prompt "检查邮箱，有重要邮件就通知我"

定时任务存储在 ~/.openclaw/cron/jobs.json 中，Gateway 加载到内存并按计划执行。这让 OpenClaw 从一个”被动的问答工具”变成了一个”主动的数字员工”——早上给你发简报，下午提醒你开会，晚上帮你整理当天的笔记。

为什么这套架构能赢

回到最开始的问题：OpenClaw 的架构凭什么？

总结下来，3 个核心设计决策：

1. Gateway 与 Agent 的彻底分离。 这让它能在不改核心逻辑的情况下接入 40+ 平台。大多数 AI 项目把消息处理和推理逻辑混在一起，导致每接入一个新平台就要改一堆代码。OpenClaw 从第一天就把这两层拆开了。

2. 用 Markdown 替代 JSON Schema 做工具描述。 这让任何人都能贡献 Skill，5400+ 的社区生态就是证明。技术门槛越低，生态增长越快。

3. 把”时间”和”状态”当成输入。 不只处理用户发来的消息，还处理时间触发的事件和系统状态变化。这让 Agent 从”被动响应”变成了”主动服务”。

OpenClaw 的开发团队自己也承认，这个项目”仍处于极度早期阶段”。安全问题没完全解决，Token 消耗需要优化，很多边界情况还没覆盖。但它的架构方向是对的——一个分层的、可扩展的、事件驱动的 Agent 运行时。

这不是一个聊天机器人。这是 AI Agent 时代的基础设施。

理解了它的架构，你就理解了为什么黄仁勋说它是”个人 AI 的操作系统”——它不是一个应用，它是一个让无数应用能跑起来的平台。

你觉得 OpenClaw 的架构设计最打动你的是哪一点？如果让你来设计一个 AI Agent 框架，你会做出什么不同的选择？欢迎在评论区聊聊。