我还停在 8.2,OpenClaw 已经跑到 10.1——15 个后续版本,升级看得我头大

“

新功能一项接一项，老用户只想问：这次更新，能把我的助手完整带过去吗？

前两天，我刚把 OpenClaw 从 8.2 到 9.9 的升级风险翻了一遍。

今天又打开 GitHub。

好，10.1 正式版来了。

我的升级决定还没做完，上一份“最新版升级指南”已经需要改标题了。

这种更新速度，让人一边佩服开发者的手速，一边默默摸向备份盘。

我想要一个能长期帮忙的 AI 助手。结果看着发布列表，感觉自己又接了一个版本管理的活。

先把话说明白：本文截至 2026 年 10 月 11 日，基于官方 Releases、发布标签说明和 GitHub Issue。涉及事故的是社区报告，涉及升级安排的是我的建议，不冒充我已经亲自把所有版本装过一遍。

📌 本文看点

起点是 2026.8.2，终点是今天的最新稳定版 2026.10.1。

跟 8.2 向前升级直接相关的发布，一共 15 个。

其中，13 个正式版，2 个 Beta。

正式主线有 10 个：9.1、9.2、9.3、9.4、9.5、9.6、9.7、9.8、9.9、10.1。

八月维护线还有 3 个：8.33、8.34、8.35。

十月测试线有 2 个：10.1-beta.1、10.1-beta.2。

同期另外发布了旧六月、七月维护线的 6.35、7.35。如果只按“8.2 发布之后”机械统计，数字版本发布共有 17 个；它们两个不是 8.2 向前升级的目标。还有一个 linux-stable 滚动资产标签，也不该充当一个新的软件版本。

至于 8.2 → 8.33，别紧张。不是要求补装中间三十来版。维护回补线的编号不能直接当成升级次数。

从 10 月 4 日那次调研到今天，仅一周，就新增 9.9、10.1 两个正式版和两个 Beta。

我只是想决定“升不升”。官方已经给我加了四道阅读理解。

还有个细节：今天 npm 的 latest 和 beta 都指向 2026.10.1，extended-stable 仍指向 2026.8.35。标签是动态入口，版本才是这次变更的具体对象。官方发布列表

公平一点，OpenClaw 确实在快速变强。

多 Agent 协作、个人技能库、会话归档、会议资料库、远程工作区、模型账号、浏览器与文件面板，越来越像一套可以长期使用的个人工作系统。

发布说明也在反复补那些真正要命的环节：任务做完能不能回话，重启后能不能继续，升级失败能不能恢复，历史和记忆能不能保住。

问题恰恰在这里。

新用户看到的是“又多一个功能”。老用户读到的是“我那几个插件，那些旧会话，还有本地中文记忆，这次要不要重新验收？”

功能可以一键安装。信任没法一键迁移。

下面按版本一个个过。这里的“坑”，包括已报告故障、行为变化和发布范围限制；不会为了凑吐槽，给每个版本硬编一个崩溃。

9.1：技能库、图表和快速安装都来了

更新内容： Mermaid 图表进聊天，个人技能库、新安装快速启动、Codex 工具授权和多端界面升级；更新失败保护与重启恢复也做了增强。

特点： 入门更顺，界面更丰富，个人与团队使用开始分得更清楚。

坑： Windows 升级后计划任务被禁用的历史报告 #138934，说明后台服务这一关还不能跳过。包装上了，要核对服务能不能真正启动。

我想要一个更好用的助手。第一份作业是先证明它还活着。9.1 发布说明

9.2：更快的聊天，默认开启的多 Agent

更新内容： GPT-6 Astra、更多配置热更新、个人模型账号、默认开启 Swarm、Realtime Talk、Discord 会议笔记与长对话性能优化。

特点： 协作能力和运行效率一起往前推。

坑： Windows 的 9.2/9.3 有 SQLite WAL 膨胀、影响启动的历史报告 #143524。另一个要检查的不是 bug：默认跨 Agent 会话可见性发生变化，想保持隔离的用户，要核对权限边界。

助手开始学会组队，我开始学会看数据库和权限。9.2 发布说明

9.3：升级前检查、分享和会议库

更新内容： 在隔离候选状态里检查更新、技能集合、浏览器标签、公开会话分享、会议资料库和团队活动报告。

特点： 终于开始认真处理“换上新版本之前，先检查一下”。

坑：9.3/9.4 的升级可靠性有专门跟踪项 #145252。分享则有明确行为边界：公开链接的访问者可以读取获分享的内容，不能把它当成只给同事看的私人链接。

