概述

隨着 Cursor 等智能編程工具的崛起、Manus 產品的推出，以及 Claude Sonnet 等大語言模型在編程領域能力的顯著提升，MCP 逐漸引起了技術社區的廣泛關注與重視。本文將深入淺出地介紹 MCP 的核心概念，並結合具體場景探討其實際應用價值。

什麼是 MCP？

MCP（The Model Context Protocol，模型上下文協議）是一個開放協議，由 Anthropic 在 2024 年 11 月提出。MCP 能夠實現 LLM 應用與外部數據源和工具之間的無縫集成。無論是在構建一個 AI 驅動的 IDE、增強聊天界面，還是創建自定義 AI 工作流，MCP 都提供了一種標準化的方式，將 LLM 與所需的上下文連接起來。 可以把 MCP 理解爲 Agent 世界的 轉接頭。

MCP 整體架構

MCP 遵循 client-server 架構，對於一個 Agent 而言可以連接多個 MCP Server。整體架構包含 4 部分：

• MCP Host：通過 MCP 訪問數據的 AI 工具的程序，如 Claude Desktop、集成開發環境（IDE）或 Agent 等

• MCP Client：與 MCP Server 保持 1:1 連接的協議客戶端

• MCP Server：輕量級程序，通過標準化的 MCP 暴露特定功能，包括工具（Tools）、外部資源（Resources）和提示詞模版（Prompts）等。

• MCP Protocols：定義 MCP Client 和 MCP Server 之間的通信方式

MCP Host

MCP Host 可以是任何需要訪問外部數據的 LLM 應用 / Agent。它們負責：

• 初始化和管理多個 MCP Client。

• MCP Client-MCP Server 生命週期管理。

• 處理用戶授權。

• 管理跨 MCP Client 的上下文聚合。

MCP Client

每個 MCP Client 負責：

• 專用連接：每個 MCP Client 與 MCP Server 保持一對一的有狀態連接。這種專用連接模式確保了通信界限清晰，並實現安全隔離。

• 消息路由：MCP Client 負責處理所有雙向通信，高效地在 MCP Host 和所連接 MCP Server 之間傳遞請求、響應和通知。

• 能力管理：MCP Client 通過維護服務器的可用工具、資源（上下文數據）以及提示模板等信息，監控並管理所連接 MCP Server 的能力。

• 協議協商：在初始化階段，MCP Client 會與 MCP Server 協商協議版本和相關能力，以確保 MCP Host 與 MCP Server 之間的兼容性。

• 訂閱管理：MCP Client 維護對 MCP Server 資源的訂閱關係，當這些資源發生變化時，負責處理並分發相應的通知事件。

MCP Server

MCP Server 是爲 LLM 提供外部數據和上下文的基礎構建單元。MCP Server 的關鍵組成包括：

• 工具（Tools）：工具是可執行的函數，使得大語言模型能夠與外部應用進行交互，其作用方式類似於傳統 LLM 調用中的函數。例如，一個名爲 LIST_FILES 的工具，接收目錄名稱作爲參數，執行後會獲取該目錄下的文件，並將結果返回給客戶端。此外，工具也可以是對外部服務的 API 調用，例如 Gmail、Slack 和 Notion 等。

• 資源（Resources）：資源包括文本文件、日誌文件、數據庫結構定義、文件內容以及 Git 歷史記錄等，可以爲 LLM 提供額外的上下文信息。

• 提示模板（Prompt Templates）：預定義的模板或指令，用於指導 LLM 的互動行爲。

工具由模型自主控制，而資源和提示模板則由用戶進行控制。模型能夠根據給定的上下文自動發現並調用所需工具。

MCP Protocols

所有的 MCP Protocol 必須遵循 JSON-RPC 2.0。目前協議定義的類型有：

• Requests：執行操作的消息，必須包含唯一的 ID 和方法名。

• Responses：返回的消息，必須包括 Request 中的 ID。

• Notifications：單向消息無需返回，必須不包含 ID。

關於協議的更多內容可以參考：https://spec.modelcontextprotocol.io/specification/2024-11-05/

Function Calling vs MCP

主要區別如下：

Function Calling 由特定的大模型服務提供商（如 OpenAI 的 GPT-4）引入的功能。它允許模型根據輸入，生成特定格式的函數調用請求。應用程序接收到該請求後，執行相應的操作，並將結果返回給模型。這種機制使模型能夠主動請求外部功能的執行，但並不強制要求使用特定的通信協議或格式。

MCP 是在 OpenAI 的 Function call 和 GPTs 之後提出的，可以說 Function call 爲 MCP 提供了靈感和基礎功能。MCP 是一種開放協議，旨在通過標準化的接口，實現大型語言模型與外部數據源及工具的無縫集成。它規定了上下文與請求的結構化傳遞方式，確保消息傳遞的標準化和一致性。MCP 的設計初衷是通過本地運行服務器來確保用戶數據的安全性，避免將敏感信息直接發送給 LLM。

主要區別：

• 層級定位：Function Calling 更側重於模型的具體實現和特性，是特定大模型廠商提供的獨特功能。而 MCP 則是一個更底層、更通用的標準，相當於爲所有人提供的 “公共基礎設施”。

• 通信方式：Function Calling 的通信格式並不固定，可能根據不同廠商的實現而有所不同。而 MCP 要求通信格式遵循 JSON-RPC 2.0 標準，確保消息傳遞的標準化和一致性。

• 依賴關係： 兩者並不互相包含，也沒有誰必須依賴誰。應用可以選擇在 MCP 之上通過特定機制（包括 Function Calling）與模型交互，也可以在 MCP 範式下使用其他不基於 Function Calling 的方式與模型或數據源交互。

參考資料

• Model Context Protocol Introduction

• Model Context Protocol Specification

• 給 MCP 祛魅

• MCP 與 Function Call 區別 - 蟈蟈俊 - 博客園

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