ARTICLE · 1047236
升级 AI 助手必须停机赌一把?OpenClaw v2026.9.5 先在私有副本里验完再切换
原子更新 · 私有校验副本 · 插件热装 · schema 21 · 会话冷归档 · openclaw/openclaw
—— 这一版把「升级」从一次停机赌注，改成了先验证、再切换、可回退的流程。 对把 AI 助手跑在自己机器上的人而言，可用性第一次被当成硬指标来设计。
项目概述：常驻的 AI 网关
OpenClaw（仓库名 openclaw/openclaw）是一个多通道 AI 网关，TypeScript 编写，MIT 许可。 它做的事情很直白：把 WhatsApp、Telegram、Discord、Slack、飞书、邮件等入口， 接到运行在自有设备上的 AI Agent 上。
它不是云端助手，而是「自己部署、自己配模型、自己管数据」的那一类工具。 截至 v2026.9.5，仓库累计 39 万+ star、8.2 万+ fork，是这一品类里体量最大的开源项目之一。
网关进程 Gateway 是它的运行核心，模型调用、插件、定时任务、通道连接都挂在这个常驻进程上。 也正因为它是常驻服务，一旦停机，通道与定时任务就同时中断，升级方式因此成了关键设计点。
它也能同时跑多个专职 agent：写代码的、查资料的、专门盯某个通道的，各自有独立工作区。 规模上去之后，同一个进程要背的就不再只是聊天，还有数据库、插件与历史会话。
v2026.9.5 发布于 2026-09-19，包含 4,179 个 PR 与 64 个直接提交。 三条主线分别是：安装与升级、插件生命周期、会话存储与归档。
升级窗口里的可用性账
自托管服务最怕的不是功能少，而是升级窗口太长。 老流程要停掉 Gateway、换安装包、跑数据库迁移、重启、再观察， 整个过程里通道消息可能积压，定时任务可能错过触发时刻。
失败的含义同样模糊。包换了一半、迁移只完成一部分、插件与核心版本对不上， 这些状态过去只能靠人读日志判断，用户拿到的往往是一段报错，而不是一句「下一步做什么」。
验证也来得太晚。新版本能否启动、现有配置是否仍然有效、插件能不能加载， 这些问题过去要等真正切换过去才知道，等于把「能不能用」押在下一次启动上。
这一版还多了一个变量：agent 数据库升级到 schema 21，旧版本无法打开它。 数据库结构变更不可逆，回滚应用不等于回滚数据， 所以升级前的备份从建议变成了硬要求。
真实的坑在上一版就出现过。已经安装的 2026.9.4 更新器可能在切换前直接拒绝， 报出 managed-service-preflight，并提示命令正运行在网关进程树内。 这种情况下新版本救不了旧更新器，只能由管理员在独立终端里手动完成那一次升级。
规模越大，这笔账越明显。长期运行的实例里，会话库会涨到需要专门清理的程度， 而插件更新与通道配置调整过去都挂在同一个重启动作上，一次变更就牵动全部通道。
这一版能做什么
升级路径被收敛成几条明确命令：
• 直接升级：openclaw update
• 先看再动：openclaw update --dry-run，结果用 openclaw update status --json 读取
• 出问题就修：openclaw update repair；配置问题交给 openclaw doctor --fix
• 清理恢复原件：openclaw update cleanup --dry-run
• 切换发布通道：openclaw update --channel beta，或用 --tag 指定版本
插件这条线同样不再要求停机：
• 安装、启用、重载都作用于正在运行的 Gateway，界面与 CLI 都能做
• 重载一个或多个插件：openclaw plugins reload <id> <id>
• 一条命令处理多个插件：openclaw plugins enable a b c
• 首次通道配置也不再需要重启（PR #146481）
会话存储多了一套冷归档：
• 入口在 Settings -> Agent Defaults -> Session 的 Session storage 面板
• 默认关闭；打开后可设「超过 N 天自动归档」，改阈值不用重启
• 面板显示记录数、数据库与 WAL 体积、归档文件字节数与压缩后体积
• 打开或恢复被归档会话时，历史先恢复再使用，即使后来关了归档也仍可读
升级前的动作清单也变了：schema 21 无法回退，必须先做一份经过校验的备份， 并把它与归档文件一起保留。
题外话：平心而论， OpenClaw的升级成本都比较高， 考虑到它等更新频率，总体的升级成本就更高了， 单元openclaw也会有瘦身的一天。
为什么能做到不停机
关键在于「验证」与「切换」被拆成了两步，验证全程发生在私有副本里。
更新器先按状态目录生成一份副本，包含配置投影、状态数据库与插件载荷。 复制不是无脑全量：它会先测量体积，按 「数据字节 × 2 + 最大单文件 × 3 + 插件字节 + 64MB」估算所需临时空间， 再据此选择合适的临时盘，避免大库把更新卡在拷贝上。
副本之上会拉起一个 canary Gateway，使用临时 loopback 端口， 并显式关掉后台监听，包括 MCP Apps 沙箱、浏览器控制与通道服务。 因此它不会和正在服务的 Gateway 抢端口。 它使用临时 token，保留 gateway.auth.rateLimit 这类非密钥策略，关闭 Tailscale 身份认证。
校验按阶段推进：snapshot、doctor、lint、config、plugins、runtime、startup、readiness。 配置、数据库、插件、启动、就绪逐项过关，候选版本才被允许接手服务。
真正停机的窗口只剩：切换、必要的数据库迁移、插件下载与收敛、服务启动。 切换之后还有一次验证；若数据与配置仍然兼容，恢复流程可以退回上一版本。 需要注意，私有验证副本不是回滚备份，数据库迁移也无法靠回滚应用撤销。 后台的更新检查读取与保存都挪进了工作线程，关机时会等已受理的检查写完再退出， 避免检查动作本身成为新的卡顿来源。
插件热装依赖的是生命周期租约：替换前要等旧实例的在途调用结束， 清理成功才允许替换；清理失败则按提示重载，必要时回退到旧插件。 这既是它能一边服务一边换插件的前提，也是代价。