OpenClaw 升級驗收要看恢復能力
OpenClaw 2026.9.7 的版本說明很容易讓人先看見兩個數字，2,818 個 PR、344 位貢獻者。高負載處理、長對話、更新備份，以及符合條件時的資料庫 rollback，看起來都是很實在的改善。不過從 SRE 的角度，我會把「服務能不能啟動」放在驗收清單的第一格，卻不會把它當成通關條件。
真正容易在半夜出事的，通常是啟動後才會跑的東西。排程還在不在、Telegram 或其他 channel 能不能收發、上一個尚未完成的工作要怎麼收尾，這些才是升級會不會影響使用者的關鍵。討論串裡有人回報 cron jobs 完整保留，也有人遇到升級後 Telegram 停止，修復後才恢復。兩種回報放在一起看，剛好說明了單一成功案例不能取代自己的驗收。
我會把這次升級拆成三段。升級前先盤點現況，至少記下所有 cron job 的名稱、排程、時區、最近一次執行結果，以及每個通訊管道的健康狀態。若平常沒有留紀錄，先把設定和執行清單匯出保存，並確認誰負責在失敗時接手。這一步很無聊，但沒有基準資料，升級後看到「好像都還在」其實沒有辦法證明。
升級完成後做一輪小型 smoke test。先確認程序和版本，再手動觸發一個不會造成副作用的排程，檢查它是否真的執行、是否留下紀錄。接著從每個重要 channel 發一則測試訊息，確認收得到，也確認回覆能送出去。只測 Web UI 或只看 process status 都不夠，因為 channel 的問題可能要到真正發訊息才會顯現。
最後要驗收恢復語意。2026.9.7 的重啟恢復可以辨識未完成工作，這對長任務很有幫助，但 interrupted tool calls 不會自動 replay。值班人員必須先寫清楚：工具呼叫被中斷時，工作會標成失敗、待人工確認，還是由流程重新建立；哪些操作可以安全重跑，哪些會重複扣款、發信或改資料。若只看見「未完成工作被辨識」就當成自動恢復，風險會被藏到下一次事故。
我的小型驗收清單會是：升級前保存排程與 channel 基準，升級後確認版本和程序，手動跑一次安全排程，對重要 channel 做收發測試，最後用一個可中斷的測試工作確認狀態與人工接手路徑。每項都留下時間和結果，失敗時回到備份或 rollback 路徑。
大型版本有 2,818 個 PR，不代表每個人的部署都會遇到同一種問題。升級真正完成的時間點，應該是值班的人知道系統現在做了什麼、沒做什麼，以及下一步怎麼恢復，而不只是終端機印出啟動成功。
作者：承翰