你已經能跑通 OpenClaw Gateway，下一步通常是把 Model Context Protocol（MCP） 工具接進代理工作流：查倉庫、調內部 API、跑受控命令。現實摩擦集中在三類問題——工具發現與版本漂移、網關側白名單與最小權限、以及線上常見的 握手失敗 / 超時 / 子進程僵死。本文說明與站內 安裝、安全加固、modelRouting、觀測 各篇的分工，給出 stdio 與遠程 MCP 形態對照、六步可復現上線清單，並附症狀對照表，幫助你在生產裡把 MCP 當成可審計的「工具供應鏈」而不是臨時插件。
MCP 把「工具調用」從一次性腳本提升成隨會話復用的能力面：多一個工具，就多一條數據路徑與一段子進程生命周期。若仍按「本地能跑就行」推進，很快會在網關側遇到工具枚舉爆炸、隱式升級、無超時、無白名單四類問題。下面七條用於評審會自檢，避免把演示配置抄進生產。
當你有三條以上答案是「是」，就應該把 MCP 當成受治理的供應鏈：需要顯式登記、版本釘扎、觀測與回滾，而不是把 openclaw.json 當草稿紙。
工具清單是否隨重啟漂移：若每次上線工具數量與名稱都會變，說明發現路徑未版本化或未鎖定工作目錄，排錯會變成「猜今天枚舉到了什麼」。
是否缺少顯式白名單：默認「全開」在演示很快，在生產等於把任意 prompt 映射成任意系統能力；應與 dmPolicy / 執行審批策略一起評審。
stdio 子進程有沒有硬超時：無上限等待會讓 Gateway 線程/隊列被單個僵死 MCP 佔滿，表現為「模型還在回，但工具永不返回」。
遠程 MCP 是否繞過出站策略：HTTP/SSE 工具若未納入 networkPolicy 討論，等於在網關背後開新出口，與安全加固篇的假設衝突。
密鑰是否經由環境注入：把令牌寫在全局環境而不分工具實例，會讓一次洩露影響所有 MCP；應分配置段並支持輪換。
是否與 modelRouting 打架：大上下文走高價模型、小任務走輕模型時，工具失敗重試可能被不同模型重複觸發，需要路由層與工具層共同限流。
觀測是否只看 Gateway：若日誌裡看不到 MCP 子進程啟動參數與退出碼，線上只能「重啟試試」；應與觀測篇的日誌欄位對齊。
把這些信號攤開之後，核心結論是：MCP 接入 = 配置 + 進程 + 網絡 + 權限 四條線同時收緊。接下來用一張表把 stdio 與遠程 MCP 的差異釘死，再進入六步上線清單。
與站內文章分工可記為：三端安裝與 systemd/Docker 篇負責「Gateway 進程如何常駐」；安全加固篇負責「誰能連上、能出站到哪」；modelRouting 篇負責「模型分層與成本」；本文負責「工具從哪來、如何被允許、如何排錯」——四者疊在一起才是可審計的生產拓撲。
這張表用於架構評審：同一業務需求往往兩種都能實現，但威脅模型與故障模式不同；不要只比較「哪種少寫兩行配置」。
| 維度 | stdio（本機子進程） | 遠程 MCP（HTTP/SSE 等） |
|---|---|---|
| 進程邊界 | 與 Gateway 同用戶/同主機，繼承環境變量與文件權限 | 跨主機，需單獨 TLS、鑑權與健康檢查 |
| 網絡暴露 | 默認無額外監聽；風險在本地命令與路徑注入 | 引入新端點與出站依賴，需納入 networkPolicy |
| 升級與復現 | 依賴本地二進位/包管理器版本，需釘版本與哈希 | 可集中發布，但要處理滾動升級與兼容矩陣 |
| 典型故障 | PATH/權限/解釋器不匹配導致啟動即退出 | DNS、TLS、反代超時與 401/403 鏈路問題 |
| 觀測抓手 | 子進程 PID、退出碼、stderr 切片 | HTTP 狀態、重試曲線、端到端延遲分位 |
MCP 不是「多一個插件」，而是多了一條可執行供應鏈；選 stdio 還是遠程，本質是在選把風險放在本機邊界還是網絡邊界。
若你還把重型構建或 macOS 專屬工具鏈放在遠端執行層，常見拓撲是：Gateway 跑在 Linux/VPS，獨佔遠程 Mac承載 xcodebuild 與籤名相關步驟，通過受控通道回傳日誌與製品。此時 MCP 更適合暴露「輕量編排面」，而不是在網關裡堆疊長耗時任務；算力與磁碟仍應落在可合同化的節點上。
按順序執行，目標是把「工具能用」升級成「變更可審計、失敗可定位、回滾有路徑」。
登記工具身份：為每個 MCP 寫入穩定名稱、版本來源（包名/commit/digest）與負責人；禁止匿名腳本隨倉庫漂移。
最小權限啟動參數：stdio 用絕對路徑與專用工作目錄；遠程 MCP 顯式 TLS、超時、重試上限，避免隱式系統代理。
配置校驗：變更後先跑 openclaw config:validate，再跑 openclaw doctor，把報錯當作合併門檻。
白名單對齊：將允許的工具清單與 dmPolicy / 執行審批策略交叉檢查，避免「配置裡關了、模型還能猜路徑」的錯位。
灰度通道：先在低流量會話啟用新工具，保留舊工具並行一周；記錄對比指標（失敗率、P95 延遲、子進程重啟次數）。
回滾包：備份上一版 openclaw.json 與鏡像 digest；故障時優先回滾配置與鏡像，再排查工具本身。
{
"mcpServers": {
"internal-git": {
"command": "/opt/mcp/git-mcp",
"args": ["--config", "/etc/mcp/git.prod.json"],
"env": { "MCP_LOG_LEVEL": "info" }
}
}
}
提示：示意片段僅表達結構層次，真實鍵名與嵌套請以你正在使用的 OpenClaw 版本文檔為準；升級大版本前先在預發集群跑同一套 validate/doctor。
安全加固篇強調監聽面、Token、dmPolicy 與 networkPolicy；MCP 接入後，工具調用成為新的「執行出口」，需要把允許調用的工具集合與允許觸達的下遊放在同一評審表裡。實踐上可為每類工具定義：最大並發、單調用超時、日調用預算，以及失敗後的熔斷策略。
出現「模型說在調用工具但前端一直轉圈」時，優先對照三類根因：子進程未啟動（路徑/權限）、握手未完成（協議版本/鑑權）、下遊阻塞（網絡或業務 API）。不要在未採集退出碼與 stderr 的情況下反覆重啟 Gateway，否則會把間歇性故障洗成持續性事故。
與觀測篇配合時，把 MCP 啟動與銷毀事件納入同一日誌關聯 ID，便於把「模型請求 → 工具調用 → 子進程退出」串成一條鏈。
注意：不要在生產環境長期開啟「調試級工具枚舉日誌」而不做脫敏；工具參數裡常夾帶倉庫路徑、內網主機名與令牌片段。
下列條目用於值周與事故復盤；具體閾值請用你們自己的 SLO 與監控補齊。
僅在本機筆記本上堆 MCP、缺少網關治理與穩定執行平面時，往往在睡眠、磁碟與多人爭用會話上頻繁踩坑；把重負載硬塞進 Gateway 同進程也可能放大故障半徑。對需要可審計工具鏈、穩定磁碟與 7×24 可預期算力的團隊，更務實的組合是：OpenClaw Gateway 負責會話與策略，獨佔遠程 Mac 節點承接 macOS/iOS 構建與長任務，MCP 只暴露窄接口。綜合工具治理與算力成本，NodeMini 的 Mac Mini 雲端租賃適合作為執行層底座：把網關上的 MCP 編排與雲上 Mac 的構建/籤名解耦，再用本文 checklist 管住版本、白名單與超時。
建議先 openclaw config:validate，再 openclaw doctor；需要自動修復已知無效鍵時謹慎使用 doctor --fix 並留變更記錄。更多連接與訂購問題可參考 幫助中心。
stdio 適合同機、邊界清晰；HTTP/SSE 適合跨主機但要疊加 TLS、鑑權與 networkPolicy。請把選項與 OpenClaw 專欄中的安全篇一起評審，而不是單獨拍腦袋。
Gateway 繼續負責對話與工具策略；重負載放到獨佔遠程 Mac。可先瀏覽 OpenClaw 分類與 租賃價格說明，把工具編排與算力節點分開規劃。