MCP josn-rpc A2A

69 阅读17分钟

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 工作流程示例

  1. 用户输入:  用户在 Host 应用程序(例如 Claude Desktop)中输入一个请求,例如“更新我的日程表,将明天的会议提前一小时”。
  2. Host 处理:  Host 内部的 LLM 会分析这个请求,并识别出需要调用外部工具来修改日程表。
  3. Host -> Client:  Host 决定需要哪个 MCP Server 的能力(例如,一个与日历服务集成的 MCP Server),然后指示其对应的 Client 准备发送请求。
  4. Client -> Server:  Client 将请求格式化为 MCP 消息(例如,一个 tools/execute 请求,包含会议ID和新的时间参数),并通过 MCP 协议发送给日历 MCP Server。
  5. Server 执行:  日历 MCP Server 接收请求,调用底层的日历 API,将会议时间提前一小时。
  6. Server -> Client:  Server 将操作结果(例如,成功更新的确认)通过 MCP 协议返回给 Client。
  7. Client -> Host:  Client 收到响应,将其传递回 Host。
  8. Host 呈现:  Host 接收到结果,并将其呈现给用户,例如显示“您的会议已成功更新”。

总结

MCP 通过引入 Host、Client 和 Server 的分层架构,实现了 AI 应用程序与外部世界的模块化、标准化和上下文感知的交互。Host 负责用户界面和 LLM 的核心推理,Client 负责协议细节和与特定 Server 的连接,而 Server 则暴露具体的外部能力。这种设计极大地简化了 AI 应用的集成复杂性,并促进了更强大、更灵活的 AI 系统的构建。

JSON-RPC 的原理

JSON-RPC 是一种轻量级的远程过程调用 (RPC) 协议,它使用 JSON (JavaScript Object Notation) 格式来编码数据。它的核心思想是允许客户端程序调用位于不同地址空间(通常是网络上的另一台计算机)中的过程或函数,就好像它们是本地过程一样。

核心原理:

  1. 请求/响应模型:  JSON-RPC 遵循经典的请求/响应模型。客户端发送一个请求给服务器,服务器处理请求并返回一个响应。
  2. JSON 作为数据格式:  所有消息(请求和响应)都使用 JSON 格式进行编码。这使得协议非常易于解析和生成,并且与各种编程语言兼容。
  3. 方法调用:  客户端通过发送一个包含要调用的方法名称和参数的 JSON 对象来发起请求。
  4. 无状态:  协议本身是无状态的,这意味着每次请求都包含足够的信息来完成操作,服务器不需要记住之前的请求状态(尽管底层服务可以是有状态的)。
  5. 跨平台/语言:  由于使用 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。

工作流程概览:

  1. 客户端准备请求:  客户端程序将要调用的方法名和参数打包成一个 JSON-RPC 请求对象。
  2. 发送请求:  客户端通过网络(通常是 TCP/IP,可以使用 HTTP 或 WebSockets 作为传输层)将 JSON-RPC 请求发送到服务器。
  3. 服务器解析请求:  服务器接收到请求后,解析 JSON 字符串,提取方法名和参数。
  4. 执行方法:  服务器调用其内部对应的方法,并传入解析出的参数。
  5. 准备响应:  方法执行完成后,服务器将结果或错误信息打包成一个 JSON-RPC 响应对象。
  6. 发送响应:  服务器将 JSON-RPC 响应发送回客户端。
  7. 客户端解析响应:  客户端接收到响应,解析 JSON 字符串,获取结果或错误信息。

优点:

  • 简单性:  协议结构非常简单,易于理解和实现。
  • 易于解析:  JSON 格式使得数据解析变得轻而易举。
  • 语言无关:  可以在任何支持 JSON 的语言中使用。
  • 低开销:  相对于 SOAP 等其他 RPC 协议,JSON-RPC 的开销较低。

MCP (Model Context Protocol) 的原理

MCP 的核心原理是在 JSON-RPC 的基础上,为 AI 模型与外部世界(工具、数据、服务)的交互定义了一套标准化、有上下文的通信协议。它不是替代 JSON-RPC,而是在 JSON-RPC 之上构建了一层语义和约定

