目录

随着 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，这样就足够了。