首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >OpenClaw 2.0:欠下的技术债,这次连本带利还清

OpenClaw 2.0:欠下的技术债,这次连本带利还清

作者头像
腾讯云开发者
发布2026-09-10 16:46:55
发布2026-09-10 16:46:55
510
举报

关注腾讯云开发者,一手技术干货提前解锁👇

从 v2026.8.1(16,000+ PR、933 位贡献者)看个人 Agent 运行时如何从「能跑」走向「可托付」。

2026 年 8 月 31 日,OpenClaw 发布了 v2026.8.1,官方别名是 OpenClaw 2.0。这个版本合并了一万六千多个 PR、来自 933 位贡献者。而在此之前的七周,项目几乎没有发过版本;再往前推 230 天,它发了 106 次。

Changelog 正文分三节:Highlights 8 条、Changes 约 130 条、Fixes 超过 200 条(原文末条截断)。表面看这是一次功能大版本:重建的 Web 控制台、全新的引导流程、会话搜索、云端会话、交互式组件。

把 Fixes 逐条读完,主题就变了:这一版在兑现,把过去半年高速迭代攒下的不确定性收拢成可预期的行为。这篇文章不列功能,只回答三个问题:架构上换了什么,为什么必须换,代价是什么。

01

六个必须分清的概念

OpenClaw 的术语体系有一套自己的含义,直接读 changelog 容易误判。先对齐:

2.0 的整体形状:Gateway 居中,左侧是多种接入客户端,右侧是可迁移的执行单元,下方是新迁入的存储层。会话不再绑在某一台机器上,Gateway 可以把它调度到任意执行单元,工作区跟着一起走。

02

会话:从进程内的状态,变成可迁移的资源

这是 2.0 最大的一条变化,其他变化都建立在它之上。会话在三个维度上被解耦。

位置解耦

「Sessions beyond your Gateway」允许把工作放到配对设备或云 worker 上执行,工作区跟着会话一起走。热机器和项目种子可以被后续云会话复用。配套的生命周期策略是:空闲一段时间后挂起 worker,下一条消息时重新供给,会话与已协调的工作区都保留。

时间解耦

进度卡片在重载后依然存活,跨 web / macOS / iOS / Android / dashboard 保持同一张卡。会话重置的默认值也改了:没有配置重置策略时,不因空闲或跨天而重置。还有会话分支,可以从一条已持久化的用户消息回退或分叉,早先的对话路径仍然保留。

主体解耦

共享会话引入了可见性与成员关系:可以设置谁能查看、谁能建议、谁能直接参与;团队操作员角色(Team operator roles)给已验证用户分配具名角色,限制其可访问的 agent、他人的会话与操作范围;共享 Gateway 档案则管理显示名、头像与在线状态。

会话迁移:会话不再是 Gateway 进程里的状态,而是一个带着工作区一起移动的对象。动画循环演示「发起 → 迁移 → 挂起保留」三个阶段。

判断 三条合起来看,会话已经具备一种资源的全部特征:可寻址、可迁移、可共享、可快照、可恢复、有访问控制。聊天机器人只在乎这一轮说什么,作业运行时还必须回答「这个任务现在在哪、谁在看、断掉之后从哪继续」。 会话一旦成为资源,UI 就退化成它的一个观察者。下一节讲这件事。

代价:换存储层的账单比想象中长

2.0 把会话与 transcript 搬进了 SQLite,配套给出 openclaw backup sqlite 的 create / list / verify / restore 全套能力。收益是实打实的:会话搜索、并发安全、快照恢复。代价是这一版 Fixes 里密度最高的一组问题,几乎全部由这次存储更换直接引发:

changelog 中与 SQLite 化直接相关的修复(均为原文条目)

风险 回滚不是免费的。官方要求:回退到旧的文件存储版本之前,必须先由当前版本 CLI 恢复已归档的旧 transcript 产物。迁移之后新建的会话,在旧版本里看不到。所以升级前的备份必须是能 restore 的,复制文件不算。 打算换会话存储层的团队都一样:先建回滚路径,再切存储。

03

控制面:UI 退化为 Gateway 的一个客户端

官方给了两个数字:在 mocked Gateway + 50ms HTTP/1.1 延迟的模拟中,默认会话的 JavaScript 请求数从 140 降到 45,启动时间从约 1.6 秒降到 575 毫秒。

请求收敛:上面 30 个点与下面 10 个点,是同一次默认会话发起的请求数对比。横条以同一速度揭示,长度差就是时间差。测试条件是 mocked Gateway + 50 ms HTTP/1.1 延迟。

