A2A 是 agent 之间的互操作协议，让调用方可以像找服务一样去发现并调用另一个 agent。
先用一句话理解 A2A
如果 MCP 更像“让模型或应用接上工具和上下文”，那么 A2A 更像“让一个 agent 去雇另一个 agent 完成一段工作”。 这时调用方不再只是在调某个原子工具，而是在把一个目标交给一个拥有自主执行能力的远端 agent。
例如，一个主控 agent 负责接收用户目标，它发现某个远端 agent 擅长检索企业知识库， 另一个远端 agent 擅长生成报价文档，那么主控 agent 就可以按协议分别把任务分派出去， 再把多个远端 agent 的结果合并回来。
核心边界很重要：A2A 暴露的是“我能做什么、我怎么接任务、我怎样回传结果”，而不是“我内部每一步如何实现”。
A2A 的典型架构
下图展示了一个比较典型的 A2A 协作面：左侧是业务应用或主控 agent，中间是协议层与远端 agent， 右侧是远端 agent 私有持有的模型、工具和企业系统。主链路是发现能力、创建任务、远端执行、回传状态与产物。
A2A 的几个关键组成
相当于一个 agent 的公开名片。它告诉外部：我是谁、我有哪些能力、接受什么输入、支持哪些交互方式。
Task 表示一次协作任务，Message 表示任务里的沟通内容。调用方通常围绕 Task 生命周期和 Message 往返来推进协作。
Artifact 是远端 agent 最终或中间交付出来的产物，比如文本、结构化数据、文件引用，或者阶段性结果。
这些对象组合起来后，A2A 的交互就不只是“请求一次，返回一次”。 它更接近一种带状态的协作会话：调用方提交目标，远端 agent 不断更新状态、发送中间产物， 最后在完成时给出可消费的结果。
一次 A2A 协作通常怎么发生
- 调用方先找到可合作的 agent，并读取它的 Agent Card，确认它是否具备所需能力。
- 调用方创建 Task，把目标、上下文或用户请求包装成 Message 发给远端 agent。
- 远端 agent 根据自己的内部策略去规划任务，调用模型、工具链或企业系统。
- 执行过程中，远端 agent 可以流式回传状态变化、中间结果或通知，而不是等到最后一次性返回。
- 任务结束后，调用方拿到 Artifact 或完成信号，再决定是否继续把结果交给下一个 agent。
这一点使 A2A 很适合多 agent 编排场景，因为主控方不必知道每个远端 agent 的实现细节， 只需要依赖它对外承诺的协作接口。
A2A 和 MCP 有什么区别
| 对比项 | A2A | MCP |
|---|---|---|
| 主要连接对象 | agent 到 agent | 模型或应用到工具、资源、提示上下文 |
| 抽象层级 | 更高，面向“一个能自主执行任务的远端协作者” | 更底层，面向“一个可被调用的工具或上下文接口” |
| 典型交互 | 发现能力、创建任务、跟踪状态、接收产物 | 列出工具、读取资源、执行单次工具调用 |
| 实现透明度 | 远端 agent 内部实现通常保持私有 | 工具输入输出通常更直接、边界更明确 |
| 适合场景 | 多 agent 协作、跨团队能力编排、把复杂能力封装成服务 | 给单个 agent 或应用接工具、数据源、工作流入口 |
简单记法：MCP 像把工具接给 agent，A2A 像把一个 agent 接给另一个 agent。
什么场景适合用 A2A
当你的系统里开始出现“专业分工明确的 agent”时，A2A 的价值就出来了。 比如销售 agent 负责商机判断，知识检索 agent 负责查内部资料，文档生成 agent 负责产出正式文件。 这时让一个主控 agent 去直接持有所有工具，往往会越来越重；而把能力拆成多个 agent， 再用 A2A 协议协作，会更符合长期维护。
一句话总结
A2A 的本质，不是“再造一个工具调用协议”，而是把 agent 作为可被发现、可被委托、可持续回传状态的协作者 来对待。 当系统不再只有一个大而全的 agent，而是有多个专业 agent 需要互相合作时，A2A 就会成为非常自然的基础协议层。