OpenClaw 2026.9.5 Atomic Updates 与 Schema 21 迁移：升级前必须做的一次备份
如果你正在用 OpenClaw 管理团队的多 Agent 协作，或者在自托管一台 Gateway 服务给公司内网用，那么 2026 年 9 月 19 日发布的 v2026.9.5 不只是又一次普通的版本号变化。这次发布同时改写了”升级”和”回滚”两件事的玩法，并且第一次把”升级前必须做一次完整备份”从官方建议升级成了硬性前提。本文用一份升级操作清单的形式，讲清楚 Atomic Updates 到底保住了什么、Schema 21 迁移又会丢掉什么，以及自托管玩家在 9 月 21 日这个时间点应该怎么排升级窗口。
一、这次发布改了什么：4,179 个 PR 浓缩成 6 件大事
9 月 19 日的 release thread 把 4,179 个 PR、64 个直接 commit 和 502 位贡献者浓缩成了六个主要功能块。官方 release notes 在 docs.openclaw.ai/releases/2026.9.5 列出的高亮条目分别是：Atomic Updates、Plugin hot reload、Conversation sharing、Expanded GPT Live、Shared browser pages、Conversation archives 和 Guided agent team setup。任何一项单拎出来都够写一篇解读，但真正影响”能不能安心点升级按钮”的只有第一项。
Atomic Updates 的工作机制并不是简单的”下载新版本然后重启 Gateway”。它的执行顺序是先在后台准备一个”影子环境”，把当前版本的数据结构和配置复制过去，跑一遍预演迁移和健康检查，确认影子环境能起来之后才把流量切换过去，最后再清理影子。中间任何一步失败，自动回滚到原版本，并且尽量保留一个能诊断问题的 agent 在跑。这一套听起来很像 Kubernetes 的 deployment rollout，但 OpenClaw 做在了单机自托管场景里，影响的是每一个用 npm i -g openclaw@latest 或者 Docker 部署的用户。
无重启装插件是第二件值得注意的事。9.5 之前，装一个新的 plugin 必须重启 Gateway 服务才能生效，这意味着所有正在跑的对话、cron、scheduled task 都会被中断一次。9.5 之后，plugin 的加载变成热插拔，可以一边继续接收用户请求一边安装。这一项对生产环境的运维是真实收益，但更深的意义是它意味着 OpenClaw 把 plugin registry 当成了一个独立的运行时子系统，跟 Gateway 主循环解耦了。
Shared browser pages 和 GPT Live 集成这两件事，本文不展开。它们各自有专门的官方文档，GPT Live 走的是 gpt-realtime-2.1 模型，目前只支持音频（要用摄像头需要单独的 gpt-realtime 视频版）。如果你关心的是浏览器同屏和会议场景，参考 docs.openclaw.ai 的对应章节即可。
二、Schema 21 迁移：升级路径上第一道真正的坎
9.5 把 agent database 的 schema 升到了 21，老版本打开不了。docs 上专门用一段警告文字强调了这件事：”Make and verify a pre-upgrade backup that includes committed data still in the database journal, or WAL. Going back requires restoring that backup with its matching older build and loses work saved after the backup.”
翻译成运维语言：如果你现在跑的是 9.5 之前的版本，数据库里有未提交到主表的 WAL 数据，备份必须把这部分也带上；如果你升级之后想回退，必须用回退目标版本的 build 配合升级前那份完整的备份；光重新装一个旧版本的 npm package 是不够的；不要手动改 schema 标记或者删表来”骗”老版本打开新库。
这意味着三件事。第一，Atomic Updates 的”自动回滚”在数据库迁移场景下是有边界的。代码和配置可以自动回到原版，但数据如果已经被新 schema 改写，自动回滚救不回来。第二，从 2026.9.2 直升 9.5 的用户需要走一次手动 schema 升级路径，不是 npm update 一下就完。第三，回退这件事在 9.5 之后变得比以前更复杂，老的”重装 package”经验不再适用。
三、回滚与恢复的真实流程（参考 docs.openclaw.ai/install/updating/rollback-and-recovery）
官方把回滚分成了三类：自动回滚、手动备份恢复和 openclaw doctor --fix 修复。9.5 的 Atomic Updates 只覆盖第一类。第二类和第三类都需要操作员介入。
自动回滚的触发条件是影子环境验证失败，原理是切流之前在 candidate 环境跑一次”迁移预演 + 健康检查”，预演会生成临时的 migration-rehearsal 快照，验证通过后会被删除，不作为正式备份留存。换句话说，自动回滚能保住你的 Gateway 进程不挂、配置文件不被覆盖，但是保不住迁移期间产生的任何新写入。
手动备份恢复的步骤在 rollback-and-recovery 文档里写得很清楚：第一步，停掉所有会写 OpenClaw 数据的进程，包括 channel 适配器、cron job、外部 API 回调；第二步，用 openclaw backup 创建一份带时间戳的归档（默认包含所有数据库和配置目录），并把归档拷到目标版本能识别的位置；第三步，安装目标版本的 build（注意：必须装跟这份备份匹配的那个版本，不是任意老版本）；第四步，恢复备份；第五步，用 openclaw triage 检查恢复后的状态，确认 conversation history、task list、memory store 都正常。
openclaw doctor --fix --non-interactive 是第三种选择，它尝试在保留当前数据的前提下修复 schema 标记和 meta.lastTouchedVersion。如果修复失败，最终仍然要走”备份恢复”路径。文档明确警告：”changing either version marker does not undo the migration”，也就是不要试图手动改版本号字段来骗系统接受新格式。
四、升级前的 5 步操作清单
把上面所有内容折算成一份今天就能照着做的操作清单，按照执行顺序排列。
第一步，先确认当前版本。在终端跑 openclaw --version 记录输出。如果你跑的是 2026.9.2 或者更早，要走手动 schema 升级路径；如果跑的是 2026.9.3 或 2026.9.4，可以走标准 Atomic Updates 路径。
第二步，做一次完整备份并验证。在低峰时段跑 openclaw backup，归档完成后用一个独立目录解压检查，确认 conversation、task、memory 三类主表都有数据。备份文件不要留在 OpenClaw 的工作目录里，拷到外部存储或者对象存储。docs 上反复强调”verified backup”，意思是不能只看到”备份成功”的提示就当备份可用，必须真的打开看过一次。
第三步，停止写入进程。停掉 channel 适配器（如果有 Telegram、Slack、Discord 适配器在跑），停掉 cron，暂停外部 API 回调。9.5 的 Atomic Updates 可以在 Gateway 运行的同时做影子验证，但你显式停掉写入源能把回滚风险窗口压到最小。
第四步，执行升级。npm i -g openclaw@latest 或者拉最新 Docker 镜像。Atomic Updates 会自动做影子验证和切换。如果切换失败，看 openclaw triage 的输出定位问题；如果切换成功，跑一遍 smoke test，确认核心对话、plugin、cron 都能正常触发。
第五步，保留备份至少 7 天。即便升级一切顺利，也至少把升级前的备份留一周。Schema 21 的某些兼容性影响可能在跑几天之后才暴露，比如旧 client 拉新格式的 conversation 出现解析错误。docs 上给的命令是 openclaw update cleanup，用来在确认无误后清理升级过程产生的中间文件，但这一步要在”确认无误”之后才能跑。
五、自托管玩家最该关注的 3 个边界条件
第一，Atomic Updates 只覆盖”受支持的升级路径”。npm 全局安装和官方 Docker 镜像属于受支持路径；从源码 checkout 出来的某个 commit、第三方 fork 出的 build、或者企业内部分发的私有 build 都不在覆盖范围内。如果你用的是私有 build，需要自己实现影子验证逻辑，不能依赖 openclaw update 的自动行为。
第二，AI repair 不是默认开启的。如果影子验证失败，系统会问”是否启动 AI repair”，这个提示会调用你的账号和 token，并设置一个 30 秒超时。生产环境如果要避免被这个交互卡住，可以用 --non-interactive 参数提前拒绝 AI repair，让系统直接走回滚路径。
第三，回滚不是备份的替代品。docs 写得很直白：”The private validation copy is not a rollback backup.” 影子环境是为切换决策服务的，不是为数据恢复服务的。如果你想要一份能真的在灾难场景下恢复数据的备份，必须走第二步那个 openclaw backup 命令。
六、9.5 其他几条值得记下来的改动
除了上面三件大事，9.5 的 release notes 还藏了几条不那么显眼但对长期运维很重要的改动。
Schema 标记锁：openclaw update 在做版本切换之前会先做 schema 对比，如果 candidate 版本的 schema 不在当前数据库支持范围里，直接拒绝切换，避免出现”代码已经更新但数据库还停在旧格式”的中间状态。
Gateway I/O 响应性改进：在排队写入期间保持 I/O 响应，并能把 stalled 连接识别为传输超时。这两项对长连接场景（持续运行的 channel adapter、TUI session）更友好，老版本偶尔出现的”Gateway 假死几秒”现象在 9.5 上有明显缓解。
并发计算调度：bound concurrent compute work and queued inputs，并发计算任务和排队输入都做了边界保护。如果你的 OpenClaw 同时跑很多 memory-heavy 的 task，这一项能减少 OOM。
文档侧要求 PR 提交 UI 截图：从此以后 chat 和 PR 都要求附带 UI 截图（Require UI screenshots in chat and pull requests）。这条对贡献者有意义，对使用者意义不大，但能看出项目对文档质量的重视。
七、写在最后：升级窗口该怎么排
如果你在企业内网跑 OpenClaw 给团队用，建议把升级窗口排在升级后至少观察 48 小时再清备份。9.5 是 schema bump 的版本，跨过这条线之后任何回退都要走完整备份恢复路径，不像过去 npm i -g openclaw@9.4 那么轻量。把 9 月 21 日到 9 月 23 日这三天的备份都留好，等 atomic updates 跑过一周、shadow validation 跟实际生产流量交互过至少 5 天，再考虑 openclaw update cleanup。
个人玩家或者开发环境的升级可以激进一点，但仍要遵守”备份—停写—升级—smoke test—保留备份”五步。如果只是想体验新功能，不在意数据连续性，可以直接拉 Docker 镜像起一个新实例，9.5 在 Docker 场景下的回滚就是停容器、重启老版本镜像，复杂度比 host 安装低得多。
OpenClaw 把升级这件事的”原子性”做到了单机自托管能给的极限，但原子性保的是进程和配置，不保数据。理解这一点，比记住 4,179 这个数字更重要。
来源与延伸阅读：
- OpenClaw v2026.9.5 官方 release notes：
- Rollback and recovery 文档：
- Database schemas 参考：
- GitHub release page（含 503 位贡献者列表）：
- MarkTechPost 独立报道：
