升級硬體、切換雲端區域或災難演練時，OpenClaw 工作區裡同時存在明文組態、模型快取與 launchd 參照路徑——直接複製整個家目錄往往把過期金鑰與數 GB 快取一起搬走。本文給出 2026 年可重現流程：來源端打包排除規則、SHA-256 校驗、目標機目錄對齊、守護程序重啟順序，以及一張「遷移前／後」對照表。另含七步操作序列與回滾時間盒建議，讀完應能獨立驗收「閘道器程序存活＋最小對話成功」雙條件。
守護程序首次驗收見 無頭 onboard 與閘道器驗收；金鑰與 plist 環境變數見 鑰匙圈與 .env；升級與回滾節奏見 維運 runbook。遠端圖形授權用 VNC 說明；SSH／連線總覽見 幫助中心。需要估價與區域選擇可開 定價頁。
遷移前必須釐清的三類路徑相依
- 工作區根目錄：
WorkingDirectory在 plist 裡寫死後，目標機必須使用相同使用者名稱或同步改 plist——只拷檔案不改 plist 是最常見故障。 - 快取與工件：模型與 npm 快取可能佔 30～120 GB；全量搬運拖長視窗，應明確排除或改為遷移後按需拉取。
- 監聽埠與 bind 位址：舊機若綁定特定 en0 IP，新機 DHCP 變化會導致「程序在跑但 health check 失敗」。
打包排除建議（tar／rsync 思維）
| 路徑／模式 | 是否納入歸檔 | 備註 |
|---|---|---|
| SOUL.md, TOOLS.md, AGENTS.md | 必須 | 體積通常 < 5 MB |
| **/node_modules | 通常排除 | 目標機 npm ci 重裝更可重現 |
| 模型權重快取目錄 | 依策略 | 窄頻鏈路可只遷組態，首次對話允許 < 15 分鐘預熱 |
七步遷移序列
建議在變更單裡寫明「允許的最終不一致」：例如允許快取未預熱導致首則回應慢於基線 20%，但不允許工具呼叫失敗率上升。把可接受偏差寫成數字，比口頭「差不多」更能減少遷移夜的爭執。
- 唯讀快照：停閘道器或切維護標籤，避免遷移中寫入
MEMORY.md。 - 產生歸檔並紀錄 SHA-256：將校驗和寫入變更單附件。
- 傳到目標機：優先內網 scp；公網傳敏感包時用加密通道並限制 ACL。
- 解壓到最終路徑：
chown與來源使用者一致。 - 安裝依賴：鎖定 Node 次版本與 lockfile，避免 silent major 跳版。
- 對齊 LaunchAgent：核對
ProgramArguments與EnvironmentVariables。 - 雙條件驗收：連續 3 次健康檢查＋一輪最小工具呼叫成功。
大工作區傳輸：頻寬與斷點續傳參數
當歸檔超過 50 GB 時，優先使用支援斷點續傳的工具（如 rsync --partial 或物件儲存分片上傳），並在傳輸前後各做一次校驗。以 100 Mbps 對稱鏈路估算，80 GB 淨荷約需 110 分鐘理論下限——實際常翻倍，因此變更視窗要按「最壞鏈路」申報。跨洋傳敏感包時，避免經過未加密的中轉桶；必要時用客戶自有 KMS 包裹後再交給供應商物件儲存。
遷移前後對照檢查表
| 檢查項 | 遷移前基線 | 遷移後應一致？ |
|---|---|---|
| openclaw 版本號 | 紀錄 semver | 是，或註明有意升級並附 doctor 輸出 |
| API 金鑰指紋 | hash 末 6 位 | 是，除非同步輪換 |
| 監聽埠 | lsof 截圖 |
是，或已更新安全群組／隧道文件 |
回滾時間盒：若 45 分鐘內雙條件驗收失敗，應預設回退到舊機閘道器（維持唯讀），而不是並行雙寫——雙寫階段最容易產生分叉狀態與重複計費。舊機唯讀期建議不超過 72 小時，避免長期雙棧維運。
常見問題：能否只同步設定檔而不同步快取？
可以，且往往是正確預設：把 SOUL.md、工具宣告與版本鎖檔打成一個「輕量包」，在目標機執行與來源機相同大版本的 openclaw 後再跑依賴安裝。首次對話延遲可能上升 2～4 倍，但換來較小攻擊面與較可稽核的歸檔體積。若業務不能接受冷啟動，可對快取目錄單獨做增量 rsync，並同樣計算校驗和。
遷移後閘道器反覆重啟怎麼排？
先比對 plist 中的環境變數鍵名是否有多餘空格或引號巢狀錯誤——從 tar 解壓複製時偶發。再檢查目標機 Node 路徑與來源機是否一致；不一致時應在 plist 裡寫絕對路徑而非依賴 login shell 的 PATH。若仍 crash-loop，暫時以前景模式啟動閘道器擷取 stderr，保留最近 200 行日誌附在工單。
跨地域換機時的延遲與合規提醒
從香港節點遷到東京節點時，工作區裡的日誌可能含使用者對話片段——歸檔傳輸應走加密通道並在 ROPA 中登記。若 RTT 從 25 ms 變 55 ms，工具鏈裡硬編碼逾時的作業可能偶發失敗，遷移後應跑一輪 soak。NodeMac 多區域上架便於你把閘道器貼近資料駐留區而無需重寫業務邏輯。
若組織同時運行多台閘道器，遷移其中一台時務必凍結「指向該實例」的入站路由（例如 Slack 事件訂閱或固定 IP 白名單），否則會出現舊位址仍接收流量、新實例閒置的假陽性。把 DNS 或負載平衡的 TTL 暫時降到 60 秒級，可在回滾時更快切回；遷移完成並穩定 24 小時後再恢復較長 TTL，降低權威 DNS 查詢成本。
自動化團隊可為每次遷移產生一頁「差異摘要」：歸檔位元組數、排除規則列表、新舊監聽埠、以及 doctor 輸出 diff。該摘要應進入內部知識庫而非只留在聊天——三個月後你會感謝自己能搜到當時為何排除了 node_modules。
Mac mini M4 的統一記憶體與大快取頻寬適合遷移後快速重建依賴與模型熱層；原生 macOS 減少容器路徑差異帶來的隱性 breakage。透過 NodeMac 按需租用香港、日本、韓國、新加坡或美國節點，可在同一套 SSH／VNC 流程下完成「舊機打包—新機解壓—launchd 拉起」，把遷移從固定資產轉移變成可重複的營運動作。獨佔實體機也意味效能基線可對照遷移前後表內數值，快速判斷問題是組態漂移還是上游模型。
在臺灣與鄰近區域，許多團隊會把「遷移視窗」排在離峰並預留額外 30% 緩衝給跨海鏈路抖動；若工作區含個資，建議同步檢視委外處理約款與日誌保存年限，避免歸檔落在錯誤地理區而觸發額外法遵工時。完成遷移後，將新節點的資產標籤與負責人寫回 CMDB，可讓下次演練或權杖輪換不必重新盤點主機清單。