OpenClaw 升級前先把 rollback 寫清楚
OpenClaw 最近有一串「Still Not Updating」討論，發文者決定停在 2026.7.1-2，因為更新弄壞原本能跑的系統。有人只為了新模型升級，也有人建議先讀 release notes。有人回報每個 agentic session 都在 /tmp 裝進 200+MB 的 Codex CLI，最後把 SSD 塞滿。
放到 enterprise 場景，我的 take 是，OpenClaw update 應該走 change management。版本號沒有 production readiness 的保證，真正要問的是，變更會碰到哪些 workflow，誰能判斷成功，出事後誰有權限 rollback。
我會先列 5 到 10 個 critical workflows，例如每日報表、客服 escalation、知識庫查詢、寫入 CRM 的 agent。每項都要有 acceptance criteria，像「20 筆測試資料，至少 19 筆正確寫入」。只寫「確認功能正常」，無法支撐 go 或 no-go decision。
接著挑 1 個 agent 做 canary，使用 custom config、指定 model、tool permission 和檔案寫入。先在第二套環境跑完整 workflow，再放到 production。除了 response quality，也要看 startup time、disk usage、token cost、error rate，以及 model entitlement 是否有效。新模型能不能用，常取決於帳號、workspace 或 billing policy。
最小 release gate 我會寫死四項。第一，owner review 過 release notes，custom patch 已逐項對照。第二，canary 通過 acceptance criteria。第三，disk usage 有 baseline 和上限，/tmp 清理方式已驗證。第四，rollback owner、時間窗和指令已確認，回復後要重跑哪些 workflow 也列出來。
Ownership 很容易被低估。升級可由 platform team 執行，驗收卻可能要 PM、security 或業務 owner 簽核。若凌晨出事，誰停用 agent，誰還原 custom config，沒有名字就等於沒有流程。Rollback 也要先確認 state migration 和資料格式支援回復。
我不會因為一個新模型就批准整批升級。若 business value 只是多一個 model entitlement，先評估能否獨立開通。release gate 過了再 rollout，ROI 通常比大爆改後花兩天救火好算。
作者：Vivian L