您已能跑通 OpenClaw Gateway 與 stdio MCP，卻在正式環境看到子程序數緩慢上揚、RSS 攀升或偶發 OOM，不確定該調設定或改架構。本文與 MCP stdio/HTTP 握手與僵死排查、Gateway 生產觀測 分工：先用七條清單劃清邊界，再用一張stdio 對 HTTP 維運對照表收斂取捨，最後給出六步回收與限流 Runbook，並說明 systemd／Docker 下環境變數與重啟策略；文末連到 OpenClaw 專欄 與算力情境。
stdio MCP 的連線握手、僵死、權限拒絕優先對照 握手與僵死篇；白名單與工具策略對照 MCP 工具鏈白名單篇；健康檢查、日誌與升級回滾對照 觀測篇。本篇只回答：當 Gateway 已能穩定接受工作階段，但子程序與記憶體曲線仍不可接受時，如何分層治理。
首次握手失敗：先看 MCP 傳輸與下游可執行路徑，不在此篇展開。
Token／scope 與 gateway closed (1000)：對照 closed(1000) 專文，而非改回收指令稿。
純安全策略：dmPolicy／networkPolicy 變更走安全加固篇。
Gateway 起不來／not ready：先看啟動就緒排錯篇的連接埠、記憶體與 compose 順序。
業務層模型後端逾時：與 MCP 子程序治理可並行，但根因可能在模型路由而非程序表。
一次性外洩的第三方 MCP 實作 Bug：需要上游修復或版本釘選；回收只能緩解。
把「清理」當萬靈丹：無水位與版本臺帳的強殺會掩蓋真實外洩點。
在開源社群討論中，stdio MCP 作為 Gateway 子程序長時間工作階段時，可能出現子程序池隨工作階段成長而膨脹的現象；具體行為隨版本而變，維運上應把「可接受的程序上限＋回收策略」寫進值班手冊，而不是依賴預設。下面先建立工作階段隔離 → 堆積可預期的心智模型，再進入對照表。
與握手篇的交叉點在於：握手失敗會在日誌裡表現為連線／握手錯誤；而本篇處理的典型訊號是程序數單調增、記憶體曲線階梯式上升、在固定週期後被 OOM killer 命中。排障時先確認 Gateway 主程序與 MCP 子程序的父子關係（ps／容器內 pstree），避免把模型後端或通道程序誤算進 MCP。
若您同時執行多套工具鏈（本機指令稿＋遠端 Mac 上的常駐 Agent），建議把「哪台機器跑 Gateway、哪台跑重 MCP」畫成拓撲：Gateway 所在節點的記憶體餘量直接決定您能承載多少並行 stdio 工作階段。更多算力與接入說明可結合 雲端租賃價格 與說明中心網路需求。
從觀測角度，建議至少蒐集三類序列：程序數、Gateway 與 MCP 的 RSS、工具呼叫 QPS 與工作階段數。沒有工作階段維度，很難判斷「堆積」是業務高峰還是回收缺失。與 觀測篇 中的日誌欄位對齊後，再在儀表板做同比／環比，否則值班只能憑感覺重啟。
另一個常見誤區是把「子程序多」直接等同於「要換 HTTP」。若工具本身極輕、並行極低，問題更可能出在工作階段未關閉或下游可執行檔阻塞；此時應先收緊用戶端工作階段生命週期，再評估傳輸層遷移成本。
stdio 傳輸把 MCP 伺服器作為子程序緊耦合在 Gateway 生命週期內；HTTP 傳輸則更像獨立服務端點，伸縮與健康檢查路徑不同。下面用一張表協助評審「繼續最佳化 stdio」還是「上 HTTP」。
| 維度 | stdio MCP | HTTP MCP |
|---|---|---|
| 程序耦合 | 子程序隨 Gateway／工作階段模型變化，易出現堆積感知 | 通常獨立程序，Gateway 只做用戶端 |
| 水平擴充 | 常需同步擴充 Gateway 或限流工作階段 | 可對 MCP 服務單獨副本擴充 |
| 健康檢查 | 依賴 Gateway 日誌與程序表 | 可用 HTTP 探針與獨立 SLO |
| 故障爆炸半徑 | 子程序問題易拖慢同機 Gateway | 隔離較佳，但多一跳網路 |
| 適用情境 | 工具輕量、並行低、同機可信 | 工具較重、並行高、需獨立發布節奏 |
「治理」不是無限堆機器，而是給程序與記憶體曲線設合約：超過合約就限流、回收或換傳輸方式。
若團隊已在 stdio／HTTP 握手篇 驗證過設定無誤，但仍長期在記憶體紅線附近徘徊，應把「HTTP 化」納入架構評審，而不是無限調高主機規格掩蓋問題。
下列步驟強調「先取證、再限流、最後才換架構」：與 觀測篇 的日誌欄位對齊，避免無日誌強殺。
建立基線：記錄穩定負載下的程序數、RSS、Gateway 版本與 MCP 套件版本，寫入變更臺帳。
區分尖峰與外洩：尖峰多與並行工作階段相關；單調增更像未回收或下游掛起，需擷取執行緒／子程序堆疊資訊。
收緊並行與逾時：在設定允許範圍內下調平行工具呼叫、縮短閒置逾時，觀察曲線是否隨工作階段下降。
計畫內回收：在維護窗滾動重啟 Gateway 或隔離節點，先 drain 工作階段再操作。
容器與 systemd：核對環境變數是否注入實際執行環境（daemon 與互動式 shell 不一致是高頻坑）。
評估 HTTP 遷移：對重型 MCP 或需獨立伸縮的服務，落地獨立部署與健康檢查，Gateway 側改 HTTP 傳輸。
ps -axo pid,ppid,rss,comm | grep -E 'openclaw|mcp|node' | head -n 50 # 容器內可搭配 pstree -p 1 觀察父子關係
提示：修改 openclaw.json 後務必執行站內文件建議的校驗指令路徑（如 config:validate／doctor），再滾動重啟，避免「設定以為生效、程序仍用舊值」。
在 GitHub Issue 類公開討論中，曾有「stdio MCP 子程序在工作階段輪換時未回收」的報告，維運上應把週期回收＋版本追蹤當作暫時緩解，同時跟進上游修復。不要長期依賴未文件化的手動 kill。
若您使用外部編排（如 systemd timer 或 k8s CronJob）做旁路回收，務必保證與 Gateway 的啟動使用者、環境變數、cgroup 記憶體上限一致；否則會出現「回收指令稿看到的程序樹」與「真實服務程序樹」不一致，排障時互相甩鍋。對小型單節點部署，更推薦先透過設定把並行與逾時壓到合約內，再考慮旁路複雜度。
最後，把每次回收或限流變更關聯到發布版本號：stdio 行為可能隨 Gateway 小版本變化，缺少版本對齊的曲線對比沒有統計意義。
systemd 服務不會繼承互動式 shell 的 ~/.zshrc；Docker Compose 情境下 MCP 可執行檔路徑與唯讀掛載也會導致子程序反覆拉起。請在對照 Docker 生產篇 的前提下檢查：Environment=、WorkingDirectory=、命名卷與映像 digest。
注意：頻繁 docker compose restart 而不看前一次結束代碼，容易把「設定錯誤」誤判成「記憶體外洩」。
與 not ready 排錯篇 聯動：記憶體不足時 Gateway 可能尚未進入穩定 MCP 工作階段階段，此時應先解決資源與啟動順序，再談子程序治理。
下列數字為工程常用起點，以您實際負載為準。
把 Agent 與 Gateway 全堆在不穩定的小記憶體節點上，會出現「工具鏈與模型雙重抖動」；純靠加機器而不改工作階段模型，成本會線性失控。對需要長期上線、可預期算力跑 macOS 側建置或自動化、又要給 OpenClaw 周邊工具鏈留足餘量的團隊，NodeMini 的 Mac Mini 雲端租賃在固定 SSH 與清楚規格上通常優於拼湊筆電或超賣共享機；可先查看 雲端租賃價格說明，並在 說明中心 核對網路與接入要求。
落地時建議把「stdio 工作階段上限＋回收策略＋ HTTP 遷移觸發條件」寫進同一頁維運合約，研發與 SRE 用同一套指標評審。
若需對外覆盤，可附上程序快照與日誌片段，便於區分「設定誤配」與「上游缺陷」。
不一定。先區分工作階段隔離帶來的預期成長與外洩式堆積，再結合 RSS 曲線與 Gateway 版本核對已知問題；必要時升級到修復版本而非只加 cron。
當子程序生命週期長期難以與工作階段模型對齊，或節點記憶體餘量持續不足且無法水平擴充時，HTTP MCP 通常更易做獨立伸縮與健康檢查。更多工具鏈背景可見 OpenClaw 分類。