1. 痛點拆解：裝得上≠能維運
（1）路徑分裂＝設定分裂：全域 CLI 讀 ~/.openclaw，容器掛載另一路徑，原始碼庫還有一份設定；常出現「改對檔但行程沒 reload」。（2）Node 22 門檻：舊教學停在 18/20，原生模組或 pnpm workspace 在 CI 與筆電 minor 不一致時易崩。（3）升級／回滾無順序：先升全域再改 compose 標籤，或只回滾映像不回滾卷內 schema，會半一致。（4）觀測與權限口徑分裂：有人用 sudo 裝全域套件、有人用使用者層級 npm prefix，日誌目錄與 launchd 的執行使用者不一致時，會出現「行程在跑但寫不進狀態檔」的假死；runbook 必須寫死執行使用者、工作目錄、umask三要素。
2. 三條路徑對照矩陣
| 維度 | npm 全域 | Docker Compose | pnpm 原始碼 |
|---|---|---|---|
| 上手速度 | 最快 | 中等，需理解卷與網路 | 最慢，適合 fork／稽核 |
| 隔離／多實例 | 弱 | 強 | 中 |
| 資料持久化 | 使用者目錄，需備份文件 | 必須 volume | 依執行方式綁定 |
| 升級 | npm i -g，注意權限 PATH | 改映像 tag + pull | git pull + pnpm i + build |
| 回滾 | 固定上一版或 minor | 映像回退＋卷快照 | git tag／分支 + 依賴重裝 |
3. 五步落地
- 凍結執行期：統一 Node 22+（或 README 明示之 LTS），並寫清「不支援區間」；Docker 路徑則凍結 compose 檔與映像 digest 紀錄方式。
- 四類目錄地圖：設定、憑證、工作階段／技能狀態、日誌；容器路徑務必在 compose 註解寫清宿主掛載點。
- 黃金路徑：依選定形態完成 onboard → 最小渠道 smoke → Gateway 前景／守護各跑一次，並把指令寫進內部 runbook。
- 升級 SOP：先公告 → 備份卷或目錄 → 升級 → doctor → channels probe；禁止跳過備份。
- 回滾 SOP：映像／套件版本與資料快照成對回退；回滾後強制執行《無回覆排錯》中的 status／doctor。
4. 可引用參數
- 同時維護兩種形態超過 14 天無真源文件，每週多耗 2～4 小時在「哪個 Gateway 在跑」。
- 生產變更應至少保留一次可恢復快照。
- 遠端 Mac 上對齊 launchd WorkingDirectory 與 CLI 預設路徑，可減半設定漂移工單。
5. 遠端 Mac 決策
| 訊號 | 建議 |
|---|---|
| 要 7×24 但筆電會闔蓋 | VPS 或遠端 Mac＋launchd |
| 容器與宿主 DNS／NTP 不一致 | 生產選單一拓撲 |
| Apple 工具鏈＋OpenClaw 同一 SLA | 優先評估遠端 Apple Silicon |
變更紀律補充：無論選哪條路徑，請在工單系統把「安裝形態＋資料卷 ID＋負責 on-call」綁成三元組，否則事後只能得到「好像有台機器在跑」這類不可稽核結論。遠端 Mac 場景亦建議將 SSH 跳板、VNC 與 Gateway 健康檢查的告警路由分開；並每季做一次「從快照還原＋ channels smoke」演練，成本遠低於真實故障徹夜排除。
6. FAQ
全域 CLI 管容器內 Gateway？可，但遠端 URL、權杖、設定路徑要寫在同一張表，否則易變成「CLI 指 A、daemon 跑 B」。Rootless Docker？依資安基線；對卷 UID 與 user 對應更敏感，compose 需明示。
pnpm 原始碼路徑如何做 CI？流水線固定 pnpm i --frozen-lockfile，測試用 Gateway 與正式資料卷分離。升級後渠道全靜音？先 doctor／pairing，勿先重裝三遍；見《無回覆手冊》。
Compose 要不要健康檢查？建議為 Gateway 行程設最小存活探針（或等效 HTTP／TCP 檢查），並把 restart 與退避上限寫進變更單，避免半啟動狀態變成重啟風暴。多環境能共用快照格式嗎？可共用流程，但金鑰與渠道憑證不可共用；還原演練應分環境各做一次。
7. 深度觀察
2026 年 OpenClaw 功能迭代快，瓶頸常是沒有單一安裝真源。npm 求快、Docker 求隔離、pnpm 求稽核；若文件層面混跑，維運半徑會快速崩壞。
Docker 路徑建議把映像 tag 策略（實驗可用 latest，正式須可追溯 tag 或 digest）、卷備份視窗（對齊渠道離峰）與compose 專案命名寫進同一頁維運手冊。pnpm 路徑則要納入 corepack、.npmrc 與私有 registry 鏡像是否進程式碼審查，缺一環就可能讓凌晨建置隨機解析出不同依賴樹。
客服／營運自動化場景下，可預測回滾與可複製環境比「永遠最新」重要；無快照回滾的恢復常以天計，在 SLA 視角往往高於租一台專用遠端 Mac 的月費。可把安裝形態理解成可維運半徑：半徑越大，越能容忍並行變更、輪值與委外接手。
許多團隊最終把長時 Gateway、批次工具呼叫，以及與 Final Cut、Xcode 搶統一記憶體的負載放到可租遠端 Mac，本機只做輕量 CLI 與除錯——這不是否定 Docker 或 npm，而是把互動機與伺服器機從實體上拆開，降低散熱與長尾延遲。常見組合是正式 Gateway 跑在固定拓撲的遠端節點（裸機 launchd 或單一 compose 堆疊），筆電僅負責渠道配對與技能調校，從流程上消滅「闔蓋即斷流」。
再補一組上線前核對：全域路徑要確認 PATH 僅指向一個 openclaw 實體；Compose 路徑要確認 .env 與祕鑰保管（Vault、Secrets Manager 等）一致，避免正式權杖落在會被同步到筆電的目錄；pnpm 路徑要確認 CI 與部署機的 pnpm-store／registry 策略一致，否則會出現「鎖檔相同、解析樹卻不同」的幽靈相依問題。
若同時維護創意專案與自動化專案，建議在預算表並列專用遠端節點與「本機反覆升降級的隱性工時」：Apple Silicon 遠端節點在轉檔、批次縮圖與 Gateway 並存時，統一記憶體調度通常比筆電溫控降頻更可預期；這也是許多工作室把 OpenClaw 常駐從剪輯同機遷出的現實理由。
再補稽核與協作：任何安裝形態都應留下「誰有權變更執行期版本」的名單；Docker 路徑要把 compose 檔納入程式碼審查或基礎設施即程式碼流水線，避免口頭改映像標籤卻無法追溯。pnpm 路徑則建議把 package.json 的 engines 與實際 CI 映像的 Node 版本定期對檢，避免「文件寫 22、流水線還在 20」的假安全。
若港台與其他時區團隊併行協作，請留意雲端同步軟體對 openclaw.json 的副作用：部分同步客戶端會產生衝突副本，讓 Gateway 讀到舊設定仍自認已 reload。這類問題與 npm／Docker／pnpm 無直接關係，卻常被誤判為 OpenClaw 不穩；在部署手冊寫清「哪些目錄必須排除同步」可一次砍掉大量假議題。
最後補一段容量與成本對照：把 Gateway 與影片轉檔、批次輸出放在同一台筆電時，散熱與電源策略往往會讓 CPU／GPU 進入輪流降頻，渠道延遲呈長尾分布；改為可租遠端 Apple Silicon 節點專跑 Gateway，可把延遲分布壓回較窄的區間，對客服機器人與即時回覆類場景特別有感。此處比較的是可觀測的尾延遲與工時，而非單純規格表上的時脈數字。
若你已導入監控，建議在儀表板同時畫出渠道 round-trip與主機溫度／功耗：兩條曲線的相關性常常直接指向「該把 Gateway 移出剪輯機」的結論，而不需要再爭辯要選 npm 還是 Docker。另可加上錯誤率與重試次數，避免只看平均延遲而被長尾掩蓋；把圖表存進變更紀錄，也比口頭共識更容易向財務與資安持份者說明為何要租節點。
8. 收束與轉化
（1）限制：全域安裝易受系統 Node、權限與企業 MDM／資安軟體拖累；Docker 仰賴卷與映像紀律，DNS／NTP 一漂移排錯難度指數上升；原始碼路徑耗費建置與審查成本，lockfile 紀律不足會出現「能 build 不能跑」。若三路徑在文件上混跑，設定漂移與「到底誰在讀哪份 openclaw.json」會被放大。
（2）遠端 Mac：Apple Silicon、統一記憶體與創意／自動化工具鏈一致，利於長時 Gateway；launchd 與桌面工作階段解耦後，渠道抖動與 GUI 干擾顯著減少，維運邊界更清晰。
（3）MACGPU：若要以低門檻試用專用遠端 Mac 跑通「單一路徑＋launchd 常駐」再決定上雲或擴容，MACGPU 提供可租節點與協助入口；下方 CTA 連結公開方案（無需登入）。