給 MCP 祛魅

MCP（Model Context Protocol，模型上下文協議）推出將近一年，隨着 Cursor 等 IDE 工具的興起和 Claude Sonnet 的編程能力的提升，逐步得到技術圈人的關注。最近，隨着 Manus 的一圈轟炸，有人給出了 Manus=Cursor+MCP 的解方，這時 MCP 漸漸進入一般大衆的視野，熱度頓時提升爲 “神” 級創新。那麼，今天我們來給 MCP 祛魅。

MCP 是在 OpenAI 的 Function call 和 GPTs 之後出現的，那麼它一定是看到了 Function call 的開發和使用的複雜性，而且看到了 GPTs 的封閉和不開放性。

Function call 可以說是 MCP 的靈感的來源和基礎功能，可以理解 Function call 等同於工具（tools）。大模型（LLM）能夠理解工具的描述和參數的規定，然後，會從一堆工具中去選擇一個和幾個工具來解決用戶提出的問題。沒有 LLM 能自動選擇和調用工具的能力，也沒有 MCP 這個概念的可能。這是 MCP 的源頭和基礎，不得不說，這是 OpenAI 的巨大原始貢獻。

但是，Function call，或者 Tools 使用，對很多開發者，就不用說一般用戶了，儘管能用大模型來 copilot，還是很不方便，網絡訪問，權限控制，流程控制，錯誤處理，可靠性，版本維護，升級改動，等等，一大堆事情都要去編程處理。而且，對不同的應用場景，可能還需要定製化。

既然 Function call 這麼複雜不好用，那麼 OpenAI 提出了 GPTs 的概念，說白的，GPTs 就類似於微信的小程序，它的底層實現，依然是基於 Function call，做好的一個一個 GPTs，用戶可以選擇使用哪一個。這兒的問題是，GPTs 相當於是已經包裝好的閉源應用，只能在 OpenAI 平臺上使用，不開放，不是生態玩法（可能只是 OpenAI 生態）。你給 OpenAI 做了個 GPT，對別的平臺，你還得做一個，這樣，對服務商，開發者，依然不方便，不利於市場拓展。

由此看到，Function call 太底層，GPTs 太高層，這時，就有了 MCP 這樣處於中間層的協議或產品出來了。

大家習慣用下面這張圖來說明 MCP 的架構。

但我覺得下面這張更清晰。

中間的 Java Gen AI Application 就是一個應用，用更流行的詞，是 Agent（智能體），然後，它可以調用（觸發）不同的 Java MCP Client 來完成一個用戶的需求，而這時，Client 會通過 MCP protocol 來調用和它配套的 MCP Server 來實際完成任務。所有的細節處理，都有 MCP SDK 來包裝完成的。

再底層一點的實現，是下面這張圖。懂不懂不重要，大概知道一層一層實現就可以了。

MCP 處理的一個用戶的需求（query 或 request）是這樣的：

MCP Client 從 MCP Server 得到所有工具（tools 或 function calls）的列表和描述，包括參數描述。

MCP Client 將用戶的需求和工具加描述列表送給大模型（LLM）。

大模型確定應該使用哪個工具。

MCP Client 通過調用 MCP Server 來執行大模型選擇的工具，從而得到工具執行後的結果。

MCP Client 講結果送給大模型來提供自然語言的描述，然後呈現給用戶。

在 MCP Server 中，是通過類似 Java 的文檔規範來定義和說明工具的，這樣，MCP SDK 可以通過這種方式來自動輸出工具和描述列表的。

MCP 的好處是用這種形式開發的產品或應用，可以通過 MCP Client 的方式，嵌入到別的 AI 應用中，它們類似於開發中的組件，或庫，或微服務，水都可以盡情的調用。這些 MCP 應用更新，升級，對這些新開發的 AI 應用都是無感的，這樣，更利於 Agent 生態的開發。

但 MCP 也有它的不足，還是有很多的開發量，對一般的普通用戶，實際也很難上手開發。

也許，MCP 還是一個 AI native 時代的過渡產品，我們還可以期待更多更讓人激動的創新出來。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/qtsxTC8_LioHUuZHQo5CoA