OpenClaw 2026.9.3 更新｜Node 26、升级恢复、实时浏览器、Skills 与升级建议

OpenClaw 在 2026-09-08T14:15:53Z 发布了 v2026.9.3，GitHub Release 标记为 draft: false、prerelease: false。因此截至本站 2026-09-10 核验时，9.3 已取代 9.2 成为当前 Stable。

这次更新规模很大，但普通用户不需要逐条读完变更。真正会影响安装、升级和长期使用判断的，是下面几组变化。

先说结论：9.3 值得升，但先检查 Node

新安装用户可以直接以 9.3 为稳定基线。

已经运行 9.2 的个人单用户环境，9.3 对更新恢复、Session 重连、浏览器自动化可视化、模型账号管理和长期工作流都有直接价值，可以在备份后升级。

成熟的多 Agent、多 workspace、长期 Memory / Skills 环境不要只看 doctor 和数据库检查变绿就删除快照。发布后已经有少量旧环境迁移现场报告，建议保留完整回滚点并实际验证主 Agent 连续性、workspace ownership、Memory 与 Workshop。

升级前第一件事不是跑 openclaw update，而是确认 Node：

node -v

9.3 当前要求：

Node 24.16.0+（24.x）；或
Node 26.1.0+；
推荐 Node 26；
Node 22、23、25，以及低于上述门槛的 24 / 26 都不再支持。

这不是普通的“推荐版本变化”。官方把门槛与 SQLite 安全问题关联起来，旧 Node 应先升级，再升级 OpenClaw。

1. 更新机制继续变得更像事务：先 rehearsal，再 activation

9.3 最值得长期运行用户关注的是更新流程。

支持的 core 与 plugin 更新会先在隔离的 candidate state 中排练和验证，再切换真实运行安装。启用的 npm plugin 会在停机前检查目标；私有 plugin 副本会保留受支持的依赖结构，避免只验证 core、不验证实际插件环境。

如果 candidate validation 失败，符合条件的情况可以进入有边界的 repair；最终仍必须通过独立验证才能 activation。需要修改真实配置的问题则会明确交给用户处理，而不是在 rehearsal 中偷偷改生产配置。

这比“下载完直接覆盖，再看能不能起来”安全得多。

但它不等于不需要备份。事务式更新降低失败升级的破坏面，不会替你验证业务语义。 对长期 Agent 来说，真正需要确认的是升级后它是否仍绑定到正确 workspace、Session、Memory 与权限。

2. 9.2 → 9.3 的恢复链更完整

9.3 对 9.2 的 shared-state schema 变化提供了明确的兼容恢复路径，并能处理部分 abandoned update records，而不是每次发现残留更新记录就先停掉一个其实健康、版本也正确的 Gateway。

对普通用户，这意味着更新失败后的状态判断会更清楚：

当前运行安装是否健康；
candidate 是否验证通过；
activation 是否完成；
rollback / recovery 是否已经恢复到可工作的版本；
还有什么需要人工处理。

所以升级后不要只看版本号，继续跑：

openclaw doctor
openclaw gateway status --deep

复杂环境再加 doctor --post-upgrade 与插件检查。

3. Session 重连与性能：不是“更快一点”这么简单

9.3 的性能工作重点放在长期会话：保留 warm prompt cache、减少冷 Session 更新与 Memory Search 中不必要的工作，并尽量在会话间复用 worker build。

对长会话、多 Agent 和频繁切换任务的人，这类优化通常比单次 benchmark 更有实际价值，因为它减少的是反复恢复上下文、重建运行环境和搜索 Memory 的固定开销。

4. Browser：现在能实时看 Agent 页面变化

Control UI 的 Browser panel 在支持的路径上可以实时流式显示页面 repaint。页面加载、滚动或响应时，不必总等下一张 screenshot 才知道 Agent 做到哪里。

原有 click、type、scroll、Annotate、Inspect 仍然保留。某些 paired-node browser、Chrome MCP existing-session profile，以及无法 streaming 的路径继续回退为 screenshot，这一点不要写成“所有浏览器都变成视频流”。

macOS 端还增加了 native WebKit tabs。用户自己打开的链接可以与 Agent browser tabs 放在同一个 Browser panel 中，并在切换 conversation 时继续保留。

5. 可以分享只读聊天链接，但它是真正的公开链接

9.3 加入了可撤销的只读 conversation sharing。

Session creator 或 Gateway admin 可以发布一个链接，使持有链接的人看到当前以及后续新增的聊天文本，直到链接被撤销。公开页面会排除 tools、reasoning、files、images 和 executable widgets。

这里的安全边界要写清楚：

“revocable” 是可以停止后续访问，不是撤回别人已经保存的副本；
分享前要检查整个 conversation，因为未来新增文本也会继续出现在同一公开链接中；
普通 private-session preview 仍然需要原来的认证，不能和 public transcript sharing 混为一谈。

如果对话中存在客户数据、内部代码、凭据线索或其他不适合公开的信息，不要因为“只读”就直接分享。

6. Meeting：保存后的会议终于可以按全文找回来

9.3 增加 searchable Meetings library：可以浏览已保存会议、搜索完整 transcript，并管理 capture sources。

