OpenClaw 如何安全升级?这里教你三步走

很多人升级工具，习惯其实都差不多。

看到新版本了，先跑个 update。版本号变了，终端也没报错，心里就默认这次升级已经完成了。

但 OpenClaw 这类东西，不太一样。

因为它不是一个单纯的本地软件。它背后往往还挂着消息入口、网关、自动化链路，甚至是你每天都在用的工作流。

所以升级这件事，真正该问的，根本不是版本有没有升上去。而是升级之后，它还能不能继续稳定工作。

我现在看 OpenClaw 升级，脑子里其实就一条线：

先预演，先留痕，再验收

如果这三步没走完，那就不叫升级完成。

下面这套不是官方标准流程，而是我现在自己在用的一套 OpenClaw 升级 SOP。

一、第一步别急着升，先预演

我现在升级 OpenClaw，第一步不会直接正式执行。我会先跑一遍预演。

openclaw update --dry-run

这一步看起来很朴素，但真挺重要。

因为很多升级翻车，压根不是升级动作本身有多复杂，而是你正式执行之前，环境就已经不对了。

比如当前版本识别异常、目标版本解析有问题、node 本身有问题、权限有问题、包管理器链路不通，这些都可能在真正升级之前就把你绊住。

dry-run 的价值，不是走个形式。而是先把地上的雷找出来。

而且这一步会顺手帮你回答几个很基础，但又很关键的问题：

• 当前版本识别正不正常
• 目标版本识别正不正常
• 升级链路到底走的是 npm 还是 pnpm
• 系统有没有已经在报一些你本来没注意到的错

这些问题如果在正式升级前不看，后面一旦出事，你就很容易把锅甩给升级本身。

其实不是。有时候只是环境早就歪了。

二、dry-run 没问题，也别裸升，先把现场留住

如果 dry-run 跑完没报明显异常，下一步我也不会直接无痕升级。

我更推荐一边升级，一边把过程完整存下来。

mkdir -p ~/.openclaw/workspace/backupsopenclaw update | tee ~/.openclaw/workspace/backups/openclaw-update-live-$(date +%Y%m%d_%H%M%S).txt

这条命令真正值钱的地方，不只是留个日志。而是后面一旦出了问题，你至少知道升级过程里到底发生了什么。

它卡在了哪一步。是升级命令自己失败了，还是升级结束以后，运行状态出了异常。

很多人一看到升级不顺，就开始重试、乱改配置、删东西，甚至直接重装。

但坦率地讲，这种时候最该做的，恰恰是先把现场留下来。

你先有证据，后面排障才有抓手。

如果你想再稳一点，我建议升级前再补一组状态快照。

openclaw --versionopenclaw status --deepopenclaw security audit --deepwhich openclawwhich npmwhich pnpmnode -v

这组命令的意义很直接。

后面如果出了问题，你可以拿升级前后的状态做对照。到底是版本没变，还是状态异常；是安全审计多了新告警，还是命令路径和你以为的根本不是一套东西。

这种对照特别重要。

因为很多排障失败，不是因为问题太难，而是因为你手里没有升级前的基线。

三、真正容易被忽略的，是升级后的验收

很多人以为 openclaw update 跑完，这事就结束了。

其实不是。

对 OpenClaw 这种 agent 工具来说，最重要的从来不是命令跑完了没有。而是它升级之后，整条链路还能不能继续跑。

所以我一般会固定跑下面这几条。

openclaw --versionopenclaw status --deepopenclaw security audit --deep

这三条分别在看三件事：

第一，版本是不是真的更新了。第二，系统状态是不是正常。第三，安全审计有没有出现异常新增。

但说真的，这还不够。

因为 OpenClaw 真正值钱的，从来不是它在你本地看起来没问题。而是它跟真实世界的连接还在不在。

如果你的主入口是飞书，那你就真的发一条测试消息过去。比如发一句：「升级后测试」。

看它能不能正常回复。

这一步特别朴素。但也特别关键。

因为很多升级，表面看全绿，真到消息入口一测，链路已经断了。

本地命令正常，业务入口失灵。这种升级，不能算成功。

四、我现在判断一次升级是否成功，只看四项

我现在对 OpenClaw 升级的判断标准，其实很简单。

不是看版本号升了没有。而是看下面这四项，是不是同时成立。

1、版本已更新

openclaw --version

2、系统状态正常

openclaw status --deep

3、安全审计无异常新增

openclaw security audit --deep

4、真实回复链路正常

如果你的主入口是飞书，那就真的去测飞书。如果你的入口是别的通道，那就测你真实在用的那条入口。

只有这四项同时成立，我才会把这次升级算作真的完成。

少一项都不算。

因为升级成功，不是把版本号升上去，而是升级之后，它还能继续稳定地跑下去。

五、如果升级卡住了，先别乱动

升级过程中如果长时间没输出，或者你明显感觉它卡住了，我更倾向先中断当前进程，再重新采集状态，而不是在未知状态下继续追加操作。

最简单的做法就是先 Ctrl + C，然后立刻重新采集当前状态。

openclaw --versionopenclaw status --deepopenclaw security audit --deep

接下来再去对照升级前留下的日志和快照，判断问题到底属于哪一类。

是升级命令执行失败。还是核心升级已经成功，但插件同步异常。还是 gateway 重启异常。还是通道异常。还是配置变化带来的连锁问题。

最忌讳的一种做法，就是一慌就开始乱删 node_modules、乱改配置、连续重复 update，或者在没判断原因之前先来一句：「重装试试。」

这种做法有时候会把一个小问题，硬生生放大成大问题。

六、最后收成一句最实用的话

我现在对 OpenClaw 升级的统一口径，其实就一句：

先预演，先留痕，再用版本、状态、审计、回复能力四项验收。

升级这件事，真正重要的从来不是把版本号升上去。而是升级之后，它还能继续稳定地跑下去。

这才叫升级成功。

如果你也在折腾 OpenClaw 这类长期运行的 agent 工具，欢迎把你的升级踩坑经历留在评论区。有些坑，提前知道一条，真的能少折腾半天。

@宇怡辰