升 agent 平台跟更新 app 是兩回事
r/openclaw 最近有個討論串，有人從 2026.4.23 升到 2026.5.x，升完之後 WhatsApp connector 壞掉、會話卡住、隔天又多出幾個新問題，說整個更新體驗像在跑 beta。評論裡另一派人說他們跑 2026.5.7 很穩，沒出事。
差別在哪？穩的那群人升版前會先讓 agent 讀 release notes、掃 GitHub known issues、備份 config，有人甚至在複本環境先試跑一遍，確認沒問題才碰 production。
我看完這串討論的結論很簡單：問題不是某個版本穩不穩，是大家對「升版」這件事的心智模型根本不一樣。
你不是在更新一個 app
更新一個 app，頂多介面跑版、有個功能消失。stateless 的，重裝就好。
OpenClaw 不是這樣運作的。它有 session 狀態、connector 的連線協定、plugin 的依賴鏈、workflow 裡 agent 間的 handoff 邏輯，還有你幾個月積累的 config 和 custom prompt。任何版本改動，都可能讓系統的某個節點在特定條件下掛掉，而且通常不是升完馬上掛，是你在跑某個任務的時候才發現。
這就是為什麼有人升完沒事，有人升完隔天才踩到坑。觸發條件不一樣，regression 就不會同時出現。
升版前固定做的事
1. 讀 release notes，聚焦 breaking changes 和 deprecation
不是看摘要，是全讀。尤其找和你的 connector、plugin 有交集的段落。2026.5.x 改過 WhatsApp connector 的訊息格式，有用 custom parser 的基本上第一個炸。坑我踩過，很痛。
2. 跑 config diff
把你的 config.yaml 和新版預設值比一遍。很多版本更新會加新的 required field，舊 config 套上去有時候靜默失敗。靜默失敗才是最難查的，症狀可能是某個 workflow 行為悄悄變了，你搞不清楚是 bug 還是設定問題，debug 起來特別浪費時間。
3. 確認 plugin 兼容性
OpenClaw 的 plugin 不一定跟主版本同步發版。升主版本前，先確認你在用的 plugin 有沒有 release 對應版本，GitHub 看一下 release 時間戳就知道了。這步很多人跳過，然後升完才發現某個 plugin 在新版行為不對。
4. 備好 rollback 路徑
升版前先做 snapshot，或確認你能回到的方式。不是因為你預期會出事，是因為 agent 系統的 regression 很難即時發現。有些問題要等你跑 production 任務才踩到，這時候你需要的是快速還原，不是邊跑邊 debug。
5. 跑你最複雜的 workflow
如果有 staging 環境，升完後先測最依賴的 flow，不是最簡單的那個。邊界條件通常在複雜 workflow 才會觸發，最簡單的 flow 通過不代表什麼。
升完先看哪裡
我習慣升完先看 gateway log，不是 UI。connector 的 reconnect 行為、session 建立是否正常、有沒有 unexpected error type 出現，這些在 UI 層通常看不出來，但 log 裡已經在噴了。
再跑一遍：
openclaw gateway status
有接 WhatsApp 或其他 connector 的，確認 status 是 connected，不是 degraded。這一步三十秒，省下的是你之後找問題的兩個小時。
有人說「這不就是 QA 的工作嗎？」對，就是。但用 agent 系統越深、workflow 越複雜，upgrade 的 regression 成本就越高。不先做 impact review 就升版，那筆帳早晚要還，而且通常在最不方便的時候還。
作者：鍵盤工人