OpenClaw 2026.9.3 升級：Node 版本、更新預演與 Skills 遷移

為什麼 Node 要先升#

官方 release 將 runtime 門檻列為 breaking change，原因是避免 SQLite text truncation。不同版本線的判斷如下：

先在互動 shell 記錄：

1
node --version
2
which node
3
openclaw --version
4
openclaw update status
5
openclaw gateway status

node --version 正確仍不代表 system service 使用相同 binary。若 OpenClaw 由 launchd、systemd、container 或版本管理器啟動，要一起檢查 service 的 PATH、映像與啟動 log。升級後出現「終端機正常、Gateway 起不來」時，這通常比重裝 OpenClaw 更值得先查。

官方也提醒，Node-based CLI／Gateway 安裝若仍在 macOS 11–13.4，或使用官方 Linux ARMv7 provisioning，還要核對受支援主機條件；不能只把 Node binary 換新就推論整個平台已相容。

升級前保存可回復證據#

至少保存這四類資訊：

1. openclaw --version、Node 版本、安裝方式與 Gateway 啟動方式。
2. ~/.openclaw 的受控備份；其中可能含 API Key、OAuth 與 private session，不可上傳公開 repository。
3. 啟用中的 plugins、模型 primary／fallback、provider account 順序與 agent Skills 清單。
4. 一個可重複的 smoke test，例如讀取指定檔案、完成單次模型呼叫與傳送一則測試 channel 訊息。

若要建立本機狀態備份，可先停止會持續寫入資料的程序，再使用你既有的加密備份流程。不要直接複製來源不明的一行 rm 或覆寫指令；更新回復需要完整舊狀態，而不是只留 openclaw.json。

OpenClaw 先前的 provider 或 plugin 遷移也可能和這次一起浮現。如果仍有已移除的舊 Google Antigravity 路徑，可先看 OpenClaw 更新與 provider 遷移檢查，不要在 2026.9.3 升級時繼續修改 node_modules 版本字串。

先 dry-run，再讓 candidate state 預演#

先看更新狀態與預計動作：

1
openclaw update status
2
openclaw update --dry-run

確認 Node、channel、目標版本與 plugin 變更符合預期後，再執行：

1
openclaw update

2026.9.3 的 safer updates 會把 core 與 plugin 變更先放進隔離的 candidate state rehearsal，通過獨立驗證後才 activation。符合條件的 2026.9.2 migration 也可被處理；遺留的 update record 則能在不停止健康且版本相符的 Gateway 下回復。

這裡有三個邊界要保留：

• rehearsal 成功只代表內建驗證通過，不代表你的 channel、外部工具與私有 plugin 都已驗收。
• 有些 candidate-validation failure 可進入有限次數的自動 repair；需要修改設定的情況仍會留給 operator。
• 更新失敗報告只有在明確同意後才會送出，不應為了排錯把含敏感狀態的資料自動外傳。

因此，正式環境仍應設定 maintenance window、負責人與 rollback 條件，不要把新的更新機制當成「可以無人值守升級」的保證。

Skills Workshop 的 ownership 會遷移#

2026.9.3 將 Workshop skills 改成每個 agent 一份可寫、跨 workspace 持續存在的 collection，不再由單一 workspace 擁有。啟動或執行 openclaw doctor --fix 時，只會自動遷移能證明 ownership 的 legacy skills；歸屬不明的項目會保留，等待人工 review。

升級後請核對：

• 每個 agent 的 Workshop 是否只出現它應擁有的 Skills。
• 同名 Skill 是否因舊 workspace 複製而重複。
• 完整 instructions 比較結果是否一致，不要只看 Skill 名稱。
• 已消失的 draft suggestion 是否由 Doctor 安全收斂，而不是留下可誤用的捷徑。
• 原本依賴 skills.workshop.allowSymlinkTargetWrites 的流程是否需要改寫；該設定已退役。

若 Skills 涉及寫檔、shell、瀏覽器或外部服務，逐項用最小權限任務驗證。ownership 遷移成功不等於 Skill 的工具權限與 secrets 邊界仍符合預期。

升級後的六項 smoke test#

完成 activation 後執行：

1
node --version
2
openclaw --version
3
openclaw update status
4
openclaw gateway status
5
openclaw doctor

接著驗收：

1. Gateway：service 使用的 Node 與互動 shell 一致，restart 後狀態健康。
2. 模型：primary、ordered fallbacks、provider accounts 與優先順序沒有被重排。
3. Skills：agent-owned Workshop collection 完整，執行一個只讀 Skill 與一個受控寫入任務。
4. 記憶與效能：舊記憶可搜尋，新回合可保存；不要只因 warm prompt cache 改善就忽略冷啟動測試。
5. Browser／channel：測試一個 browser tab 與實際使用的訊息 channel，確認 live activity 沒把斷線 session 誤報為 idle。
6. 資料分享：檢查 public session transcript 與 Team Reports 是否維持停用或符合既有政策。

2026.9.3 新增可撤銷的 public conversation link，但公開範圍包含該 session 既有與未來的 conversation text。read-only view 不含 tools、reasoning、files、images 與 executable widgets，仍可能暴露 prompt、貼上的程式碼或後續文字。沒有明確分享需求時，不要只為測試點下 publish。

更新失敗怎麼回復#

若更新未完成，先保存 update record、Gateway log、Node 路徑與 candidate validation 結果。官方既有流程提供：

1
openclaw update repair
2
openclaw doctor
3
openclaw gateway status

2026.9.3 會對符合條件的失敗做 bounded repair，但修復不能把原始失敗改寫成成功紀錄。需要設定變更時，應先 review 工具回報，再手動處理；不要重複執行 update 到錯誤訊息消失，因為這會覆蓋最有價值的第一次失敗證據。

如果問題是 Node 不支援，先把 service runtime 修到符合門檻；如果是第三方 plugin，停用該 plugin 後在隔離環境重跑；如果是設定 migration，從備份和 diff 確認具體欄位。回復目標是恢復已知健康版本與 Gateway，不是強迫新版本在不相容狀態下啟動。

這版其他功能要不要一起開#

2026.9.3 還包含 live browser tabs、provider account priority、model fallback picker、meeting archive、Team Reports、repository-backed cloud sessions 與 recursive delegation 等變更。它們不應和 runtime 升級一次全部啟用。

先完成 Node、Gateway、模型、Skills 與 channel 的基本驗收，再將每項新能力拆成獨立測試。尤其 public transcript、Team Reports 與 recursive delegation 會改變資料可見性或 agent 執行範圍，應先定義 owner、資料來源、concurrency、sandbox 與撤銷方式。

常見問題#