修補版也要先做復原驗證
這週看到 Reddit r/openclaw 有一篇介紹 OpenClaw v2026.10.6 patch release 的文章，提到 Windows 被誤判 offline maintenance、資料庫錯誤、Bun 安裝 cleanup，還有 update recovery 卡住等問題。更重要的是，Gateway restart 之後，queued messages 和還在寫入的 replies 可以繼續。
在日本這邊的觀察是，團隊看到 patch release，第一個反應通常是先確認風險，再決定升級時機。我們公司做 NPC 行為和對話生成，正式環境每次換 model、改 prompt runtime，甚至只調一個 cache policy，都要先放進 staging。會議上最常問的是出事時能不能回到上一個狀態，玩家的任務會不會消失，誰有權限按 rollback。這種慎重有點慢，但線上遊戲有一個任務狀態壞掉，客服和工程師可能要一起追兩三天。
我以前也踩過一次很笨的坑。測試環境升級 AI service 時，migration 成功，health check 也顯示 green，結果重啟 worker 後，還沒寫完的對話 session 被當成 completed。服務看起來活著，玩家看到的卻是 NPC 忘記前一段對話。那次只影響 0.7% 的 session，其中一批剛好是活動任務，回報量在兩小時內堆到 43 件。從那以後，我看到「修正啟動失敗」這類 release note，會把 install 之外的 recovery path 一起列入檢查。
我現在會把 patch release 轉成三步驗證清單。第一步，先在 staging 做 cold start 和 Gateway restart，各跑 20 次，確認資料庫、queue、未完成 reply 的狀態都能保留。第二步，故意中斷 update，包含斷網、殺掉 worker、留一筆寫入中的任務，確認 recovery 不會卡在半完成。第三步，才做小流量 canary，先放 5% 流量，觀察 30 分鐘的啟動錯誤、queue backlog、session loss，再決定是否擴到全量。每一步都要有明確的 rollback 指令和負責人，不能只在 ticket 裡寫「必要時回退」。
日本團隊這種保守文化的好處，是大家會把故障復原當成產品的一部分。弱點也很明顯，驗證做得太重時，小 patch 可能兩週都進不了正式環境。我的做法是把測試分級，安全性和資料一致性相關的 patch 走完整三步，純 UI 或 log 修正則縮短流程。重點在於，patch release 代表有人修了問題，不代表你的工作狀態已經被保住。升級前先問一句，重啟之後還接得回來嗎，通常比看版本號安心得多。
作者：嵐山貓