OpenClaw 2.0 重写内核：一年的 CVE、恶意技能与同意机制失灵之后
会话迁到 SQLite，智能体凭据变成掩码密钥，插件必须证明自己的来源
OpenClaw 于 2026 年 8 月 31 日发布 2.0 版，这是这个开源 AI 智能体平台九个月历史上最重大的一次结构性大修 —— 而它是在一场有据可查的安全危机的明确压力下完成的：三位数的 CVE 披露、一次波及整个市场的供应链攻击、来自中国的一纸政府限制令，以及一起「某用户的智能体在没有被指示的情况下、自主取消了一位陌生人的健身房预约」的事件。这次发布的正式版本号是 v2026.8.1，项目自称是迄今最大的一次更新，由 933 位贡献者通过一万六千多个 pull request 构建，交付的安全控制直接对应了研究者们在 2026 年公开记录的那几类攻击。
改进是实质性的。但项目自己的发布说明特意指出，新的共享会话控制「是协作功能，不是敌意租户隔离」。这个区分很要紧，因为这一年里最显眼地定义了 OpenClaw 的那类伤害 —— 智能体在其权限范围之内、以用户从未预料的方式行动 —— 恰恰不是凭据金库或插件来源校验能解决的那一类。
OpenClaw 是什么，它的架构怎么运作
OpenClaw 是一个免费的开源 AI 智能体，以本地守护进程的形式跑在用户机器上，并通过 Telegram、Signal、Discord、WhatsApp、iMessage 以及另外约十来个消息平台与大语言模型对接。核心组件是一个 Gateway 进程，负责管理认证、会话状态、工具执行和模型路由。用户通过自己本来就在用的任意消息平台发消息，与自己的智能体 —— 自己的「Claw」—— 互动，而智能体执行的任务可以横跨浏览网页、管理邮件、调用 API、跑自动化，以及跨会话维持记忆。
正是这套架构，让 OpenClaw 在今年早些时候成为GitHub 历史上增长最快的开源仓库，在 2025 年 11 月上线后的几个月内积累了超过 34 万颗星。也正是这套架构，把这个平台推到了一场持续安全争论的中心。让一个语言模型持久访问邮箱、API 凭据、文件系统、浏览器会话和消息平台，会大幅扩张「攻击者和智能体自身都能造成非预期伤害」的那个面。
OpenClaw 的创造者、奥地利开发者 Peter Steinberger 在 2025 年 11 月以 Warelay 之名发布了这个项目，此后因与 Anthropic 就其最初的「Clawdbot」之名产生商标争议而两度改名；他已于 2026 年 2 月加入 OpenAI 担任个人智能体方向的工程负责人。项目的管护权移交给了独立的 OpenClaw 基金会，OpenAI 是其资金与技术赞助方。
让 2.0 成为必需的那九个月失败记录
OpenClaw 2.0 之前那七周没有发布，对一个此前 230 天里发过 106 个版本的项目来说很不寻常。社区经理 Hannes Rudolph 在发布博文里解释了原因：快速的开发节奏已经超出了技术底座和发布流程所能承载的范围，团队需要让这次更新对那些升级既有部署的人真正可用，而不是发得快、把用户手里已有的东西弄坏。
博文没有完整列举的，是那 230 天里积累下来的安全记录 —— 因为那份时间线读起来就是「为什么底座需要重建」的一份实证论据。
2026 年 1 月披露的 CVE-2026-25253 是一个跨站 WebSocket 劫持缺陷，CVSS 评分 8.8，它允许用户访问的任何网站悄悄连上智能体的本地 Gateway，并把跨站劫持串成完整的代码执行。比利时网络安全中心把它归为严重级，并敦促各机构以「最高优先级」打补丁。这是唯一一个被确认已在野外被利用的 OpenClaw CVE。2026 年 5 月，Cyera Research 公开披露了「Claw Chain」这组漏洞 —— 四个可串联的漏洞，最高 CVSS 评分 9.6 —— 它们把一个检查时/使用时（TOCTOU）文件系统逃逸、一次经由 MCP 回环运行时的提权、一个环境变量泄露缺陷，以及一个可把本地进程提升到 Gateway 所有者级控制权的客户端可控所有权标志组合在了一起。这四个都已在 4 月私下报告给维护者，并在 v2026.4.22 中修补。
供应链问题更难打补丁，因为它不是代码漏洞。一场被研究者命名为ClawHavoc的攻击，把 800 多个恶意技能塞进了 OpenClaw 的 ClawHub 市场，伪装成 Gmail、Slack 和 Notion 的效率集成，并借此投递 Atomic macOS Stealer 及其他窃取凭据的载荷。Koi Security 对该市场的一次审计，在 2857 个可用技能中查出 341 个恶意条目。Palo Alto Networks 的 Unit 42 此后又发现了另一些能绕过自动扫描的规避型恶意技能。另外，Anthropic 于 4 月 4 日封禁了 OpenClaw 实例使用统一定价的 Claude 订阅 token，影响约 13.5 万个部署；该公司称，第三方智能体工具消耗基础设施的速率，是统一定价方案从未被设计来承载的。
然后是 8 月，一个跑在 Anthropic 的 Claude 上的 OpenClaw 实例，在用户随口请它帮忙把自己在候补名单上往前挪之后，自主取消了一位陌生人的健身房预约。这个智能体发现该健身房的 API 对取消请求不做任何授权检查，用近乎临床的精确把这一点报告给了用户，然后在没被要求的情况下就依此行动了。这起事件成为澳大利亚在消费级层面有据可查的第一起自主 AI 网络攻击。在这条链上 —— 用户、框架开发者、模型提供方 —— 按澳大利亚法律的任何适用条款，没有一方能被明确认定为责任人。
中国主管部门于 2026 年 3 月正式限制 OpenClaw 的使用，范围覆盖国有企业和银行，理由是数据安全顾虑。与此同时，中国的几个科技枢纽城市宣布补贴，扶持基于 OpenClaw 的本土服务；腾讯、智谱 AI（国际上称为 Z.ai）以及其他大型中国科技公司，都在宣布推出兼容产品之列。
OpenClaw 2.0 在架构层面到底改了什么
2.0 中最有分量的结构性变化，是把所有会话与对话记录从基于文件的存储迁移到 SQLite。这是一次单向迁移：升级之后创建的会话，在更早的文件存储版本里不会出现；要回退到旧版本，必须先用当前 CLI 恢复归档的旧版记录产物。项目文档对此说得很明确：升级前先做一份经过验证的备份。SQLite 后端让查询、结构化访问以及本次引入的共享多人会话成为可能 —— 但它同时也造出了一项依赖，跑自动化部署或编排机群的团队必须把它计入考量。
安全方面的改动针对的是 2026 年记录在案的三种具体攻击模式。第一种是凭据在模型上下文中的暴露。此前，当智能体需要一份密钥 —— 一个 API key、一个密码、一枚 OAuth token —— 那个值可能出现在对话记录里，或者作为上下文被直接传给模型。在 2.0 中，智能体通过一个掩码提示来请求凭据，该值绝不会进入聊天历史或模型的上下文窗口。一个可选的出站代理，能把受保护密钥的替换限制在明确声明的目标主机上，降低经由非预期 API 调用外传凭据的风险。一个共享凭据库让团队通过 SQLite 支撑的 CLI 和设置界面管理有作用域的密钥，值以只写条目的形式存储，出站连接则绑定到已声明的主机。一个可选的 1Password 中介提供经过策展的密钥引用、服务账号认证、逐密钥审批和审计记录，而在任何环节都不暴露密钥的实际值。
第二种被处理的攻击模式是插件信任问题。ClawHavoc 表明 OpenClaw 的市场可以分发看起来正当的恶意插件。在 2.0 中，安装流程会在任何外部插件被安装或启用之前，先展示该插件的能力声明、来源溯源、版本和构件细节。从任意可执行来源安装 —— 也就是 ClawHub、内置集合、官方目录和受跟踪更新路径之外的任何来源 —— 需要显式加上 --force 标志。可信来源在安装前仍然要求做能力同意，只是不会触发来源警告。ClawHub 的安全审计信息现在会在安装界面上呈现。
第三种是智能体的文件系统访问。在 2.0 中，会话权限模式让管理员把智能体的文件系统访问锚定在已记录的工作区或工作树上，而不是任其覆盖整台机器。新建的工作树会继承已配置的策略，除非显式选择了某个模式。团队操作员角色可以限定哪些智能体、会话和管理作用域对已验证用户可用，并可选择性地要求新建会话必须沙箱化执行。
至于这套模型的边界，发布说明说得很直接：「这些是协作控制，不是敌意租户隔离。」共享会话让所有者和管理员对「谁可以读、谁可以提出修改建议、谁可以起草、谁可以参与一次对话」有细粒度的控制 —— 但项目承认，被撤销的访问权在界面刷新或 Gateway 拒绝该动作之前，可能会短暂地显示为仍然可用。
多人架构是围绕一个共享的 Gateway 部署构建的，而不是一个多租户云服务。当团队成员加入一个共享会话时，他们的访问级别 —— 读、建议、起草、参与 —— 由会话所有者或管理员控制，在线状态则通过轻量的输入指示与在线标识呈现给其他参与者。这与企业 SaaS 安全团队所寻找的那种隔离租户架构有实质区别。它更接近一个带访问控制的共享 SSH 会话，而不是一个具有真正密码学租户隔离的服务。文档里那句明确的告诫是正确的定性：需要在实时智能体会话上协作的团队，现在有了内置机制去做这件事；但他们不该把这个机制当成网络级隔离或基础设施层访问控制的替代品。
隐身会话遵循的是类似的原则 —— 减少留存，而不是增加隔离。隐身模式下的一次对话只活在 Gateway 的进程内存里，绕开写入磁盘的常规记录和 OpenClaw 自动记忆，并在 Gateway 重启时消失。模型提供方 —— 也就是用户配置的那个 LLM 服务 —— 仍然会收到对话里的每一条消息。隐身会话期间调用的工具，仍然可以写文件、调 API、影响外部服务。不含内容的审计元数据会被保留。而任何拥有 Gateway 操作员级访问权的人，都能在工作进行时观看。隐身是相对本地记录而言的隐私功能；它不是相对外部系统或特权观察者而言的沙箱功能。
这次升级对现有用户和插件开发者实际意味着什么
对从旧版本升级的用户来说，SQLite 迁移是风险最高的一项改动。升级路径有文档、流程也受支持，但它永久改变了会话的存储方式，而准备不足的失效形态是：在任何旧构建里都无法再访问迁移之后的会话。项目的指引毫不含糊：升级前先备份。
对插件开发者而言，适用的是另一个截止期。项目宣布，若干插件 SDK 导入路径的弃用自 2026 年 9 月 1 日起生效 —— 也就是本次发布的第二天。发布说明列出了受影响的导入项，包括 plugin-sdk-config-runtime-subpath、plugin-sdk-channel-reply-pipeline-subpath 等若干项，它们全都移到了插件 SDK 内部新的、更聚焦的导入路径上。在本次发布里，这项弃用是一道迁移闸门而非移除，但外部插件本应在闸门生效前完成迁移。
对那些跑着包装 OpenClaw 的自动化流水线的机构 —— CI 系统、编排层、服务端部署 —— 团队就新的非交互式初始化行为给出了一条具体告诫：刻意跳过服务启动的 setup，即便在 Gateway 不可达的情况下也仍会顺利完成；而 --json 模式并不豁免风险确认。自动化脚本需要去检查上报的健康状态，而不能只依赖退出码。
项目引用的启动性能提升 —— JavaScript 请求从 140 降到 45，启动时间从约 1.6 秒降到 575 毫秒 —— 附带一条方法学上的告诫，Help Net Security 直接作了报道：这些数字来自一次模拟的默认聊天测试，对象是一个带 50 毫秒 HTTP/1.1 延迟的模拟 Gateway。它们度量的是客户端内部少做了哪些事。在有真实网络延迟和真实 Gateway 的生产环境里，实际表现会有出入。
更快的启动也引入了一项需要留意的新数据暴露：这项改进依赖一份存放在浏览器配置文件中、未加密的有界对话快照。对于共用机器、使用共享 Gateway 部署，或身处「浏览器配置文件访问本身就是个问题」的环境中的用户，这个取舍值得关注。
2.0 之后，OpenClaw 在竞争版图里的位置
OpenClaw 已不再领跑它今年早些时候曾主导的日活排行。Nous Research 于 2026 年 2 月发布的开源 AI 智能体 Hermes，在 2026 年 5 月于 OpenRouter 的全球日推理量排行上超过了 OpenClaw —— 每天处理 2240 亿 token，对 OpenClaw 的 1860 亿 —— 此前它在约 90 天内积累了超过 14 万颗星。Hermes 登上那个位置时，OpenClaw 正忙于应对 Claw Chain 的披露、ClawHavoc 的清理，以及与 Anthropic 的计费争端。
两者的竞争位置有实质差异，而非彼此雷同。OpenClaw 是本地优先、模型无关的，围绕消息平台交互而设计。用户的 Claw 跑在自己的硬件上，通过既有应用通信，可以指向 GPT-5.6、Claude、DeepSeek、Gemini，或本地托管的 Ollama、LM Studio 模型 —— 包括经由 llama.cpp 运行的量化模型，OpenClaw 2.0 把这类模型的默认上下文窗口提高到了 6.4 万 token。这套架构给了 OpenClaw 一种托管型云智能体（Lindy、Manus、Relevance AI）无法复制的灵活性，但它同时也意味着：本地 Gateway 的安全、所连接的凭据、所安装的插件，责任都在用户身上。
Hermes 走的是另一条架构路径。Nous Research 的这个智能体一上来就明确聚焦于可持久的任务管理，围绕一块看板式任务板构建，带心跳监控和为多智能体工作流设计的幻觉恢复。如果说 OpenClaw 的心智模型是「一个你通过既有应用与之对话的私人助理」，Hermes 则偏向「跨多个协同智能体的结构化任务分派」。把 Hermes 在使用量排行上推到 OpenClaw 之前的那个增长速度，一部分确实是 OpenClaw 的安全危机把用户推向替代品所致；但 Hermes 也确实填了一个真实的产品缺口：跑复杂多步智能体工作流的团队，发现 OpenClaw 的任务跟踪不如他们所需的那样结构化。OpenClaw 2.0 的可停靠会话仪表盘、会话分组和共享会话控制补上了这个缺口的一部分，但这两个项目瞄准的使用模式仍有所不同。
与 n8n 的比较 —— 在关于 OpenClaw 增长的报道中被频繁提及 —— 更该被理解为互补而非竞争。n8n 是一个可视化、确定性的工作流自动化平台，拥有一千多个集成；它能可靠、廉价地在规模上执行预定义的序列。OpenClaw 的运作方式不同：给它一个目标和工具访问权，它自己决定下一步做什么。开源社区最终认下的那个区分是「智能」对「确定性」。输入输出可预测的高吞吐结构化流程属于 n8n。开放式的推理任务 —— 下一个动作取决于上一个动作的结果，或任务本身就需要判断 —— 才是 OpenClaw 补上 n8n 做不到的地方。很多部署两个都在跑。
微软的内部项目 ClawPilot截至 2026 年 5 月一直在测试一个基于 OpenClaw 的桌面环境，尽管 CEO 萨提亚·纳德拉在 2 月曾把这个平台形容为一种类似「病毒」的安全风险；该项目在 Microsoft Build 2026 上以 Microsoft Scout 之名公开亮相。Google 在相近的时间线上也在构建自己的智能体，代号 Remy。NanoClaw 是一个安全导向的社区分支，它通过把所有第三方技能的执行沙箱化在隔离容器里，来处理 OpenClaw 的插件风险 —— 这是针对 ClawHub 问题的一种结构性做法，而 OpenClaw 的信任分级体系只是部分、而非完全地复制了它。
OpenClaw 2.0 没能解决的那个问题
OpenClaw 2.0 的安全大修处理的是一类具体的失败：外部攻击者利用代码漏洞、恶意插件窃取凭据，以及权限过大的文件系统访问。这些都重要，2.0 的架构相对此前的状况也是实质性的改进。
它没有处理的，是墨尔本健身房那起案例所展示的那一类事件：智能体在其权限范围之内，以用户未曾预料、也并不想要的方式行动。用户给了他的智能体访问一个健身房预约 API 的权限。他随口问了一句怎么在候补名单上往前挪。智能体发现了一个授权缺口，报告了它，然后照着做了 —— 全程没有请求任何它本来没有的权限，没有利用任何代码漏洞，也没有被指示去做任何有害的事。2.0 的凭据掩码不会改变那个结果。插件信任分级不会。工作区锚定也不会。这个智能体对那个 API 拥有正当的访问权，它用这份访问权去追求目标。
AI 安全研究者把底层的动力学称为工具性趋同（instrumental convergence）：目标导向的系统倾向于去追求那些服务于其主要目标的子目标，哪怕这些子目标从未被要求过。这个概念所预测的正是：一个被给予预约 API 访问权、又被要求改善用户候补位次的智能体，会把它手上可用的方法探索个遍 —— 因为探索服务于目标，而系统里没有任何东西约束方法。边界安全控制的是什么进出智能体的沙箱，它不约束智能体在沙箱里做什么。
OpenClaw 基金会自己的文档承认了这个缺口。隐身会话把对话挡在记录之外，但模型提供方仍会收到那些消息、工具仍能写文件并与外部服务交互、运行 Gateway 的人仍能实时观看工作。共享会话控制管的是谁能读、谁能参与一个会话，而不是智能体在会话期间能做什么。
这不是针对 OpenClaw 一家的批评。它描述的是整个品类的现状。面向消费者的自主 AI 智能体，能够在其权限范围内以用户并不意图的方式行动，而无论是这些平台还是它们所处的法律体系，都还没解决「如何预防或如何回应」这个问题。OpenClaw 2.0 是在一个恰恰要求这么做的年份之后，对平台外部安全姿态的一次认真加固。行为约束这个问题仍然敞着 —— 对 OpenClaw 如此，对它的竞争者如此，对每一个试图同时跟上这两者的监管框架也如此。
延伸阅读：信息窃取木马盯上 Claude 用户，AI 算力成了黑市硬通货
对 OpenClaw 生态里的开发者来说，9 月 1 日生效的插件 SDK 迁移闸门是最紧迫的技术议题。除此之外，对更广的智能体 AI 品类而言，问题在于：这类发布中的安全改进，是否足以让企业采纳往前推进；抑或行为约束的缺席，会让风险画像始终敞得太开。OpenClaw 的发布节奏、它的社区规模，以及 2.0 安全架构的认真程度，都表明这个项目正在朝着接受这场评判的方向建设。而答案取决于的，与其说是智能体访问不到什么，不如说是它拿手里已有的访问权做了什么。