10張動圖深度剖析 MCP 架構原理

最近，模型上下文協議（MCP）特別火，你可能已經聽說過了。

今天，我們來搞懂它到底是個啥。

簡單來說，MCP 就像是給你的 AI 應用準備的一個 USB-C 接口。

就像 USB-C 提供了一個標準化的方式來連接各種配件一樣，MCP 標準化了你的 AI 應用如何連接到不同的數據源和工具。

讓我們稍微深入一點，從技術角度來剖析。

MCP 的核心是客戶端-服務器架構，一個主機應用可以連接到多個服務器。

它有三個關鍵部分：主機（Host）、客戶端（Client）和服務器（Server）。

在我們深入之前，先簡單了解一下??

主機代表任何 AI 應用（比如：Claude 桌面版，Cursor），它提供了 AI 交互的環境，訪問工具和數據，并運行 MCP 客戶端。

MCP 客戶端在主機內部運行，以實現與 MCP 服務器的通信。

最后，MCP 服務器展示了特定的能力和提供數據訪問，比如：

• 工具：讓大語言模型（LLMs）通過你的服務器執行操作。
• 資源：將你的服務器上的數據和內容暴露給 LLMs。
• 提示詞：創建可重用的提示詞模板和工作流程。

理解客戶端-服務器通信對于構建你自己的 MCP 客戶端-服務器至關重要。

所以，我們來理解一下客戶端和服務器是如何通信的。

在我們一步步分解之前，先看一個示意圖...

首先，我們有功能交換，其中：

• 客戶端發送一個初始請求來了解服務器的功能。
• 服務器然后響應它的功能細節。
• 例如，一個天氣 API 服務器，當被調用時，可以回復可用的“工具”，“提示詞模板”，以及客戶端可以使用的其他資源。

一旦這個交換完成，客戶端確認成功連接，進一步的消息交換繼續進行。

這是這種設置如此強大的原因之一：

在傳統的 API 設置中：

• 如果你的 API 最初需要兩個參數（比如：天氣服務的位置和日期），用戶將他們的應用程序集成以發送帶有這些確切參數的請求。
• 后來，如果你決定添加第三個必需參數（比如：溫度單位，攝氏度或華氏度），API 的結構就改變了。
• 這意味著你 API 的所有用戶都必須更新他們的代碼以包含新參數。如果他們不更新，他們的請求可能會失敗，返回錯誤，或提供不完整的結果。

MCP 的設計解決了這個問題：

• MCP 引入了一種與傳統 API 截然不同的動態和靈活的方法。
• 例如，當一個客戶端（比如：一個 AI 應用，如 Claude 桌面版）連接到一個 MCP 服務器（比如：你的天氣服務）時，它發送一個初始請求來了解服務器的功能。
• 服務器響應有關其可用工具、資源、提示詞和參數的詳細信息。比如：如果你的天氣 API 最初支持位置和日期，服務器將這些作為其功能的一部分進行通信。

• 如果你后來添加了一個單位參數，MCP 服務器可以在下一次交換期間動態更新其功能描述?？蛻舳瞬恍枰簿幋a或預定義參數——它只需查詢服務器的當前功能并相應地調整。

這樣，客戶端就可以即時調整其行為，使用更新的功能（比如，在請求中包括單位），而無需重寫或重新部署代碼。

到此，我希望你徹底理解 MCP 的作用。

未來，我將探索創建自定義 MCP 服務器并圍繞它們構建實踐演示。敬請期待！

本文轉載自??玄姐聊AGI??  作者：玄姐???