1. 痛點拆解：拷走倉庫≠拷走執行態
（1）狀態目錄與 workspace 混為一談：很多人把「技能指令碼、提示詞、工具配置」放在專案裡，卻把會話、渠道繫結、Gateway 快取留在使用者態目錄；換機後只恢復 git 倉庫，表現為 CLI 能跑但頻道側「幽靈會話」或空配置。（2）金鑰與 OAuth 重新整理令牌的落點分散：Slack、Discord、企業 IM 的 token 往往既在配置檔案也在執行時加密儲存裡；只備份明文 openclaw.json 而不備份完整狀態樹，會在新機上觸發重新授權，若未按順序停 Gateway，會出現雙端搶 session 的競態。（3）launchd 與 shell 環境不一致：launchd 不會繼承你在 .zshrc 裡 export 的 API Key；遷機時若把變數只寫在互動 shell，而 plist 未同步，會出現「終端裡手動起 Gateway 正常、重啟後 plist 拉起就缺變數」的經典錯位。（4）遠端 Mac 上的使用者與會話邊界：VNC/SSH 登入使用者與跑 Gateway 的使用者必須一致；換機到遠端節點時若混用 root 與登入使用者，檔案許可權與 Keychain 訪問會分叉，排錯成本指數上升。
2. 分工表：該備份什麼（2026 實操口徑）
| 物件 | 典型路徑 / 含義 | 是否應納入「冷遷移包」 |
|---|---|---|
| 使用者態狀態樹 | ~/.openclaw（版本差異下子目錄名可能微調，以官方文件為準） |
是：含渠道繫結、快取與本地金鑰材料；遷機核心 |
| Workspace / 專案 | 技能、指令碼、openclaw.json（若放在倉內） |
是：但需與狀態樹同一快照時間，避免 schema 半一致 |
| launchd / 服務單元 | ~/Library/LaunchAgents/ 下對應 plist |
是：記錄執行使用者、工作目錄、環境變數鍵名 |
| 容器卷（若用 Docker） | compose 中命名的 volume 或繫結掛載點 | 條件：與《Docker 生產》路徑一致時再整體快照 |
| 系統 Keychain 中的秘密 | 部分渠道或工具把重新整理令牌放進鑰匙串 | 謹慎：優先走官方「重新授權」流程，避免粗暴匯出違反合規 |
3. 五步遷移（凍結→打包→校驗→冷啟動→重配對）
步驟 1：凍結寫入：在舊機先停 Gateway 與相關 launchd job（或 compose 棧），確認沒有後臺會話仍在寫狀態目錄；若不停服就打包，快照裡可能含半寫入的 SQLite/鎖檔案，恢復後隨機損壞。步驟 2：打「成對快照」：同一時刻打包 ~/.openclaw 與 workspace（含 lockfile）；若用 Docker，再對卷做只讀複製或映象匯出，三者時間戳對齊。步驟 3：校驗與脫敏：在新機解壓前，用校驗和確認包完整；檢查配置裡是否硬編碼了舊機 hostname、絕對路徑或內網 URL，需要批次替換為遠端節點可達地址。步驟 4：冷啟動 Gateway：先以最小配置啟動（僅本地 loopback 或管理埠），跑 openclaw doctor 或專案文件中的自檢；確認日誌目錄、許可權與監聽埠與 plist 一致。步驟 5：頻道重配對：按渠道官方流程重新 OAuth / webhook 註冊——很多系統不允許同一 bot 多例項並行；應在舊機徹底下線後再在新機啟用，避免重複投遞與簽名衝突。
NUMBERS / THRESHOLDS（可引用）
① 快照三件套：~/.openclaw + workspace + plist（或 compose 檔案與卷清單）缺一則視為不完整遷移。
② 環境變數：launchd plist 與互動 shell 的 export 必須顯式對齊；至少核對 API/代理/時區三類鍵。
③ 頻道切換：舊例項停止與新例項拉起的時間窗建議 ≥ 渠道文件建議的冷卻時間；無文件時以分鐘級灰度為準。
④ 遷到遠端 Mac：SSH 使用者 = 跑 Gateway 使用者；會話工具（Screen Sharing）與無人值守 launchd 不要混用不同 UID。
⑤ 回滾預案：保留舊機只讀快照至少一個釋出週期，再銷燬可寫副本。
4. 引數與排錯：為什麼「啟動了卻無回覆」
遷移後最常見的假陽性是程序存活、健康檢查透過，但頻道訊息進不來。第一查監聽地址：是否從 127.0.0.1 改成了內網 IP 卻忘了同步反向代理或防火牆規則。第二查 webhook URL：雲平臺控制檯裡的回撥地址是否仍指向舊公網 IP 或已失效的隧道域名。第三查時鐘與 TLS：遠端 Mac 若 NTP 漂移過大，部分簽名驗證會失敗；企業 MITM 代理若替換證書，也會導致 TLS 握手靜默失敗。第四查工具 profile：若你在舊機用 tools.profile 限制了可執行路徑，新機路徑變化會導致工具呼叫被靜默拒絕——對照《sessions_spawn 與 tools.profile》逐項放開或改寫白名單。
5. 決策表：繼續本機 vs 遷到遠端 Mac Gateway
| 維度 | 留在本機 | 遷到遠端 Mac（常駐） |
|---|---|---|
| 可用性 | 受合蓋、睡眠、差旅影響大 | 7×24 邊界清晰，適合渠道客服類負載 |
| 許可權與 Keychain | 與桌面會話繫結，除錯方便 | 需明確無人值守策略，避免 GUI 彈窗阻塞 |
| 網路 | 家庭寬頻出口可能變 IP | 可用固定 egress 或隧道域名，利於 webhook |
| 成本 | 硬體折舊與電費隱性 | 租賃透明，適合 SLA 導向團隊 |
6. FAQ：遷移中最常被問到的五個問題
問：能不能只同步 workspace，不同步 ~/.openclaw？可以跑通部分 CLI 場景，但只要涉及渠道與會話連續性，就強烈不建議；你會在排錯上花掉遠超備份體積的時間。問：Docker 與裸機混遷怎麼選？優先保持目標側與文件一致的一種形態；跨形態遷移等於同時做換機與換棧，風險疊加。問：plist 裡能不能寫明文 API Key？能跑但不推薦；更穩妥是檔案許可權受限的 env 檔案 + plist 引用，或託管金鑰方案。問：遠端 Mac 上要不要開螢幕共享？日常運維可用 SSH；僅當工具強依賴 GUI 或首次授權時才短時開 VNC，並在變更單記錄。問：舊機要不要立即 wipe？建議先並行觀察一個完整業務週期，再銷燬可寫資料。
7. 深度分析：遷移本質是「狀態與身份」一起搬家
2026 年 OpenClaw 一類代理棧的複雜度，早已不在「能不能裝」，而在狀態如何被多個程序讀寫、渠道如何把外部身份對映到內部會話。換機如果只搬程式碼不搬狀態，就像搬辦公室只搬了桌椅沒搬保險櫃——門能開，業務不能續。workspace 裡的 openclaw.json 往往描述「意圖與工具白名單」，而使用者態目錄承載「已經與外部世界握過手的憑據與快取」；二者必須同事務級一致，否則就會出現 doctor 全綠、頻道全啞的詭異分裂。
launchd 與互動式 shell 的分裂，是 Mac 遷移中第二常見的坑。許多開發者在終端裡 export 了模型供應商的 API Key，卻在 plist 裡忘記寫入，結果 launchd 拉起的 Gateway 讀不到金鑰，日誌裡卻只有含糊的 401。反過來，有人在 plist 裡塞滿環境變數，卻忘了給日誌目錄與狀態目錄正確的使用者所有權，程序能啟動但無法 rotate 日誌，最終在磁碟滿時一次性暴雷。遷移清單裡應把「環境變數三件套」——plist、shell profile、CI/遠端指令碼——放在同一頁表格裡交叉核對。
頻道重配對不是「重複勞動」，而是安全與一致性機制：多數 IM 與協作平臺假設 bot endpoint 唯一；雙活會導致重複投遞、亂序響應，甚至被平臺風控。遷移 runbook 裡應寫明舊例項下線確認（程序、監聽、DNS、控制檯回撥四聯查），再執行新例項上線與灰度觀察。對於企業微信、飛書、Slack 等不同渠道，冷卻時間與 IP 白名單策略各異，不宜用一份模板套所有客戶。
遷到遠端 Mac 時，還要把「圖形會話」與「無人值守服務」從心智上拆開：前者適合偶發除錯與授權彈窗，後者應是可審計、可重啟、可回滾的守護路徑。MACGPU 一類節點提供的價值，是把 Apple Silicon 與統一記憶體留在「正確的一層」跑長期 Gateway，讓筆記本回歸互動與創作，而不是 7×24 的熱節流與合蓋斷流。這與「安裝路徑選型」一脈相承：先定棧與狀態真源，再談渠道與 SLA。
8. 收束：換機可以快，但不能省步驟
（1）當前方案的客觀限制：狀態目錄隨版本演進可能調整佈局，遷移包應記錄 OpenClaw 版本號；跨大版本時優先參考發行說明中的 breaking changes。金鑰與合規策略可能禁止直接複製鑰匙串，需要預留重新授權視窗。（2）為什麼遠端 Mac 常更省心：固定拓撲、固定使用者與固定出口，減少「筆記本即伺服器」帶來的長尾故障。（3）與 MACGPU 的銜接：若你希望把 Gateway 遷到可租賃、可預期的 Apple 生態節點上完成驗收，再決定長期拓撲，可從首頁瞭解套餐與幫助入口。