圖解「模型上下文協議（MCP）」：從與傳統 API 的比較入手
最近，關于模型上下文協議（MCP）的討論非常熱烈。你一定聽說過它。
今天，讓我們一起來了解一下模型上下文協議（MCP）。
直觀地說，MCP 就像 AI 應用的 USB-C 接口。
正如 USB-C 為設備連接各種配件提供了標準化方案，MCP 也將 AI 應用連接到不同數據源和工具的方式標準化了。
1.gif
接下來從技術角度進行深入探討。
MCP 的核心遵循客戶端-服務器（client-server）架構，Host 應用程序可以連接到多個 Server。
它包含三個主要組件：
- Host
- Client
- Server
在我們進行深入探討之前，先來了解一下整體架構??
2.gif
Host 代表任何提供 AI 交互環境、訪問外部工具和數據源并運行 MCP Client 的 AI 應用（如 Claude 桌面版、Cursor）。
MCP Client 在 Host 內運行，實現與 MCP Servers 的通信。
image.png
MCP Server 對外開放特定能力，并提供對數據源的訪問權限，包括：
image.png
- Tools：使大語言模型能夠通過你的 Server 執行操作。
- Resources：將 Server 上的數據和內容開放給大語言模型。
- Prompts：創建可復用的提示詞模板和工作流程。
要構建屬于你自己的 MCP 系統，理解客戶端-服務器通信機制是必不可少的。
現在我們來解析客戶端與服務器的通信流程。
本文將對該過程進行逐步拆解，請看下方這張示意圖...
3.gif
首先進行 Capability Exchange（譯者注：Capability Exchange（能力交換）是一種動態服務發現與適配機制，是MCP連接建立的必經步驟，類似于“握手協議”。），流程如下：
- 客戶端發送初始請求，獲取服務器能力信息
- 服務器返回其能力信息詳情
- 例如當天氣 API 服務器被調用時，它可以返回可用的“tools”、“prompts templates”及其他資源供客戶端使用
交換完成后，客戶端確認連接成功，然后繼續交換消息。
這種機制非常強大，原因如下：
在傳統的 API 架構中：
- 如果你的 API 最初需要兩個參數（例如，天氣服務的 location 參數（譯者注：地理位置）和 date 參數（譯者注：日期）），用戶需嚴格按此參數結構構建應用。
image.png
- 之后，如果你決定為該 API 添加第三個必選參數（例如，unit參數（譯者注：溫度單位）），將API “契約”進行變更。
image.png
- 這意味著該 API 的所有用戶都必須更新代碼，增加對新參數的支持，如果未及時更新，他們的請求可能會失敗、報錯或提供不完整的結果。
image.png
MCP 的設計解決了這個問題，具體方法如下：
- MCP 引入了一種動態、靈活的方法，與傳統 API 形成鮮明對比。
- 當 Client（例如 Claude Desktop 這類 AI 應用）連接 MCP Server（例如天氣服務）時，會發送初始請求，以便了解 Server 的能力。
- Server 的響應包含可用的 tools、resources、prompts 以及相關參數的詳細信息。例如，若天氣 API 最初僅支持 location 和 date 參數，服務器會通過能力交換告知這些信息。
當新增 unit 參數時，MCP Server 可在下次進行能力交換時動態更新能力描述。Client 無需硬編碼或預定義參數，只需查詢 Server 的最新能力并自動適配。
這樣，Client 就能使用更新后的新功能（例如在其請求中包含 unit 參數），實時調整行為，而無需重寫或重新部署代碼。
希望本文能闡明 MCP 的作用。
后續我們將探索如何創建自定義的 MCP servers 并圍繞它們構建實踐演示，敬請期待！
Thanks for reading!
Hope you have enjoyed and learned new things from this blog!
