「Agent Tool」什么是 A2A 协议？它和 MCP 协议的区别是什么？

0 前言

本文内容整理自公众号「小林面试笔记」的文章 12. 什么是 A2A 协议？它和 MCP 协议的区别是什么？，用于记录与总结 AI Agent 工具调用相关的核心面试知识点。

「什么是 A2A 协议？它和 MCP 协议的区别是什么？」，可以这样作答：

A2A（Agent-to-Agent）是 Google 发布的开放协议，解决的是「多个 AI Agent 之间怎么互相通信协作」的问题——一个 Agent 把子任务委托给另一个专业 Agent，接收方按自己声明的能力承接，支持异步长任务和流式返回结果。

和 MCP 的区别一句话：MCP 解决「单个 Agent 怎么连工具和数据」，A2A 解决「多个 Agent 之间怎么分工协作」——MCP 向下连工具、A2A 向外连 Agent，一纵一横、各管一层，两者互补而非竞争，复杂的多 Agent 系统里通常都在用。

为什么需要多个 Agent？单个 Agent 有工具数量、上下文窗口、专业能力三块天花板；把任务拆给专业 Agent 后，调研过程挤在它自己的上下文里、只把结论传回来，调度 Agent 保持轻量——这是多 Agent 协作在上下文层面的核心收益。

如今 Agent 应用已经很少单打独斗：Google 自家的 Agent 开发框架（ADK）就把 A2A 作为多 Agent 协作的默认协议之一——各 Agent 发布自己的 Agent Card、通过 Task 委派与回收任务；而每个 Agent 内部接工具、接数据，走的还是我们前面几篇反复讲的 MCP 标准（第 3 篇讲过 MCP 是什么，第 7 篇讲过 Agent Skill 的能力声明）。这篇把协议层的「一纵一横」讲透。

1 为什么需要 A2A：单个 Agent 的三块天花板

先回答面试官的反问：「单个 Agent 不够用吗？」

一个 Agent 本质上就是「一个 LLM + 一组工具 + 一段上下文窗口」，这三个维度各有天花板：

工具数量限制：不可能给一个 Agent 装 100 个工具——模型处理效率极低，还容易在调用上出混乱；
上下文窗口限制：128K tokens 听起来很多，但搜索的中间产物（搜索结果、草稿、反思记录）很快把它塞满，写到后面已经顾不上前面的内容；
专业能力限制：同一个 Agent 又做代码审查又做市场分析，不如为各自任务专门配置、微调的 Agent 效果好。

单个 Agent 的工具数量、上下文窗口与专业能力三块天花板

举个具体的例子：「帮我做一份 AI 编程工具的竞品分析报告，要有行业趋势、技术对比、商业模式分析、SWOT」——单 Agent 的困境是：搜索结果和草稿把上下文撑满，写到 SWOT 时前面的行业趋势已经被挤出有效注意力；而且市场调研和技术分析需要不同的知识侧重，一个 Agent 很难兼顾。

拆成多个 Agent 后，上下文压力真的变小了吗？关键在于机制：调度 Agent 把「行业趋势分析」委托给市场 Agent，市场 Agent 自己搜几十个网页、写草稿、反复迭代——这些中间过程都发生在它自己的上下文里；任务做完，只把最终结论（几百字的摘要）经 A2A 传回给调度 Agent。调度 Agent 的上下文只多了一份摘要，而不是几十个网页的原文——把「调研过程」的上下文压力隔离在专业 Agent 内部，调度 Agent 保持轻量，这就是多 Agent 协作在上下文层面的核心收益。

单 Agent 包揽 vs 多 Agent 委托：调研中间过程隔离在专业 Agent 上下文内

自然解法也就出来了：调度 Agent 负责任务拆分，市场 Agent 专门做趋势调研，技术 Agent 专门做工具对比——每个 Agent 聚焦自己擅长的部分，整体效果远好于一个 Agent 包揽全局。

2 互相认识：Agent Card 与能力自述

多 Agent 协作的第一个基础问题：Agent A 想把任务委托给 B，它怎么知道 B 能做什么？

最笨的方案：写死配置——在 A 的代码里硬编码「B 可以做竞品分析」。问题是太脆：B 的能力一变，A 就得改代码重新发布，无法维护；
更好的方案：B 主动「发名片」声明自己能做什么，A 需要时来查——这就是 Agent Card 的设计思路。

