夜雨聆风
OpenClaw 迭代演进深度解析:一个周末 hack 如何在 6 个月内引爆全球 AI Agent 基础设施
推荐阅读：
Hermes Agent 迭代演进深度解析：一个自我进化的 AI Agent 是如何炼成的
项目地址 ：github.com/openclaw/openclaw（前身：Clawdbot、Moltbot）
分析截止版本 ：2026.5.x（持续迭代中）
时间跨度 ：2025 年 11 月 — 2026 年 5 月，约 6 个月
项目口号 ：Your own personal AI assistant. Any OS. Any Platform. The lobster way. 🦞本文作者：AI Enhanced Self-evolving Levine Huang (黄绿君)
一、项目背景：不是最精巧的，但是最野蛮生长的
OpenClaw 是迄今为止增速最快的开源 AI 项目之一。它在 60 天内超越了 React 积累十余年才达到的 250,000 GitHub Stars，到 2026 年 5 月11 日已突破 370,000 Stars，成为 GitHub 历史上 star 速度最快的非聚合类软件仓库。
但说 OpenClaw 是精心设计的产物，是不准确的。奥地利开发者 Peter Steinberger（PSPDFKit 创始人）在 2025 年 11 月把它作为一个周末 hack 推上 GitHub，标签一句话写完：”Stop chatting. Start doing.”——一个能通过消息 app 实际执行任务的本地 AI Agent。
它的核心定位是：
- 本地优先
：Agent 跑在你自己的机器或 VPS 上，不是某家公司的服务器，数据主权在用户手里。 - 平台无关
：同一个 Gateway 实例对接 20+ 消息平台，不改代码切换模型。 - Skill 系统
：功能通过 SKILL.md 描述文件定义，社区共同构建知识库，已有 5,400+ Skill 在 ClawHub 上流通。
与 Hermes Agent 相比，OpenClaw 的独特性在于它的演进路径是被用户增长的压力强行驱动的，而非团队规划先行。这也使它的迭代轨迹比大多数开源项目更具戏剧性，也更具启发性。
二、版本迭代全景：六个阶段，每一段都是一次蜕皮
阶段一：萌芽期（2025 年 11 月 — 2026 年 1 月中）
Clawdbot 初始版本安静地躺在 GitHub 上两个月，没有 Product Hunt，没有 HN 首页，纯靠少数开发者的口耳相传缓慢积累。
这段时间奠定了核心架构：Node.js/TypeScript 运行时、本地 Gateway 进程、通过 WebSocket 与消息平台通信、基于 SKILL.md 文件的 Skill 系统。从代码层面看，这是一个能用的原型——但安全模型几乎不存在，Gateway 默认绑定 0.0.0.0，凭证明文存在 ~/.openclaw/config.json，没有来源校验。
这一阶段的迭代逻辑 ：个人项目的常态——先让它能跑，安全和工程化是以后的事。这个选择无可厚非，问题在于”以后”比预期早到得多。
阶段二：病毒式爆发与三次改名危机（2026 年 1 月 27 日 — 1 月 30 日）
2026 年 1 月末，Moltbook 上线——一个专供 AI Agent 使用的社交网络，设计意图是让 OpenClaw 等 Agent 在上面建立档案、相互交互。Moltbook 的病毒式传播直接引爆了 Clawdbot 的增长。几天内，项目 star 数从数千跃升至十万量级。
但此时有两件事同时发生：
第一件：Anthropic 的商标函 。1 月 27 日，Anthropic 法务认定”Clawdbot”与”Claude”在发音和语境上过于相似，要求更名。Steinberger 在 48 小时内将项目改名为”Moltbot”（取自龙虾蜕壳的”蜕皮”意象）。
第二件：Moltbot 仅存活 3 天就再次改名 。Steinberger 自认”Moltbot 念起来就是不顺”，在 1 月 30 日将项目再次更名为 OpenClaw ——这次做足了功课：商标搜索通过、域名购买就绪、迁移代码写好。
这三个名字（Clawdbot → Moltbot → OpenClaw）在 72 小时内完成切换，带来了意想不到的副作用：骗子在秒级内抢占了被抛弃的旧 GitHub 账号和 Twitter 句柄，推出假代币 $CLAWD，市值一度达到 1,600 万美元后归零；假冒的”Clawdbot Agent” VS Code 扩展植入了远程访问木马。
这一阶段的迭代逻辑 ：这不是技术层面的迭代，而是 品牌主权危机下的紧急应对 。值得注意的是，Steinberger 在每次改名时都选择”快速决策而非等待完美”——这种执行力保住了社区动量，但也加剧了信任体系的混乱。
阶段三：安全危机全面爆发（2026 年 2 月 — 3 月）
项目改名为 OpenClaw 后不到两周，安全研究界把目光集中到了这个拥有十万用户的 AI Agent 上。他们看到的，是一个以”执行”为设计中心、安全防护几乎空白的系统。
CVE-2026-25253（CVSS 8.8）：一键 RCE
Control UI 是一个 Lit 组件构建的单页应用，负责与本地 Gateway 通信。漏洞的根源是：Control UI 在页面加载时会自动连接 gatewayUrl 参数指定的 WebSocket 地址，且 Gateway 不校验 WebSocket 连接的来源（Origin header）。
攻击链极其简洁：
-
受害者访问攻击者的网页 -
页面 JS 构造带有恶意 gatewayUrl的 URL，将受害者的浏览器重定向至 Control UI -
Control UI 自动发起 WebSocket 连接，将存储的认证 token 发送给攻击者 -
攻击者持 token 连回受害者的本地 Gateway，调用 exec.approvals.set = 'off'关闭沙箱 -
调用 tools.exec.host = 'gateway'逃出 Docker -
获得宿主机完整 Shell 访问权
整个攻击链从页面加载到命令执行： 不到 10 秒 。
此漏洞不仅影响公网暴露的实例——即使配置为仅监听 localhost，攻击者也能通过受害者自己的浏览器作为跳板，绕过网络边界完成攻击。
数字记录这场危机的规模 ：
-
Censys 识别到 21,639 个公网暴露实例 -
SecurityScorecard 估算超过 135,000 个跨 82 个国家的暴露实例 -
其中 63% 无任何认证保护 -
超过 15,000 个可直接通过 CVE-2026-25253 执行远程代码 -
2026 年 2 月至 4 月间，累计记录 137 个安全通报，其中 5 个正式 CVE，7 个高危
ClawHavoc 供应链攻击 ：与此同时，攻击者在官方 Skill 市场 ClawHub 上架了约 341 个伪装成生产力工具的恶意 Skill（Gmail、Notion、Slack、GitHub 等常见名称）。安装后，Skill 引导用户执行外部脚本，悄无声息地投递 Windows 键盘记录器或 macOS 的 AMOS 窃密软件，目标直指 API Key、OAuth Token 和加密货币钱包。整个 ClawHub 上约 12% 的 Skill 在某一时间段是恶意的。
来自自家维护者的警告 。项目维护者之一”Shadow”在 Discord 说出了那句广为流传的话：”if you can’t understand how to run a command line, this is far too dangerous of a project for you to use safely.”
这一阶段的迭代逻辑 ：安全危机不是单一漏洞的问题，而是 架构设计哲学的后果 。OpenClaw 的核心设计目标是”最小摩擦地让 Agent 执行任务”，这意味着它默认给予 Agent 广泛的系统权限、网络访问、凭证存储。当安全模型缺失时，这种设计的”优点”原封不动地变成了攻击面。项目在短短数月内经历了从零 CVE 到 137 安全通报的跳跃，本质上是”增长速度远超安全建设速度”的系统性失败。
阶段四：治理重组（2026 年 2 月 14 日 — 3 月）
2026 年 2 月 14 日，Steinberger 宣布加入 OpenAI，同时宣布 OpenClaw 将由一个 501(c)(3) 非营利基金会接管，OpenAI 承诺为项目提供赞助，但不拥有代码所有权，MIT 许可证保持不变。
这一事件有几个值得关注的维度：
首先是时机。Steinberger 在安全危机高峰期宣布离职，并非”丢下摊子跑路”，而是在安排好接班机制后才公开——他说”项目已经远超我一个人能维护的规模”。这个决策本身是对项目治理的负责任态度。
其次是治理架构选择。选择 501(c)(3) 基金会而非公司化，保持了项目的社区属性，避免了商业利益主导路线图的风险。这与 Linux 基金会、Apache 基金会等成熟开源项目的治理路径一致。
3 月 3 日，OpenClaw 在 star 数上超过 React（250,000），成为 GitHub 历史上增速最快的仓库。同月，NVIDIA 发布 NemoClaw，在 NVIDIA OpenShell 运行时中为 OpenClaw 提供安全沙箱环境，这是大厂对 OpenClaw 生态的第一次正式背书。
与此同时，中国政府要求国有企业和政府机构停止使用 OpenClaw，理由是数据安全风险。而中国本土科技公司（腾讯、字节跳动、阿里巴巴）则积极将 OpenClaw 适配到国内模型（DeepSeek、Qwen）和消息平台（微信、QQ）上。
这一阶段的迭代逻辑 ：当一个开源项目成为”基础设施级别”的存在，单人维护就不再是可持续模式。治理重组是项目从”个人项目”升级为”公共基础设施”的必经之路，OpenClaw 在极短时间内完成了大多数项目需要数年才走完的治理转型。
阶段五：控制面革命（2026 年 3 月 31 日 — 4 月）
安全危机驱动的反思，最终落地为一次架构层面的重大升级——Task Brain 和 Plugin Manifest 权限声明系统 。
Task Brain（2026.3.31） ：在此之前，OpenClaw 的后台任务是散乱的”孤儿进程”，没有统一的生命周期管理。Task Brain 将四条不同的后台执行路径统一到一个 SQLite 账本上：
openclaw flows list / show / cancel
：首次让运维人员能够看见并控制后台任务状态 - 父子任务关系
：子任务结果能追溯到父会话，告别”任务跑完不知道汇报给谁” - 阻塞状态持久化
：被阻塞的任务在同一 flow 内重试，而非碎片化成新任务
一位中国技术博主的类比值得引用：”Kubernetes 统一了容器的调度到控制面，OpenClaw 这次做的事非常相似——它把 AI Agent 的任务统一调度到了 SQLite 账本上。区别在于 Kubernetes 调度容器，OpenClaw 调度 AI Agent 的任务。”
Plugin Manifest 权限声明系统 ：针对 ClawHavoc 的核心教训，OpenClaw 引入了声明式权限模型。插件只能访问在 manifest 中明确声明的资源，没有声明的能力一律失败关闭（fail-closed）。这是从”默认允许”到”默认拒绝”的安全哲学转变。
ACP 审批语义分类 ：Agent Client Protocol 引入了语义化的工具调用审批，操作按语义类别分类，而非靠开关全开全关——精细化的信任边界管理成为可能。
这一阶段的迭代逻辑 ：这是典型的”危机倒逼架构升级”模式。如果没有 CVE-2026-25253 和 ClawHavoc，Task Brain 和 Manifest 权限体系可能会晚很多才出现。安全危机实际上加速了 OpenClaw 从”能跑的原型”向”可信赖的基础设施”的演进。
阶段六：工程成熟期（2026 年 4 月 — 5 月，持续中）
经历了命名危机、安全危机、治理重组、架构重写之后，OpenClaw 进入了相对稳定的工程成熟期。这一阶段的迭代特征是： 功能推进与可靠性修复并行，Manifest 驱动逐渐成为组织原则 。
Active Memory（2026.4.10） ：彻底改变记忆模型。在此之前，MEMORY.md 在会话开始时静态加载一次。Active Memory 在每次回复前自动运行一个记忆子 Agent，动态查询相关的偏好、历史上下文和过往会话细节——记忆从”快照”变成”实时检索”。
Google Meet 原生参与插件（2026.4.25） ：Agent 能加入 Google Meet 会议、实时转录（通过 Gemini Live）、在会议中发言、导出出席记录。这代表了 Agent 从文字平台扩展到实时语音/视频领域的关键一步。
VoiceClaw 实时 Brain 端点 ：Talk、Voice Call、Google Meet 等语音交互界面现在可以将复杂问题交接给完整的工具支持 Agent 处理——不再局限于简单的实时语音应答。
Manifest 驱动的持续深化 ：从 2026.3 开始，越来越多的运行时逻辑（Provider catalog、model 目录、channel 路由、认证元数据）从硬编码迁移到可审计的 Manifest 文件中。这个方向持续延伸到 2026.5，DeepInfra、NVIDIA 等新 Provider 全部通过 Manifest 接入，而非修改核心代码。
平台覆盖持续扩展 ：截至 2026.5，OpenClaw 支持 20+ 消息平台，包括 WhatsApp、Telegram、Discord、Slack、iMessage、微信、QQ、LINE、Nostr、Twitch、Tlon 等，覆盖了从主流到小众的广泛生态。
这一阶段的迭代逻辑 ：大项目在经历一次重大危机之后，通常面临两种选择：激进重写或渐进重构。OpenClaw 选择了后者——每个 release 里既有用户要求的新功能（Google Meet、Active Memory），也有基础设施层面的渐进重构（Manifest 化）。这是工程成熟度的体现：不以”大版本重写”为旗帜，而是让每个迭代都同时向前走一步、向下打一层根基。
三、四条核心演进主线
主线 A：社会现象级爆发 — 从 hack 到基础设施
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
OpenClaw 的增长曲线在开源历史上是罕见的异常值，60 天内超越 React 十年的积累。这不是因为代码写得多精巧，而是因为它在恰好的时间点，精准击中了”AI 应该真正做事”这个被压抑已久的用户需求。
主线 B：安全从零防护到声明式权限体系
零防护（2025.11）
↓ 用户自发暴露实例，13.5万实例公网裸奔
CVE 爆发（2026.2）
↓ WebSocket 劫持 RCE、供应链攻击、137 安全通报
被动修补（2026.2-3）
↓ 版本后加 Origin 校验、绑定到 127.0.0.1、凭证加密存储
控制面加固（2026.3.31）
↓ ACP 审批语义分类、Plugin Manifest 声明式权限、fail-closed 默认
Manifest 驱动（2026.4-5）
↓ 所有 Provider/Channel 权限可审计化，供应链可追溯
主线 C：控制面从无到有
OpenClaw 的 Task Brain（2026.3.31）是这条主线最清晰的节点。在此之前，后台任务是散落的 ACP 记录，调试靠 grep 日志。Task Brain 之后，统一的 SQLite 账本让任务可见、可控、可追溯——这是 Agent 系统从”实验玩具”走向”生产工具”的标志性转变。
主线 D：治理从单人到生态
Steinberger 单人维护（2025.11）
↓ 危机高峰期加入 OpenAI（2026.2.14）
501(c)(3) 基金会接管，OpenAI 赞助（2026.2）
↓ NVIDIANemoClaw 企业级背书（2026.3.16）
104+ 核心贡献者（2026.3.31 单版本）
↓ ClawHub5,400+ Skill，生态自运转（2026.4-5）
四、深度解读
4.1 安全演进：从”架构性忽视”到”声明式防御”
OpenClaw 的安全演进是这个项目最值得深入分析的维度，因为它呈现出的不是一个团队”不够努力”，而是一种 系统性的哲学冲突 。
CVE-2026-25253 的根本原因不是某行代码写错了，而是设计哲学：为了让 Agent “尽可能少摩擦地执行任务”，系统默认给予 Agent 广泛权限，并将用户体验（无需额外配置）凌驾于安全设计（最小权限原则）之上。
安全研究机构 eSentire 的专家 Alexander Feick 在安全危机前就预警过：”OpenClaw 最根本的缺口不是某个复选框，而是缺乏一个能表达细粒度信任边界的控制面。”这正是后来 Task Brain 和 Manifest 权限系统所回答的问题。
三阶段演进模式 ：
- 零防护期（2025.11 — 2026.1）
：设计中心是功能和易用性，安全不在威胁模型里。 - 被动响应期（2026.2 — 3月初）
：CVE 出来之后才修——WebSocket 来源校验、Gateway Token 强制、端口绑定改 127.0.0.1、凭证加密。修的是”漏洞”，而非”设计”。 - 主动设计期（2026.3.31 后）
：引入 Manifest 声明式权限，把安全边界编入架构，而非依赖用户正确配置。这才是从”打补丁”到”设计安全”的真正转变。
ClawHavoc 揭示的第二个系统性问题 ：开放的 Skill 市场没有信任验证机制。12% 的 ClawHub Skill 在某时间段是恶意的，这个比例来自于”开放即信任”的设计假设。修复路径同样是 Manifest 化——每个 Skill 声明它需要的权限，用户能看见也能拒绝，而不是”安装即授权一切”。
对 AI Agent 领域的启示： 开放 Skill/Plugin 市场是 Agent 平台的核心竞争力，也是最难防守的攻击面 。npm 和 PyPI 经历了十年才建立起相对成熟的供应链安全机制，AI Agent 的 Skill 市场几乎是从零开始，却面临一个更危险的威胁模型——因为 Skill 调用的不是代码，而是 Agent 的行动权限。
4.2 架构决策：Manifest 驱动的渐进式重构
OpenClaw 没有选择”停下来做大重写”，而是在持续发布的压力下，推进了一场 渐进式 Manifest 化重构 。
其核心思路是：把原本散落在运行时代码里的元数据（Provider 目录、channel 路由规则、认证元数据、工具声明）逐步迁移到可读、可审计、可版本化的 Manifest 文件中。
这个方向在 2026.3 之后的每个 release 里都有体现：
providers/*.manifest
：Provider 的 model 目录、认证方式、能力声明 channels/*.manifest
：Channel 的路由规则、SecretRef 合约 plugins/*.manifest
：Plugin 的权限声明、工具合约、依赖声明
重构动因分析 ：Manifest 化并非来自某个宏大的架构决策，而是由两个压力驱动：
- 安全压力
：Manifest 声明式权限是 ClawHavoc 后最直接的防御响应——让权限可见才能让用户审计。 - 扩展压力
：Provider 和 Channel 数量增长到 20+，运行时硬编码变得难以维护，Manifest 文件是自然的解耦手段。
这与 Hermes Agent 引入 Transport ABC 的逻辑相似： 架构抽象发生在扩展压力积累到足够高的时候，而非”提前规划” 。过早抽象是浪费，适时抽象是工程成熟度的体现。
4.3 社区生态：一个意外诞生的 Skill 经济
OpenClaw 的 Skill 生态是这个项目最出乎意料的演化结果。
项目发布 6 个月后，ClawHub 已有 5,400+ 社区 Skill，覆盖从学术论文搜索、银行 API 对接、日程管理、创意写作到”帮 AI Agent 参加 Casino 游戏”的各种场景。awesome-openclaw-skills 仓库收录并分类了这些 Skill，成为社区自发建立的目录层。
更有趣的是生态的”经济化”：172 个初创公司基于 OpenClaw 生态建立产品，月生态营收达 36.1 万美元（2026 年 3 月数据）；ClawHub 月访问量 2,700 万，月活用户 200 万。
从技术角度看，Skill 系统的设计极为简洁——一个目录下放 SKILL.md 描述文件，AI 根据描述决定何时调用。这种”文本描述即接口”的设计降低了贡献门槛，任何人都能写 Skill，不需要 SDK 知识。这也正是安全问题的源头：无需代码审查即可发布意味着恶意 Skill 可以同样轻松地混入。
Skill 生态的三个发展阶段 ：
- 野生期（2025.11 — 2026.1）
：官方 Skill 为主，社区贡献零散 - 爆发期（2026.1 — 3月）
：Moltbook 引发用户激增，社区 Skill 数量从数百跳升至数千；ClawHavoc 同期混入 - 治理期（2026.3 至今）
：Manifest 权限声明引入，官方开始对 Skill 进行验证分级；NVIDIA 等大厂开始在 ClawHub 发布经过安全审查的企业级 Skill
4.4 治理模式：从”技术天才个人项目”到”社区基础设施”
Steinberger 在 2026 年 2 月 14 日（安全危机高峰）宣布加入 OpenAI 并移交项目，是 OpenClaw 历史上最关键的治理事件。
值得关注的是移交的 方式 ：不是卖给某家公司，而是建立独立的 501(c)(3) 非营利基金会，接受来自 OpenAI 的赞助但不移交控制权。这保证了项目的中立性，也使 OpenClaw 成为 AI 基础设施层的一个真正意义上的公共品。
Sam Altman 称 Steinberger 是”a genius with a lot of amazing ideas about the future of very smart agents”——这不只是客套话，而是一个信号：OpenAI 把 OpenClaw 视为理解 Agent 在野外如何使用的重要窗口。
104 贡献者单版本的意义 。2026.3.31 的 Task Brain 版本由 104 名开发者合力完成。这个数字说明 OpenClaw 已经完成了从”Steinberger 的项目”到”社区的项目”的实质性转变——不再依赖任何单一个体。这种去中心化正是 501(c)(3) 治理结构所追求的。
五、对 AI Agent 领域的启发
5.1 “增长速度是安全成熟度的最大敌人”
OpenClaw 用最戏剧化的方式证明了：一个面向公众的 AI Agent 平台，其安全边界必须在用户大规模到达之前建立好。当 13.5 万个实例暴露在公网时，任何补丁都只能是亡羊补牢。
这对正在构建 Agent 平台的团队有直接警示： 安全模型应该作为 0.1 版本的设计约束，而不是 2.0 版本的技术债 。
5.2 “Skill 市场即攻击面，开放与安全必须同步设计”
ClawHavoc 展示了一个新型攻击向量：通过开放的 Skill 市场，攻击者可以用专业文档包装的恶意 Skill，在用户授权瞬间获得 Agent 的全部行动能力。这比传统恶意代码更危险，因为用户主动安装了它。
Manifest 声明式权限是目前最接近解决方案的方向——让用户在安装前就能看见 Skill 需要什么权限，类似于移动 App 的权限申请界面。但这还不够：Skill 市场还需要类似 App Store 的代码签名和定期审核机制。
5.3 “控制面是 Agent 从玩具到工具的分水岭”
Task Brain 的意义不只是”加了个任务管理功能”，而是让 Agent 的行为 对运维人员变得可见和可控 。一个你不能监控的系统是无法信任的，一个你不能停止的任务是危险的。
对 AI Agent 开发者的启示： 控制面（task status、approval flow、audit log）应该和功能特性同等优先级 。没有控制面的 Agent，无论功能多强大，都无法在生产环境中放心使用。
5.4 “治理结构决定项目天花板”
Steinberger 选择 501(c)(3) 而非公司化，在短期内是有代价的（基金会治理比公司决策慢），但长期看这是对项目最有利的选择：它让 OpenClaw 能够被 NVIDIA 这样的大公司背书、被 OpenAI 赞助、被中国和美国的开发者同时贡献——而不会被任何单一商业利益挟持。
这对于想要构建长期开源生态的项目来说是重要参考： 当项目成为基础设施时，中立的治理结构就是最重要的护城河 。
5.5 “社会现象级增长不能被策划，但可以被准备”
OpenClaw 的病毒式传播不是营销的结果，而是功能与时机的化学反应——一个真正能做事的 Agent，在 AI 能力初步成熟的节点爆发。
但如果项目没有”准备好接受这一切”——没有足够的安全模型、没有清晰的治理结构、没有可扩展的贡献者机制——病毒式增长会把它摧毁，而不是助力它。OpenClaw 几乎在这个边缘跌落，最后靠着 Steinberger 快速移交治理权和社区的力量稳住了局面。
六、总结：一个被用户增长强行催熟的项目
OpenClaw 的演进哲学可以用一句话概括： 被外部压力推着走，但每次都找到了正确的方向 。
改名危机推着它建立品牌主权意识；安全危机推着它建立声明式权限体系；治理危机推着它建立社区基础设施；规模压力推着它建立控制面和 Manifest 驱动的架构。
这不是最优雅的演进路径，但它是真实的。与那些在精心规划下缓慢演进的项目不同，OpenClaw 展示了另一种可能：在野蛮生长的压力下，一个项目可以在极短的时间内完成从”个人 hack”到”社区基础设施”的跨越——只要每次危机都被转化为架构升级的契机，而不是逃跑的理由。
OpenClaw 代表的方向，是 AI Agent 从”聪明的聊天机器人增强版”到”可信赖的自主执行系统”的演进——这条路还很长，但 OpenClaw 已经在最混乱的环境里，蹚出了一段值得研究的轨迹。
数据来源：openclaw/openclaw GitHub Release Notes、Wikipedia OpenClaw 词条、Petronella Cybersecurity、DEV Community 安全分析、36氪技术解读、Blink Blog 历史档案。分析截止日期 2026 年 5 月 11 日。