请求数掉三分之二,只能由数据获取模型的重做来解释,此前几乎可以确定存在大量 N+1 拉取与重复初始化。changelog 里留了对应的注脚:启动响应性一条写着「避免重复的 CLI 插件准备与重复的 provider 目录规划」,运行准备性能一条则提到复用目录策略、路由查找、提示上下文准备与引导统计,减少重复的 SQLite schema 元数据扫描。

停靠面板,以及被明确写出来的边界

重建后的 Control UI 把会话放在中心,旁边是可停靠的面板:工作区文件编辑器、git 支持的 Changes 面板(带 PR 状态与 CI 摘要)、浏览器面板(元素检查与截图批注)、全屏 Web 终端。

文件编辑器不能新建或删除文件;Changes 面板是只读的;Create PR 会把你交给 GitHub,而不是在 OpenClaw 内部提交。

这三条限制被原样写进了文档。这是有意的架构克制:OpenClaw 不打算成为 IDE,也不打算成为 Git 客户端,它只想在会话旁边提供够用的上下文。越界的代价是开一个自己打不赢的战场。

多端一致性是被迫做对的事

当 web、macOS、iOS、Android、Wear OS、Linux 托盘、甚至 Telegram Mini App(/dashboard)都是同一个 Gateway 的客户端时,一致性问题会从「体验瑕疵」升级为「正确性缺陷」。这一版 Fixes 里那些看起来很底层的条目,正是这条架构路线的直接后果:

  • 设备时钟偏移:所有客户端改用 Gateway challenge 时间戳做设备证明,覆盖 TypeScript / Control UI / 浏览器扩展 / Android / Apple / Linux / watchOS(#116679)
  • 重连事件顺序:每替换一次 WebSocket 就重置外层事件序列基线,防止不同连接代次之间做 gap recovery(#116043)
  • 状态三处一致:工具进度在折叠行、展开卡片、侧栏详情里必须给出一致状态(#131622)
  • 身份对齐:显示真实用户头像、去掉发送者标签上的 profile UUID 后缀(#111537)

判断 展示层彻底客户端化之后,Gateway 就是唯一真相源,UI 之间任何「本地状态」都是潜在 bug。这条路线一旦选定,时钟同步、事件序列、重连语义就不是「有空再修」的东西,必须一次做对。2.0 把这批债一并还了。

04

能力供给:核心变薄,依赖外置

2.0 把一大批官方 provider 从核心拆出去,改成按需安装的独立包:第一批是 BytePlus、ComfyUI、Mistral、NovitaAI、OpenCode、Synthetic、Volcengine、Vydra、Xiaomi,第二批是 Cohere、Meta、DuckDuckGo 搜索、Voyage embeddings、iMessage。只有 OpenCode Go 仍然内置。

留下哪一个是信号。内置的判定标准已经从「是否常用」变成了是否与 Agent 执行循环强耦合。模型接入属于后者。

能力外置:九个 provider 从核心弹出为独立包。中间那个会周期性变成「缺失」,随后由 update repair 恢复。这个闭环必须和外置一起交付。

外置必须同时交付的四件事

能力外置的分量比「模块化」重。它把一部分正确性责任从代码转移到了运维,所以下面四件事必须同时交付,缺一件外置就是灾难:

  • openclaw update repair 与 openclaw doctor --fix 负责恢复缺失的已配置包
  • Gateway 启动前自动应用安全的 doctor 配置迁移,不等用户发现(#132135)
  • 安装或启用外部插件前显示其能力、来源、版本与确切产物;拒绝更新时保留原插件不变(#130168)
  • CLI / 聊天安装任意可执行来源需要显式 --force;ClawHub、内置、官方目录与可追踪更新来源跳过该警告但保留能力同意;ClawHub 安装前显示可用的安全审计信息

外部 skill 引用(skills-sh:)也一起收敛:不再从源 registry 直接下载,改为走 ClawHub 的 commit-pinned 镜像产物并施加常规安全检查。

破坏性变更与迁移窗口

2.0 的破坏性变更与迁移动作

SDK 那一条的措辞值得注意:它是门控,本次并不移除。官方保留了几个公共 helper 的调用方名称(resolveStorePathresolvePluginProvidersresolveThinkingDefaultWithRuntimeCatalog 接受 loadModelCatalog),同时明说这些修复不免除迁移要求。给插件作者的窗口只剩一天。先修兼容、再催迁移、最后才真正移除,这种三段式处理公共 API 演进算是体面的做法。

05

安全:一条信任边界,并且明确声明它不是什么

2.0 的安全设计可以拆成三层。最有价值的反而是它对各层「不能做什么」写得有多直白。

三层防线

  • 入口层:Gateway 默认绑定 loopback;多数聊天渠道对未知 DM 发送者回以配对码;受信任代理下的浏览器配对,其 scope 升级受运维配置的上限约束,而 key / role / metadata 的变更仍需单独批准。
  • 凭证层:私有凭证请求通过遮蔽提示框收集,值既不进聊天也不进模型上下文;可选代理把「受保护 secret 的替换」限定在已批准的目的地;共享凭证库中的 secret 值只写不可读,且出口绑定声明的 host;1Password broker 逐条授权、审计里不含值。
  • 执行层:会话权限模式把受限的文件系统访问锚定在其记录的工作区或 worktree 上;shell 展开导致无法生成可强制执行的 allowlist 计划时,ask=off + askFallback=deny 下直接 fail closed;自动化授权针对「精确操作」授予一次,job 或 operation 变更时需要重新授权;被拒绝的插件请求会明确告知 agent 已关闭,不得重试或再次提请审批。

凭证的最短路径:明文只存在于用户输入到 Gateway 之间,进入 Gateway 后立刻变成不可读的引用;向下通往模型上下文的那条路,在入口处就被截断。

那组被反复引用的攻击数据,真实含义是什么

这组数字在 changelog 里检索不到。它的原文在官方 Security 文档的 Prompt injection 章节:2026 年的一次众测竞技场,272K 次攻击,覆盖 41 个 agent 场景,判定标准是「既执行了有害动作、又向用户隐藏了它」。成功率是:Claude Opus 4.5 为 0.5%,Sonnet 4.5 为 1.0%,Haiku 4.5 为 1.3%,Gemini 2.5 Pro 为 8.5%。

出处:docs.openclaw.ai/gateway/security 的 Prompt injection 章节。截图三段依次是攻击的定义、272K 竞技场的口径与成功率、官方自己写下的两条保留条款。

数据解读 这两组数字要放在一起读。8.5% 与 0.5% 之间差 17 倍,说明模型选型确实是一道有效缓解。但同一页紧接着警告:自适应的人类攻击者,对最先进防御的成功率仍超过 80%。 所以模型选择只是第一道缓解,不是防线。任何依赖模型自律的方案都不成立,硬执行层只能是工具策略、执行审批与沙箱。这也解释了 OpenClaw 为什么把自动化的默认授权设计成「一次性、针对精确操作、变更即失效」:它不指望模型判断,只做机械的作用域约束。

被明确写下的两个「不是」

共享会话与团队操作员角色的定位是协作控制,不是租户隔离,也不是安全边界。多人共用一套 Gateway 时,隔离粒度到不了租户那一层。

Incognito 带着同样的限定。它管的是本地留存,管不了对外发送:

Incognito 默认关闭,会话只留在进程内存里。但消息仍然会发给模型 provider。

两条声明直接排除了两种用法:共享会话做不了多租户隔离,Incognito 保证不了消息不出本机。想这么用的人不必自己试一遍,文档已经给了否定答案。

06

记忆与自学习:把上下文变成有所有权的数据资产

这一组默认值的改动密度很高,方向也一致,全部是「默认开启」:

  • 个人会话召回:启用 Active Memory 后,个人部署默认检索同 agent 的有界私有会话上下文;可显式关闭,群组与频道始终排除。
  • Grounded dreaming:模型驱动的后台记忆整合默认开启,只把「带来源限定(provenance-qualified)」的材料提升进长期记忆,配 Dream Diary 与显式关闭开关。
  • 自动自学习:默认捕获强可复用经验,并自动应用通过扫描的新 skill 或 Workshop 自有的 skill;用户自己撰写的 skill 改动保持 pending,显式的 off / propose 设置受保护。
  • 会话重置默认:没有配置重置策略时,会话跨空闲期与跨天保留。

配套的还有所有权机制:能查到哪些会话贡献了某条记忆,能把选定的来源排除在准入之外,也能用 openclaw memory forget 删掉可识别的派生记忆,源 transcript 则完整保留。Skill Workshop 那边有可恢复的评审流、/learn 时复用已有 skill,以及由 Gateway 系统级自动化驱动的定期合集评审。

记忆的可撤销:三条记忆都带着回到源会话的 provenance 连线。中间那条被 memory forget 删除时,左侧的源 transcript 只是亮一下,内容没动。

判断 这一组的共同点是可撤销。默认开启、显式关闭、来源可追溯、可定点删除,四件事凑齐,记忆才算数据资产而不是缓存。 很多 Agent 产品只做前两件,用户想删掉某段记忆时唯一手段就是清空全部。memory forget 加上「保留源 transcript」,才是记忆功能敢默认开启的前提。

07

四类反复出现的可靠性模式

把 200 多条 Fixes 当成一个整体看,会浮现出四类模式。这不是零散的 bug 修复,是一套已经成形的工程规范。

从 Fixes 中提炼的四类可靠性模式(均为 changelog 原文条目)

同一个分岔口:ask=off + askFallback=deny 时,无法生成可强制执行的 allowlist 计划就直接拒绝,而不是发一个注定超时的审批请求。

判断 四类模式回答的是同一个问题:系统失败时应该是什么样子。静默降级、可观测地失败、还是可控地恢复。 2.0 的答案落在后两者。这也是我觉得这个版本最值得读的地方。功能列表可以抄,这套规范抄不来,它只能从足够多的真实故障里长出来。

08

这不是一次无条件的升级

  • Volcengine 的 ClawHub 镜像因社区 runtime-ID 冲突被推迟。官方 npm 包本身已验证,镜像渠道没有
  • Telegram、MiniMax 以及 catalog / subprocess 的 flake 属于 waived(豁免),不是 passed(通过)
  • 更高的 beta 线仍在 2026.9.1-beta.1,说明稳定版之后还有未收敛的分支
  • npm 包与全部 93 个包通过了 registry 签名与 Sigstore 溯源验证,89 项插件运行时检查通过。这个覆盖度确实罕见,但验证的是产物,不是行为

更要紧的是节奏本身。七周停摆之后一次性合入 16,000+ PR,回归风险客观存在。社区在此前的 v2026.7.1 上报告过自动更新卡住的情况,官方也建议 Cron 较重的生产 Gateway 先在 staging 验证 SQLite 迁移。changelog 顶部的更新提示同样不客气:如果自动更新失败,用本地的 coding harness 协助完成更新、诊断迁移错误并验证 Gateway 能正常启动。

建议的升级顺序:

# 1. 先备份配置与状态(要能 restore 的备份,不是简单复制) openclaw backup sqlite create # 2. 升级前先体检,看清会迁移什么 openclaw doctor # 3. 升级 openclaw update # 4. 执行破坏性迁移(OpenProse 清理、codex/* → openai/* 路由) openclaw doctor --fix # 5. 验证 Gateway 正常启动,重点看模型路由与 SQLite 会话 openclaw status

结论 适合现在升级:全新安装 / 重新引导、以 Control UI 为主要工作面、小团队共享一个 agent、移动 + web 组合使用者。 建议先在 staging 验证:Cron 密集的生产 Gateway、依赖受影响 provider 的部署、以及任何需要保留旧版本会话可读性的场景。

信息来源与核验说明

  • 官方发布说明:docs.openclaw.ai/releases/2026.8.1(Highlights / Changes / Fixes 三节,本文所有 changelog 引文与 PR 编号均出自此页)
  • OpenClaw 2.0 发布说明:openclaw.ai/blog/openclaw-2-accidentally(PR 数、贡献者数、停摆周期、Control UI 性能数字、SQLite 迁移与回滚限制)
  • 官方 Security 文档:docs.openclaw.ai/gateway/security 的 Prompt injection 章节(272K 众测竞技场数据、各模型成功率、80% 自适应攻击成功率的原文出处,第四节截图即取自该页;此项不在 changelog 中)
  • 发布证据:GitHub release v2026.8.1;npm openclaw 2026.8.1;macOS 签名产物(ZIP / DMG)

口径说明:Changelog 原文未标注发布日期,发布日 2026-08-31 来自官方发布页与第三方发布追踪;条目数为对 changelog 的粗略统计,原文 Fixes 末条被截断,实际条目数更多。本文中的架构判断与模式提炼为作者分析,非官方表述。

-End-

原创作者|凌弘毅

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2026-09-08,如有侵权请联系 cloudcommunity@tencent.com 删除
目录
  • 01
  • 02
    • 位置解耦
    • 时间解耦
    • 主体解耦
    • 代价:换存储层的账单比想象中长
  • 03
    • 停靠面板,以及被明确写出来的边界
    • 多端一致性是被迫做对的事
  • 04
    • 外置必须同时交付的四件事
    • 破坏性变更与迁移窗口
  • 05
    • 三层防线
    • 那组被反复引用的攻击数据,真实含义是什么
    • 被明确写下的两个「不是」
  • 06
  • 07
  • 08
    • 信息来源与核验说明
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档