升級終於過了。Gateway 穩了。
昨天把幾台 staging 的 OpenClaw 升到 2026.10.2，原本只是想把 patch 補上，結果順手驗證了一輪我最在意的維運問題。這次最有感的不是新功能，而是升級和故障恢復終於比較像 production 會需要的樣子。
我之前在 Ubuntu 24.04 的 x86_64 staging 跑升級，package 被替換後偶爾會卡在半套狀態，Windows 測試機和 cloned filesystem 的路徑也不太穩。這版更新後，我用同一份流程測了 6 台機器，包含 2 台 ARM64 node，升級、重啟 gateway、重新連回 private node 都完成了。每台大約 2 到 4 分鐘，沒有再遇到 package 已換掉但 service 還指向舊檔的情況。
Doctor 的改善也很實際。我刻意在測試環境留下幾個髒狀態：legacy import、stale gateway lock、memory reindex lock，還有一個已刪除帳號殘留的 allowlist。以前這種狀態通常要人工翻設定檔，先備份再猜哪一段能刪。現在 Doctor 能辨識這些殘留並跨過去，原有資料也保留。我會建議把它放進升級後的 systemd maintenance 流程，但權限仍然要鎖好，不要讓服務帳號可以任意改整個 home。
安全性這次也有補到我一直擔心的邊角。大型 tool output 在跨 chunk 時，credential masking 不能只看單一 chunk，否則 token 剛好被切開就可能漏出去。現在這段遮罩邏輯連長輸出和 redaction stack overflow 都一起處理，實測餵進很長的 log，Gateway 沒再卡住。我還是會在 reverse proxy、journal 和外部 monitoring 各做一次敏感字串過濾，因為應用層修好不代表整條管線都安全。
另外幾個小修復在多節點環境反而很關鍵。Control UI reconnect 後不再一直轉圈，切換模型時載入大型 plugin 不會把 Gateway 卡死，agent startup 遺失回覆、Telegram preview 消失、subagent 答案被截斷這些問題也少了。我的做法是先升一台 canary，觀察 30 分鐘的 restart count、RSS、event loop latency，再分批推到其他 node。
重點是，這種 patch release 不要只看版本號就全量 rollout。先驗證升級路徑、Doctor、credential masking 和 reconnect，再看 systemd、firewall、node auth 是否維持原狀。實測結果是這版在我的 staging 穩定許多，但 production 還是會保留 canary 和 rollback package，尤其 ARM64 與 cloned filesystem 的環境，不能只拿單一台 Ubuntu 測過就算完成。
作者：Bo-Han Chen