引子：当你让两个 AI 同时回答「订一张机票」
如果你把订机票这件事交给两个 AI 助手，一个只负责航班搜索，另一个只负责行程规划，它们之间的对话会是什么样？这个看似简单的问题，在过去一年里成了 AI 工程圈最热的实验题——它的官方名称叫「Agent-to-Agent（A2A）协议」。
A2A 协议要解决的是：当 AI 不再是单个聊天机器人，而是若干任务级 Agent 协同完成一件事时，它们如何「开口说话」。这和十多年前微服务之间的 API 调用相似又不相同：相似的部分是协议握手、消息结构、能力协商；不同的部分是，Agent 之间传递的不只是数据，还有「意图、上下文、失败回退」。
A2A 不是新名词，但为什么在 2025 年又被提起
「Agent-to-Agent」在分布式系统语境里已经存在十多年。在 2025 年再次成为热词，是因为大模型 Agent 落地遇到了三个具体瓶颈：
- 单个 Agent 的能力边界被大模型上下文窗口与工具调用限制所束缚。
- 多 Agent 协作时，意图、约束、失败恢复要在毫秒级到分钟级之间灵活切换，这远超传统 RPC 的请求-响应模式。
- 厂商各自实现自己的「跨 Agent 调用框架」，协议的封闭性让 Agent 生态相互割裂。
于是，一场「让 Agent 学会握手」的标准之争在 2024 年下半年展开。Google 在 Google Cloud Next 2024 上推出 A2A Protocol v0.1；Anthropic 在 MCP（Model Context Protocol）里加入了 Agent 协商扩展；Cisco、Microsoft、IBM、华为、阿里云、百度智能云陆续表态支持不同子协议。版本虽不统一，但诉求高度一致：「让 Agent 们用同一种语法对话。」
A2A 协议的核心四件套
1. Agent Card：自我介绍
每个 Agent 在注册时需要出示一份「Agent Card」——用 JSON 描述自己的能力、模型版本、可用工具、SLA、计费模型。类似 OAuth 里的元数据，但更细粒度。Agent 在被另一个 Agent 调用前，会先比对目标 Agent Card 是否符合自己的任务约束。
2. Task Unit：任务级消息
每个 A2A 任务以「Task Unit」为单位发起。Task Unit 包含四类信息：
- 意图（Intent）：用结构化 JSON 描述「我要做什么」，比如 {action: “find_flight”, constraints: {origin: “PVG”, destination: “PEK”, date: “2026-10-01”}}。
- 上下文（Context）：从前序 Agent 传递过来的会话状态、数据凭证、临时缓存键。
- 截止条件（Deadline & Fallback）：明确写到「这一轮不行就降级到什么方案」。
- 输出契约（Output Schema）：用 JSON-Schema 约定返回结构，违反 schema 即视为失败。
3. Transport：传输层选择
官方 A2A v0.1 推荐两种传输：JSON-RPC over HTTPS 与 gRPC。后者适合在数据中心内 Agent 密集协作，前者适合跨云跨厂商。两条路并不矛盾，企业通常根据网络拓扑混用。
4. Discovery & Trust：发现与互信
Agent 之间的相互发现是 A2A 体系里最薄弱、也是最关键的一环。常见模式包括：
- 共享目录服务（类似 LDAP）。
- 去中心化哈希表（DHT），用于跨组织的 Agent 注册。
- 本地缓存 + 主动刷新，模拟 DNS 行为。
Trust 机制则通过签名令牌、TLS mTLS 与零知识证明结合实现。「我这个 Agent 没有把你的指令修改过」是当前协议尚未完美解决的问题，工程界普遍认为需要至少两到三个版本才能稳定下来。
一次完整的 A2A 协作长什么样
以「帮我订一张 10 月 1 日从上海飞北京的国航早班机票」为例：
- 用户向「行程管家 Agent」说出意图；它判断需要调用「航班搜索 Agent」。
- 行程管家读取航班 Agent 的 Agent Card：发现它支持 find_flight、有 SLA（响应
- 航班 Agent 返回候选航班列表。行程管家根据用户偏好过滤后，再调用「支付 Agent」，附上前序 Context。
- 支付 Agent 收到 Context 后要求 3DS 校验，触发用户侧的人脸验证——这步会切回同步 RPC，与 A2A 异步并行机制混跑。
- 支付完成后，行程管家将订单结果回写至用户的「行程档案 Agent」。
这个过程中，跨 Agent 共出现了 4 次握手、2 次 Schema 校验、1 次鉴权。最关键的是：每个 Agent 都不需要知道其他 Agent 的内部实现。它们之间只交换 Task Unit。
为什么很多企业还在观望
A2A 协议本身已经稳定到可以商用，但落地到企业仍有几个坎：
- 贵：Agent Card 注册、托管、签名验证都要建设，初期投入要按百万级服务调用估算。
- 难调试：跨 Agent 的链路追踪比单体应用难 10 倍，行业普遍使用 OpenTelemetry 与 W3C Trace Context，但 A2A 自己的语义尚未完整定义。
- 合规差异：欧盟 AI Act 把「AI Agent 自动决策」列为高风险类别，需要额外的可审计性。这对协议设计提出了「决策解释」字段的硬性要求。
- 人才稀缺：既有大模型经验又懂分布式系统协议的工程师极度稀缺。
三个值得追的趋势
1. 边缘 Agent 协作
把一部分小型 Agent 部署到设备端，例如工厂机械臂、智能家居、车载系统，让它们在局域网里完成低延迟协作。这种结构倒逼 A2A 协议支持轻量传输层（QUIC、MQTT-SN）。
2. 跨厂商互联
OpenAI、Anthropic、阿里云、华为云等已经分别推出自己的 Agent 平台。互联的真正瓶颈，在于「跨厂商 Agent Card」的可信注册机制——一旦某个公链（公链指不被任一厂商独管的去中心化网络）成为公共注册表，互联将得到极大加速。
3. 以「行为合约」取代「指令调用」
目前在 A2A 协议里，Agent 普遍采用「请求-响应」模式。未来可能被「行为合约」取代——各 Agent 同时订阅同一个任务流，谁先把任务做完就回执结果，其他 Agent 自动放弃。这与人脑的潜意识处理机制相似，能显著降低任务时延。
结语：协议稳定后，真正的难题是治理
A2A 协议并不是什么艰深的概念。它的核心是把 Agent 当成「有边界、有契约、有失败回退的服务」，与十年前的 SOA（Service-Oriented Architecture）异曲同工。但当下的 AI 时代让这种结构重获新生：Agent 比微服务更「聪明」，但也比微服务更难预测。当协议稳定到能商用后，下一个被推到台前的难题一定是治理——谁有权注册新的 Agent？谁来决定 Agent 之间的优先级？谁能审计 Agent 的每一个动作？这些问题还没有统一答案，但每天都在被反复讨论。