A2A 规范建议每个 Agent 在约定位置发布一份 JSON 名片（推荐路径 /.well-known/agent-card.json，早期版本叫 agent.json，两个路径社区里都能见到），里面写清楚：

叫什么：Agent 的名称与一段能做什么的描述；
能做哪类任务：Skill 列表（每项描述一类能力，如「竞品分析」「行业趋势分析」，附示例输入）；
支不支持流式返回、支不支持异步回调（push notification——任务完成后能不能主动通知调用方）。

Agent Card：Agent 发布能力名片供协作方发现与调用

Skill 列表是名片里最关键的部分：调度 Agent 拿着任务的描述，和各个 Agent 的 Skill 描述做匹配，决定「这个任务和哪个 Agent 的哪个 Skill 最匹配」——这就是任务路由。

{
  "name": "market-research-agent",
  "description": "负责行业趋势与竞品调研",
  "skills": [
    {"id": "trend-analysis", "name": "行业趋势分析", "description": "搜索并归纳行业动态与趋势"},
    {"id": "competitive-analysis", "name": "竞品分析", "description": "对比竞品功能与商业模式，输出分析报告"}
  ]
}

（以上为简化示意，真实 Agent Card 的字段更多。这里的 Skill 声明和第 7 篇讲过的 Agent Skill 是同一套思想——把能力变成可被外部发现和调用的声明。）

「发名片」带来的可插拔效果很直接：新增一个 Agent，只需要发布自己的 Agent Card，调度 Agent 就能自动发现并利用它，完全不用改调度代码。

新增 Agent 发布名片后即可被调度 Agent 自动发现利用

3 Task：A2A 里的一等公民

认识了之后，怎么干活？A2A 把一次任务协作抽象成 Task——调度 Agent 委托任务，就是在创建一个 Task；接收方执行；完成后把结果作为 artifacts 返回（可以是文本、文件等）。

Task 有完整的生命周期状态机：

刚创建是 submitted（已提交、等待处理）；
开始执行变 working；
结束进入 completed（成功）或 failed（失败）。

A2A Task 生命周期状态机：submitted → working → completed/failed

为什么要把状态设计得这么完整？因为 A2A 专门为长任务设计：「竞品分析」这类任务要跑几分钟（先搜索、再整理、再写报告），不可能让调度 Agent 同步干等。提交 Task 之后，调度 Agent 完全可以去做别的事，再通过两种方式得知结果：

轮询状态：定期查一下 Task 到哪一步了；
push notification：接收方完成时主动回调通知。

从调度 Agent 的视角看，整个过程非常干净：提交 Task → 定期查状态 → completed 后取 artifacts。它全程不知道 B 内部用了什么工具、调了几次 LLM——执行方的内部实现对它完全黑盒，这种不透明恰恰是解耦的意义。

4 架构本质：Agent 的微服务化

如果只能记住一个类比，记住这句：A2A 就是 Agent 世界里的微服务架构。

微服务里，每个服务是独立部署的 HTTP 服务、有自己的 API 文档，服务之间经 HTTP 互相调用，耗时任务交给异步消息队列。A2A 把这套思路几乎原样搬了过来，只是把「服务」换成了「Agent」：

Agent Card ≈ API 文档：告诉别人你能做什么、怎么调用你；
Task 状态机 ≈ 异步消息队列：把任务提交进去就去做别的事，完成后取结果；
/.well-known 下的 Agent Card ≈ 微服务注册中心里的一条记录：让其他 Agent 自动发现你。

A2A 是 Agent 世界的微服务架构：服务换成 Agent，其余复用同一套思路

由此每个 A2A Agent 对外就是一个 HTTP 服务：任何支持 A2A 的系统都能发现它、给它发任务、收结果——不绑定特定 AI 框架，也不依赖特定编程语言。这和 MCP 的思路一脉相承：MCP 让工具成为独立的标准化的服务，A2A 让 Agent 本身成为独立的标准化的服务。

5 A2A 和 MCP：一纵一横，各管一层

最后回到最常被搞混的问题：A2A 和 MCP 到底是什么关系？

看方向就清楚了：

