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

最近，模型上下文協(xié)議（MCP）特別火，你可能已經(jīng)聽說過了。

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

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

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

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

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

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

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

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

MCP 客戶端在主機內(nèi)部運行，以實現(xiàn)與 MCP 服務器的通信。

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

• 工具：讓大語言模型（LLMs）通過你的服務器執(zhí)行操作。
• 資源：將你的服務器上的數(shù)據(jù)和內(nèi)容暴露給 LLMs。
• 提示詞：創(chuàng)建可重用的提示詞模板和工作流程。

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

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

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

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

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

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

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

在傳統(tǒng)的 API 設置中：

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

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

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

• 如果你后來添加了一個單位參數(shù)，MCP 服務器可以在下一次交換期間動態(tài)更新其功能描述。客戶端不需要硬編碼或預定義參數(shù)——它只需查詢服務器的當前功能并相應地調(diào)整。

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

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

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

本文轉(zhuǎn)載自??玄姐聊AGI??  作者：玄姐???