目录

随着 AI 智能体（agent）日益普及，下一个挑战已经转向“如何让智能体彼此协作”。如果说 MCP 是把智能体连接到“工具”的标准，那么 A2A（Agent2Agent）就是把智能体连接到“另一个智能体”的标准。它让基于不同厂商和框架构建的 AI 能够通过共同的约定来对话与协作。

本文面向初学者，梳理 A2A 是什么、为什么需要它、它与 MCP 有何不同、Agent Card 与 Task 如何运作，以及它的现状和落地实现。

A2A · 连接智能体的标准

MCP 是纵向（工具），A2A 是横向（同伴）

—— AI 通过共享约定对话与协作

🔌

MCP = 纵向连接

把一个智能体连接到工具与数据。

🤝

A2A = 横向协调

把智能体彼此连接起来，并把工作委派出去。

1. 什么是 A2A？

A2A（Agent2Agent）是一套开放标准（协议），让 AI 智能体能够跨越各自的构建框架，相互发现、通信与协作。Google 于 2025 年 4 月发布，并在同年 6 月将其捐赠给 Linux Foundation，到 2026 年达到 v1.0。它正被塑造成一种不依附于任何单一公司的“通用语言”。

可以把它想象成“企业间业务合作的礼仪”。如果说 MCP 是自己的员工使用工具，那么 A2A 就是请另一家公司（另一个 AI）来做某项工作并接收成果所共用的规则手册。无论对方是用什么构建的，你都可以通过固定的流程交换“请帮我做这个”和“完成了”。

💡 一句话概括：A2A =“AI 智能体之间的通用对话协议”。MCP 负责“连接到工具”，而 A2A 负责“与同伴协调”。

2. 为什么需要它：智能体协作的时代

2026 年，AI 正走向这样一种模式：与其让一个智能体包办一切，不如让多个各有专长的智能体分工协作，也就是所谓的多智能体系统。例如，像“安排一次旅行”这样的请求会以接力的方式处理：规划智能体 → 酒店预订智能体 → 支付智能体。

但当每个智能体由不同厂商和技术构建时，要把它们连接起来每次都得做定制开发。这正是通用协议 —— A2A 发挥价值的地方。只要大家都遵循共享的约定，你就能把多智能体系统变成“可以组合的零件”。这与当年让 MCP 成为工具连接通用标准的转变如出一辙。

3. 它与 MCP 有何不同（纵向 vs 横向）

A2A 与 MCP 并非竞争对手 —— 它们角色不同，常被解释为“纵向 vs 横向”。把两者叠加使用，正是 2026 年的标准配置。

MCP · 纵向

智能体 ↔ 工具

把一个智能体连接到工具与数据 —— 数据库、API、文件。一种“增添能力”的连接。

A2A · 横向

智能体 ↔ 智能体

把智能体彼此连接起来，来回委派工作。一种“与同伴协作”的协调。

口诀很简单：“连接工具 = MCP；连接同伴 = A2A。”在真实系统中，每个智能体通过 MCP 持有自己的工具，同时通过 A2A 与其他智能体协调 —— 这种纵向 MCP 加横向 A2A 的双层结构，正成为企业级智能体运营的默认路线。

4. 工作原理：Agent Card 与 Task

A2A 的核心是 “Agent Card”。它是每个智能体公开的一张“名片”式的 JSON，写明“我能做什么”“在哪里与我对话”以及“认证如何运作”。它的位置甚至是固定的，就在 /.well-known/agent-card.json。

步骤 1

发现（Agent Card）

读取对方智能体的名片，了解它“能做什么”。

步骤 2

请求（Task）

发送一个“Task”。它携带状态 —— working、input-required、completed。

步骤 3

结果（Artifact）

接收输出。长时间运行的任务还能流式返回进度。

通信建立在广泛使用的技术之上 —— HTTP、Server-Sent Events（SSE）和 JSON-RPC 2.0。关键在于，智能体之间不会向彼此暴露内部细节。每个智能体都把自己的内容（所用的工具、推理过程）隐藏起来，只交换任务和结果。正因如此，它们即便跨公司也能安全协作。

⚠️ 安全仍是必须：智能体协作很方便，但你需要一套不会过度信任外部智能体的设计。请结合护栏和权限管理一起使用。

5. 现状与落地实现

A2A 正在快速普及。根据 Linux Foundation 的公告（截至 2026 年 4 月），已有超过 150 家组织在生产环境中使用它，它拥有 22,000+ GitHub stars，并提供五种语言的 SDK（Python、JavaScript、Java、Go 和 .NET）。Microsoft、Salesforce、SAP、ServiceNow 等大厂均有参与，进一步巩固了它作为行业标准的地位。

在实现方面，各语言的 SDK 让构建“公开 Agent Card 的一方（服务端）”和“向其他智能体委派的一方（客户端）”都变得相当容易。推荐的顺序是先构建单个智能体，等熟悉之后，再让它通过 A2A 与其他智能体协调。与 Skills 和 MCP 一样，其根基都是“通过通用格式实现组件化”这一理念。

* 文中数据与规格引用自多方披露（截至 2026 年 6 月）。该协议仍在演进，最新情况请查阅 Linux Foundation / 官方规范。

总结

关于 A2A 的三个要点。

  • 它是什么：一套让 AI 智能体跨框架相互发现与协作的开放标准。诞生于 Google，由 Linux Foundation 治理。
  • 区别在哪：MCP 是纵向（智能体 ↔ 工具）；A2A 是横向（智能体 ↔ 智能体）。把两者叠加使用是标准做法。
  • 如何运作：通过 Agent Card（名片）发现 → Task（请求）→ Artifact（结果）。在隐藏内部细节的同时安全协作。

从单个智能体走向相互协作的“团队”—— A2A 就是这座桥梁。建议与 MCP 和多智能体系统一起阅读，以把握 2026 年智能体协作的全貌。

常见问题

Q. 我该用 A2A 还是 MCP？

A. 这并非二选一。要把智能体连接到工具与数据，用 MCP；要让智能体之间协调，用 A2A。在真实系统中，你会把两者叠加：“每个智能体通过 MCP 持有自己的工具，并通过 A2A 协作。”

Q. 什么是 Agent Card？

A. 智能体的“名片”。它是一份 JSON，写明“它能做什么、在哪里与它对话、如何认证”，放置在 /.well-known/agent-card.json。对方读取它，来判断是否可以委派。

Q. 它能与另一家公司的 AI 协调吗？

A. 这正是 A2A 的全部目标。因为它是通用协议，来自不同厂商和框架的智能体都能协调。各方都把内部细节隐藏起来，只交换任务和结果。

Q. 个人开发者需要 A2A 吗？

A. 如果你只有一个智能体，那就不需要。A2A 在你想让多个独立智能体协调时才发挥价值。先构建单个智能体，等到确实需要协调时再引入 A2A，这样就足够了。