中文译本。原文见同目录 README.md

第 14 课：Agent 协议 —— MCP 与 A2A

引言

你已经能构建 Agent，能给它工具，甚至能搭一支协作的 Agent 团队。但当 Agent 需要使用别人做的工具时呢？或者需要与另一团队、另一公司、用另一框架构建的 Agent 协作时呢？

没有标准，你就会为每一种组合写自定义集成代码。这不可扩展。

本课介绍两个解决该问题的开放协议：Model Context Protocol（MCP） 用于把 Agent 接到工具与数据，以及 Agent-to-Agent Protocol（A2A） 用于让 Agent 跨组织与厂商协作。二者共同构成现代 Agent 生态的通信层。

为什么协议重要

N × M 集成问题

假设有 5 个 Agent 框架和 10 个工具。没有标准协议时，每个框架需要为每个工具写自定义连接器。那就是 5 × 10 = 50 个自定义集成。

再加 5 个工具，你需要再写 25 个集成。再加一个框架，又要 15 个。成本呈乘法增长。

Without a standard protocol:

  Agent A ---custom---> Tool 1
  Agent A ---custom---> Tool 2
  Agent A ---custom---> Tool 3
  Agent B ---custom---> Tool 1
  Agent B ---custom---> Tool 2
  Agent B ---custom---> Tool 3
  ...
  (N agents x M tools = N*M integrations)


With a standard protocol:

  Agent A ---\                  /--> Tool 1
  Agent B -----> [Protocol] ---+--> Tool 2
  Agent C ---/                  \--> Tool 3
  (N + M integrations)

这正是 USB 为硬件解决过的问题。USB 之前，每种设备都有专有接口。打印机要并行口，键盘要 PS/2，相机要串口线。USB 给了大家统一接口，生态随之爆发。

协议对 Agent 做同样的事。

两种通信

Agent 需要以两种本质不同的方式通信：

  1. Agent 到 Tool：「用这些参数调用这个函数，把结果给我。」这是结构化、具体、同步的。由 MCP 处理。

  2. Agent 到 Agent：「我需要在这个目标上获得帮助。想办法完成，做完告诉我。」这是开放式、目标导向、可能异步的。由 A2A 处理。

理解这一区分，是理解为什么需要两个协议而不是一个的关键。

MCP vs A2A Protocol Comparison

Click components to learn more. Use tabs to explore scenarios.

MCP
Model Context Protocol — App to Tool
Tools Resources Prompts
A2A
Agent-to-Agent Protocol — Agent to Agent
Agent Cards Tasks Artifacts
When to use which?
Side-by-Side Comparison
Aspect MCP A2A

Model Context Protocol（MCP）

什么是 MCP

MCP 是连接语言模型与 Agent 到外部工具和数据源的开放标准。最初由 Anthropic 创建，现已在业界广泛采用，为 AI 应用与其需访问的服务提供统一接口。

可以把 MCP 想成 AI 工具的万能适配器。正如 USB 口让你把任意 USB 设备插到任意电脑上，MCP 让任意 Agent 使用任意 MCP 兼容工具，而无需自定义集成代码。

架构：Host、Client、Server

MCP 采用三部分架构：

+------------------+
|      Host        |    (Your AI application - IDE, chatbot, agent)
|  +------------+  |
|  |   Client   |  |    (MCP client - manages connections to servers)
|  +-----+------+  |
+---------|---------+
          |
     MCP Protocol
     (JSON-RPC)
          |
+---------|---------+
|     Server        |    (MCP server - wraps a tool or data source)
|  +------------+   |
|  | Tool/Data  |   |    (The actual capability - database, API, file system)
|  +------------+   |
+-------------------+

Host： 用户交互的应用。可以是 VS Code 这类 IDE、聊天界面，或你的 Agent 应用。Host 包含一个或多个 MCP client。

Client： MCP client 住在 Host 内，管理到 MCP server 的连接。负责协议协商、消息路由与连接生命周期。单个 client 可连接多个 server。

Server： MCP server 封装特定工具或数据源，并通过 MCP 协议暴露。有数据库、文件系统、API、SaaS 产品等各类 server。任何人都可以构建 MCP server。

