写在前面：

升级失败最可怕的是什么？

不是升级过程出问题——问题总有办法解决。最可怕的是没有备份，一旦出错，连退路都没有。

好在我用的是腾讯云轻量服务器，有快照功能。每次出问题，回滚快照，所有Agent重新活过来，然后我才能继续摸索、总结经验。

今天的这篇文章能写出来，全靠这些快照。没有快照，我现在可能还在从零重建整个系统——不仅仅是重建系统，还要重新训练所有Agent。

如果你也在用云服务器，升级前先做快照。这不是建议，这是救命稻草。

先说明一个重要情况：

如果你是用腾讯云轻量服务器部署的OpenClaw，一般情况下，升级很简单——直接点击腾讯云控制台的"一键升级"按钮就行。

但这次不一样。2026.4.11版本是个重大版本升级，配置文件的schema结构发生了变化。腾讯云的"一键升级"不了解这个变化，升级完成后启动就报错。

所以我才不得不介入，手动排查问题、修改配置、重新安装。整个过程才变得这么曲折。

但无论是一键升级还是手动升级，有一点必须记住：升级前先做快照。

这一步不能省。

"升级吗？"

"不敢，怕挂。"

这是最近OpenClaw用户群里最常见的对话。

OpenClaw在4月份发布了八次版本更新——从2026.4.1到2026.4.11，共发布8个正式版本（另外还有3个beta版本）。每次更新都有新功能、新优化，让人心痒。但升级失败的案例也此起彼伏：有人升级后Agent全部失联，有人卡在安装进程二十分钟，有人启动报错一脸懵逼。

我也是受害者之一。

准确说，是受害者×4。四次升级，四次踩坑，最后才摸出一条成功升级的路。

今天把这段血泪史分享出来，希望能帮后来人少走弯路。

第一次：全军覆没，AI把自己杀了

第一次升级，我犯了一个致命错误——让AI自己升级自己。

当时看到新版本发布，心想：OpenClaw不就是个AI Agent吗？让它自己执行升级脚本不就行了？

天真。

升级脚本跑起来之后，系统弹出approval确认窗口。正常情况下，用户手动点个确认就行。但AI在跑脚本，没人点确认。进程卡住，超时，被系统杀死。

然后，所有Agent挂掉。

我打开后台一看，一片空白。原本跑得好好的8个Agent，全没了。那种感觉，就像回家发现房子塌了。

还好我用的是云服务器，有快照功能。赶紧回滚快照，Agent们重新活了过来。但失败原因？不知道。只知道AI自己杀自己的路，走不通。

教训：AI可以帮你做事，但不能帮你升级自己。就像医生不能给自己做手术，AI也不能自己改自己的底层。

第二次：卡在npm安装，二十分钟的煎熬

有了第一次的教训，我决定自己动手。

从官网拉取最新代码，执行安装命令。进度条开始滚动，一切顺利。直到卡在这里：

download-lib.js: downloading from GitHub CDN...

整整二十分钟，进度条纹丝不动。我查了下原因：OpenClaw有一些原生依赖，需要从GitHub CDN下载。而GitHub CDN在国内，你懂的。

AI进程还在运行，但安装卡死了。我又不敢强制中断，怕把环境搞乱。最后只能硬等，等网络抽风结束，等它终于跑完。

装完之后我查了下时间——从开始到结束，四十七分钟。一个升级，差点耗掉我一个小时。

教训：npm在国内安装原生依赖，就是一场赌博。赢了快，输了等死。

第三次：schema变更，启动报错

第二次升级虽然慢，但好歹成功了。第三次，我遇到了更诡异的问题。

安装顺利，但启动时直接报错：

Error: channels.feishu.accounts.main: invalid config: must NOT have additional propertieschannels.feishu.accounts.vegeta: invalid config: must NOT have additional propertieschannels.feishu.accounts.piccolo: invalid config: must NOT have additional properties...

什么意思？

新版本的schema变了。旧版本允许的botName、enabled这些字段，新版本不认了。我的配置文件里还留着这些字段，启动就被拦截。

我试了openclaw doctor --fix，希望能自动修复。结果：

No auto-fix available for schema migration

行，自己动手。用jq把多余字段删掉，再启动，终于成功了。

