Model Context Protocol (MCP) 是一种开放标准,旨在定义 AI 应用程序如何连接到外部数据源和工具。它的核心机制是基于 客户端-服务器架构 (Client-Server Architecture) ,但在这个架构中引入了一个额外的组件,即 Host (宿主) 。
以下是 MCP 的机制以及 Host、Client 和 Server 的角色:
1. MCP 的核心理念
- 标准化集成: MCP 的目标是为 AI 模型与外部世界(数据、工具、服务)的交互提供一个标准化的接口。这就像 USB-C 端口,允许不同的设备以统一的方式连接到各种外设和配件,避免了为每个集成编写定制代码的复杂性。
- 上下文感知: MCP 不仅仅是简单的数据传输,它还支持上下文的传递和维护,使得 AI 模型能够更好地理解和利用外部信息。
- 双向通信: MCP 允许 AI 模型既可以获取信息,也可以动态触发外部操作。
2. Host、Client、Server 的角色
在 MCP 架构中,这三个组件协同工作:
-
Host (宿主):
-
定义: Host 是用户直接交互的 AI 驱动应用程序。例如,像 Claude Desktop 这样的 AI 聊天界面、AI 增强的集成开发环境 (IDE) 如 Cursor、或自定义的智能代理应用。
-
职责:
- 用户交互和权限管理: 处理用户的输入、管理用户权限和安全策略。
- 连接协调: 通过其内部的 MCP Client 组件启动与 MCP Server 的连接。
- 流程编排: 协调用户请求、大型语言模型 (LLM) 处理以及外部工具的调用。
- 结果呈现: 将处理结果以连贯的格式呈现给用户。
- LLM 集成: 通常在 Host 内部运行 LLM,LLM 根据用户提示决定是否需要调用外部工具或获取外部数据。
-
-
Client (客户端):
-
定义: Client 是 Host 应用程序内部的一个组件。它不直接与用户交互,而是作为 Host 和特定 MCP Server 之间的中介。
-
职责:
- 1:1 连接: 每个 Client 维护与一个特定 MCP Server 的一对一连接。
- 协议处理: 处理 MCP 通信的协议级别细节(通常基于 JSON-RPC 2.0)。
- 请求转发与响应处理: 接收 Host 的请求,将其格式化为 MCP 消息发送给 Server,并接收 Server 的响应,然后将其传递回 Host。
- 能力发现: 当连接建立时,Client 会向 Server 查询其提供的能力(Tools、Resources、Prompts)。
- 安全边界: 确保客户端之间的数据隔离,一个客户端不会“窥探”属于另一个客户端的资源。
-
-
Server (服务器):
-
定义: Server 是一个独立的程序或服务,它通过 MCP 协议向 AI 模型暴露特定的功能。这些功能可以是访问外部工具、数据源或服务。
-
职责:
-
提供能力: 提供各种“能力”给 Client,这些能力通常分为:
- Tools (工具): 可执行的功能,例如调用一个 API、运行一个脚本、执行代码等。
- Resources (资源): 可供读取的数据和内容,例如文件系统、数据库、Web 页面内容、日历事件等。
- Prompts (提示): 预定义的模板和工作流,用于标准化 LLM 交互。
-
执行操作: 接收 Client 的请求,执行相应的操作(例如,查询数据库、调用外部 API),并将结果返回给 Client。
-
数据源/服务连接: Server 本身可以连接到各种本地数据源(文件、本地服务)或远程服务(如 Google Drive、Slack、GitHub API)。
-
状态维护: MCP Server 通常与 Client 保持有状态的连接,允许一系列具有共享上下文的来回交互。
-
-
3. MCP 工作流程示例
- 用户输入: 用户在 Host 应用程序(例如 Claude Desktop)中输入一个请求,例如“更新我的日程表,将明天的会议提前一小时”。
- Host 处理: Host 内部的 LLM 会分析这个请求,并识别出需要调用外部工具来修改日程表。
- Host -> Client: Host 决定需要哪个 MCP Server 的能力(例如,一个与日历服务集成的 MCP Server),然后指示其对应的 Client 准备发送请求。
- Client -> Server: Client 将请求格式化为 MCP 消息(例如,一个
tools/execute请求,包含会议ID和新的时间参数),并通过 MCP 协议发送给日历 MCP Server。 - Server 执行: 日历 MCP Server 接收请求,调用底层的日历 API,将会议时间提前一小时。
- Server -> Client: Server 将操作结果(例如,成功更新的确认)通过 MCP 协议返回给 Client。
- Client -> Host: Client 收到响应,将其传递回 Host。
- Host 呈现: Host 接收到结果,并将其呈现给用户,例如显示“您的会议已成功更新”。
总结
MCP 通过引入 Host、Client 和 Server 的分层架构,实现了 AI 应用程序与外部世界的模块化、标准化和上下文感知的交互。Host 负责用户界面和 LLM 的核心推理,Client 负责协议细节和与特定 Server 的连接,而 Server 则暴露具体的外部能力。这种设计极大地简化了 AI 应用的集成复杂性,并促进了更强大、更灵活的 AI 系统的构建。
JSON-RPC 的原理
JSON-RPC 是一种轻量级的远程过程调用 (RPC) 协议,它使用 JSON (JavaScript Object Notation) 格式来编码数据。它的核心思想是允许客户端程序调用位于不同地址空间(通常是网络上的另一台计算机)中的过程或函数,就好像它们是本地过程一样。
核心原理:
- 请求/响应模型: JSON-RPC 遵循经典的请求/响应模型。客户端发送一个请求给服务器,服务器处理请求并返回一个响应。
- JSON 作为数据格式: 所有消息(请求和响应)都使用 JSON 格式进行编码。这使得协议非常易于解析和生成,并且与各种编程语言兼容。
- 方法调用: 客户端通过发送一个包含要调用的方法名称和参数的 JSON 对象来发起请求。
- 无状态: 协议本身是无状态的,这意味着每次请求都包含足够的信息来完成操作,服务器不需要记住之前的请求状态(尽管底层服务可以是有状态的)。
- 跨平台/语言: 由于使用 JSON,JSON-RPC 可以轻松地在不同操作系统和编程语言之间实现互操作。
JSON-RPC 请求的结构(客户端发送给服务器):
JSON
{
"jsonrpc": "2.0", // 协议版本,目前通常是 "2.0"
"method": "someMethod", // 要调用的方法名
"params": [param1, param2, ...], // 方法参数,可以是数组或对象
"id": 1 // 请求ID,可选。如果存在,服务器必须在响应中包含相同的ID。用于匹配请求和响应。
}
jsonrpc: 总是 "2.0"。method: 一个字符串,包含要调用的方法的名称。params: 一个结构化值,作为调用方法时使用的参数。它可以是按位置传递的数组,也可以是按名称传递的对象。id: 一个唯一标识请求的值。通常是字符串、数字或null。如果省略,则表示这是一个通知 (notification),客户端不期望响应。
JSON-RPC 响应的结构(服务器发送给客户端):
成功响应:
JSON
{
"jsonrpc": "2.0",
"result": "someResult", // 方法返回的结果
"id": 1 // 对应请求的ID
}
错误响应:
JSON
{
"jsonrpc": "2.0",
"error": {
"code": -32601, // 错误码,预定义或自定义
"message": "Method not found", // 错误消息
"data": "Optional error data" // 额外的错误信息
},
"id": 1 // 对应请求的ID
}
result: 如果请求成功,此字段包含方法返回的值。error: 如果请求失败,此字段包含一个错误对象,其中包含code(错误码)和message(错误描述)。id: 对应请求的 ID。
工作流程概览:
- 客户端准备请求: 客户端程序将要调用的方法名和参数打包成一个 JSON-RPC 请求对象。
- 发送请求: 客户端通过网络(通常是 TCP/IP,可以使用 HTTP 或 WebSockets 作为传输层)将 JSON-RPC 请求发送到服务器。
- 服务器解析请求: 服务器接收到请求后,解析 JSON 字符串,提取方法名和参数。
- 执行方法: 服务器调用其内部对应的方法,并传入解析出的参数。
- 准备响应: 方法执行完成后,服务器将结果或错误信息打包成一个 JSON-RPC 响应对象。
- 发送响应: 服务器将 JSON-RPC 响应发送回客户端。
- 客户端解析响应: 客户端接收到响应,解析 JSON 字符串,获取结果或错误信息。
优点:
- 简单性: 协议结构非常简单,易于理解和实现。
- 易于解析: JSON 格式使得数据解析变得轻而易举。
- 语言无关: 可以在任何支持 JSON 的语言中使用。
- 低开销: 相对于 SOAP 等其他 RPC 协议,JSON-RPC 的开销较低。
MCP (Model Context Protocol) 的原理
MCP 的核心原理是在 JSON-RPC 的基础上,为 AI 模型与外部世界(工具、数据、服务)的交互定义了一套标准化、有上下文的通信协议。它不是替代 JSON-RPC,而是在 JSON-RPC 之上构建了一层语义和约定。
MCP 的主要创新点在于:
-
定义了标准化的“能力”(Capabilities): MCP 规定了 AI 模型可以请求的外部能力类型,主要包括:
- Tools (工具): 可执行的操作,例如:
tools/execute(执行某个工具)、tools/list(列出可用的工具)。 - Resources (资源): 可读的数据源,例如:
resources/read(读取资源内容)、resources/list(列出可用资源)。 - Prompts (提示): 预定义的提示模板或工作流,例如:
prompts/apply(应用某个提示)。 这些能力在 MCP 中都有明确定义的方法名和参数结构,允许 AI 模型以统一的方式调用它们。
- Tools (工具): 可执行的操作,例如:
-
上下文管理: 传统的 RPC 往往是无状态的。但 AI 模型与外部世界的交互通常需要上下文。MCP 通过以下机制支持上下文:
- 持久连接: 通常使用 WebSocket 或其他持久连接来保持客户端和服务器之间的连接,允许连续的、有上下文的对话。
- 有状态交互: MCP Server 可以维护与特定 Client 相关的状态信息,例如已打开的文件句柄、会话变量等。
- 请求 ID 和通知: 虽然继承自 JSON-RPC,但其
id字段对于匹配连续的、有上下文的请求和响应至关重要。
-
能力发现机制: MCP 允许客户端(Host 内部的 MCP Client)查询服务器以发现其支持的所有工具、资源和提示。这使得 AI 模型可以在运行时动态地了解可用的外部功能,而不需要硬编码。例如,客户端可以发送一个
tools/list请求来获取服务器当前提供的所有工具列表。 -
安全和权限: 虽然 MCP 协议本身不直接处理身份验证和授权,但它设计用于与底层安全机制(例如,TLS 加密、OAuth2 等)结合使用,以确保安全通信和访问控制。MCP 通常在应用层提供能力级别的权限管理。
MCP 工作原理(基于 JSON-RPC):
MCP 在 JSON-RPC 的基本结构上,增加了特定的 method 名称和 params 约定。
以 tools/execute 为例:
假设 AI 模型需要执行一个名为 Google Search 的工具来搜索信息。
-
AI 模型决定执行工具: AI 模型(在 Host 中运行)通过推理决定需要调用
Google Search工具。 -
Host 构造 JSON-RPC 请求: Host 内部的 MCP Client 会构造一个 JSON-RPC 请求,其
method字段是tools/execute,params中包含要执行的工具名称和其参数。JSON
{ "jsonrpc": "2.0", "method": "tools/execute", "params": { "tool_id": "Google Search", // 要执行的工具ID "parameters": { "query": "MCP protocol details" // 工具的参数 } }, "id": "req-123" } -
客户端发送请求: 这个 JSON-RPC 请求通过网络(例如 WebSocket)发送到连接的 MCP Server。
-
服务器解析并执行: MCP Server 接收到请求,解析它,识别出
tools/execute方法和Google Search工具。然后,Server 调用其内部的Google Search逻辑,执行搜索操作。 -
服务器返回 JSON-RPC 响应: 搜索完成后,Server 将结果或任何错误信息打包成一个 JSON-RPC 响应。
JSON
{ "jsonrpc": "2.0", "result": { "output": "搜索结果:Model Context Protocol (MCP) is an open standard..." // 搜索结果 }, "id": "req-123" } -
客户端接收并处理: Host 内部的 MCP Client 接收到响应,提取
result字段中的内容,并将其提供给 AI 模型进行后续处理或向用户展示。
MCP 和 JSON-RPC 的关系总结:
- JSON-RPC 是底层协议: MCP 使用 JSON-RPC 作为其基础通信协议。这意味着 MCP 消息的格式遵循 JSON-RPC 的规范(例如,包含
jsonrpc、method、params、id等字段)。 - MCP 提供了语义层: MCP 在 JSON-RPC 的通用框架之上,定义了特定于 AI 交互的“方法”和“参数”约定。它为
method字段的值规定了特定的含义(如tools/execute、resources/read),并定义了这些方法对应的params结构。 - MCP 是 JSON-RPC 的应用: 可以把 MCP 理解为一种特定领域的 JSON-RPC "应用协议",就像 HTTP 也是一种基于 TCP 的应用协议一样。
通过这种方式,MCP 能够利用 JSON-RPC 的简洁性和通用性,同时为 AI 模型与外部世界的复杂交互提供了一个高度结构化和可扩展的框架。
A2A (Agent-to-Agent Protocol) 和 MCP (Model Context Protocol) 都是为了解决 AI 代理 (AI Agents) 在现实世界中面临的互操作性挑战而设计的开放标准协议。然而,它们的目标和侧重点是互补而非竞争的。
简单来说:
- MCP (Model Context Protocol): 专注于AI 应用程序/模型如何与外部工具和数据源进行交互。可以把 MCP 看作是 AI 模型的“USB-C 端口”,允许它标准化地连接到各种外设(工具、数据库、API、文件系统等)。
- A2A (Agent-to-Agent Protocol): 专注于不同的 AI 代理之间如何进行通信和协作。A2A 就像一个“网络线”,让一个 AI 代理可以与其他 AI 代理进行对话、委托任务和协调行动,无论这些代理是由谁构建的、运行在哪里。
以下是它们的详细区别:
MCP (Model Context Protocol)
-
开发者: 主要由 Anthropic (Claude 的开发者) 提出并推广。
-
核心目标: 将 AI 模型(特别是 LLM)连接到外部的、结构化的数据和工具。它解决了 AI 模型获取实时、特定上下文信息和执行外部操作的挑战。
-
角色分工:
- Host (宿主): 用户直接交互的 AI 应用 (e.g., Claude Desktop, AI-powered IDEs)。它包含 LLM 和 MCP Client。
- Client (客户端): 存在于 Host 内部,负责与特定的 MCP Server 进行一对一通信,处理协议细节,并协调请求/响应。
- Server (服务器): 提供对外部能力(Tools, Resources, Prompts)的访问。例如,一个 MCP Server 可以提供访问 Google Drive、GitHub API 或本地文件系统的工具。
-
通信机制: 通常基于 JSON-RPC 2.0,通过持久连接 (如 WebSockets)。
-
主要功能:
- 工具执行 (Tools): 允许 AI 模型调用外部函数或 API (e.g.,
tools/execute用于执行搜索、发送邮件等)。 - 资源访问 (Resources): 允许 AI 模型读取或写入外部数据 (e.g.,
resources/read用于读取文件内容,resources/list用于列出文件)。 - 提示管理 (Prompts): 允许 AI 模型应用预定义的提示模板或工作流。
- 上下文感知: 强调在交互中维护上下文,使 AI 模型能够进行有状态的对话和操作。
- 工具执行 (Tools): 允许 AI 模型调用外部函数或 API (e.g.,
-
用例:
- 让一个 AI 聊天机器人能够读取和总结用户的本地文档。
- 让一个 AI 编程助手能够访问和修改代码库。
- 让一个 AI 助手能够查询数据库或调用企业内部 API。
A2A (Agent-to-Agent Protocol)
-
开发者: 由 Google 主导并与50多个行业伙伴共同开发。
-
核心目标: 实现 AI 代理之间的互操作性、协作和任务委托。它旨在构建一个多代理生态系统,让不同的专业 AI 代理可以协同工作来完成复杂任务。
-
角色分工: A2A 通常也采用客户端-服务器模型,但这里的“客户端”和“服务器”都是 AI 代理。一个代理可以作为客户端发起请求,另一个代理作为远程代理(服务器)来响应和执行任务。
- Client Agent (客户端代理): 发起任务或请求的代理。
- Remote Agent (远程代理): 接收请求并执行任务的代理。
-
通信机制: 也基于 JSON-RPC 2.0,通常通过 HTTP(S) 作为传输层,并支持 Server-Sent Events (SSE) 进行流式更新。
-
主要功能:
- 代理发现: 代理可以发布“代理卡 (Agent Card)”,描述自身的能力、技能和 API 端点,以便其他代理发现并选择合适的协作对象。
- 任务委派: 代理可以将任务(可以是复杂的、多步骤的)委派给其他更专业的代理。
- 多模态通信: 支持文本、图像、音频、视频等多种形式的信息交换。
- 长运行任务: 设计用于处理长时间运行的任务,包括需要人工干预或分阶段完成的流程。
- 协作与协调: 允许代理之间进行有意义的对话和信息交换,以共同完成目标。
-
用例:
- 一个“项目管理代理”将“生成报告”的任务委派给一个“报告生成代理”。
- 一个“日程管理代理”与一个“差旅预订代理”协作,根据用户的日程安排预订航班和酒店。
- 不同公司或团队的 AI 代理通过 A2A 协议进行业务流程的自动化协作。
核心区别总结
| 特性 | MCP (Model Context Protocol) | A2A (Agent-to-Agent Protocol) |
|---|---|---|
| 主要关注点 | AI 模型 (LLM) 如何访问外部工具和数据 | AI 代理之间如何通信和协作 |
| 交互对象 | AI 应用 / 模型 ↔ 外部工具 / 数据源 | AI 代理 ↔ AI 代理 |
| 比喻 | AI 的“USB-C 端口” (连接到外设) | AI 之间的“网络线” (连接不同计算机) |
| 能力类型 | 工具 (Tools), 资源 (Resources), 提示 (Prompts) | 任务 (Tasks), 消息 (Messages), 能力发现 |
| 谁是发起者 | 用户与 Host (AI 应用) 交互,Host 的 LLM 决定调用外部能力 | 一个 AI 代理 (Client Agent) 发起与另一个 AI 代理 (Remote Agent) 的协作 |
| 上下文 | 维护 AI 模型与外部系统交互的上下文 | 维护代理之间对话和任务执行的上下文 |
| 主要目标 | 统一 AI 与外部世界的集成,提供上下文感知的数据和工具访问 | 实现 AI 代理的跨平台、跨框架互操作,促进多代理协作 |
| 底层协议 | JSON-RPC 2.0 (通常通过 WebSockets) | JSON-RPC 2.0 (通常通过 HTTP(S) 和 SSE) |
它们如何协同工作?
A2A 和 MCP 并非相互排斥,而是可以协同工作,共同构建更强大的 AI 系统:
- 一个通过 A2A 协议协作的项目管理代理,可能需要通过 MCP 协议来访问其内部的文档管理工具,以获取项目文档或更新状态。
- 一个专门负责数据分析的 A2A 代理,在接收到其他代理委派的数据分析任务后,可能会利用 MCP 协议连接到数据库或数据分析工具来执行实际的数据处理。
简而言之,MCP 赋予 AI 代理使用工具和数据的能力,而 A2A 则让这些拥有能力的 AI 代理能够相互交流和组队,共同解决更复杂的任务。 它们一起为下一代自动化和智能代理系统奠定了开放标准的基础。