MCP 与 A2A 协议

MCP 规范（本节以 2025-06-18 版为准）说，MCP 用 JSON-RPC 2.0 消息在三方之间通信：

两个要点：

• 一个客户端只对应一个服务器（1:1）。宿主想接 3 个服务器，就建 3 个客户端。
• 架构文档的设计原则写着：服务器不能读到整段对话，也不能「看进」别的服务器。宿主掌握全局，负责安全边界。这和第 27 讲（压缩与隔离）的「隔离」是一个思路。

MCP 参考了 LSP（语言服务器协议）。LSP 让一个编辑器支持所有编程语言，MCP 想让一个 AI 应用接上所有工具。

传输方式有两种：本地进程用 stdio（标准输入输出），远程用 Streamable HTTP。

服务器可以向客户端提供三类东西。规范用「谁来控制」区分它们：

可以这样记：

• Prompts 是用户点菜，例如输入 /总结周报；
• Resources 是服务员把资料放到桌上，由应用决定附加哪些文件；
• Tools 是厨师自己决定用哪把刀，由模型决定何时调用。

反方向，客户端也可以向服务器提供三种能力：

• Sampling（采样）：服务器请客户端代它调用一次大模型；
• Roots（根）：服务器询问自己可以操作哪些目录或 URI 范围；
• Elicitation（征询）：服务器请求向用户追问更多信息。

演示：一次工具调用的消息往来

下面是简化后的 JSON-RPC 消息。方法名 tools/list 和 tools/call 来自规范，具体工具是编的示例。

第 1 步：握手。 客户端发 initialize，双方交换版本号和各自支持的能力，比如服务器声明「我有 tools」。

第 2 步：问有哪些工具。

{"jsonrpc": "2.0", "id": 1, "method": "tools/list"}

服务器回复工具清单，每个工具有名字、描述和输入 schema（第 29 讲（工具调用 / Function Calling）讲过的那种）：

{"jsonrpc": "2.0", "id": 1, "result": {"tools": [
  {"name": "get_weather", "description": "查询城市天气",
   "inputSchema": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}
]}}

第 3 步：模型决定调用。 宿主把工具清单交给模型。模型输出一个工具调用，客户端转成：

{"jsonrpc": "2.0", "id": 2, "method": "tools/call",
 "params": {"name": "get_weather", "arguments": {"city": "上海"}}}

第 4 步：服务器返回结果。

{"jsonrpc": "2.0", "id": 2, "result": {"content": [{"type": "text", "text": "上海：多云，18°C"}], "isError": false}}

第 5 步： 宿主把结果放回模型的上下文，模型继续回答。

和第 29 讲（工具调用 / Function Calling）对比：工具循环本身没变，变的是工具从哪来。以前写死在应用代码里，现在可以运行时从任何 MCP 服务器发现。

安全原则（规范中的要点）

规范专门有一节「安全与信任」，核心是用户知情和同意：

• 宿主把用户数据交给服务器之前，必须获得用户明确同意；
• 宿主调用任何工具之前，必须获得用户明确同意；
• 工具的描述应当视为不可信，除非服务器本身可信；
• 规范建议，应该始终有人在回路里，能够拒绝工具调用；
• 采样请求要由用户批准，协议有意限制服务器能看到的提示内容。

「工具描述不可信」很关键：恶意的 MCP 服务器可以在工具描述里藏指令，这正是第 39 讲（提示注入）要讲的提示注入。

MCP 解决「Agent 用工具」。如果要把任务交给另一家公司的 Agent呢？对方是一个完整的智能系统，不是一个函数。A2A 规范称这类 Agent 为「不透明的」：协作只靠声明的能力和交换的信息，不需要共享内部的思考、计划或工具实现。

A2A 复用现成的标准：HTTP、JSON-RPC 2.0、Server-Sent Events（流式传输）。

核心概念

怎么找到对方？ 常见方式是访问约定地址 https://{对方域名}/.well-known/agent-card.json 读取 Agent Card。

演示：一张 Agent Card 和一次任务（示意）

一家差旅公司的 Agent Card（字段经过简化）：

{
  "name": "差旅预订助手",
  "description": "预订机票和酒店",
  "version": "1.0.0",
  "skills": [{"id": "book-flight", "name": "订机票", "description": "按日期和城市查询并预订航班"}],
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["text/plain", "application/json"]
}

我方的行政 Agent 读到名片，发消息：「帮我订 11 月 5 日上海到北京的早班机。」

1. 对方创建任务，状态是已提交（submitted），随后进入处理中（working）。
2. 对方发现缺信息，状态变为需要输入（input-required），并发消息问：「乘客姓名和身份证号？」
3. 我方补充信息，任务回到处理中。
4. 订好后，对方给出 Artifact（行程单），状态变为已完成（completed）。

任务状态（规范定义，简化）：

• 进行中：已提交、处理中；
• 中断（等外部动作）：需要输入、需要认证；
• 终止：已完成、失败、已取消、已拒绝。

为什么要有状态？A2A 规范把「异步优先」列为设计原则，任务可能跑很久，中间还需要人参与。所以除了同步请求，还支持流式更新和通知（任务有进展时调用客户端提供的 webhook）。

A2A 规范附录专门写了两者的关系：互补，不是竞争。

规范给的例子：客户端 Agent 通过 A2A 把复杂任务交给服务端 Agent；服务端 Agent 内部再用 MCP 调用多个工具和数据源来完成这个任务。

演示：用这张表做判断

• 「让我们的客服 Agent 能查订单系统」：订单系统是数据和 API，用 MCP。
• 「让我们的客服 Agent 把退款争议转给支付公司的风控 Agent」：对方是独立的智能系统，任务可能要几小时、中途还要补材料，用 A2A。

• Model Context Protocol Specification（2025-06-18）：modelcontextprotocol.io
• 同版本子页面
• A2A Protocol Specification：a2a-protocol.org