OpenClaw 更新一次，我就多請半天假。後來我先把回滾路徑做好
上個月一個週六早上，我想說趁工廠還沒開工，把 OpenClaw 更新一下。想法很單純，版本更新應該就是按下去等它跑完，結果更新完之後，原本可以叫它整理報價單的流程壞了，幾個 plugin 也互相打架。
我那天沒有在修工廠的東西，反而花了快四個小時陪 coding agent 找原因。中間重跑了好幾次，Claude 的 token 也燒掉不少。最麻煩的是，當時沒有記錄更新前的狀態，大家只能一直猜到底是哪個設定被改掉。以我們這種小公司來說，老闆坐在電腦前修半天，表面上沒有薪資支出，實際上就是半天沒有處理客戶和現場問題，成本一樣在流血啦。
後來我看到 Reddit 上有人分享每次更新都要花 token 修復，也有人會先讓 coding agent 在測試副本跑過一輪，還有人同時留 LTS 和 bleeding-edge。我覺得這些做法很實際，就把自己的流程改掉了。我沒有突然變得很會技術，先承認自己承擔不起每次都從事故裡學習。
現在我固定留兩個環境。一個是 production，給日常工作用，一個是 staging，資料用複製的測試資料，權限也少一點。新版本先進 staging，至少放半天，沒有通過檢查就不碰正式環境。正式環境我偏向留穩定版，真的想試新功能才在 staging 另外裝。
我目前只做五個 smoke test，清單很小，但比憑感覺可靠：
- 能不能正常啟動，health check 有沒有回來。
- 能不能讀到一份測試訂單，請它整理成摘要。
- 原本在用的兩個 plugin 能不能各跑一次。
- 權限限制還在不在，測試帳號不能碰正式資料。
- 重開服務後，設定和排程有沒有留著。
每次升級我給自己 20 分鐘的檢查上限。20 分鐘內過不了，就停手，不要為了證明這次一定能修好而一直加 token。這個時間是我自己訂的，沒有什麼標準答案，但很適合小公司，因為超過這個時間，通常已經開始從升級變成除錯專案了。
還有一件事以前完全沒做，現在一定做。升級前先留 snapshot，設定檔和 plugin 清單另外存一份，能用 git stash 就先 stash，重要變更則放到 isolated feature branch。AGENTS 裡也寫清楚，沒有我批准，不准改 core 和 plugins。批准後只能在隔離分支動，測試前要能 revert，主機也要有回復 snapshot 的路徑。
我踩過最大的坑，是以為有 snapshot 就代表可以回滾。第一次測試時，snapshot 留了，但我沒有實際演練恢復，等真的要回復才發現資料目錄和服務設定不是同一個地方。後來我把 rollback path 寫成三步，先停服務，再恢復設定和資料，最後重開並跑五項檢查。每月演練一次，目標是 10 分鐘內回到可工作的版本。
現在更新還是可能出問題，這點沒有魔法。差別是以前出問題才開始想怎麼回去，現在更新前就知道要回哪裡。對我們這種人少、每個人都身兼好幾份工作的公司，最有用的是兩個環境、五項檢查、20 分鐘上限，還有一條真的走過的回滾路徑。先把跌倒後站得起來這件事做好，才有本錢繼續試新東西吧。
作者：吳啟文