A2A（Agent-to-Agent Protocol）深度剖析 —— 是什么、为什么会有、解决什么问题，以及与 MCP 的关系

你在手机助手上说了一句：”帮我订一张周五上海飞北京的机票，顺便看看要不要买延误险，最后把行程同步到我的日历。”

它先去查航班（调用工具）、再问你偏好（人机交互），然后做了两件和以前不一样的事：把”订票”这件事委托给了航空公司的票务 Agent，把”延误险评估”委托给了保险公司的 Agent，最后汇总结果、同步日历。

前两步我们已经很熟了——MCP 干的就是”Agent 调用工具”这件事。但后两步是全新的：一个 Agent 委托另一个 Agent。问题随之而来：一个 Agent 怎么发现另一个 Agent？怎么知道它能不能订票、收费几何、靠不靠谱？怎么把任务交过去、怎么拿回结果？任务要跑几小时甚至几天，中间需要人拍板，怎么跟进？

这就是 A2A（Agent-to-Agent Protocol，Agent 间协议）要回答的问题。

这篇文章沿用之前《MCP 全面解析》《从大模型到 Agent》两篇的剖析风格，把 A2A 从头到尾拆一遍：是什么、为什么会有、解决什么问题、底层原理，以及它和 MCP、ACP 的关系。

一、是什么：A2A 的定位与本质

1.1 一句话定义

A2A 是一个开放协议，让不同厂商、不同框架、不同实现的 Agent 之间，能够安全、标准地互相发现、沟通、委派任务与协作。

它只关心一件事：Agent 与 Agent 之间的通信。至于”Agent 怎么调用工具”，那是 MCP 的地盘；至于”Agent 内部用不用大模型、用什么记忆、怎么编排”，A2A 一概不管。

1.2 出身：Google 提出，捐给 Linux Foundation

• 2025 年 4 月，Google 在 Cloud Next 大会上发布 A2A，发布当天就有 50 多家伙伴联署，包括 Atlassian、Box、Cohere、Intuit、LangChain、MongoDB、PayPal、Salesforce、SAP、ServiceNow、Workday 等，横跨 SaaS、数据库、框架、支付等各领域。
• 2025 年 6 月，Google 把 A2A 捐赠给 Linux Foundation，成为独立的开源治理项目（归在 LF AI & Data 旗下），不再由 Google 一家主导。
• 规范与 SDK 托管在开源仓库 google/A2A，官方站点 a2a-protocol.org。

这个”出生即带着一票生态伙伴、迅速中立化”的路径，和 MCP（Anthropic 提出 → 全行业跟进）几乎一模一样：谁都怕被某一家厂商锁死在私有协议里，所以更愿意拥抱一个中立的、开源的、有治理的公共标准。

1.3 定位辨析：它管什么，不管什么

一句话：MCP 解决”Agent 怎么动手”，A2A 解决”Agent 怎么对话与协作”。

二、为什么会有 A2A：从单 Agent 到多 Agent 的必然

2.1 真实任务很少由一个 Agent 单打独斗

一个”订机票 + 买保险 + 同步日历”的任务，理想情况下由三个各司其职的 Agent 完成：

这三个 Agent 分属不同公司、跑在不同框架上（LangChain / AutoGen / 自研），数据和权限天然分散——没有任何一家会把自己的票务系统和风控模型合并进别人的进程里。所以”一个超大型 Agent 包打天下”在工程上既不现实、也不安全。

协作，是逼出来的，不是选出来的。

2.2 没有统一协议时的三种别扭做法

在 A2A 出现之前，让两个 Agent 协作，业界只能硬凑，各有各的毛病：

第三种尤其值得注意：把一个 Agent 压扁成一个”无状态函数”，等于把一台会思考、会反问、会持续推进任务的机器，当成一个只会”输入→输出”的 API。 你调一下它能给你个结果，但它没法在任务中途反过来问你”要不要靠窗座位”，没法跑三小时后主动通知你”出票失败，需要你补个护照号”。这些恰恰是 Agent 协作的核心价值。

