我最近在 staging 升級 OpenClaw，最有感的不是版本號變新，而是升級前終於有人先問：現在這個 Gateway 到底是用哪個 Node 在跑？

我的環境是 Ubuntu 24.04，Gateway 由 systemd 管理，主機上同時裝過 apt 的 Node、nvm 版本，還有幾台 ARM64 小主機用不同的 service user。平常在 shell 裡執行 node --version 顯示 22.x，不代表 systemd 啟動服務時也會吃到同一個 binary。之前我就遇過手動檢查正常，真正更新時卻因為 service 使用另一個 Node 而中途失敗。

我現在升級前固定做三個檢查：

1. 用 systemctl cat openclaw-gateway 確認 ExecStart 和環境變數，不只看目前登入帳號的 PATH。
2. 用 readlink -f $(command -v node) 對照 service 實際指向的 Node 路徑，再確認版本是否符合新套件需求。
3. 先在 staging 做 package update，確認失敗時舊的 Gateway 還能繼續服務，並把 journal log 留下來。

如果目標版本需要更高的 Node，更新會先停在檢查階段，不會硬把 production 的現行服務換掉。對只有一台 Gateway 的 self-hosting 環境來說，升級失敗不應該等同於服務中斷。

另一個我在 ARM64 節點上注意到的點，是 Bun 啟動時的 database access check。磁碟比較慢或剛開機時，檢查逾時太短，Gateway 可能還沒真的壞就先被判定失敗。我現在會把 startup log、磁碟 I/O 和 service restart 次數一起看，不會只看到一行 timeout 就重灌。

子代理結束後，父 session 是否保留原本的 working context，也會影響我在多節點上排查問題時能不能接著做。否則每次 agent 回來都要重新交代環境和已經試過的指令。

實測結果是，升級流程最重要的檢查點不是下載速度，而是 runtime、service identity 和 rollback 邊界。尤其 production 要注意，先確認誰在跑 Node，再談要不要更新。