功能叫“分享”，验收表上得再加一项“到底分享给了谁”。9.3 发布说明

9.4：界面更漂亮，旧更新程序可能更倔

更新内容： Web UI、插件和技能发现、从历史对话学习技能、Node 恢复、GPT Image 2.5、云会话控制与终端交互增强。

特点： 好用和好看都往前迈了一大步。

坑：#157818 记录了 9.4 → 9.6 被旧更新程序的 300 秒预算拦住。目标版修了超时，已经跑起来的旧程序却用不到那份修复。

你知道新房门能开。问题是，旧楼的电梯不送你上去。9.4 发布说明

9.5：Atomic Updates，听名字我差点放心了

更新内容： Atomic Updates、插件免重启安装、专家团队向导、会话归档、GPT Live、浏览器并排工作，还有侧问、评论和头像。

特点： 从“能用”向“日常工作平台”明显扩张。

坑： 有 Windows 启用 Slack 后启动严重卡顿的报告 #155152，以及插件越多启动越慢的报告 #155859。原子更新提供了保护机制，但包、数据、插件、服务不能因此被当成一个必然同时成功的动作。

名字很有安全感。老用户还是得看自己的那套配置能不能过。9.5 发布说明

9.6：功能清单长了，存量状态的压力也暴露了

更新内容： 未完成工作恢复、30 天用量、GitHub reader、远程 Files／Memory／Skills、持续会议笔记，以及更多模型。

特点： 工作场景更完整，运行状态更可见。

坑： 大型会话库的 SQLite I/O 和 WebUI 超时调查 #160386，Windows 插件捕获、Cron 和降级 schema 限制的报告 #162514，都提醒我们：新装空库跑得好，不代表老用户的历史库一样轻松。

有时候，“你使用得太久、留下得太多”，反而成了升级时最需要测试的条件。9.6 发布说明

9.7：长会话和更新保护继续补课

更新内容： 高负载与长对话性能、备份与回滚保护、从 9.5 升级的修复、Agents API、ChatGPT 登录 Beta，以及多端聊天增强。

特点： 明显在收拾前几版的大型存量环境。

坑：9.7 → 9.8 仍有托管更新卡在激活、直到主机重启的事故报告 #164800，以及 macOS Desktop 更新卡住的报告 #164695。这些是旧版本升级路径的事故，不应直接写成今天的 10.1 已经复现同样问题。

每次读到“改进升级可靠性”，我都会很开心。随后去看 Issue，再把开心调成谨慎。9.7 发布说明

9.8：专门补可靠性，仍留下过明确的发布缺口

更新内容： Agent 结果回传、Codex 内存、插件设置保留、更新恢复、Windows 会话，以及 Matrix、Telegram 的修复。

特点： 比起大规模加功能，更像一版集中的稳定性修补。

坑： 当时 #164066 明确指出部分升级修复在主分支，却不在 9.8 发布包；旧 V2 迁移凭证也有阻断问题 #164842。后者已在 9.9 获得修复。9.8 对 GPT-6.1 Sol 的支持，官方也明确写过仍不完整。

版本号不能替代发布内容，模型名出现在列表里，也不代表整个运行链都准备好了。9.8 发布说明

9.9：模型终于补齐，恢复问题还在接力

更新内容： 托管 Codex 0.160.0 与 GPT-6.1 Sol、WAL 所有权检查、后台技能与 Cron、Windows 会话、消息投递和 Node 退出挂起修复。

特点： 官方 Changelog 明说，除让已宣传的 Sol 能力在托管 Codex 中生效，没有有意扩大功能范围，重点就是修补。

坑： 临时交接数据库变化导致恢复受阻 #167557，旧迁移凭证绑定错误 #167428，Windows 飞书等插件加载失败 #167579。今天的 10.1 已纳入对应多项修复，不能继续全部当作最新版原样未修。

9.9 的发布验证还明确：Telegram 三项集成检查被豁免、未运行，Android APK 跳过。这不等于全部测试没做，也不等于渠道验收可以省掉。

上一版负责把功能送到，下一版负责把恢复带回来。老用户在中间负责保管所有证据。9.9 发布说明

8.33：给八月老底子补安全和模型

更新内容： 安全回补、GPT-6 Astra、Fable 5.1、GPT Image 2.5，以及模型路由、Discord 和依赖安全修复。

特点： 基于八月代码，补重要修复和必要模型兼容，不追着整个九月功能一起跑。