关键原语

MCP 定义了 server 可暴露的三个核心原语：

原语 是什么 方向 示例
Tools 模型可调用的函数 模型发起，server 执行 search_database(query)、send_email(to, body)
Resources 模型可读的数据 模型请求，server 提供 文件内容、数据库记录、API 响应
Prompts 模板化交互 Server 提供，用户选择 「总结这篇文档」「调试这个错误」

Tools 是最常用的原语。工作方式与第 3 课讲的 function tools 相同，但有一套跨任意 MCP 兼容 Agent 的标准化接口。

Resources 在无需 function call 的情况下为模型提供上下文。可把它们想成模型可引用的只读数据源。

Prompts 是 server 可提供的预制交互模板，帮助用户发现 server 能做什么。

万能适配器类比

没有 MCP 时，把 Agent 接到新数据源大概是：

  1. 阅读该数据源的 API 文档
  2. 写认证代码
  3. 写请求/响应处理
  4. 写错误处理
  5. 为你的特定框架定义 tool schema
  6. 测试集成

有了 MCP，变成：

  1. 安装该数据源的 MCP server
  2. 把 Agent 连上去
  3. 完成

MCP server 处理认证、请求格式、错误处理与 schema 定义。你的 Agent 只需会说 MCP。

MCP 的好处

  • 写一次，处处用。 做成 MCP server 的工具可与任意 MCP 兼容 Agent 一起工作——ADK、Claude、Cursor 或任何其他 Host。

  • 动态工具发现。 Agent 可在运行时发现可用工具，而不是一切硬编码。连上新 MCP server，Agent 自动获得新能力。

  • 生态杠杆。 有数百个社区构建的 MCP server 覆盖常见服务。要接 GitHub？Slack？PostgreSQL？很可能已有现成 MCP server。

  • 关注点分离。 工具构建者专注工具。Agent 构建者专注 Agent。协议处理二者之间的接口。

在 ADK 中使用 MCP tools

ADK 内置支持 MCP。你可以连接任意 MCP server，并像原生 ADK tools 一样使用其工具。

from google.adk.agents import Agent
from google.adk.tools.mcp_tool import MCPToolset, SseConnectionParams

# Connect to an MCP server
mcp_tools = MCPToolset(
    connection_params=SseConnectionParams(
        url="http://localhost:3000/mcp",
    )
)

agent = Agent(
    name="mcp_agent",
    model="gemini-3.5-flash",
    instruction="You are a helpful assistant with access to external tools.",
    tools=[mcp_tools],
)

Agent 在运行时从 MCP server 发现可用工具。若 server 暴露 search_database 与 create_ticket，你的 Agent 无需额外代码即可使用二者。

了解更多： MCP Tools in ADK

局限与安全考量

MCP 很强大，但有你应理解的取舍：

Tool shadowing（工具影子）。 若两个 MCP server 暴露名字或描述相似的工具，模型可能搞不清该调哪个。要有意识地选择连接哪些 server，并检查命名冲突。

Context window bloat（上下文膨胀）。 每个连上的 MCP server 都会把 tool 定义加入上下文窗口。连太多会挤占真实对话空间。每个 tool 定义通常消耗 100–500 tokens。

无原生作用域限制。 MCP 没有内置细粒度权限控制。Agent 若连上数据库 MCP server，理论上可访问该 server 暴露的任何数据。你需要在 server 侧或通过 guardrails 处理授权。

信任与供应链。 社区构建的 MCP server 是你的 Agent 会执行的第三方代码。要以对待任意开源依赖的同样谨慎对待它们。审查代码、检查维护者，并在沙箱环境运行。

延迟。 每次 MCP 工具调用都涉及与 MCP server 的网络通信。对时间敏感的应用，要把这笔开销算进去。

考量 风险 缓解
Tool shadowing 模型调错工具 审计工具名，限制已连接 server
Context bloat 推理质量下降 只连接需要的 server
无作用域限制 数据访问过宽 服务端认证、guardrails
供应链 恶意或有 bug 的 server 代码审查、沙箱
延迟 工具响应慢 本地 server、缓存