MCP 的主要创新点在于:

  1. 定义了标准化的“能力”(Capabilities):  MCP 规定了 AI 模型可以请求的外部能力类型,主要包括:

    • Tools (工具):  可执行的操作,例如:tools/execute (执行某个工具)、tools/list (列出可用的工具)。
    • Resources (资源):  可读的数据源,例如:resources/read (读取资源内容)、resources/list (列出可用资源)。
    • Prompts (提示):  预定义的提示模板或工作流,例如:prompts/apply (应用某个提示)。 这些能力在 MCP 中都有明确定义的方法名和参数结构,允许 AI 模型以统一的方式调用它们。
  2. 上下文管理:  传统的 RPC 往往是无状态的。但 AI 模型与外部世界的交互通常需要上下文。MCP 通过以下机制支持上下文:

    • 持久连接:  通常使用 WebSocket 或其他持久连接来保持客户端和服务器之间的连接,允许连续的、有上下文的对话。
    • 有状态交互:  MCP Server 可以维护与特定 Client 相关的状态信息,例如已打开的文件句柄、会话变量等。
    • 请求 ID 和通知:  虽然继承自 JSON-RPC,但其 id 字段对于匹配连续的、有上下文的请求和响应至关重要。
  3. 能力发现机制:  MCP 允许客户端(Host 内部的 MCP Client)查询服务器以发现其支持的所有工具、资源和提示。这使得 AI 模型可以在运行时动态地了解可用的外部功能,而不需要硬编码。例如,客户端可以发送一个 tools/list 请求来获取服务器当前提供的所有工具列表。

  4. 安全和权限:  虽然 MCP 协议本身不直接处理身份验证和授权,但它设计用于与底层安全机制(例如,TLS 加密、OAuth2 等)结合使用,以确保安全通信和访问控制。MCP 通常在应用层提供能力级别的权限管理。

MCP 工作原理(基于 JSON-RPC):

MCP 在 JSON-RPC 的基本结构上,增加了特定的 method 名称和 params 约定。

以 tools/execute 为例:

假设 AI 模型需要执行一个名为 Google Search 的工具来搜索信息。

  1. AI 模型决定执行工具:  AI 模型(在 Host 中运行)通过推理决定需要调用 Google Search 工具。

  2. Host 构造 JSON-RPC 请求:  Host 内部的 MCP Client 会构造一个 JSON-RPC 请求,其 method 字段是 tools/executeparams 中包含要执行的工具名称和其参数。

    JSON

    {
      "jsonrpc": "2.0",
      "method": "tools/execute",
      "params": {
        "tool_id": "Google Search", // 要执行的工具ID
        "parameters": {
          "query": "MCP protocol details" // 工具的参数
        }
      },
      "id": "req-123"
    }
    
  3. 客户端发送请求:  这个 JSON-RPC 请求通过网络(例如 WebSocket)发送到连接的 MCP Server。

  4. 服务器解析并执行:  MCP Server 接收到请求,解析它,识别出 tools/execute 方法和 Google Search 工具。然后,Server 调用其内部的 Google Search 逻辑,执行搜索操作。

  5. 服务器返回 JSON-RPC 响应:  搜索完成后,Server 将结果或任何错误信息打包成一个 JSON-RPC 响应。

    JSON

    {
      "jsonrpc": "2.0",
      "result": {
        "output": "搜索结果:Model Context Protocol (MCP) is an open standard..." // 搜索结果
      },
      "id": "req-123"
    }
    
  6. 客户端接收并处理:  Host 内部的 MCP Client 接收到响应,提取 result 字段中的内容,并将其提供给 AI 模型进行后续处理或向用户展示。

MCP 和 JSON-RPC 的关系总结:

  • JSON-RPC 是底层协议:  MCP 使用 JSON-RPC 作为其基础通信协议。这意味着 MCP 消息的格式遵循 JSON-RPC 的规范(例如,包含 jsonrpcmethodparamsid 等字段)。
  • MCP 提供了语义层:  MCP 在 JSON-RPC 的通用框架之上,定义了特定于 AI 交互的“方法”和“参数”约定。它为 method 字段的值规定了特定的含义(如 tools/executeresources/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 模型能够进行有状态的对话和操作。
  • 用例:

    • 让一个 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 代理能够相互交流和组队,共同解决更复杂的任务。  它们一起为下一代自动化和智能代理系统奠定了开放标准的基础。