坑： 它是 Gateway-only 的延长稳定版。不能以为核心换成 8.33，手机、桌面和所有第三方插件就同步升级；也不是每一项九月功能都被搬过来。

不想追快车？官方开了一条慢车道。但还是得看清车票写了什么。8.33 发布说明

8.34：113 个审计筛选修复

更新内容： 回补升级、Doctor、认证、会话、插件、渠道、文件和沙箱等 113 个审计筛选修复单元。

特点： 主要保护那些已经积累下来的凭据、历史、插件和服务归属。

坑： 更新集中在修复，不意味着没有配置修复与迁移。第三方插件仍要独立验证，不能把“延长稳定”理解成“完全不碰存量状态”。

老用户看到“保留配置”，会比看到一个新按钮更开心。8.34 发布说明

8.35：当前延长稳定通道的落点

更新内容： 更安全的更新与恢复、完整的 Agent／CLI／Cron 结果、Gmail／IMAP／Matrix／Telegram／MCP 修复、Codex 内存与模型兼容。

特点： 在八月代码线上继续补可靠性。官方发布文案称其当前等价于 LTS，但没有因此承诺永久支持。

坑： 它不是九月和十月所有修复的大合集，也不是通往 10.1 的官方必经桥。此处没有独立证据证明“8.35 必有一个专属大 bug”，就不编一个给你凑数。

若核心诉求是安全回补和少变化，可以评估它；若需要十月新能力，要测试真正的十月目标。8.35 发布说明

10.1-beta.1：新能力和插件兼容一起上桌

更新内容： Code Mode 的 store/load、Workboard、YouTube 卡片、编码助手历史导入、外部备份、无模型条件检查、技能检索、企业仓库支持等。

特点： 十月功能线的集中预览，资料和工作流整合更深。

坑： 发布说明明确列出第三方插件的 SDK breaking change：使用退役兼容入口或整库会话 helper 的插件，必须迁移。既有 Agent 转成 Claws、不可变安装采用，都有明确授权和适用条件，不能读成所有用户自动被转换。

新功能目录很好看。真正升级之前，先问问插件作者：你跟上了吗？Beta 1 发布说明

10.1-beta.2：没加新能力，先救升级和回复

更新内容： 归档和中断更新恢复、旧 macOS 与 Windows 任务恢复、Telegram／Discord 投递、插件与云运行时修复。

特点： 官方明确说没有新能力，是基于前一 Beta 的热修版，覆盖 40 个间隔提交，不能把整份十月累计变化又算一遍。

坑： 发布说明直说：这些修复改不了你机器上已安装的旧更新程序；如果旧 preflight 已拒绝，可能要按原安装方式先手动安装新 CLI，再跑 Doctor。它仍是预发布，不是稳定性承诺。

更新程序不让你更新的时候，你需要先更新更新程序。读着像绕口令，碰上以后就像加班。Beta 2 发布说明

10.1：今天早上的正式版，终于把不少坑填进发布包

更新内容： 会话与缓存迁移、媒体和回复、Code Mode、Workboard、MCP Apps、Claude Haiku 5.5；还集中修复更新恢复、Doctor、Windows 插件、数据库工作进程、Cron、子 Agent 和本地模型索引内存等问题。

特点： 既有新能力，也有一大批直接关系存量升级的修复。9.9 的交接数据库恢复、延迟导入凭证、Windows 插件路径，以及老 Linux 快照问题，已有对应修复进入发布说明。

但别漏看十月的 SDK 断点：若第三方插件仍导入退役的渠道、配置、运行时聚合入口或整库会话 helper，到了 10.1 必须适配。9.9 还能加载的插件，不能自动当成 10.1 兼容。旧的部分 context 命名别名仍保留，别跟真正移除的 API 混为一谈。

坑： 它在北京时间 10 月 11 日 07:54 才发布。我们能确认修复被纳入，不能替你确认几十 GB 历史、你的插件和中文模型已经长期运行通过。

而且今天已经出现 #168750 等同一事故的报告：Ubuntu ARM64 从 9.5 升 10.1，激活 Doctor 失败并留下核心与 Codex 插件版本不一致；后续独立 CLI 修复完成，真实回复恢复。这是特定环境的一次事故，不能当成三台机器故障，也不能推断所有 8.2 用户都会中招。

也有尚未随本版发布的修复：Windows 硬链接校验 #164308、晚期失败后服务恢复 #167343。Qwen／vLLM 的特定严格模板，还存在最后一条 system 消息触发 HTTP 400 的报告 #168787，修复在主分支，不应误写成发布包已修。