但这个问题让我后怕：如果我升级前没看过changelog，如果我没有技术背景知道怎么改配置，这次升级是不是就废了？

教训：大版本升级，先看schema变更。别指望工具能自动修一切。

第四次：成功升级，32.7秒的胜利

总结前三次的教训，第四次我做了完整规划：

第一步：备份

云服务器有快照，但我还是多做了一手——把 ~/.openclaw 整个目录打包：

tar -czf openclaw-backup.tar.gz ~/.openclaw

这个习惯救过我不止一次。

第二步：检查配置

翻了下最新版本的schema，提前把不兼容的字段删掉：

jq 'del(.channels.feishu.accounts[].botName, .channels.feishu.accounts[].enabled)' ~/.openclaw/openclaw.json > ~/.openclaw/openclaw-fixed.json && mv ~/.openclaw/openclaw-fixed.json ~/.openclaw/openclaw.json 

第三步：换pnpm

npm卡了我二十分钟，这次换成pnpm。pnpm对依赖的处理更快更稳，尤其在国内网络环境下。

第四步：手动执行

这次我完全没让AI碰升级命令。自己打开终端，自己敲命令，自己看输出。

结果：

pnpm install -g openclaw@latestDownloading openclaw@2026.4.11: 46.82 MB/46.82 MB, doneDone in 32.7s

三十二秒。

上次四十七分钟，这次三十二秒。工具选对，效率差了八十倍。

启动，验证：

openclaw --version2026.4.11openclaw status所有Agent正常运行

成功升级。

小心：腾讯云控制台的版本号"假象"

还有一个小坑值得一提。

升级成功后，我去腾讯云控制台看了一眼——版本号显示的还是旧版本！

我心里咯噔一下：难道升级失败了？

又跑了 openclaw --version 和 openclaw status ，确认都是新版本。这才放心。

原因：腾讯云控制台显示的版本号是缓存的，不会实时更新。实际版本要以命令行输出为准。

所以，升级后别被控制台的显示误导。用命令行验证，才是最准确的。

最后总结：升级安全指南

四次升级，四次教训。我把它们总结成一份检查清单，供大家参考：

1. ⚠️ 升级前必须备份

· 云服务器：创建快照

· 非云服务器：打包 ~/.openclaw 目录

2. ⚠️ 不要让AI执行升级命令

AI可以帮你分析问题，但升级过程涉及进程重启，AI会把自己杀死。这一步必须手动。

3. ⚠️ 升级前检查schema变更

新版本可能不兼容旧配置字段。提前看changelog，提前改配置，别指望自动修复。

4. ⚠️ 用pnpm代替npm

pnpm更快、更稳、更省空间。尤其在有原生依赖的场景下，差距明显。

5. ⚠️ 升级后验证

openclaw --version  # 确认版本openclaw status     # 确认Agent状态

🔧 完整命令汇总（可直接复制使用）

# ===== OpenClaw 安全升级完整流程 =====# 1. 备份（云服务器做快照，非云服务器打包目录）$ tar -czf openclaw-backup.tar.gz ~/.openclaw# 2. 修复配置（删除schema不兼容的额外字段）$ jq 'del(.channels.feishu.accounts[].botName, .channels.feishu.accounts[].enabled)' ~/.openclaw/openclaw.json > ~/.openclaw/openclaw-fixed.json && mv ~/.openclaw/openclaw-fixed.json ~/.openclaw/openclaw.json# 3. 验证配置$ cat ~/.openclaw/openclaw.json | jq '.channels.feishu.accounts'# 4. 升级安装（用pnpm，更快更稳）$ pnpm install -g openclaw@latest# 5. 启动服务$ openclaw gateway start# 6. 验证版本$ openclaw --version$ openclaw status

升级不可怕，可怕的是裸奔。

备份在手，心中有数。前路漫长，祝大家都能成功升级。

🔺关于云趣星图：企业上云的专业伙伴

作为腾讯云、火山引擎、京东云等主流云厂商的授权合作伙伴，云趣星图自创立以来，始终专注于为企业提供专业、高效的上云与用云服务。不论是初创团队的轻量上云需求，还是中大型企业的复杂系统迁移与架构优化，云趣星图均能依托定制化的解决方案与扎实的技术服务，协助客户在控制成本的同时，充分挖掘云计算带来的业务价值。