A2A 协议详解：当 AI Agent 学会"互相打电话"

做一个思想实验。

你有一个 AI Agent，它能帮你分析市场数据、生成报告、自动发邮件。很强。但有一天你需要它做一件事：找另一家公司的 AI Agent 询价，然后根据报价自动调整采购计划。

你的 Agent 愣住了。

它会调用 API，会读数据库，会用各种工具——但它不知道怎么跟"别人家的 Agent"说话。就像一个业务能力很强的员工，却没有电话，没有邮箱，甚至不会说对方的语言。

这不是一个假设性问题。这是 2025 年之前 AI Agent 生态的真实困境。

每个 Agent 都是一座孤岛。它们可以通过 MCP 调用工具，可以通过 RAG 检索知识，但 Agent 与 Agent 之间？没有标准，没有协议，没有"通信录"。

直到 A2A（Agent-to-Agent）协议出现。

2025 年 4 月，Google 发布了 A2A 协议的初始规范。一年后的今天，它已经被 Linux Foundation 托管，获得 150+ 组织支持，发布了 1.0 正式版。这篇文章，我们来深入拆解这个正在重塑 AI Agent 协作方式的协议。

为什么 Agent 之间需要一个"电话协议"？

在 A2A 出现之前，如果你想让两个 Agent 协作，你大概率会做这样一件事——

写一堆胶水代码。

Agent A 的输出格式是 JSON，Agent B 期望的输入是 Markdown。Agent A 跑在 LangChain 上，Agent B 是用 AutoGen 搭的。你需要手动定义它们之间的消息格式、调用方式、错误处理、超时重试……

听起来熟悉吗？这就是 Web 服务在 REST API 标准化之前的样子。每接一个新服务，就得重新造一套对接方案。

想想手机的历史。在 GSM 标准出现之前，每个运营商的手机只能打给同网络的用户。你用诺基亚能打给同事，但打不到用摩托罗拉的客户——不是手机不行，是它们之间没有共同的通信协议。

GSM 标准解决了这个问题：不管你是什么品牌的手机，只要遵循同一个通信标准，就能互相打通。

A2A 就是 AI Agent 世界的"GSM 标准"。

数据说话

Gartner 的数据显示，从 2024 年 Q1 到 2025 年 Q2，企业对多 Agent 系统的咨询量增长了 1,445%。预计到 2026 年底，40% 的企业应用将嵌入 AI Agent——但如果这些 Agent 之间不能互通，这个数字就只是一堆"孤岛"的叠加。

问题不在于"Agent 够不够聪明"。一个 Agent 再强，如果它只能独自工作，那它充其量是一个高级脚本。真正的智能体生态，需要 Agent 之间能够发现彼此、理解彼此、协作完成任务。

Agent 不缺能力，缺的是沟通方式。

A2A 的通信机制长什么样？

好，我们知道了"为什么"，接下来聊"怎么做"。

A2A 协议的核心可以用三个词概括：发现（Discovery）、认证（Authentication）、通信（Communication）。三步走完，两个从未谋面的 Agent 就能协作干活。

第一步：递名片——Agent Card

想象你参加一个行业大会。你不认识任何人，但每个人胸前都别着一张名片，上面写着：姓名、公司、擅长什么、怎么联系。

A2A 的 Agent Card 就是这张名片。

每个 A2A Agent 都会在一个固定地址发布自己的"名片"：/.well-known/agent-card.json。任何想找它的 Agent，访问这个 URL 就能拿到它的全部信息。

{
  "name": "PricingAgent",
  "description": "实时获取供应商批发报价",
  "capabilities": ["pricing", "negotiation", "bulk-discount"],
  "endpoint": "https://pricing.example.com/a2a",
  "authentication": {
    "type": "oauth2",
    "tokenUrl": "https://auth.example.com/token"
  },
  "supportedModes": ["sync", "async", "stream"]
}

关键在第 7 行：supportedModes。它告诉调用方："我支持同步调用、异步任务、还有流式响应。你选。"

这就像名片上不仅写了电话号码，还写了"可以打电话、可以发邮件、可以视频会议"。调用方根据自己的需求选择最合适的沟通方式。

关键区别

Agent Card 和传统 API 文档最大的不同是：它是机器可读的。不是给人看的 Swagger 文档，而是给另一个 Agent "阅读"的标准化 JSON。Agent 可以自动发现、自动解析、自动决定怎么调用。

第二步：握手——认证与安全

知道对方是谁之后，下一步是确认"你有没有资格跟我对话"。

A2A 在安全上直接复用了 OpenAPI 的认证体系：API Key、OAuth 2.0、OpenID Connect，都支持。不重新发明轮子，而是站在已有标准的肩膀上。