10.1 有成功完成的官方验证流程；发布记录同时注明 Telegram beta E2E 证据未提供，Android APK 本次跳过。测试通过值得承认，验证边界也得看清。

所以，我认可 10.1 在补课。但生产升级的验收单，还是得自己签。10.1 发布说明

列完这十五版，最容易冒出来的念头是：那我是不是得一站站升过去？

不用。

官方没有要求 8.2 用户依次安装九月每个版本，也没有要求先过 8.35。特定更旧状态有桥接要求，要按数据形态识别，不能把旧版本迁移规则一股脑套给所有人。

真正要弄明白的是：第三方插件能否适配目标 SDK，Node 和后台服务是否使用正确运行时，历史状态能否迁移，本地记忆模型是否保持一致，旧补丁会不会被替换。

10.1 目标的 Node 支持仍是 >=24.16.0 <25 或 >=26.1.0。终端里版本正确，也要看后台 Gateway 实际用哪个 Node。

模型这件事尤其要克制。已经能用的中文本地模型，先保留文件、校验值、服务构建和向量维度。升级后复测中文长句和真实语义查询。没有证据要求全库重建，就别顺手把索引和模型一起换了。

还有一个不那么好听的事实：backup create --verify 是校验过的便携归档，并不是整个机器原样快照；--dry-run 是更新计划检查，也不是实际迁移演练。

备份覆盖要核对，重要存量环境要另做停写后一致性快照。退回旧包，也不会自动退回新数据库格式。官方 10.1 升级指南

开发者持续发版、持续修复，我是认可的。

但老用户真正希望看到的，还包括清楚的插件兼容范围、明确的数据迁移边界、能保护旧修复的流程，以及失败后不靠人肉猜测的恢复入口。

版本号变了，插件可能还没跟上。

核心启动了，渠道可能还没回消息。

数据库打开了，老历史不一定都验证过。

任务做完了，结果不一定送到原会话。

这个差距，才是升级焦虑的来源。

每次新增一个自动化，我就多一条想保护的工作流。每次修好一个中文模型，我就多一份不想重来的配置。

开发者看到版本之间的代码差异。用户看到的是自己几个月攒下来的生活秩序。

我想请一个管家，不想为了保住管家，再给自己安排一份运维值班。

第一关，盘点旧环境。记下安装方式、实际服务账户、Node、插件来源、所有本地补丁，以及模型和状态路径。

第二关，准备真的能还原的备份。除了便携归档，重要环境保留停写后的完整恢复点和匹配的旧软件版本。

第三关，在独立副本直接演练 8.2 → 10.1。副本不能继续往生产渠道发消息、跑同一批定时任务，绝对路径也不能偷偷指回生产数据库。

第四关，逐渠道真实收发。飞书、QQ、微信、Telegram 或其他实际渠道，一条条测；健康检查绿了，也要看用户收到的答案。

第五关，验记忆和后台工作。真实中文检索、Cron、子 Agent 单次回传、历史会话和重启恢复，全都要过。

第六关，留观察期。副本通过后再安排生产切换，重点观察内存、WAL、磁盘、延迟和任务投递。刚发版就少几个 Issue，不代表已经证明稳定。

失败时先保存报告和恢复原件，再按具体指导处理。不要删除迁移凭证、交接数据库，也不要修改 schema 标记强行放行。

如果维护余量不够、也没有迫切的新功能需求，可以先评估 8.35 extended-stable。如果目标就是最新版，那么今天该演练的是 10.1，不能继续拿 9.9 的结论当最新判断。

我希望 OpenClaw 继续快速进步。

但用户没有义务用所有存量数据，给每个刚发布的版本做第一轮现场验收。

十五个后续版本，可以认真读，可以挑着测，也可以暂时不切生产。

真正值得升级的那一刻，是新能力到了，旧工作也还在。

别只告诉我“这版功能更强”。

请让我看到：我的历史带过去了，中文记忆还好用，渠道还能回话，任务还能继续，出了问题有路退。

到了那时候，我点“升级”会很痛快。

在那之前，功能我欣赏，备份我先做。

资料口径：核验截至 2026 年 10 月 11 日；版本简称均省略 2026.。历史事故注明原版本，发布包纳入修复与现场彻底解决分开。Issue 数量和优先级不等于失败概率。

上期参考：摩卡乐园《OpenClaw 8.2 升级实录》。官方来源：Releases、10.1 发布记录、升级与恢复说明。逐版风险及刷新状态另附完整版本盘点表。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。