2.3 一句话总结

当 AI 从”一个模型回答一个问题”演进到”多个 Agent 共同完成一件事”，Agent 之间的通信协议就变得和 TCP/IP 之于互联网一样基础。A2A 想做的，就是 Agent 世界的”共同语言”。

三、解决什么问题

把 A2A 的价值拆成四点，正好对应它设计时的四个”设计原则”。

3.1 互通性：打破框架与厂商割裂

没有标准时，M 个框架 × N 个厂商 = M×N 套适配。A2A 把”Agent 怎么描述能力、怎么发现、怎么通信”统一成一套协议，任何实现 A2A 的 Agent 都能即插即用、互相委派。这和 MCP 解决的”M×N 工具集成困境”是同一个思路，只是作用在”Agent 与 Agent”这一层。

3.2 发现机制：Agent 能被”找到”并”读懂”

协作的前提是知道对方存在、且知道对方能干什么。A2A 用一张 Agent Card（下文详解）作为 Agent 的”公开名片”，描述它的身份、能力、技能、端点、鉴权方式。别的 Agent（或人）拿到这张卡，就能判断”这家伙能不能订票、要不要收费、接不接长任务”，从而决定是否委托。

3.3 长任务与人在环：从”几秒”到”几天”

Agent 之间的协作，经常不是”一问一答”的秒回，而是：

• 任务要跑几分钟到几天（调研、审批、批量处理）；
• 中途需要人拍板（”预算超了 20%，要不要继续？”）；
• 结果可能以多种形态返回（文字、报表、音频、表单）。

A2A 用 Task 状态机来承载这一切：任务从提交到完成，会经历 submitted → working → input-required / completed / failed / canceled / rejected 等状态，双方都能随时查询进度、在需要输入时暂停、在完成时收到通知。这是”把 Agent 当工具硬塞”做不到的，也是 A2A 与普通 RPC 的本质区别。

3.4 形态无关 + 实现不透明

• 形态无关：消息与产物可以是文本、文件、结构化数据、音频、视频，甚至一个可交互表单（例如让用户在结果里直接点”确认改签”）。
• 对内部不透明：A2A 不假设对方 Agent 用不用大模型、用哪个框架、记忆怎么存。它只管”通信契约”，不管”脑子长什么样”。这让它既能连接基于 LLM 的智能体，也能连接纯规则引擎、传统 RPA 机器人。

四、核心概念：协议的骨架

A2A 把一次协作抽象成四个核心对象：Agent Card、Task、Message（及其 Part）、Artifact。理解了这四样，就理解了整个协议。

4.1 Agent Card：Agent 的”公开名片”

Agent Card 是一个 JSON 文档，通常挂在约定的路径 /.well-known/agent.json 下，任何客户端都能 GET 到。它回答三个问题：我是谁、我能干什么、怎么找我/鉴权。

{
  "name": "Airlines Ticketing Agent",
  "description": "查询航班、比价、出票、退改签",
  "url": "https://agents.example.com/ticketing",
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,          // 是否支持流式返回
    "pushNotifications": true,  // 是否支持主动推送
    "stateTransitionHistory": true
  },
  "skills": [
    { "id": "search_flights",  "name": "查航班",   "description": "按城市/日期查询航班" },
    { "id": "book_ticket",     "name": "出票",     "description": "下单并出票" }
  ],
  "securitySchemes": { },   // 鉴权方式：apiKey / OAuth2 / OpenID ...
  "defaultInputModes": ["text"],
  "defaultOutputModes": ["text", "file"]
}

要点：

• skills（技能） 是这张卡的核心增量：它让别的 Agent 不仅能”找到你”，还能理解你具体会干什么，从而做能力匹配。这比传统 API 的”只有 endpoint 没有语义”前进了一大步。
• capabilities 声明你支不支持流式、支不支持推送，对方据此选择最合适的交互方式。
• securitySchemes 声明鉴权方式，是 A2A “安全默认”的落点之一。