Agent-to-Agent Protocol（A2A）

什么是 A2A？

A2A 是最初由 Google 开发、现由 Linux Foundation 治理（2025 年捐赠）的开放协议，用于让 Agent 发现、通信并向其他 Agent 委托任务——即使这些 Agent 由不同团队、用不同框架、在不同组织构建。

MCP 处理「Agent 与工具对话」的问题，A2A 处理「Agent 与 Agent 对话」的问题。

职业网络类比

想想现实世界中专业人士如何协作。需要法律建议时，你不会自己变成律师。你找合格的律师，说明需求，由他们处理。

你如何找到那位律师？

  1. 发现（Discovery）： 查找——可能通过名录、推荐或职业网络
  2. 能力核验： 看资料是否处理你这类案件
  3. 接洽： 描述情况与需求
  4. 委托： 他们离开去工作，并向你发送更新
  5. 交付： 带着结果回来

A2A 对 Agent 以同样方式工作：

  1. 发现： 你的 Agent 通过 Agent Cards 找到其他 Agent
  2. 能力核验： 读卡片看对方能做什么
  3. 接洽： 发送带任务描述的 task
  4. 委托： 远程 Agent 工作，发送状态更新
  5. 交付： 远程 Agent 返回完成结果

关键概念

Agent Cards

Agent Card 就像 Agent 的名片。它是标准化的 JSON 文档，描述 Agent 能做什么、如何通信、需要什么认证。

{
  "name": "Travel Booking Agent",
  "description": "Books flights and hotels based on travel requirements",
  "url": "https://travel-agent.example.com/a2a",
  "capabilities": {
    "streaming": true,
    "pushNotifications": true
  },
  "skills": [
    {
      "id": "book_flight",
      "name": "Book Flight",
      "description": "Search and book flights between cities"
    },
    {
      "id": "book_hotel",
      "name": "Book Hotel",
      "description": "Find and reserve hotel rooms"
    }
  ],
  "authentication": {
    "schemes": ["oauth2"]
  }
}

Agent Cards 托管在 well-known URL（通常是 /.well-known/agent-card.json），发现过程直观。你的 Agent 可检查已知端点，查看另一 Agent 提供什么。

Tasks

Task 是 A2A 中的基本工作单元。一个 Agent 想让另一个 Agent 做事时，会创建 task：

  • Task 创建： 调用方发送描述需完成事项的消息
  • Task 生命周期： Task 经历状态——submitted、working、input-required、completed 或 failed
  • Task 更新： 工作中的 Agent 可发送进度更新，让调用方知道发生了什么
  • Task 完成： 工作中的 Agent 以 artifacts 返回结果

Artifacts

Artifacts 是 task 的输出。可以是文本、文件、结构化数据，或工作 Agent 产出的任何其他内容。

Event queues

A2A 通过 Server-Sent Events（SSE）支持实时通信。这让 Agent 可以流式推送进度更新，而不必等整个 task 完成。对长时任务尤其重要——调用方（或人类）希望看到中间进度。

A2A 与直接 API 调用的对比

你可能想：为什么不直接调另一个 Agent 的 API？可以，但会再次面对前面讨论的 N × M 问题。A2A 给你：

  • 标准化发现 —— 无需知道具体 API 就能找到 Agent
  • 统一的 task 生命周期 —— 每个 Agent 以同样方式处理 task
  • 默认流式 —— 无需自定义 WebSocket 代码即可实时更新
  • 跨框架兼容 —— 你的 ADK Agent 可与 LangChain Agent 协作
  • 认证标准 —— 跨 Agent 一致的安全模型

何时用 A2A vs MCP

这是最重要的区分之一：

方面 MCP A2A
谁与谁对话 Agent 到 tool Agent 到 agent
通信风格 「做这件具体的事」 「达成这个目标」
请求复杂度 单次 function call 开放式任务
对方是否有智能 Tool（无推理） Agent（有推理）
示例 「查询这个数据库」 「研究这个主题并写报告」
类比 使用计算器 聘请顾问

MCP 用于 tools。 你确切知道要调什么函数、传什么参数。工具执行并返回结果。对方没有推理。

