每次更新都在燒 token。正式環境不該是測試場
Reddit 最近有一串 OpenClaw 2026.9.3 的抱怨：更新本身能完成，後面卻留下 plugin 失效、設定要重修的問題，最後還得花 Claude tokens 把環境救回來。有人提議讓 Codex 或 Claude 在 OpenClaw 外部協助升級，再做一條 upgrade rehearsal pipeline。
從產品面來看，這直接碰到 retention。使用者每遇到一次客製設定消失，下一次更新就會被標成高風險事件。久了自然會延後升級，直到被迫處理。對需要持續迭代的工具，這個摩擦很貴。
我會先做三個檢查點
第一，先做 release rehearsal。發布前用同一份設定、同一組 plugin 和同一批 workspace 複製測試副本。副本要保留 environment variables、custom tool、prompt、排程和權限，刻意模擬老使用者的環境。驗收問題很簡單：原本能完成的工作，升級後還能不能完成？
第二，跑固定 smoke tests。先列 10 個案例：啟動 gateway、呼叫 tool、讀取既有記憶、跑排程，再看 log 有沒有 error。每次 release 都跑同一組，留下版本號和 pass rate。10 個過 9 個也要停下來看，剩下那一個可能正好是某個團隊每天都在用的流程。
第三，先寫好回滾與成本門檻。升級前定義失敗條件，例如 15 分鐘內無法啟動、核心 tool 連續失敗兩次、custom config 沒有完整遷移，或 pass rate 低於 100%。碰到任一條件就 rollback，agent 不要在 production 裡邊猜邊修。每次也記 recovery time、人工介入次數和 token 用量。假設一次事故花 40 分鐘、80k tokens，團隊就能拿它和事前多花 10 分鐘 rehearsal 做 trade off。
這套流程的重點，是把升級驗收從「版本裝上了嗎」拉回使用者工作能否延續。最小可行版本很樸素：複製環境，跑 10 個測試，確認回滾條件，再碰 production。步驟有點無聊，總比把正式環境交給新版本後祈禱設定平安回來好。產品經理最怕的通常是團隊開始把更新當成賭博。單次 bug 還能修，賭博心態會拖垮升級節奏。
作者：MingTech