终于OpenClaw 从 8.2 爬到 10.3:软件升级了,我也快成运维了

“

更新按钮只管把版本号往前推，老用户还得负责把日子接回来。

上篇文章，我还在盘点：8.2 之后，怎么又冒出来十五个后续版本？

那时候，我的状态是——版本看了不少，升级还没敢动，且还在持续增长。

现在可以交作业了。

从 8.2 出发，先统一 Node，再到 9.5，跑一晚，补一份恢复点，最后升到 10.3。然后微信修一下，飞书再换一套插件（我之前用的独立插件）。

终于到了。

看到版本号的那一刻，我没有特别想庆祝。

我只想问一句：今天能不能先别发新版了，让我安安静静用一天？多 Agent、长会话、记忆、自动化，这些能力我还是想要的。不然也不会看了那么多风险，最后还是决定动手。

但这两天真正让我印象深刻的，不是新增了哪个按钮。

是“升级完成”这四个字，原来有这么多层。

先交代口径：这是我这台 Mac 从 2026.8.2 走到 2026.10.3 的实录，主要操作发生在 10 月 14 日至 16 日。不是所有人的必经路线，也不是把中间每个版本都装了一遍。本文说的完成，是核心升级和飞书接管落地，不是给所有插件、模型和办公功能盖一个“永不出错”的章。

📌 本文看点

动手之前，我底气还是有一点的。

毕竟每天都往 GitHub 备份。

有提交，有推送，有记录。看起来非常像一个认真保护数据的人。

一检查，关键数据库不在当前备份里。

不是 GitHub 坏了，也不是备份完全没用。工作区、配置、技能和不少历史资料确实在。问题是，共享状态库、主要 Agent 数据库，被忽略规则排除在当前提交之外。有些旧文件、归档甚至数据库旁边的辅助文件还在，但不能靠它们拼出一份“今天能恢复”的完整状态。

这就像出门前认真检查了行李箱，衣服、充电器一样不少。

护照没带。于是，第一步不是升级，是补恢复点。

保留原来的 GitHub 备份，只补关键数据库、对应配置、凭据、服务定义和必要的运行资料。放外接盘，加密，随机密码进本机钥匙串。

而且，不能只是把运行中的 SQLite 文件随手复制过去。已经提交的新数据，可能还在旁边的 WAL 日志里；只拿主文件，不一定拿到了完整状态。

这次做了在线一致快照，又把加密映像打开，文件读回来，数据库完整性再查一遍。

“备份成功”是有一份文件。“恢复准备好了”是知道它里面有什么，也验证过它能读回来。版本号还在 8.2。

我的升级计划，已经长出了灾备章节。

— 每天有备份，不代表最关键的数据库已经装进恢复箱。

接着查 Node。

终端里是 24.21.0。看上去符合要求，可以往前走了。

但后台 Gateway，实际跑的是另一份 Node 22；启动入口，又指着另一个 Node 版本目录里的 OpenClaw。

同一台 Mac，同一个助手，终端和后台各过各的。

— 终端和后台，可能根本没踩在同一套运行环境里。

你在前台问“升好了吗”，后台可能还穿着旧衣服上班。

所以先不碰核心版本，只统一运行环境：终端、npm 安装根、后台启动入口，指向同一份受支持的 Node 24 安装。

同时保留原来的环境变量、证书、启动包装脚本和服务参数。听起来，就是改几个路径。

第一次，没成。旧服务卸载命令已经返回，系统内部却还没完成移除。脚本紧接着加载新服务，撞上了竞态。表面是 error 5，继续查系统日志，里面是 Operation already in progress。

翻译一下：你先别急，我这边还没收拾完。

这里得讲句公道话：这是本次切换脚本缺少等待，不是证明了 Node 24 不兼容，更不能算成 OpenClaw 核心自己的崩溃。

按预案恢复原服务，再把流程补完整：等服务条目真的消失，等旧进程真的退出，才加载新定义。相关回归测试三项通过。重新执行，这次成功。

软件还没升级，我先补了一课 macOS 后台服务生命周期。

原本想让 AI 帮我少干点活。它先帮我拓宽了知识面。

准备往十月版本走时，又听到一个说法：先到 9.5，再往上升。

这事不能靠“网上都这么说”。查官方说明，再查本机历史。

官方给七月以前的老安装保留了 9.5 这座桥，用来完成一批旧状态导入和 Doctor 迁移。我的安装历史确实更早，不是第一次装就从 8.2 开始。

所以，这次选了保守路线。

8.2 → 9.5 → 10.3。

注意，不是把 9.1、9.2、9.3，一路挨个装到 10.3。