A2A 用于 agents。 你描述目标，让对方 Agent 想办法完成。对方有自己的推理、工具与路径。

实务例子： 假设你在构建旅行规划 Agent。

  • 你会用 MCP 连接航班搜索 API（接收出发城、到达城、日期并返回航班的工具）
  • 你会用 A2A 委托给酒店预订 Agent，它能理解「会议场地附近安静的地方」这类偏好，并自己找出最佳选项

了解更多： A2A in ADK 与 A2A Protocol Spec

MCP 与 A2A 如何协作

MCP 与 A2A 不是竞争标准。它们在不同层运作，彼此互补。

+---------------------------------------------+
|              Your Agent                      |
|                                              |
|  "I need to book a trip to Tokyo"            |
|                                              |
|  +-------------------+  +----------------+   |
|  | MCP Client        |  | A2A Client     |   |
|  | (talks to tools)  |  | (talks to      |   |
|  |                   |  |  other agents)  |   |
|  +--------+----------+  +-------+--------+   |
+-----------|-----------------------|----------+
            |                       |
    +-------v--------+     +-------v--------+
    | MCP Servers     |     | Remote Agents  |
    |                 |     |                |
    | - Flight API    |     | - Hotel Agent  |
    | - Weather API   |     | - Budget Agent |
    | - Calendar      |     | - Review Agent |
    +--+---------+----+     +---+--------+---+
       |         |              |        |
       v         v              v        v
    [Flight   [Weather      [Hotel    [Budget
     Data]     Data]        Booking]   Analysis]

分层架构

可以想成层次：

  1. 工具层（MCP）： 你的 Agent 通过 MCP server 连接特定数据源与 API。这给它原始能力——搜索数据库、调 API、读文件。

  2. Agent 层（A2A）： 你的 Agent 与拥有自己工具、推理与专长的其他 Agent 协作。这给它更高层能力——需要判断、规划与多步执行的任务。

  3. 编排层（你的 Agent）： 你的 Agent 根据当前任务，决定何时直接用工具（MCP）、何时委托给另一 Agent（A2A）。

具体场景

用户问你的旅行 Agent：「下个月在 $3000 预算内规划一次东京 3 日游。」

你的 Agent 可能：

  1. MCP 调用： 查用户日历找可用日期（calendar MCP server）
  2. MCP 调用： 获取那些日期的当前机票价格（flight API MCP server）
  3. A2A 委托： 请酒店预订 Agent 找涩谷附近每晚 $200 以下的住宿
  4. A2A 委托： 请本地活动 Agent 建议 3 日行程
  5. MCP 调用： 查那些日期东京的天气预报（weather MCP server）
  6. 推理： 汇总所有结果、对照预算、给出方案

注意模式：MCP 用于具体数据检索，A2A 用于需要另一 Agent 专长与判断的任务。

ELI5：理解 MCP 与 A2A

MCP 像电源适配器

你知道不同国家插座不同吗？从美国到英国，笔记本充电器插不进去。你需要适配器。

MCP 就是 AI Agent 的那种适配器。以前每个工具都有专有插头（自定义 API 集成）。MCP 给大家统一插座。把任意工具插到 MCP，任意 Agent 都能用。

工具本身不会变聪明。电源适配器不会让笔记本更快。但它让笔记本能在以前用不了的地方使用。MCP 也一样——让以前够不到的工具对 Agent 变得可及。

A2A 像同事之间的电话

现在想象你在公司做一个大项目。你负责工程，但需要营销材料。你不会自己学营销。你给市场部同事打电话。

你说：「我们下周二发布新 API。你能准备发布博客和社媒方案吗？」

同事说：「行，我起草后边做边给你更新。」

A2A 就是那通电话。一个 Agent（你）带着目标呼叫另一个 Agent（市场）。对方用自己的技能与工具完成。途中发送更新。完成后交付成品。

你不必知道市场用什么工具。不必理解他们的流程。你只需描述想要什么，并信任他们自己搞定。

为什么两者都需要