小知识：MCP 也有”服务发现”（通过 initialize 握手交换能力），但那是”客户端连接一个已知 Server”；A2A 的 Agent Card 是面向整个网络的可公开寻址的名片，更接近”黄页”。

4.2 Task：协作的原子单位 + 状态机

Task 是 A2A 里一切工作的载体。你把需求发过去，对方会创建一个 Task，然后围绕它推进、汇报、结束。Task 有明确的状态机：

submitted ──▶ working ──┬──▶ input-required ──▶ working ──▶ completed
                        ├──▶ completed
                        ├──▶ failed
                        ├──▶ canceled
                        └──▶ rejected

主要状态含义：

注意 input-required 和 auth-required：它们把”Agent 会反问、会要授权”这种人类协作的常态，固化成了协议的一等公民。 这正是”把 Agent 当无状态工具”所丢失的东西。

4.3 Message 与 Part：一次”对话”

Agent 之间一次”来回”是一条 Message，Message 由若干 Part 组成。Part 有三类：

一个 Message 可以同时塞多个 Part，比如”这是你的差旅报告（FilePart），总花费 3280 元（DataPart），需要你确认是否报销（TextPart）”。

4.4 Artifact：任务的”产出物”

Task 完成后，产出放在 Artifact 里——它同样由若干 Part 组成（一段文字总结 + 一个 PDF + 一段结构化数据）。Artifact 是”交付物”，Message 是”过程对话”，两者分开，语义清晰。

五、原理剖析：消息如何流转

5.1 底层：不发明新轮子，复用成熟标准

A2A 最聪明（也最务实）的一点，是它几乎没有发明新的传输层，而是站在既有标准肩上：

这套组合是不是很眼熟？没错——MCP 底子也是 JSON-RPC 2.0 + HTTP/SSE。两个协议在地基上同源，这让”既支持 MCP 又支持 A2A”的网关/Agent 实现起来非常自然。

5.2 关键方法（JSON-RPC 2.0）

A2A 定义的方法不多，但够用：

前三个是主干：send 发起、stream 跟踪、get 兜底查询。

5.3 一次协作的完整时序

假设”你的助手 Agent（客户端）”委托”票务 Agent（远端）”订票：

客户端 Agent                        票务 Agent
     │ ① GET /.well-known/agent.json      │
     │ ─────────────────────────────────▶ │
     │ ◀──────── Agent Card（能力/技能）── │   发现：读懂你能订票
     │                                    │
     │ ② message/send（TextPart: 订一张票）│
     │ ─────────────────────────────────▶ │   发起：创建 Task
     │ ◀──────── { taskId: "t-42" } ───── │
     │                                    │
     │ ③ tasks/get（t-42） 或 SSE 订阅     │
     │ ─────────────────────────────────▶ │
     │ ◀────── status: working ───────────│
     │                                    │
     │ ◀──── status: input-required ──────│   （需要选舱位/证件）
     │ ④ message/send（DataPart: 经济舱）  │
     │ ─────────────────────────────────▶ │
     │                                    │
     │ ◀── SSE: status completed +        │
     │          Artifact(FilePart:行程单)  │   交付
     │                                    │
     │ ⑤ （若配了 webhook）远端主动 POST    │
     │ ◀──────── 出票成功通知 ─────────────│

三步关键：①发现（Agent Card）→ ②发起（send，拿到 taskId）→ ③跟踪（SSE 流式 / get 轮询 / webhook 推送）。中间那个 input-required 来回，就是”人在环”在协议层的落地。

六、协议全景：MCP、A2A、ACP 三足鼎立

讲到这里必须把第三个名字请出来——ACP，否则”A2A 和 MCP 的关系”这个题是不完整的。

6.1 快速回顾：MCP 是”插座”

MCP（Model Context Protocol，Anthropic 2024 年 11 月开源）解决的是 Agent ↔ 工具/数据源 的接入问题，被誉为”AI 的 USB-C 接口”。它的三原语是 工具（tools）、资源（resources）、提示词（prompts），架构是 Client/Server，传输是 stdio / streamable HTTP / SSE。（细节我在《MCP 全面解析》里拆过，这里只定位。）

