首屏摘要：先判程序層再判設定層
MCP 不是「多裝外掛一定更順」。每個 stdio 伺服器都是獨立子程序，生命週期若未在回合結束或重載時正確回收，會在長工作階段、多通道、多模型路由疊加下把記憶體與控制代價吃光。社群回饋常見模式是：閘道日誌反覆出現同一 MCP 的 bundle 啟動列，而 ps 清單長度與對話輪次單調相關。當你觀察到 RSS 與子程序數同步上升，優先懷疑 stdio 樹未被回收；若只有 RSS 尖峰而程序數穩定，較可能是上下文或媒體暫存。
HTTP／SSE MCP 與 stdio MCP 不是同一條用戶端路徑。若設定僅有 url 而無本機命令包裝，目前發行版可能直接略過並記錄「only stdio」類提示。可落地做法是在 macOS／Linux 側用薄包裝指令稿把遠端能力折回 stdio（若合規允許），或暫時收斂到已驗證的 stdio 伺服器清單，而不是假設面板裡每一項都能連上。對外暴露的 HTTP 端點也要納入 SSRF 與憑證旋轉的威脅模型。
分層順序：openclaw status → openclaw gateway status → openclaw logs → openclaw doctor → openclaw channels status --probe。與閘道維運文對齊後再下鑽 MCP，避免在反向代理與 MCP 之間空轉。
痛點拆解：stdio 外洩、熱重載與 HTTP 邊界
痛點 1：熱重載≠程序回收。把 mcp.servers 改成 {} 後若閘道未完整退出，舊 npx 子樹可能仍掛在上層 PID 下。應對：openclaw gateway restart 不足時做服務級 stop → start 或容器重建，並觀察程序數是否回落。
痛點 2：多 MCP × 多工作階段 × 大上下文。每個工作階段可能觸發工具列舉與惰性啟動；若模型層頻繁重試，子程序 spawn 速率會高於回收速率。應對：先收斂啟用清單，再調模型與通道，最後才加機器記憶體。
痛點 3：升級後 plugins 與 mcp 並存衝突。讀《升級與 MCP 外掛》做快照與回滾；升級後務必跑 doctor 並對照發行說明裡的 breaking 欄位。
痛點 4：反代層斷長連線導致用戶端反覆重連。每次重連可能重新走 MCP 引導路徑，放大 spawn 次數；依《反向代理》檢查 WebSocket 與逾時。
痛點 5：CLI 與 systemd 跑的閘道版本不一致。先依《安裝路徑》統一入口，否則會在錯誤版本上讀「已修」的議題。若團隊混用全域 npm 與容器掛載路徑，請在監控上標註二進位來源，避免誤判。
決策矩陣：症狀 → 假設 → 動作
| 現象 | 優先假設 | 動作 | 關聯文 |
|---|---|---|---|
| 記憶體線性漲、ps 中多個同名 MCP | stdio 生命週期外洩 | 收斂 mcp.servers；完整重啟閘道；升級修補 | 升級 MCP 文 |
| 日誌提示 HTTP MCP skipped | 用戶端僅 stdio | 改 stdio 包裝或移除 url 項 | 安裝路徑 |
| doctor 綠但通道偶發斷 | 反代逾時 | 調 read／send 逾時與 WS 標頭 | 反向代理 |
| 升級後設定鍵被拒 | schema 變更 | 對照發行說明遷移 JSON | 升級 MCP 文 |
| 遠端 Mac 小記憶體實例 | 資源規格不足 | 減 MCP 數；限併發；換方案 | 套餐／節點 |
核心：先減活動部件再調參，比盲目加記憶體更能定位根因。
實操步驟：可貼上的排查骨架（How-to）
# 1) 版本與閘道
openclaw status
openclaw gateway status
# 2) 日誌中搜 MCP / bundle / skipped
openclaw logs --follow
# 3) 健康掃描
openclaw doctor
# 4) 通道探針
openclaw channels status --probe
# 5) 觀察子程序（示例）
ps aux | rg -i 'openclaw|mcp|npx' || true
# 6) 收斂設定後完整重啟（依你的安裝方式二選一）
openclaw gateway restart
# 或 systemd: sudo systemctl restart openclaw-gateway
# 7) 複查 ps 與記憶體；仍異常則對照發行說明升級或暫時清空 mcp.servers 冷啟動
生產環境請把 sudo 邊界與日誌脫敏寫進 Runbook；不要在生產直接把 API 金鑰貼進 shell 歷程。
資源與監控欄位：把「感覺卡」變成曲線
建議在監控裡為閘道主機增加：RSS、子程序數、開啟檔案描述元、CPU 五分鐘負載與磁碟剩餘。對話型負載下，記憶體尖峰常與上下文長度 × 平行工作階段數相關；MCP 外洩則常表現為程序數與輪次同步上升。把這兩條曲線分開看，能避免誤殺正常高峰。若同機還跑建置與公證相關工作負載，請把峰值時段標註在儀表板上，避免把批次作業誤判成閘道外洩。
遠端 Mac 或 VPS 選型時，為「7×24 閘道 + 多 MCP」預留至少數 GB 級余量與 SSD 空間；磁碟打滿時日誌輪替失敗會二次放大不穩定。
FAQ 與為何用託管遠端 Mac 跑閘道
能否只靠加記憶體解決？
短期緩解可行，但若外洩存在，曲線仍會單調上升；應收斂 MCP 與修補版本並驗證重啟後程序是否歸零。
HTTP MCP 什麼時候能直接用 url？
以目前用戶端發行說明為準；未寫明支援前應依 stdio 路徑整合或等待正式通道。
與 sessions_spawn 文關係？
該篇講子代理工具權限；本篇講 MCP 程序與傳輸邊界；可先後閱讀。
總結：OpenClaw MCP 落地要先接受stdio 程序模型的成本，用分層命令定位外洩與設定漂移，並在反代與安裝路徑上消除放大因子。
局限：自建 VPS 上要同時操心系統修補、磁碟、反代與閘道程序組；SFTPMAC 託管遠端 Mac把 Apple 相容環境與穩定線上性打包，更適合長期跑閘道並與團隊 SFTP／建置投遞同機協作。
了解方案與節點，統一遠端 Mac 上的閘道與檔案入口。