從握手到多Server聚合：MCP 把工具整合的成本，從每家重寫一次壓成協議內建

2026 年 10 月 2 日，掘金用戶「碼農悟道」發布了一篇約 16 分鐘閱讀量的 MCP 技術長文，內容從協議握手、工具定義、結構化返回，一路講到 LangChain 與 LangGraph 的多 Server 接入與聚合。這篇教學式分享本身沒有新聞事件，但它碰到的問題是真實的：當 AI Agent 從演示走向落地，工具整合這一環的成本由誰吸收、吸收多少，正隨協議標準化而被重新定價。

沒有協議時，整合成本長什麼樣子

該文開篇即點出落地現況：AI Agent 部署時最常見的需求已非更換模型，而是讓模型安全穩定地訪問外部能力，包括查詢資料庫、讀取檔案、調用業務 API、執行計算與搜尋知識庫。

在缺乏統一協議的前提下，這些操作的成本結構呈碎片化：每個模型框架各定義一套工具格式，每個業務系統各寫一套適配代碼，工具參數、錯誤處理、權限、日誌與傳輸方式互不相容。文中最直接的量化後果是：Agent 從一個平臺遷移到另一個平臺時，大量集成代碼需要重寫。

用本站的帳本語言來說，這是典型的 N 乘 M 問題。N 個框架對上 M 個業務系統，適配工作量隨兩側數量相乘增長；協議標準化後，理論上收斂為 N 加 M，每一側只需對接一次協議。MCP（Model Context Protocol）把能力提供方抽象為 Server，使用方抽象為 Client，以 JSON-RPC 與明確的初始化流程統一工具、資源、提示詞、生命週期與傳輸。文章對其價值的定位相當克制：不在於讓模型更聰明，而是讓工具調用從私有約定變成可發現、可復用、可測試的協議能力。

這與我們先前分析的企業微信把底層介面交給 AI Agent是同一條曲線上的兩個點：辦公平臺開放 CLI 與 MCP 介面，與開發者社羣大量產出 MCP 教學內容，都指向工具層介面權力正在從各平臺私有 API 向協議層移動。

三個角色與一個版本斷層

文章將 MCP 架構拆為三個角色：Host 是用戶實際使用的應用（IDE、聊天客戶端、企業工作臺），負責模型、會話與權限；Client 由 Host 創建，管理握手、能力協商與連接關閉，Python 中對應 ClientSession；Server 暴露三類能力，即 Tools（可調用函數）、Resources（可讀取上下文）與 Prompts（提示詞模板）。

值得記錄的是文中的版本斷層提示。MCP Python SDK 2.x 已將舊版 FastMCP 更名為 MCPServer，導入路徑從 mcp.server.fastmcp 改為 mcp.server.mcpserver，且兩者不能混用。配套環境固定為 Python 3.11 至 3.13、mcp==2.2.0、LangChain 1.x、LangGraph 1.x、Pydantic 2.x。這類命名遷移意味著既有專案的升級成本：文件、教學與範例代碼在 1.x 與 2.x 之間不可直接互換，社羣知識庫的有效性綁定在特定版本上，學習與維護成本並未因標準化而歸零，只是換了掛帳的位置。

傳輸層選擇與聚合成本

文章後半段涵蓋工程落地的幾個實際選項：如何在 stdio、SSE 與 Streamable HTTP 三種傳輸之間選擇，以及如何聚合多個 MCP Server 接入 LangGraph。多 Server 聚合正是 N 加 M 收斂邏輯的兌現場景：Host 不再為每個工具來源各寫一套膠水代碼，而是透過統一的 Client 層並聯多個 Server，工具的發現、調用與生命週期管理走同一套協議。

從需求分層看，這篇教學的讀者畫像也很清楚：不是模型研究人員，而是要把 Agent 接進真實業務系統的工程團隊。這一層的需求此前長期由各雲端廠商的私有 Agent 平臺吸收，MCP 的擴散等於在工具整合這個環節引入了替代品，替代的對象是客製化適配代碼的工時。與我們討論過的開源 AI 辦公客戶端的配置成本取捨類似，標準化協議把「誰來付整合成本」這個問題從平臺端攤回協議公共層，個別開發者的遷移成本下降，但協議本身的版本演進成本仍然存在。

受惠與承壓的傳導

傳導鏈可以攤開來看。受惠方首先是業務系統方：一次封裝為 MCP Server，即可被多個 Host 消費，適攤成本從按平臺計價改為按協議計價。其次是 Agent 框架與中間層（如 LangChain、LangGraph），標準化擴大了可調用工具的供給池，框架的網路效應隨之增強。承壓方則是靠私有工具整合收取客製化費用的整合商，以及原本以工具介面封閉性鎖定客戶的平臺，兩者的護城河都掛在「適配成本高」這一欄上，協議普及直接侵蝕該欄數字。

需要保留的是分寸：這篇分享屬於教學性質，展示的是單一開發者的可運行範例集，尚未提供商業部署規模、錯誤率或生產環境數據。MCP 在大規模多 Server 場景下的穩定性、權限治理與審計成本，文中僅以「工程化落地時需要關注什麼」作為章節提示，未給出量化結論。

收束判斷

一篇技術教學的熱度，通常是需求側的落後指標。當協議握手、能力協商、多 Server 聚合這類內容成為社羣的基礎產能時，說明工具整合已從差異化能力轉為表配工作。對工程團隊，這是整合成本曲線下彎的訊號；對平臺與整合商，定價權正從客製化工時轉向協議層的生態位，誰掌握 Server 的分發與治理，誰就接住下一輪帳本。