一句话：MCP 给 Agent 装手脚。

6.2 ACP：另一个”A2A”，出身 IBM

ACP（Agent Communication Protocol）是 IBM 依托其开源 Agent 框架 BeeAI 提出的另一个 Agent-to-Agent 协议，2025 年年中发布，官方站点 agentcommunicationprotocol.dev。

它和 A2A 目标高度重合——都是让 Agent 之间互相通信、委派、协作；底层也都站在 JSON-RPC 2.0 之上；也都用 Agent Card 做发现。差别主要在工程取舍上：

关键结论：ACP 和 A2A 不是”一个对、一个错”，而是同一条赛道上两个高度重叠的竞争者。对用户来说，重复造轮子意味着又要站队——这恰恰是行业想避免的。

6.3 合流：ACP 加入 A2A，归于 Linux Foundation

正因如此，2025 年 8 月，ACP 宣布”加入 A2A”，两者在 Linux Foundation 下合流（LF AI & Data），共同演进一套 Agent 间通信标准。这意味着：

• “Agent-to-Agent”这一层，市场快速收敛，避免了一家一个协议、彼此不通的碎片化；
• 这也反向印证了 A2A 路线（开放、中立、企业级）的正确性。

顺带一提，协议圈还有 ANP（Agent Network Protocol）等其他玩家，但生态声量和治理权重远不如上面三者，本文不展开。

七、什么场景选什么协议：一张决策表 + 一张协作时序图

7.1 先分清”三个层次”

最容易混的，是把这三样放在同一个维度比。其实它们作用在不同的接缝上：

        ┌─────────────────────────────────────────────┐
        │                  编排/业务逻辑               │
        └───────────────┬───────────────┬─────────────┘
                        │               │
          ┌─────────────▼──┐      ┌─────▼──────────────┐
          │  MCP（插座）    │      │  A2A / ACP（电话）  │
          │ Agent → 工具    │      │ Agent → Agent      │
          │ 查库/读文件/API │      │ 发现/委派/协作      │
          └────────────────┘      └────────────────────┘

• MCP 在”Agent 的手脚”这一层：把工具、数据、上下文接进来。
• A2A / ACP 在”Agent 的社交”这一层：让 Agent 之间打电话。
• 两者正交：一个 Agent 完全可以左手用 MCP 接工具，右手用 A2A 找别的 Agent 协作，互不冲突。

7.2 决策表

一句话记忆法：

MCP 给 Agent 装手脚，A2A 让 Agent 之间打电话，SKILL 给 Agent 发说明书。

7.3 三者在同一次调用里的协作时序

以一个真实的多 Agent 编排为例：用户说”帮我调研竞品 X 的近况并出一页报告，再把结论同步进 CRM”。

 用户 ──▶ 编排 Agent（你的助手）
                    │
   ① 用 MCP 查资料 ─┴─▶ 搜索 Agent / 数据库（MCP tools/resources）
                    │    "查竞品公开信息"
                    │
   ② 用 A2A 委派 ───┴─▶ 分析 Agent（第三方，专精报告）
                    │    Agent Card 发现 → message/send → Task 长跑
                    │    ◀── SSE 流式返回 Artifact（报告 PDF）
                    │
   ③ 用 A2A 同步 ───┴─▶ CRM Agent（SaaS 厂商）
                    │    message/send（DataPart: 结构化结论）
                    │    ◀── status: completed
                    │
   ◀── 汇总结果给用户

拆解：

1. MCP 段：编排 Agent 靠 MCP 接进搜索工具、文件系统、数据库——解决”拿原材料”。
2. A2A 段（写报告）：编排 Agent 发现并委托一个”专精报告生成”的第三方 Agent——解决”外包专业工序”，期间用 Task 状态机 + SSE 流式跟进。
3. A2A 段（写 CRM）：把结构化结论通过 A2A 发给 SaaS 厂商的 CRM Agent——解决”跨组织落地”。
4. 全程编排 Agent 是”大脑”，MCP 是它的”手脚”，A2A 是它的”电话簿和外派”。