也不是“只要当前显示 8.2，就一定不能直接升”。本机遗留检查没有命中那批已检查的退休格式；选择桥接，考虑的是更早的安装历史，以及存量状态的风险。

如果遇到特定旧记忆索引，还可能有单独的 9.7 桥接要求。我的这次检查，没有把它默认加进来。

本来以为版本号是一条直线。后来发现，是一张地铁图。你现在在哪一站，还得看你从哪条线过来的。

9.5 升好后，我没立刻接着冲。让它先跑了一晚。

以前过夜是为了睡觉。现在过夜，还能顺便当一段观察期。

— 这是本机老安装的保守路线，不是所有 8.2 用户的统一必经站。

第二天，9.5 基础运行正常。

只读 Doctor 查了 66 项，没有 error，但有 6 项 warning。不是一片无瑕的绿色，也没必要为了“看起来干净”，顺手把所有设置都改一遍。

数据库和迁移记录继续核对。

然后，发现会话索引比旧基线少了四条。

这种时候，你很难保持一个成年人的松弛。

脑子里已经开始自动播放：是不是丢历史了？是不是备份没做好？现在回退还来不来得及？

但查下去，这四条都是定时任务会话。

其中三条，对应归档找得到，旧基线里的 58 条转录事件逐条比对，全对上；另一条，在旧基线里本来就没有转录内容。

这四处差异有了解释，不能直接宣布“丢了四段记忆”。同样，也不能因为查清了这四条，就宣布所有历史都做过逐条全量对账。

另一个变化，是一个系统维护任务换了标识和执行形式。继续对照官方常量，确认是系统任务重建，不是凭空消失了一个业务任务。

最后，在 9.5 再补一个新的加密恢复点。

九份数据库，十一万多个文件和链接，封装后大约 1.42 GiB。解密读回、校验、检查，再把临时明文清掉。旧的 8.2 恢复点，也留着。

因为数据库一旦迁移了，回退就不是“把旧包装回去”这么简单。旧程序未必读得懂新数据库，得有匹配时点的软件、配置和数据。

我只是想更新一个 AI 助手。

现在已经能熟练区分：安装包回退，和状态回退。

后面的事情，大家应该猜到了。

10.3 升好了。微信插件出了问题。飞书通道也挂了。

那种熟悉的感觉又来了：版本号已经到了新世界，机器人还没赶上车。

微信这一边，单独更新插件后恢复。它有自己的版本线，不能默认跟着核心一起到位。

飞书这边，没那么省事。

我用的原插件，是飞书／Lark 开放平台团队维护的 @larksuite/openclaw-lark，本机版本为 2026.7.16。

它还在导入旧 SDK 入口：

到了当前核心，这个入口已经不再导出。插件加载报的是：

这次的现场不是“飞书突然不喜欢我了”，也不是先重新登录就能解决。

是核心和插件之间的接口，已经对不上了。

— 核心版本到了，旧插件未必适配了新的接口。

去社区看，还真有相同类型的报告：9.5 正常，进了 10.x，旧插件卡在 command-auth。甚至能看到 Issue 被关闭。

但关闭的含义，不一定是“修好了”；也可能是责任边界被划到了外部插件，需要插件适配。对维护者来说，这是分类处理。

对我来说，这是聊天框还在等回复。

这时，另一条路摆到面前：先换成 OpenClaw 官方仓库的 @openclaw/feishu。

先把名字分清。

@larksuite/openclaw-lark，是原来那套飞书／Lark 插件。

@openclaw/feishu，是 OpenClaw 官方仓库这套飞书通道插件。两个维护方，两套发布节奏。不能只看见“官方”两个字，就以为能力、配置和兼容性都一样。我也没打算因为一次故障，就把原插件连同授权彻底清走。

问题很具体：能不能先让另一套插件接管聊天，等原来的适配好了，再切回去？

可以准备这条路，但不是无损换皮。

官方 Feishu 有聊天、媒体和一批文档工具，却不是原 Lark 功能的全集。原插件的个人 OAuth 日历、任务、Sheets、个人消息历史与搜索，不能默认跟过来。

应用／机器人身份能看的文档，也不等于我个人能看的所有文档。

同一个机器人，不等于同一套能力；同一份应用密钥，也不等于同一个访问身份。

这不是给哪个插件排座次。

是切换之前，先看清楚自己愿意暂时少什么。

到了这一步，我最不想做的，就是一边救飞书，一边把好不容易恢复的微信再带走。所以，先做当前 10.3 的小型加密切换恢复集。不是拿昨天的 9.5 数据库，往今天的 10.3 上硬盖。

然后在候选配置里核对差异，跑官方预检，再离线加载官方插件：38 个发布模块、14 个工具工厂，通过。

这只能证明加载和注册这一层能过，还不能证明真消息一定收发成功。