导出支持 Markdown 与 JSONL；搜索状态下导出仍以完整选中会议为单位，不是只导出命中的几行。Web 下载仍有大小边界，大型归档应走官方 CLI 导出路径。

对把 OpenClaw 用作会议行动项、个人知识库或长期项目记录的人，这个变化比单纯“自动转写”更重要：采集完的数据开始变得可检索、可返回和可导出。

7. Skill Workshop：Skill 从 workspace 资产变成 agent 资产

9.3 让每个 Agent 拥有一套跨 workspace 持久存在的 Skill Workshop。

也就是说，一个 Agent 学到的 Skill 不再因为切换 workspace 就要跟着搬动。界面也把已安装 Skills 与等待 review 的 Suggestions 分开，减少“当前能用的能力”和“待接受变更”混在一起的情况。

Startup / Doctor 会迁移 ownership 可以明确判断的 legacy skills；模糊或冲突副本会保留给用户 review，而不是强行覆盖。

这对长期养 Agent 很有价值，但也正因为发生了 ownership migration，老多 workspace 环境升级时应专门检查：

openclaw doctor
openclaw skills check

不要看到迁移日志写着成功，就默认所有 Workshop proposal 的 target 一定已经正确落盘。

8. Models：可以单独管理账号优先级和退出某一个账号

9.2 已经引入 Personal model accounts；9.3 把管理能力继续补齐。

管理员现在可以在 Models settings 查看 provider account 的 credential source 与 health，对支持的账号调整优先级，并只登出某一个账号，而不是把同 provider 的其他连接一起断开。

Agent 的 fallback chain 也更容易直接在设置里按顺序组合。

一个值得保留的设计原则是：明确选中的账号如果失效，OpenClaw 会保留这个选择并给恢复提示，而不是悄悄换成另一个账号。 对需要可审计模型路由的工作流，这是好事。

9. Repository-backed cloud work：远端节点可以直接拥有 checkout

9.3 的 repository work 不再要求所有远程工作先在 Gateway 本机 clone。

受支持的 managed cloud 或 paired node 可以直接启动 repository session，由远端节点负责 checkout 和 setup。已接受的修改可以通过 checkpoint 在 Stop 后保留，需要本地执行时再显式 Move to Gateway。

这更适合把 OpenClaw 当长期开发工作台，但 checkpoint 不等于 Git history，也不是未接受修改的完整备份。重要代码仍应靠正常 Git 提交与远端仓库保存。

10. 9.2 的共享 Gateway 权限提醒仍然有效

9.3 成为 Stable，并没有让 9.2 引入的跨 Agent 默认值提醒失效。

如果共享 Gateway 省略了相关配置，仍应明确核对：

tools.sessions.visibility = all
tools.agentToAgent.enabled = true

不希望采用宽默认时继续显式配置，例如：

{
  "tools": {
    "sessions": { "visibility": "agent" },
    "agentToAgent": { "enabled": false }
  }
}

真正互不信任的用户仍应使用独立 Gateway，不要把 Session visibility 当作完整多租户隔离。

9.3 首发风险：目前重点看老环境迁移，不要过度外推

截至 2026-09-10，GitHub 上已经出现几条明确标注 2026.9.3 的迁移现场报告。

主 Agent 连续性：结构检查全绿仍可能不等于语义连续性正常

Issue #142580 报告一套从 2026.7.1-2 跨级升级到 9.3 的成熟多 Agent 环境：Doctor、SQLite integrity、Session 与 Gateway 检查均正常，但 main Agent 在实际交互中表现得像新建 Agent，原有有效 Memory / context 连续性没有正常体现。报告者随后回滚。

这是一次真实现场报告，但尚无最小稳定复现。因此正确解读不是“9.3 会丢 Memory”，而是：成熟环境不要把结构检查全绿当作删除快照的充分条件，必须做真实连续性验收。

legacy workspace setup：个别跨级升级被 Doctor 卡住

Issue #142585 报告同类旧多 workspace 环境中，Doctor 能识别 legacy setup state，但无法自动完成 canonical state migration，导致启动 / turn 继续被 maintenance gate 阻止。

这个报告同样没有证明是普遍问题，但它说明从很旧版本直接跨级升到 9.3，风险明显高于 9.2 → 9.3。

Skill Workshop proposal：Doctor 的“已 retarget”日志仍需二次验证

Issue #142583 报告 Doctor 先显示 Workshop proposals 已迁移 / retarget，紧接着验证阶段又把部分 proposal 标成 target 在 agent directory 外。

所以老 Skill Workshop 用户升级后应实际打开 Workshop / Suggestions 并检查目标，而不是只读一行成功日志。

这次更新对普通用户最值得记住什么

如果只记三件事：

先升级 Node：24.16+ 或 26.1+，推荐 26；
9.3 的重点是长期可靠性：更新 rehearsal / recovery、Session 重连、持久 Workshop、远程仓库工作都在往长期 Agent 工作台推进；
复杂旧环境要验证“语义连续性”：Doctor 全绿是必要条件，不是充分条件。

当前版本状态看版本中心，安装步骤看安装中心，9.2 的权限变化背景看2026.9.2 更新解读，共享环境继续先看安全入口。

搜索 OpenClaw 中文导航

OpenClaw 2026.9.3 更新解读：事务式升级、实时浏览器与持久 Skill Workshop