升級 2026.4.24 踩坑後，我終於認真建了 agent 的版本管理流程

昨晚看到 Reddit 上有人貼了一篇「Do not upgrade to 2026.4.24」，點進去一看，是熟悉的噩夢場景：gateway 起不來、約 1617 個檔案被 prune 掉、作者附了三個 GitHub issue，結論是先降回 .23 再說。

看完我第一個反應不是「天啊好可怕」，而是「還好我上次就被這種事教過了」。

說個我自己的故事。幾個月前我第一次把 OpenClaw 正式接進 team 的工作流——不是玩具，是真的在跑一些自動化任務。那次升了一個 minor version，沒看 changelog，gateway 行為改了一個地方，我的 agent skill 靜默失敗，整整兩天沒人發現，直到有個同事說「欸你那個自動報告好像壞了」。

那次之後我才認真想：agent 的穩定性跟一般服務不一樣。一般服務掛了你馬上知道，agent 壞了它可能還在「正常執行」，只是產出的東西不對。這讓版本管理這件事的重要性直接升了一個等級。

我現在的做法

固定版本，不追最新。 我的環境現在是 npm install [email protected] --save-exact，不用 ^ 不用 ~，就是釘死。追最新版是開發者的事，agent 生產環境不是實驗室。

升版前先跑 canary。 我在本機另開一個 openclaw-canary 的資料夾，跑一樣的 skills 但完全獨立。新版本先在這裡跑至少兩天，看 gateway log 有沒有異常，有沒有 unexpected prune，再決定要不要升 main 環境。兩個環境同時跑，多花的資源其實很少，省的麻煩很多。

降版流程要提前演練。 很多人包括我之前都是「等到炸了才想怎麼降版」，但降版不是 npm install [email protected] 那麼簡單，你還要確認 state 檔案的格式有沒有 migration，有些版本升上去之後 state 結構變了，直接降回去會讀不到舊資料。我現在的習慣是每次升版前先備份 ~/.openclaw/ 整個資料夾，一個指令：cp -r ~/.openclaw ~/.openclaw-backup-$(date +%Y%m%d)，三秒鐘，救過我一次。

讀 changelog，真的讀。 我知道很無聊，但 OpenClaw 的 changelog 通常會標 [BREAKING] 或 [EXPERIMENTAL]。2026.4.24 如果真的有 gateway startup 相關的改動，大概率有標注，只是很多人直接跳過了。