这个设计决策非常聪明。企业已经有一整套身份认证基础设施，A2A 不要求你重建，而是直接接入。就像你搬进一栋新写字楼，门禁系统不需要你重新办卡，你原来的工卡就能用。

第三步：协作——Task 生命周期

名片递了，手也握了，接下来就是干活了。

A2A 协议中，所有的协作都围绕一个核心对象：Task（任务）。一个 Task 有四种状态：

A2A Task 状态流转：从提交到产出

Client Agent 发起一个 Task，Remote Agent 接收后开始处理。处理过程中状态从 submitted 变为 working，最终变为 completed 或 failed。任务完成后，产出物叫 Artifact——可以是一段文本、一个文件、一张图片，甚至是一个交互式表单。

整个通信基于 JSON-RPC 2.0 走 HTTPS，长任务支持 Server-Sent Events（SSE） 做实时流式更新，还支持 Webhook 做异步回调。

你可以把它想象成一个高级版的工单系统。你在系统里提了一个需求（Task），指派给某个专家（Remote Agent），专家干活时你能实时看到进度（SSE），干完了你收到通知（Webhook），然后你拿到交付物（Artifact）。

Agent Card 就是 Agent 的 LinkedIn 个人主页——告诉全世界"我是谁、我能干什么、怎么找到我"。

MCP 和 A2A 到底什么关系？

如果你关注 AI Agent 领域，你一定听过 MCP（Model Context Protocol）。那 A2A 跟 MCP 是竞争关系吗？

不是。它们是互补关系。而且是那种"缺了任何一个都不完整"的互补。

我打一个比方：

MCP 是 Agent 的"手"——让它能操作工具、读数据库、调 API。
A2A 是 Agent 的"嘴"——让它能跟其他 Agent 对话、求助、协作。

一个只有手没有嘴的人，能干活但不能协作。一个只有嘴没有手的人，能社交但不能干活。要组建一个真正的 AI 团队，两个都需要。

维度	MCP	A2A
解决的问题	Agent 如何使用外部工具	Agent 如何与其他 Agent 协作
通信对象	工具 / 数据源 / API	另一个 Agent
发现机制	Server 发布工具列表	Agent 发布 Agent Card
交互模式	Request → Response（工具调用）	Task 生命周期（可异步、可流式）
发起方	Anthropic（2024）	Google（2025）
现状	9700 万+ 安装量	150+ 组织支持，1.0 正式版

有意思的是，这两个协议虽然分别由 Anthropic 和 Google 发起，但现在彼此都在对方的生态中被支持。微软刚发布的 Agent Framework 1.0 同时支持 MCP 和 A2A。OpenAI 的 Agents SDK 也在集成中。

这在科技圈并不常见。通常巨头之间的协议之争是"你死我活"的——想想 USB-C 之前的充电接口大战。但 MCP 和 A2A 居然走了一条"各管一摊、互不冲突"的路线。

常见误解

"A2A 会取代 MCP"——这是我最常听到的误判。A2A 解决的是 Agent 间的对话问题，MCP 解决的是 Agent 对工具的调用问题，二者工作在完全不同的层面。就像 HTTP 和 TCP 不会互相取代一样，A2A 和 MCP 是协议栈中的不同层。

MCP 管"用工具"，A2A 管"找人帮忙"。一个是手，一个是嘴，缺一不可。

一个真实场景：厨房管理员的一天

讲了这么多概念，你可能还是有点抽象。让我用 Google 官方文档中的一个案例来"落地"。

假设你经营一家连锁餐厅，你有一个 AI 厨房管理员（Kitchen Manager Agent）。它每天要做的事情包括：检查库存、采购食材、控制成本。

传统做法是什么？你给这个 Agent 接一大堆 API——库存系统的、采购系统的、价格数据库的。所有逻辑都塞在一个"全能 Agent"里。

A2A + MCP 的做法完全不同：

Kitchen Manager 的双协议协作：左边用 MCP 操作自家工具，右边用 A2A 与外部 Agent 协作

MCP 负责"自家的事"：查库存（直接读 PostgreSQL 数据库）、查菜谱（调用 Notion API）、发邮件（调用 Mailgun）。这些都是确定性的工具调用，Agent 直接操作，数据透明。

A2A 负责"找外援"：向供应商的报价 Agent 询价、向第三方质检 Agent 确认食材标准、向物流 Agent 查配送时间。这些是跨组织的协作，对方的内部逻辑对你不可见（也不需要可见），你只需要发送任务、等待结果。

这里有一个很精妙的设计原则：Agent 之间是"不透明"的。

报价 Agent 内部可能用了 GPT-5.4，也可能用了 Claude Opus 4.6，甚至可能是一个传统的规则引擎加了个 A2A 接口。你不需要知道，也不应该知道。你只关心：我发了一个询价任务，它返回了一个报价结果。

