痛點拆解：為什麼「昨晚還能回 Telegram」早上就靜默了
痛點一：工作階段綁定。互動式 shell 裡的網關隨 ssh 斷線、終端機關閉而退出；值班同仁以為「服務掛了」，實際是行程樹歸屬問題，與應用程式邏輯無關卻最常被誤判。
痛點二：升級漂移。npm i -g 或通道切換後 openclaw 路徑變更，plist 仍指向舊二進位，表現為「隨機起不來」；這類問題在深夜輪值時特別耗神，因為日誌看似乾淨、實際是載入錯誤的執行檔。
痛點三：與容器方案混談。Docker 有自己的重啟策略；裸機 遠端 Mac 或 VPS 上應明確選 launchd/systemd，並與 生產部署 文件對齊，否則同一台機器會出現兩套「誰負責拉起網關」的敘事。
為什麼僅前景執行網關不夠：工作階段、日誌與升級窗口
生產需要可預期重啟、標準輸出落盤與資源上限。前景行程難以保證崩潰後退避、難以與日誌蒐集對接，也難在維護窗做有序 reload。應先讀完 分層排障，再把「能連上」翻譯成「守護單元健康」。與 Nginx/Caddy 聯用時，上游行程必須穩定，否則代理層只會放大 502，讓你以為是 TLS 設定錯，其實是上游反覆退出。
升級窗口要記錄：Node 次版本、OPENCLAW_ 環境變數、外掛目錄；reload 前跑 openclaw doctor 做快照，並把變更寫進變更單，讓下次稽核能對照「哪一次升級改了 plist 裡的路徑」。
macOS：launchd 最小 plist 與 PATH／Node 紅線
使用 launchd 時務必寫清絕對路徑的 ProgramArguments，在 EnvironmentVariables 中注入 PATH 與 NODE_BINARY（若專案約定）；StandardOutPath／StandardErrorPath 指向可輪替檔案。KeepAlive 與 ThrottleInterval 組合可避免崩潰風暴。使用者域 plist 放 ~/Library/LaunchAgents，載入用 launchctl bootstrap；變更後 kickstart -k。詳見下方骨架；生產細節與權限仍要對照 安裝路徑文。
筆電合蓋與電源策略會影響背景工作；遠端機房 Mac mini 則較單純，但仍要確認不會被「登出後停止使用者代理」政策影響。
Linux：systemd unit、Restart= 與 LimitNOFILE
[Service] 中顯式 User、WorkingDirectory、ExecStart 指向 openclaw gateway 或包裝指令稿；Restart=always 配合 RestartSec= 退避；LimitNOFILE 與連線型網關匹配。systemctl daemon-reload 在 unit 變更後必跑。與容器並排閱讀 Docker 生產 可選型：裸 systemd 更貼近宿主機 I/O，容器更利於版本釘選；兩者擇一作為「唯一真相」來源。
若使用 journald，建議為該 unit 設定合理的日誌大小上限，避免單次事故把磁碟打滿。
決策矩陣：何時 launchd、何時 systemd、何時 Docker
| 環境 | 首選 | 買到的能力 | 典型坑 |
|---|---|---|---|
| 遠端 Mac 長期跑 | launchd＋日誌輪替 | 登入工作階段無關、合蓋策略可配 | PATH／Node 漂移 |
| Linux VPS | systemd | 統一 journal、資源限制 | 使用者 unit 與 root 混用 |
| 多實例隔離 | 容器＋ compose | 映像釘版本 | 卷內設定與宿主機不一致 |
| 僅開發自測 | 前景＋ tmux | 迭代快 | 無崩潰恢復 |
矩陣用法：先寫成功的可觀測信號（systemctl is-active、埠探活、doctor 無新增 CRITICAL），再選列；選定後把「誰負責重啟、誰負責告警」寫進 on-call 手冊，避免口頭約定。
實作骨架：plist 與 unit 片段（教學用）
# macOS: ~/Library/LaunchAgents/com.example.openclaw.gateway.plist
# ProgramArguments: /絕對路徑/openclaw gateway （依安裝方式填寫）
# KeepAlive: true 或 SuccessfulExit
# StandardOutPath / StandardErrorPath → 可寫目錄
# launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.example.openclaw.gateway.plist
# Linux: /etc/systemd/system/openclaw-gateway.service
# ExecStart=/usr/bin/env openclaw gateway
# Restart=always
# RestartSec=5
# systemctl daemon-reload && systemctl enable --now openclaw-gateway
以上為骨架，生產須補全使用者、環境檔、安全加固與變更單；升級後重做路徑校驗。
健全性檢查與日誌：可引用的基線數字
建議把首次失敗到人工介入的告警閾值寫在運行手冊：openclaw status 非零、gateway 子指令異常、doctor 新增 CRITICAL、日誌檔單檔超百兆未輪替——任選兩條組合告警。退避重試使用指數或固定間隔，避免與 通道重連 風暴疊加。
這些基線讓「軟經驗」變成可比較指標，便於與託管環境對照；若你採用 SFTPMAC 託管 遠端 Mac，也能用同一套數字做驗收，而不是只靠「感覺有通」。
FAQ 與為什麼考慮託管遠端 Mac
能用 cron 每分鐘拉網關嗎
不推薦作為主方案；與 systemd／launchd 的原生重啟語意重複且難做有序升級。
埠 18789 被佔怎麼辦
先查 lsof 再決定是否改設定或停衝突行程，見網關運維文。
升級後 doctor 全綠但通道仍斷
可能是上游代理或 DNS 快取；回到分層排障，不要只重啟網關。
總結：守護行程化解決工作階段與崩潰恢復；矩陣幫你選對 launchd、systemd 或容器。
局限：自建節點要維護 OS 修補、日誌與金鑰輪替。SFTPMAC 託管遠端 Mac 把七乘二十四運行與交付路徑打包，減少你在「能跑」與「能睡」之間的反覆拉扯。
用託管遠端 Mac 統一網關入口與運維 playbook。