Agent2Agent（A2A）：AI 代理互联互通的「普通话」协议

想象一个没有微信、没有电话的时代：每个人都说自己独特的方言，写信用完全不同的格式，任何两个组织之间的沟通都需要专门的双边协议——这正是 2024 年前后 AI Agent 领域的真实写照。

Google 在 2025 年初正式发布了 Agent2Agent（A2A）开放协议，并将其交由 Linux Foundation 托管。这个项目迅速积累了超过 23000 颗星，成为 AI Agent 互联互通领域最具影响力的标准倡议。

图1：A2A 协议在智能体技术栈中的定位

项目背景：为什么 AI 代理需要「普通话」？

当前，企业和研究团队正在构建大量专用 AI 代理：客服代理、代码审查代理、数据分析代理、法律文书代理……然而，这些代理通常基于不同的框架（LangGraph、AutoGen、Vertex AI Agent Builder 等），由不同厂商托管，运行在不同服务器上。它们很难相互「对话」，更谈不上协作。

更关键的是：现有的解决方案（如 MCP）解决的是「人类调用工具」的问题，而非「代理调用代理」的问题。当一个复杂任务需要多个专业代理协作时，我们需要的不只是工具调用协议，而是一种能让代理之间互相发现能力、协商任务、共享上下文、安全协作的完整语言——这就是 A2A 诞生的意义。

图2：A2A 项目由 Linux Foundation 托管，汇聚了全球 166 家合作伙伴

核心机制：四个能力让代理真正「互联」

1. 能力发现（Agent Cards）

每个 A2A 兼容代理在启动时公开一份「代理卡」（Agent Card），其中包含：代理名称、版本、支持的能力列表、认证方式、端点 URL 等元数据。其他代理可以查询这份卡片，了解对方能做什么，而无需进入对方的内部系统。

这类似于商业合作中的「名片交换」——双方不需要共享内部系统，只需要知道对方能提供什么服务，就能开始协作。

2. 任务协商与协作

A2A 支持三种交互模式：

• 同步请求/响应：简单任务，一次往返完成。
• 流式推送（SSE）：代理可以实时推送进度更新，适合需要用户看到中间结果的场景。
• 异步推送通知：长任务完成后，通过 Webhook 回调通知发起方。这对需要人类参与的复杂工作流尤其重要。

3. 多模态内容交换

A2A 不只传递文字，它支持文本、文件、结构化 JSON 数据、表单乃至媒体引用——这意味着一个数据分析代理可以将处理结果以文件形式交给可视化代理，后者再将图表推送给用户。

4. 安全协作（企业级保障）

A2A 全面对齐企业安全实践：支持 mTLS 双向认证、JWS 代理卡签名验证、OAuth 2.0（包含最新的 Device Code 流程和 PKCE 支持），以及基于标准 HTTP 头的鉴权机制。这使得 A2A 能直接进入企业内网环境。

A2A 与 MCP：互补而非竞争

很多初接触者会问：A2A 和 Model Context Protocol（MCP）是什么关系？是竞争关系吗？

答案是：互补，且 A2A 的设计明确与 MCP 对齐。

MCP 解决的是「AI 模型如何调用外部工具」的问题（Tool Use），而 A2A 解决的是「代理如何与其他代理协作」的问题（Agent Collaboration）。两者作用于不同的层次，Google 官方文档甚至专门用一张图说明两者如何协同工作。

图3：A2A 与 MCP 的互补关系——MCP 处理工具调用，A2A 处理代理协作

一个典型场景：用户对客服代理说「帮我分析这季度销售数据」，客服代理通过 MCP 调用数据分析工具（Tool Use），再通过 A2A 将分析请求转发给专业的财务分析代理（Agent Collaboration），后者完成工作后再通过 A2A 返回结果给客服代理，最终呈现给用户。

图4：真实场景中 A2A 与 MCP 的协同工作流示意

技术架构：站在坚实标准之上

A2A 的设计哲学是「简洁复用」——不发明新轮子，而是用经过验证的互联网标准构建代理通信语言：

• JSON-RPC 2.0：所有方法调用基于 JSON-RPC 2.0，这是 Web API 领域最成熟的标准之一。
• Server-Sent Events（SSE）：用于流式推送，Web 原生支持。
• HTTP/HTTPS：传输层，无需额外基础设施。
• Protocol Buffers（proto3）：定义消息结构，提供强类型和跨语言支持。
• gRPC + REST + JSON-RPC 三种绑定：同一协议规范可用三种方式实现，保证最大互操作性。

协议核心文件 a2a.proto 是规范的规范（normative source of truth），所有 SDK 实现都必须严格遵循。

v1.0 版本（2026年3月发布）带来了大量重要改进：移除 discriminator 字段、枚举值标准化为 SCREAMING_SNAKE_CASE、简化 ID 格式（从 tasks/{id} 改为纯 UUID）、原生支持多租户和每接口版本控制。

生态版图：166 家合作伙伴的信任票

A2A 的合作伙伴名单几乎是一部 AI 行业头部企业名录：Google、Adobe、AWS、Atlabsian、Bloomberg、GitHub、Cohere、DataRobot、Elastic、Salesforce……以及中国厂商阿里云（AliCloud）。这 166 家合作伙伴覆盖了云服务商、企业软件、数据库、安全、AI 初创等各个领域。

生态快速扩张背后有几个推动因素：

1. Google 的背书与推广：Google 将 A2A 作为其 Agent Development Kit（ADK）的核心通信协议，并在 Google Cloud 生态中大力推广。
2. DeepLearning.AI 课程：Google 与 DeepLearning.AI 联合推出了专项课程，系统讲解 A2A 协议及其在多代理系统中的应用。
3. Linux Foundation 托管：中立治理结构降低了厂商锁定的顾虑。
4. 多语言 SDK 生态：Python、Go、JavaScript、Java、.NET 五大主流语言的官方 SDK 同时推进，降低了接入门槛。

局限与挑战

尽管势头强劲，A2A 仍面临一些挑战：

1. SDK 成熟度参差不齐：Python SDK 相对完善，而 .NET 和 Java SDK 仍在快速迭代中，企业生产环境使用前需仔细评估。
2. 协议版本演进中的 Breaking Changes：v1.0 相比 v0.3.0 有多项破坏性变更（如枚举值格式、ID 格式），版本迁移需要代码适配。
3. 代理间信任机制仍在完善：Agent Card 签名验证虽然已支持，但大规模生产环境下的信任管理、权限隔离仍需要更多最佳实践积累。
4. 「碎片化」对手的存在：Anthropic 的 MCP 和其他框架的私有协议仍是 A2A 普及的竞争力量。

行业意义：多代理系统的「基础设施」

A2A 的意义不只是解决当下的互操作问题，更在于它预示了 AI 应用架构的未来方向：单代理 → 多代理系统 → 多代理网络。

随着 AI Agent 从实验走向生产，单一代理的能力边界越来越明显，而多代理协作的需求急剧增长。类比互联网的发展历程：A2A 之于多代理系统，正如 TCP/IP 之于互联网——它提供的是让整个生态能够规模化运转的底层协议。

如果用一个比喻来总结：A2A 就是 AI 代理世界的「微信协议」——不是某个聊天 App，而是让所有玩家都能接入、共同繁荣的通信标准。