正式改动，只有五处。

原 Lark 关闭，官方 Feishu 打开；再移出三个不兼容的旧设置：scopes、footer、对象形的 capabilities。

应用没换，密钥没换，WebSocket 没换。群里仍然需要 @，原有配对记录保留，没有为了方便把私聊权限放开。

旧插件不卸载，个人 OAuth 不撤销。

— 先由官方 Feishu 接管聊天；旧 Lark 和个人授权保留，未来验证兼容后再切回。

10 月 16 日早上 8 点 38 分，官方 Feishu 接管。

这次是热切换。Gateway 进程没换，没再安排一次整网关重启；微信、QQ、企业微信仍在运行。

日志里能看到插件替换、热加载生效和 WebSocket 就绪。原来那条 command-auth 导入错误，没有再出现。

看着连接状态，我终于松了口气。

但验收单没有跟着一起失忆：本人私聊、群内 @、图片、文件、长回复、定时投递和唤醒重连，仍要按真实使用核对。

原有两条飞书定时投递也留着。其中一条切换前已有上次执行失败记录，不能因为换了插件，就擅自改成“已经成功”。

我现在对绿灯，已经产生了一种成熟的感情。看见了，挺开心。但还要发句话试试。

这次真正走过的路，可以压成一句话。

补齐 8.2 恢复点，统一 Node 24，升 9.5 并观察，补齐 9.5 恢复点，锁定 10.3，逐个处理插件，再让官方 Feishu 临时接管。

看起来很长。

但里面有些是我的历史包袱，有些是我选择的保守措施，不是 OpenClaw 要求每个人照单全做。

如果你准备动手，我建议带走的是下面六件事。

第一，先问“备了什么”，别只问“有没有备份”

配置、数据库、凭据、服务定义、匹配软件版本，要能对应。每天 push 很好，但先确认权威数据有没有进去。

第二，查后台实际跑什么，不只看终端输出

Node 路径、安装根、启动入口、服务环境，四样对上。重装全局包，并不自动证明后台换了版本。

第三，按自己的历史决定桥接路线

新装的 8.2，和从更早版本一路升上来的 8.2，不能只凭屏幕上同一个数字，就认定迁移条件相同。

第四，插件单独验，别把核心升级当全家桶升级

尤其是消息通道、个人 OAuth、办公工具和手工补丁。包能安装、插件能加载、账号能连接、真人能收到回复，是四件事。

第五，回退要回对对象

服务路径切错，可以只恢复服务定义。数据库已经升代，就要用匹配的恢复集。临时换插件，则只恢复相关字段，不要拿整份旧配置覆盖今天的新变化。

第六，别拿生产助手练勇气

先做不接生产消息、不跑生产定时任务的隔离演练。留窗口，留恢复材料，留观察期；不要一口气把核心、Node、模型和所有插件一起换掉，然后对着十种报错猜谁先动的手。

原 Lark 以后如果发了兼容版，也得先验证再回切。不是把现在这个坏版本重新打开，就叫恢复。

公平地说，OpenClaw 一直在进步。

多 Agent、长期记忆、工具生态、自动化，确实有吸引力。没有这些价值，我也不会一路折腾到这里。

开发者持续修复，值得肯定。

但老用户的期待，其实没有那么复杂。

我愿意为新能力花时间。可每次更新，都得重新确认历史、认证、插件、后台服务能不能一起过桥，这个成本，不能永远算成用户的“动手乐趣”。

发布列表上，是一版接一版的进步。

落到一台用了几个月的机器上，是一层接一层需要接住的旧状态。

上篇我还在吐槽：怎么又出了这么多版本？

这篇终于可以补上后半句：版本我追上了一段，坑也亲手走了一段。

没有传说中的一键丝滑。

有恢复点，有失败后回退，有过夜观察，也有升完核心再去救插件。

这趟从 8.2 到 10.3，我最想要的新功能，是下次升级能少用一点我自己。

— 助手更新到了 10.3，用户也顺便多了一份运维工作。

至于下一个版本？

发布说明我会看。升级按钮，让我先缓缓。

记录截至 2026 年 10 月 16 日。文中版本简称均省略 2026.；运行连接、真实消息验收和长期稳定性分别表述。本文不提供脱离环境可直接照抄的安装命令，也不把本机经历推断为所有用户必然遭遇。

前期参考：

摩卡乐园《OpenClaw 8.2 升级实录：功能真香，我劝你别升》。

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

技术依据：10.3 版本升级说明、同类 Lark 兼容故障报告、9.5 发布说明、10.3 发布说明。社区故障及 Issue 关闭含义，按本次 10 月 15 日调查记录，不代表其此后的实时处理状态。

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