回到同事类比：

  • MCP 像你桌上的工具——键盘、显示器、代码编辑器。你直接用。
  • A2A 像你的同事——你把工作委托给他们，他们用自己的工具。

两者都需要。有些事你自己用工具做。有些事你请专家处理。

两个协议的安全考量

MCP 安全

  • Server 认证： 连接前验证 MCP server 身份。所有通信使用 TLS。
  • 最小权限： 只连接 Agent 真正需要的 MCP server。每多一个 server 就扩大攻击面。
  • 输入校验： MCP server 应校验收到的所有参数。不要假定模型总会发送格式良好的输入。
  • 审计日志： 记录所有 MCP 工具调用，便于调试与安全审查。

A2A 安全

  • Agent 核验： 委托任务前，通过 Agent Card 与认证方案验证远程 Agent 身份。
  • 数据最小化： 只共享远程 Agent 完成任务所需的信息。不要发送全部上下文。
  • 结果校验： 对远程 Agent 的结果保持适当怀疑。关键输出在行动前先验证。
  • 访问控制： 定义哪些 Agent 可访问你的 Agent 的哪些能力。

纵深防御

两个协议都受益于分层安全：

  1. 传输安全： 处处 TLS
  2. 认证： 双方验证身份
  3. 授权： 限制每个连接能做什么
  4. 监控： 留意异常模式
  5. Guardrails： 在每个边界校验输入与输出

生态现状

MCP 生态

MCP 自推出以来采用迅速。生态包括：

  • 数百个 MCP server 覆盖常见服务（数据库、云平台、SaaS、开发工具）
  • 主流 AI 平台支持，包括 Claude、ADK、VS Code 等
  • 不断增长的社区 构建与维护 server

A2A 生态

A2A 更新，生态仍在发展：

  • ADK 支持 创建 A2A 兼容 Agent，以及连接远程 A2A Agent
  • 参考实现 展示常见模式
  • 构建多 Agent 系统的组织兴趣上升

可以期待什么

两个协议都在积极演进。预计会看到：

  • 更多面向企业工具与服务的 MCP server
  • 更多 Agent 框架采用 A2A 支持
  • 更好的发现、测试与监控协议连接的工具
  • 安全模式与最佳实践的标准化

实务提示

开始使用 MCP 时

  1. 从官方 server 起步。 在尝试社区版之前，先用可信来源、维护良好的 MCP server。
  2. 先本地测试。 开发期间先本地跑 MCP server，再指向远程。
  3. 监控 token 用量。 每个连上的 MCP server 都会把 tool 定义加入上下文。跟踪工具占用了多少上下文空间。
  4. 锁定 server 版本。 MCP server 是软件依赖。锁定版本以免意外。

开始使用 A2A 时

  1. 从你控制的 Agent 起步。 自己建两个 Agent，练习 A2A 通信，再连外部 Agent。
  2. 定义清晰契约。 明确期望远程 Agent 处理哪些任务、产出什么输出。
  3. 优雅处理失败。 远程 Agent 可能慢、不可用或返回意外结果。构建重试与回退逻辑。
  4. 记录一切。 多 Agent 通信很难调试。详细日志必不可少。

关键要点

  1. 协议解决 N × M 集成问题。 没有标准时，每种 agent-tool 与 agent-agent 组合都需要自定义代码。MCP 与 A2A 用统一接口取而代之。

  2. MCP 把 Agent 接到工具。 它是让任意 Agent 使用任意 MCP 兼容工具的万能适配器。可想成 AI 版 USB。

  3. A2A 把 Agent 接到 Agent。 它让 Agent 跨组织与框架发现、通信并委托任务。

  4. MCP 与 A2A 互补。 MCP 在工具层运作（具体 function call）。A2A 在 Agent 层运作（目标导向任务）。一起用可获最大灵活度。

  5. 两层都需要关注安全。 验证身份、最小化数据共享、校验结果、记录一切。

去哪里深入学习

接下来做什么？

你已覆盖基础与核心构建块。接下来进入第 3 部分——特定主题的深潜。我们从 AGENTS.md 开始：给 AI 编程 Agent 提供项目所需上下文的标准配置文件。

下一课：AGENTS.md ->