### [A2A 协议——AI 智能体之间如何开口说话](https://youshipu.cn/article/800)

**Published:** 2026-09-06T00:42:50

**Author:** 优势铺

**Excerpt:** Agent-to-Agent 协议定义了 AI 之间如何开口说话：Agent Card、Task Unit、T…

![封面](https://api.youshipu.cn/wp-content/uploads/2026/09/cover03_a2a-1.png)

## 引子：当你让两个 AI 同时回答「订一张机票」

如果你把订机票这件事交给两个 AI 助手，一个只负责航班搜索，另一个只负责行程规划，它们之间的对话会是什么样？这个看似简单的问题，在过去一年里成了 AI 工程圈最热的实验题——它的官方名称叫「Agent-to-Agent（A2A）协议」。

A2A 协议要解决的是：当 AI 不再是单个聊天机器人，而是若干任务级 Agent 协同完成一件事时，它们如何「开口说话」。这和十多年前微服务之间的 API 调用相似又不相同：相似的部分是协议握手、消息结构、能力协商；不同的部分是，Agent 之间传递的不只是数据，还有「意图、上下文、失败回退」。

## A2A 不是新名词，但为什么在 2025 年又被提起

「Agent-to-Agent」在分布式系统语境里已经存在十多年。在 2025 年再次成为热词，是因为大模型 Agent 落地遇到了三个具体瓶颈：

1.  单个 Agent 的能力边界被大模型上下文窗口与工具调用限制所束缚。
2.  多 Agent 协作时，意图、约束、失败恢复要在毫秒级到分钟级之间灵活切换，这远超传统 RPC 的请求-响应模式。
3.  厂商各自实现自己的「跨 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 日从上海飞北京的国航早班机票」为例：

1.  用户向「行程管家 Agent」说出意图；它判断需要调用「航班搜索 Agent」。
2.  行程管家读取航班 Agent 的 Agent Card：发现它支持 find\_flight、有 SLA（响应
3.  航班 Agent 返回候选航班列表。行程管家根据用户偏好过滤后，再调用「支付 Agent」，附上前序 Context。
4.  支付 Agent 收到 Context 后要求 3DS 校验，触发用户侧的人脸验证——这步会切回同步 RPC，与 A2A 异步并行机制混跑。
5.  支付完成后，行程管家将订单结果回写至用户的「行程档案 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 的每一个动作？这些问题还没有统一答案，但每天都在被反复讨论。

**Categories:** 分类1

---