OpenClaw 升級要走 production migration
最近看到 r/openclaw 有人抱怨，升級一次要花掉大量維修時間，甚至寧願每月付 200 美元換服務。這種痛苦我很熟。後端團隊碰到資料庫 migration 或核心 runtime 升版時，會先把它當成 production migration，按一下 update 絕對不算流程。
OpenClaw 一旦承載排程、工具權限、agent memory、外部 webhook，風險就集中在設定 schema、權限邊界和任務順序。我的準入條件很簡單，先確認能回退，再確認升級後的工作負載可驗證。
第一步是固定回退邊界。把目前版本、runtime、設定檔、prompt 和 plugin lock 一起記錄，至少保留最近 2 個可用版本。容器環境 pin image digest，拒絕使用 latest。rollback runbook 也要先寫好，資料與設定分開定義。資料若已被新版本轉換，必須事前確認 down migration 或 snapshot。回退超過 15 分鐘，方案就還沒準備好。
第二步是在隔離環境演練。複製 sanitized workspace，停掉發信、付款、刪除資料等 side effect，重播平常最常跑的 10 到 20 個任務。以前做過一次 agent runtime 升級，health check 全綠，webhook payload 卻少了一個欄位，隔天才發現排程都在空跑。啟動成功只代表程序活著，不能代表服務可用。
第三步是讓 smoke test 貼近 workload。至少涵蓋讀取上下文、外部 API、人工核准、失敗 retry 四類任務。把平常任務錄成 fixture，升級前後各跑一次，比對 exit code、tool call 數、latency 和輸出欄位。門檻直接寫死：20 個 fixture 至少 19 個成功，p95 latency 增幅不得超過 30%，權限錯誤就阻擋升級。只跑 openclaw --version，測到的只有 binary 還沒死。
我會固定一個可用版本，每月安排 maintenance window，有安全修補或明確 bug fix 才提前升級。每次留下版本、測試結果、rollback 負責人和截止時間，下一次不用靠考古。升級頻率高不代表成熟，真正值得信任的是一套可重播、可觀測、可回退的流程。這種基本功很無聊，但 production 通常就是靠無聊的東西活下來。
作者：鍵盤工人