这跟面向对象编程里的"封装"原则一模一样。封装不是为了隐藏，而是为了让每个模块能独立演进，而不影响其他模块。

insider 视角

为什么 Agent 间要保持"不透明"？不仅仅是技术上的解耦——更重要的是商业上的隐私。供应商的定价策略、质检机构的评估模型，这些是核心商业机密。A2A 的设计让 Agent 可以协作，但不需要暴露内部实现。这才是企业真正愿意采纳的前提。

Agent 协作的终极形态不是"全能"，而是"专精 + 协调"。每个 Agent 做自己最擅长的事，通过 A2A 组成一个虚拟团队。

从 50 到 150+：A2A 的生态爆发

一个协议好不好，最终不是看技术多优雅，而是看有没有人用。

A2A 的采纳速度，坦白说，超出了大多数人的预期。

2025 年 4 月发布时，有 50+ 组织参与。12 个月后的今天，这个数字变成了 150+。支持者名单读起来像一本科技行业的花名册：Google、Microsoft、AWS、IBM、Salesforce、SAP、Cisco、ServiceNow……

这里有一段"小插曲"值得说说。

A2A 最初是 Google 的项目，托管在 Google 的 GitHub 上。但 2025 年底，Google 做了一个出人意料的决定：把 A2A 捐给了 Linux Foundation。

为什么？因为 Google 意识到一个道理——通信协议要想成功，不能有"亲爹"。

想想 HTTP。它之所以成为互联网的基石，不是因为某家公司推它，而是因为它由一个中立的标准组织（W3C / IETF）维护。如果 HTTP 是"Google 的 HTTP"，你觉得 Microsoft 和 Amazon 会用吗？

同理，如果 A2A 是"Google 的 A2A"，你觉得竞争对手们会积极采纳吗？捐给 Linux Foundation，等于把"所有权"变成了"共有权"。这一步棋，让 Microsoft 和 AWS 都放心大胆地在自己的平台上集成 A2A。

截至 2026 年 4 月的生态数据：

GitHub 仓库 22,000+ Stars
SDK 从最初的 Python 1 种扩展到 5 种语言（Python、JavaScript、Java、Go、.NET）
微软 Agent Framework 1.0（4 月 3 日发布）原生支持 A2A
垂直行业落地：供应链、金融、保险、IT 运维

对比一下

MCP 用了约 16 个月达到 9700 万安装量。A2A 用了 12 个月达到 150+ 组织、22K GitHub Stars。虽然指标不完全可比（一个是客户端安装量，一个是组织数），但两者的采纳曲线都呈现出典型的基础设施协议爆发模式——慢启动、快加速、一旦跨过临界点就不可逆转。

协议之争已经结束——MCP + A2A 的组合正在成为事实标准。现在的竞争，是谁能在这个标准上构建出最有价值的 Agent 生态。

我的预测：Agent 网络时代的三个判断

聊到这里，我们已经拆解了 A2A 协议的"是什么"、"怎么做"、"跟 MCP 什么关系"、"生态有多大"。

最后，我想做三个预测。给自己设一个 deadline，到时候回来验证。

预测一：2026 年底之前，"Agent 市场"会成为一个真实的商业品类。

就像 App Store 催生了移动应用生态，A2A 正在催生一个 "Agent 市场"的概念。想象一下：你不需要自己构建所有能力，而是在一个市场里搜索"报价 Agent"、"合规审查 Agent"、"翻译 Agent"，按需调用，按使用量付费。Agent Card 就是商品详情页，A2A 就是交易协议。

预测二：2027 年 Q2 之前，至少一家主流云厂商会推出 "Agent 网关" 产品。

就像 API 网关管理 REST API 的流量、认证和限速，"Agent 网关"会管理 A2A 流量——Agent 发现、负载均衡、调用审计、成本分摊。这不是一个"可能有"的产品形态，而是 A2A 大规模落地后的必然基础设施。

预测三：MCP + A2A 将像 HTTP + TCP 一样，成为开发者不需要关心、但离不开的底层协议。

最成功的协议是"隐形"的。你今天写代码的时候会想"我正在用 HTTP"吗？不会。它已经沉到了框架层。MCP 和 A2A 的终局也是如此——开发者只需要说"调用报价服务"，框架自动判断该走 MCP（直接工具调用）还是 A2A（跨 Agent 协作），开发者感知不到协议的存在。

12 个月后，我们回来看看这三个预测对了几个。

未来 AI 的竞争力，不是谁的模型参数更多，而是谁的 Agent 网络更大、连接更密。A2A 不是一个技术协议——它是 Agent 时代的社交网络协议。