MCP 是 Agent 向下连接工具——数据库、浏览器、代码执行器，Agent 通过 MCP 标准化地调用它们；
A2A 是 Agent 向外连接其他 Agent——分工、委派、回收结果，Agent 通过 A2A 标准化地协作。

MCP 向下连工具、A2A 向外连 Agent 的一纵一横示意

在真实系统里，这两层是叠着用的：一个专业 Agent 内部用 MCP 连工具、用 Function Calling 让 LLM 触发工具调用（机制见第 1 篇）——这是「纵向」连接；多个 Agent 之间用 A2A 通信、委派任务、接收结果——这是「横向」连接。两个协议解决的是完全不同维度的问题，不存在谁替代谁。

MCP 是每个 Agent 的工具箱、A2A 是 Agent 之间的协作流程

打个比方：MCP 像公司里每个员工的「工具箱」，决定这个人能用什么工具干活；A2A 像公司里的「协作流程」，决定不同岗位之间怎么分工、怎么交接任务。工具箱和协作流程是两回事，但一个运转正常的公司缺一不可——复杂的多 Agent 系统里，MCP 负责 Agent↔工具，A2A 负责 Agent↔Agent，两者合在一起，才构成真正复杂的 Agent 系统。

6 面试总结

回答这道题，最大的雷就是把 A2A 当成 MCP 的「竞品」或「替代方案」——说明没搞清楚两者面向的对象完全不同。先避开几个误区：

误区	正解
A2A 是 MCP 的竞品，Google 想替代 MCP	一纵一横各管一层：MCP 是 Agent 连工具和数据（向下），A2A 是 Agent 与 Agent 通信协作（向外），对象都不同，何来竞争
A2A 是另一种连工具的方式（和 MCP 一样）	名字就是 Agent-to-Agent：协作对象是 Agent 而不是工具
多 Agent 只是把活儿分给更多模型去干	核心是上下文隔离：中间过程留在专业 Agent 自己的上下文里，只回传结论，调度 Agent 保持轻量
A2A 和 MCP 二选一	复杂系统两者同时在用：MCP 管 Agent↔工具纵向连接，A2A 管 Agent↔Agent 横向协作，缺一不可

再按这张框架组织答案：

框架	要点
为什么需要 A2A	单 Agent 三块天花板：工具数量、上下文窗口、专业能力；委托把调研中间过程隔离在专业 Agent 内，调度方只收摘要
互相认识	Agent Card：`/.well-known/agent-card.json` 发布能力名片（名称、Skill 列表、流式/异步回调支持）；Skill 描述驱动任务路由；新 Agent 即插即用
任务协作	Task 是一等公民：`submitted` → `working` → `completed`/`failed`，artifacts 取结果；轮询或 push notification 得知完成；执行方内部黑盒
架构本质	Agent 的微服务化：Agent Card≈API 文档、Task 状态机≈异步消息队列、`.well-known`≈注册中心；HTTP 服务、框架语言无关
与 MCP 的关系	一纵一横：MCP 向下连工具、A2A 向外连 Agent；工具箱 vs 协作流程，互补不替代

追问预案：

「为什么需要多个 Agent，单个 Agent 不够用吗？」——工具数量、上下文窗口、专业能力三块天花板；且把调研过程隔离在专业 Agent 上下文里，调度 Agent 保持轻量，是上下文层面的核心收益。
「Agent 之间怎么互相认识？」——Agent Card 名片机制：约定路径发布 JSON 能力声明，Skill 列表用于任务路由，新增 Agent 发布名片即可被自动发现，不用改调度代码。
「Task 状态机解决了什么问题？」——长任务异步化：提交后调度方无需同步等待，通过轮询或 push notification 得知完成；也让执行方内部实现对调度方黑盒，便于解耦。
「A2A 和微服务有什么关系？」——A2A 是微服务思路的 Agent 化：Agent Card≈API 文档、Task 状态机≈异步消息队列、.well-known≈注册中心，Agent 对外是标准 HTTP 服务。
「A2A 和 MCP 会同时用吗？」——会。专业 Agent 内部用 MCP 连工具（纵向），Agent 之间用 A2A 协作（横向），复杂的多 Agent 系统两者缺一不可（MCP 本身的知识点见第 3 篇）。

参考