A2A 协议 2026 落地实录：当 Agent 开始互相「打电话」
MCP 解决了 Agent 用工具的问题，A2A 解决的是 Agent 之间协作的问题。本文讲清 A2A 与 MCP 的分工、协议核心机制、真实落地场景，以及现在上手是否过早。
2025 年，MCP（Model Context Protocol）让 Agent 学会了”用工具”；2026 年，另一个协议开始进入工程视野——A2A（Agent2Agent），它要解决的是”Agent 之间怎么协作”。
如果你已经被 MCP 绕晕，先记住一句话：MCP 是垂直的（Agent 向下调用工具），A2A 是水平的（Agent 之间互相调用）。
为什么需要 A2A
现实中的任务很少由单个 Agent 完成。一个”帮公司做季度财报”的任务，可能需要：
- 一个财务 Agent 负责拉数据
- 一个分析 Agent 负责算指标
- 一个设计 Agent 负责做图表
- 一个写作 Agent 负责写解读
这四个 Agent 可能来自不同厂商、部署在不同服务器、用不同框架。过去它们只能靠”人肉拼接 API”，A2A 的目标是让它们像微服务一样自动发现、互相通信。
A2A 的三个核心概念
Agent Card（代理名片）。 每个 Agent 在自己的域名下暴露一个 /.well-known/agent.json，声明”我是谁、我能干什么、我的接口在哪”。这让 Agent 可被发现——类似服务注册中心。
Task（任务对象）。 A2A 里的交互不是”一次请求一个响应”，而是”一个任务对象”，有状态（submitted / working / completed / failed）。这让长任务、需要多轮协商的协作成为可能。
Artifact（产物）。 任务产出的结果（文本、文件、结构化数据）被标准化封装，调用方可以直接消费。
A2A 和 MCP 的分工
这是最容易混淆的点。用一张表说清：
| MCP | A2A | |
|---|---|---|
| 连接对象 | Agent ↔ 工具/数据源 | Agent ↔ Agent |
| 关系 | 主从（调用方/被调用方） | 对等（协作方） |
| 传输内容 | 工具调用与结果 | 任务与产物 |
| 典型场景 | 让 Agent 查数据库、发邮件 | 让 Agent 委派子任务给另一个 Agent |
它们不冲突，而是叠加。 一个成熟的系统里，每个 Agent 内部用 MCP 调工具，Agent 之间用 A2A 协作。
真实落地场景
企业内部多团队协作。 大公司的 HR、财务、IT 各有一套 AI 助手，A2A 让”查一下小王这个月的报销和考勤”这种跨系统问题可以被自动路由。这是目前最主要的驱动力。
跨厂商 Agent 市场。 一些平台开始提供”即插即用”的第三方 Agent，通过 A2A 接入。你买一个”合同审查 Agent”，只要它符合 A2A，就能接进你的工作流。
个人助理的”外脑”。 你的主助理 Agent 可以把”订机票”这个任务整体委派给一个专业旅行 Agent，而不用自己实现所有逻辑。
现在上手是否过早
我的判断是：半早。 理由有三：
- 协议仍在演进，2026 年的 A2A 规范和 2025 年相比已有较大变化，核心 SDK 还在快速迭代；
- 生态尚未成熟，可发现、可即插即用的第三方 Agent 还很有限；
- 但概念必须现在就懂，因为架构设计一旦定型就很难改。
务实建议： 先在内部用 A2A 的思路组织你的多 Agent 系统（即便你用的是自家私有协议），把”任务对象化""Agent 名片刻意设计好”。等到外部生态成熟时，迁移成本会低很多。
结语
MCP 让 Agent 从”会说”变成”会做”，A2A 让 Agent 从”单打独斗”变成”团队协作”。如果说 2025 年是工具协议年，2026 年很可能是协作协议年。不要等到所有大厂都用上了才动手，理解协议的思维方式，比等一个完美标准更重要。