为什么需要 A2A：集成成本的平方律
设想一个典型场景：理赔智能体已经跑通——它能读保单 PDF、查客户记录、起草回复，演示效果不错。这时财务部门提出一个问题：它能不能把赔付计算委托给另一个团队早已建好的定价智能体？对方用不同框架构建、部署在不同云上、归不同管理者负责。
在这一刻，你停下了写提示词的工作，开始写集成代码。这就是 A2A 协议要解决的「无聊但昂贵」的问题。
在缺乏共享协议之前，Salesforce 生态的智能体无法把子任务委托给 ServiceNow 生态的智能体，Vertex AI 上的智能体也无法与 Bedrock 上的智能体协同——除非有人手工搭桥。每一对智能体组合都是一个独立集成项目，这意味着多智能体系统的成本大致随智能体数量的平方增长，而非线性增长。
A2A 最有意思的设计是刻意的不透明：通过 A2A 暴露的智能体不透露自己的提示词、记忆、模型，甚至不透露它调用了哪些工具。它只发布「我能做什么」，然后接受任务。调用方不需要知道工作如何完成，只需要知道请求了什么、返回了什么。这层边界让定价团队的智能体可以在周五重构，而不会弄坏你周一的理赔流程。
协议时间线：18 个月从发布到治理归一
A2A 的发展节奏在开放协议史上属于偏快的：
| 时间 | 事件 | 要点 |
|---|---|---|
| 2025 年 4 月 9 日 | Google Cloud Next 发布 A2A | 50+ 启动合作伙伴（Salesforce、SAP、ServiceNow、PayPal、Atlassian 等），Apache 2.0 开源 |
| 2025 年 6 月 23 日 | 捐赠给 Linux 基金会 | 在 Open Source Summit North America 宣布，转为厂商中立治理 |
| 2025 年 8 月 | 吸收 IBM ACP | IBM 的 Agent Communication Protocol 并入 A2A，竞争标准走向合并 |
| 2026 年 3 月 12 日 | 规范 v1.0 发布 | 签名 Agent Card（JWS）、三种传输行为一致性等稳定性承诺 |
| 2026 年 4 月 9 日 | 一周年里程碑 | Linux 基金会口径：150+ 参与组织、GitHub 22,000+ stars |
| 2026 年 5 月 | v1.0.1 补丁 | 规范修订 |
| 2026 年 8 月 17 日 | 加入 Agentic AI Foundation（AAIF） | 与 MCP、Block goose、AGENTS.md、Agentgateway、AGNTCY 同属一个厂商中立基金会 |
几个值得注意的信号：其一，IBM 竞争协议 ACP 的并入说明「多标准并存」的消耗战没有走到终局，合并是协议战争的少见结局；其二，2026 年 8 月的 AAIF 归一意味着智能体技术栈的上下两半（agent-to-tool 与 agent-to-agent）首次回答给同一个中立基金会——围绕「哪个协议赢」的辩论以合并而非胜负告终。
三大原语：Agent Card、Task、Message
把炒作成分剥离后，A2A 的机制比想象中小——这是一种称赞。整个协议几乎由三个原语支撑：
Agent Card：智能体的名片
每个 A2A 兼容智能体在约定路径 /.well-known/agent-card.json 发布一份 JSON 元数据文档，声明自己的名称、能力、支持的技能、输入输出格式、认证要求与服务端点。任何 A2A 客户端读取这张卡片来决定是否委托任务——无需中心化注册表。发现是一个 GET 请求，就像交换名片。
Task：有状态的工作单元
Task 是智能体之间交换的结构化工作单元，带有显式生命周期：
submitted → working → (input-required) → completed / failed / canceled这个生命周期模型（部分吸收自 IBM ACP）同时覆盖了快速同步交换与耗时数小时乃至数天的异步长任务。当远程智能体需要调用方补充信息时，任务进入 input-required 状态，而不是无声地卡死——这个细节在生产系统中价值很高。
Message：带类型部件的一轮对话
Message 是任务内部的一轮交互，带 user 或 agent 角色，部件类型涵盖文本、文件与结构化数据，天然支持多模态交换。
三者的协作流可以概括为一句话：发现是一次 GET，委托是一次消息发送，长任务通过 SSE 或 webhook 流式回传进度。执行过程始终不透明——对等方看到的是能力与消息，而不是彼此的内部实现。
1.0 的关键变化：签名 Agent Card 与传输一致性
密码学签名的 Agent Card
v1.0 的招牌变化是 Agent Card 支持基于 JWS（RFC 7515）的密码学签名，配合 JCS（RFC 8785）规范化。这解决的是发现环节的信任问题：客户端拿到卡片时可以验证它确实来自声明的发布方、且未被中间篡改。在智能体互连场景里，伪造能力声明意味着可能把任务委托给恶意方——签名把这类攻击面收窄了。
三种传输，一种行为
规范要求 JSON-RPC 2.0、gRPC 与 HTTP/REST 三种传输在行为上功能一致。这意味着客户端选型是基础设施决策而非功能决策：你的技术栈决定了用哪种传输，而不是协议功能绑架选型。
SDK 矩阵
官方 SDK 已从发布之初的单一 Python 实现扩展到六种语言：Python、JavaScript、Java、Go、C#/.NET 与 Rust（见 a2a-protocol.org），官方示例仓库覆盖客户端、服务端与主流框架集成。
与 MCP 的纵横分层：互补而非竞争
行业对两个协议关系的共识已经收敛为一个几何隐喻：MCP 是纵向层（agent 向下连接工具与数据），A2A 是横向层（agent 向 across 连接对等智能体）。A2A 官网也明确表述两者高度互补、设计上协同工作。
| 维度 | MCP | A2A |
|---|---|---|
| 解决的问题 | 智能体连接工具、API、数据源 | 独立智能体之间发现、委托、协作 |
| 方向 | 纵向：agent → tool | 横向：agent ↔ agent |
| 典型原语 | tools、resources、prompts | Agent Card、Task、Message |
| 信任边界 | 通常在同一系统/信任域内 | 跨团队、跨组织、跨信任域 |
| 2026 年关键演进 | 2026-07-28 规范无状态化（废弃 initialize 握手与 Session-Id） | v1.0（2026-03）签名 Agent Card；8 月与 MCP 同属 AAIF |
MCP 2026 年 3 月路线图的四个优先领域中，有一项明确写着「agent-communication primitives」——目标是与 A2A 协调而非竞争。两个协议先后进入同一基金会后，这种协同有了治理保障。一个典型的生产形态是：每个智能体各自用 MCP 连接自己的工具与数据，然后用 A2A 跨越组织边界相互委托——两个智能体都看不到对方的提示词、记忆或工具。
需要提醒的是，本站此前对 MCP 无状态化修订（2026-07-28 规范：废弃 initialize/Session-Id、显式状态处理、MRTR 双阶段往返等）已有专文解构（见文末相关研究），两篇对照阅读可以看到协议栈两层的演进节奏。
企业落地：供应链协同的真实用例
Google 在 A2A 一周年里程碑时展示了企业级部署案例，其中供应链场景最具代表性：
Tyson Foods 与 Gordon Food Service
两家独立经营的食品企业使用 A2A 智能体共享产品数据、优化供应链协作。它们的智能体通过 Agent Card 发现与任务委托跨组织协同，而不是搭建传统 EDI 式定制集成——按行业经验，后者往往以月计。
网络排障双智能体
另一个被行业媒体引用的示意场景来自网络运维：一个 A2A 智能体负责诊断路由器故障，另一个负责修复交换机故障。当问题横跨两个域时，双方通过 A2A 交换技术数据，无需人工居间翻译，也无需工程师为新组合再写一个连接器。
这两个案例的共同点是：协作发生在组织或信任域边界上。这恰好呼应了后面要谈的采纳判断——A2A 的收益是组织性的，而非纯技术性的。
边界与批评：A2A 明确不做的事
官网专门列出了 A2A 不是什么，这份「负面清单」在评估阶段比功能清单更有用：
- 不是智能体开发框架：LangGraph、CrewAI、ADK 负责构建智能体，A2A 只负责它们之间的通信层
- 不是子智能体或工具调用协议：智能体与自己的子智能体、工具的交互请用框架原语或 MCP
- 不是 MCP 的替代品：两层协议各管一段
- 不是消息应用：它是自主智能体之间的机器对机器协议
除此之外，工程社区对 A2A 还有三点更尖锐的批评，值得在架构评审时摆上桌面：
- 授权框架缺位：A2A 不定义授权框架，也没有中心化 Agent Card 注册表——身份、最小权限、凭证轮换都是集成方自己的工作。签名解决了「卡片真伪」，没有解决「该不该委托」
- 互操作不等于可移植：A2A 兼容的智能体可以跨厂商通信，但仍然可能绑定专有的记忆存储、策略引擎、计费模型或评估服务。用 A2A 保持协作边界开放是合理的，把它当作整体可迁移的证据则不成立
- 采纳时机偏晚：生态采用确实在增长（150+ 组织），但集中在大型平台厂商。对大多数还没把「单个智能体稳定调用工具」做扎实的团队，MCP 与评估体系的优先级高于 A2A
给工程团队的采纳建议
综合官方规范与多方工程实践，一个务实的判断是：A2A 的触发条件是组织性的，不是技术性的——当两个分属不同信任域的智能体（比如你的部署智能体与数据团队的迁移审批智能体）需要协作的那一天，A2A 才开始产生回报。在此之前，单个智能体配一组边界清晰的 MCP 工具，更简单、移动部件更少。
但有一件事现在就值得做：把智能体的能力拆分为离散技能，输入输出类型化，并产出结构化回执。这样当第二个智能体出现时，把一项技能升级为 Agent Card 是文书工作，而不是一次重写——先设计接缝，再决定是否装上接缝协议。
至于 A2A 在国内云厂商生态的接入进度、以及 MCP Server Cards 与 A2A Agent Card 的元数据互认进展，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。