这一张图，就是 MCP、A2A、ACP（当 ②③ 用 WebSocket 异步形态实现时）三个词在真实系统里的完整分工。

八、生态与现状

8.1 时间线

8.2 谁在支持

发布即带 50+ 伙伴，涵盖 SaaS（Salesforce、ServiceNow、SAP、Workday）、数据库（MongoDB）、框架（LangChain）、支付（PayPal）等。托管到 Linux Foundation 后，治理独立、SDK 多语言（Python、Java、JavaScript/TypeScript、Go 等）持续迭代。

8.3 它成熟了吗

相对 MCP 已经”烂大街”的普及度，A2A 目前规范稳定、生态起步：概念和设计原则清晰、企业级考量到位，但真正大规模跨组织的生产落地还在早期。这很正常——“Agent 之间协作”的场景本身，也才刚刚开始出现。

九、局限与展望

客观讲，A2A 还没到”开箱即用”的成熟度，几个开放问题值得盯着：

1. 安全与信任：跨组织协作时，怎么证明”对方 Agent 真的可信、不会作恶”？鉴权（OAuth2/OIDC）解决了”你是谁”，但”你值不值得信、办事靠不靠谱”还远未标准化。
2. 多跳编排：A 委托 B、B 又委托 C，责任链、成本分摊、故障定位、幂等与重试，都还没有成熟的最佳实践。
3. 可观测性与计费：跨 Agent 任务跑几天，中间谁慢、谁贵、谁失败了，观测与结算体系尚在早期。
4. 与 MCP 的边界是否会漂移：目前两者边界清晰（工具 vs Agent），但随着 Agent 越来越像”有状态的服务”，这个边界可能变模糊——比如把 MCP 的 tool 增强成”有状态、可反问”，那它和 A2A 的任务模型就会撞车。合流后的 A2A 如何守住并讲清这条线，值得观察。

总结

把这一路的结论收进一张图：

                 ┌────────────────────────────────────────┐
                 │            LLM（大脑：会思考）          │
                 └──────────────────┬─────────────────────┘
                                    │ 装在
                 ┌──────────────────▼─────────────────────┐
                 │      Agent（人：有手脚/记忆/目标/循环）  │
                 └──────┬───────────────────────┬─────────┘
                        │                       │
          ┌─────────────▼──────┐      ┌─────────▼──────────────┐
          │ MCP（插座/手脚）     │      │ A2A / ACP（电话/社交）  │
          │ Agent → 工具        │      │ Agent → Agent          │
          │ 发现工具·调用·读资源 │      │ Agent Card 发现·Task 状态机·流式/推送 │
          └────────────────────┘      └────────────────────────┘

• MCP 回答：Agent 的手脚从哪来、怎么接。
• A2A 回答：Agent 之间怎么互相找到、怎么委派、怎么协作、怎么跟进长任务。
• ACP 是 A2A 的同赛道竞争者，最终合流，共同把”Agent 间通信”这条赛道收敛到一个中立标准上。
• SKILL 则回答：Agent 该”怎么做一件事”的方法从哪来。

一句话收尾：

MCP 让 Agent 不再孤立地活着，A2A 让 Agent 不再孤立地干活。 前者是给单个 Agent 接上世界，后者是让一群 Agent 组成世界。

参考

• A2A 官方规范（a2a-protocol.org）
• A2A 开源仓库（google/A2A）
• Google 官方博客：Announcing the Agent2Agent Protocol (A2A)
• Linux Foundation：Launching the Agent2Agent Protocol Project
• ACP Joins Forces with A2A Under the Linux Foundation (LF AI & Data)
• Agent Communication Protocol（ACP）官方站点
• IBM：What is Agent Communication Protocol (ACP)?
• 站内关联阅读：《MCP 全面解析 —— 类型、原理与使用方式》《从大模型到 Agent：MCP、SKILL，以及 DeepSeek Harness 为什么是一个 Agent》