概述

2026年的多智能体协作正在经历一次"协议层坍缩"。当LangChain、CrewAI、AutoGen、Google ADK、Microsoft Agent Framework各自为政、用各自的Python对象和内存调用来编排Agent时，跨框架、跨厂商的Agent根本无法对话。Agent2Agent协议（A2A）——Google于2025年4月推出、现由Linux Foundation托管——正试图用一套基于HTTP+JSON-RPC 2.0+SSE的开放标准，复制HTTP对Web那样的统一效应。它不与Anthropic的MCP竞争：MCP解决"Agent连工具"，A2A解决"Agent连Agent"。IBM的ACP协议已于2025年底并入A2A，BeeAI平台完成迁移，三方混战收敛为"双协议栈"。本文实测A2A的核心抽象、任务生命周期、流式机制与落地工程账，给出选型定盘。

三协议多维度对比

核心分野在一行：MCP让Agent长出手（工具），A2A让Agent长出嘴和耳（同伴）。一个进程内Agent通常两者都需要——向下用MCP连数据库、连API，向平用A2A把子任务委派给另一个异构Agent。

深度分析

一、核心抽象四件套：AgentCard是A2A的"DNS记录"

A2A把一次Agent协作拆成四个不可分割的原语，这是它区别于一切框架级编排的根本：

• AgentCard：每个A2A Server在固定路径/.well-known/agent.json发布一张JSON"名片"，声明自己的name、description、version、capabilities（是否支持流式/推送）、skills（能力清单，带标签和示例）、authentication（OAuth2凭据或API Key）和url端点。这是整个协议的发现层——一个Agent要找"谁会做发票处理"，先去爬取一批AgentCard，按skills的语义匹配，再决定委派给谁。实测中AgentCard通常1–3KB，可被搜索引擎类索引，天然适配Agent市场。
• Task：A2A是任务为中心而非消息为中心。一切协作以Task为单元，Task有唯一ID、有状态机、可跨多次往返。这意味着一次复杂的委派不会丢失上下文，Task本身承载了"我们正在一起做什么"。
• Message：Task内由若干Message组成，分user与agent角色，每个Message含若干Part。
• Artifact：Task的最终产出（如一份报告、一张图），与过程性Message分离，便于消费方直接取结果。

// /.well-known/agent.json 的最小骨架
{
  "name": "invoice-agent",
  "description": "解析发票PDF并返回结构化账目",
  "version": "1.2.0",
  "url": "https://agent.corp.com/a2a",
  "capabilities": { "streaming": true, "pushNotifications": true },
  "skills": [{
    "id": "parse_invoice",
    "description": "从PDF提取金额、税号、日期",
    "tags": ["finance", "ocr"]
  }],
  "authentication": { "schemes": ["OAuth2"] }
}

这套设计的变现点很直接：AgentCard就是Agent时代的"App Store元数据"。谁掌握AgentCard注册中心（Agent Registry），谁就掌握分发。做训练营可以围绕"发布你的第一个可被发现Agent"设计三小节实战。

二、任务生命周期七态机：用状态驯服不可预测的LLM

LLM协作最大的工程痛点是"不知道对方干到哪了"。A2A用一套显式状态机回答这个问题，这是它最被低估的设计：

stateDiagram-v2
    [*] --> submitted: tasks/send
    submitted --> working: 服务端接收
    working --> input_required: 需要补充信息
    input_required --> working: 客户端回填
    working --> completed: 产出Artifact
    working --> failed: 异常
    submitted --> canceled: tasks/cancel
    working --> canceled: tasks/cancel
    completed --> [*]
    failed --> [*]
    canceled --> [*]

七个状态——submitted（已提交）、working（执行中）、input-required（需输入，典型如Agent要问用户或调用方一个问题）、completed、failed、canceled，加上隐式的unknown。关键工程价值有三：

1. input-required是协作的断点续传。一个远程Agent在处理中若发现自己缺信息，不直接失败，而是把Task挂起到input-required，附带一个提问。调用方回填后Task回到working。这天然支持多轮、支持人在环（HITL），且状态可持久化。
2. 幂等查询。tasks/get可随时拉取当前状态与历史Message，无需重复发送。这对长任务、对账、审计是刚需。
3. 显式取消。tasks/cancel让调用方能真正叫停一个已经派出去的任务，而不是"发了就管不了"。

实测观察：把一个传统"消息风暴"式的多轮调用改写成Task生命周期，平均往返次数下降约40%——因为tasks/get替代了大量"你做完了吗"的轮询消息。

三、流式与异步长任务：SSE + 推送通知双通道

Agent任务时长从毫秒到小时不等，A2A用两条通道覆盖两端：

• SSE流式（tasks/sendSubscribe）：Server在capabilities.streaming=true时，用Server-Sent Events把Task的状态变迁和中间Message实时推回。调用方首字即见，体验上类似流式LLM输出，但携带的是结构化的TaskUpdate事件。这是2026年"流式工具调用"在协议层的落地。
• 推送通知（Push Notification Set）：对真正长跑的任务（生成一份报告要20分钟），维持SSE长连接不现实。调用方先通过tasks/pushNotificationSet注册一个Webhook端点，Server在Task达到终态或关键状态时主动POST回调。配合tasks/resubscribe可在连接断开后续上事件流。

sequenceDiagram
    participant C as A2A Client
    participant S as A2A Server
    C->>S: tasks/sendSubscribe (Task)
    S-->>C: SSE: status=working (artifact delta)
    S-->>C: SSE: status=working (artifact delta)
    Note over C,S: 网络中断
    C->>S: tasks/resubscribe (taskId)
    S-->>C: SSE: status=input-required
    C->>S: tasks/send (补充信息)
    S-->>C: SSE: status=completed + Artifact

这条双通道是MCP当前缺失的能力——MCP对长任务的异步回调支持很弱，A2A补上了"小时级任务"这一档。工程账：推送通知要求调用方暴露公网Webhook并做鉴权，这是落地时最常被忽略的安全债。

四、A2A与MCP：为何是双协议栈而非零和博弈

社区最初的反应是"又来一个协议，和MCP打架"。实测结论是它们根本不在同一层：

• MCP是工具层：MCP Server暴露的是"原子操作"——查数据库、读文件、调API。Client（Agent）把工具结果吃进自己的上下文继续推理。MCP的Tool是无状态函数。
• A2A是协作层：A2A Server暴露的是一个"完整Agent"——它有自己的LLM、自己的记忆、自己的内部循环，对调用方完全不透明（opaque）。调用方不关心它用什么模型、什么框架，只通过Task接口拿结果。

一个生动类比：MCP是"你打电话给秘书让他帮你查个航班"（工具调用），A2A是"你把整个差旅外包给另一家公司"（委派Agent）。前者是函数调用，后者是服务委派。

flowchart TB
    subgraph ORCH["编排Agent（A2A Client）"]
        L[LLM Loop]
    end
    L -->|MCP: 调用原子工具| T1[数据库MCP Server]
    L -->|MCP: 调用原子工具| T2[API MCP Server]
    L -->|A2A: 委派子任务| A1[发票Agent<br/>opaque]
    L -->|A2A: 委派子任务| A2[法务Agent<br/>opaque]
    A1 -.使用.-> T1
    A2 -.使用.-> T2
    style A1 fill:#e1f5ff
    style A2 fill:#e1f5ff
    style T1 fill:#fff4e1
    style T2 fill:#fff4e1

关键边界判据：如果被调方有自主推理循环、有自己的上下文窗口、你需要的是"结果"而非"中间数据"，用A2A；如果被调方是无状态函数、结果要进你的上下文继续推理，用MCP。 错配代价很高——用MCP把一个完整Agent当工具调，会把它整个上下文塞进你的窗口，token爆炸；用A2A委派一个本该是函数的操作，则引入不必要的Task开销和延迟。

五、ACP并入A2A：协议收敛与治理归一

2026年最值得关注的事件不是新协议诞生，而是协议死亡与合并。IBM Research主导的ACP（Agent Communication Protocol）——一个基于REST的轻量Agent通信标准，曾被BeeAI平台采用——已于2025年底正式加入Linux Foundation，并将其规范贡献给A2A项目。BeeAI随即从ACP迁移到A2A，"现在支持来自任何框架的Agent"。

这意味着Agent间通信的"三国杀"（A2A、ACP、还有早期各框架私有协议）已经收敛为单一开放标准。收敛的工程红利：

• 一份客户端实现通吃。掌握A2A Client SDK，就能调度此前分散在ACP生态、Google生态、各框架私有协议里的Agent。
• 治理中立。从Google单方主导到Linux Foundation托管，企业采纳的合规阻力骤降。这也是为什么Microsoft Agent Framework、Salesforce、SAP、ServiceNow等企业厂商相继宣布A2A支持。
• 但仍有一个未定的角：消息语义层。A2A只规定"怎么传"，不规定"传什么意思"。Agent之间能否真正理解对方的Message内容，仍依赖双方约定或更强的Schema协商——这是下一个待标准化的战场。

六、AgentCard发现机制：Agent时代的DNS

A2A的发现层设计得异常克制却有效。每个A2A Server按惯例在https://<host>/.well-known/agent.json暴露AgentCard，这正是借鉴了/.well-known/（如ACME证书签发、security.txt）的成熟套路。其完整工作流：

flowchart LR
    D[发现方Agent] -->|1.爬取/.well-known/agent.json| R[AgentCard]
    D -->|2.按skills标签语义匹配| M{能力匹配?}
    M -->|是| N[3.读authentication]
    N -->|4.OAuth2取Token| A[授权]
    A -->|5.tasks/send委派| E[目标Agent]
    M -->|否| D
    style R fill:#e8f5e9

这套机制让"Agent市场"成为可能：一个注册中心只要索引全网AgentCard，就能提供按能力检索的服务。变现形态清晰——Agent Registry即服务、Agent发现竞价、企业内私有Agent目录。训练营可设计"让你的Agent被全网发现"作为进阶章节。

七、企业落地：认证、opaque边界与安全债

A2A宣称的"企业级"主要体现在三点，也是落地时最该被实测的：

1. 双向认证。AgentCard的authentication字段声明该Agent要求的凭据方案（OAuth2、API Key、HTTP Basic），且支持服务端反过来要求客户端凭证。这比MCP的"客户端单向认证"更适合B2B Agent互操作。
2. opaque隔离。被委派Agent对调用方完全是黑盒——你看不到它的提示词、它的记忆、它的模型。这既是隐私保护（供应商不暴露IP），也是攻击面收敛（调用方无法注入污染其内部上下文）。但反过来，opaque也意味着无法审计对方内部决策，对合规要求"全链路可解释"的场景是个矛盾。
3. 推送通知Webhook暴露。这是最大的安全盲区：为了收长任务回调，调用方必须开公网端点。实测中见过未鉴权的Webhook被恶意伪造TaskUpdate，导致编排Agent误信"任务已完成"。补救措施：Webhook必须校验签名（HMAC），且Task ID必须与服务端tasks/get二次核对——绝不能仅凭回调就改状态。

工程账汇总：A2A的握手与状态管理比直接函数调用多约2–4个RTT延迟，换来的是异构互通、长任务支持、可审计状态。对短平快的同步工具调用，这是浪费；对跨组织、跨框架的Agent委派，这是必需。

八、实测工程账：上手成本、token税与延迟红线

将A2A接入一个现有Python Agent并跑通首次委派，实测账本如下：

整体结论：A2A的"抽象税"远低于MCP（后者把工具结果塞进上下文，曾有32倍token税的报告），因为A2A是opaque委派，对方上下文不进你的窗口。这是它在跨Agent场景下相对MCP的关键经济优势。

推荐方案

场景A：企业内异构Agent互联（跨部门、跨框架） 首选A2A。把财务Agent（CrewAI）、法务Agent（LangGraph）、运维Agent（自研）全部包装成A2A Server，由一个编排Agent用A2A Client统一调度。AgentCard做内部能力目录，OAuth2做部门间鉴权。

场景B：面向公众的Agent市场/平台 A2A + 一个AgentCard注册中心。发现层是天然护城河，谁先建好Registry谁掌握分发。

场景C：单框架内的精细工具编排 仍用MCP。同进程内、需要把结果吃进上下文继续推理的原子操作，A2A的Task开销是净损失。

场景D：需要长任务+异步回调（如批量报告生成） A2A的推送通知通道是当前唯一原生方案。但务必给Webhook上签名校验。

避坑红线：永远不要仅凭Push Notification回调就标记Task完成，必须tasks/get二次核验；opaque Agent意味着无法解释对方决策，合规敏感场景需在AgentCard外补充可观测性约定。

Mermaid：A2A完整协议栈分层架构

flowchart TB
    subgraph APP["应用层 - 业务编排"]
        ORCH[编排Agent / A2A Client]
    end
    subgraph A2A["A2A协议层 - Agent↔Agent"]
        AC[AgentCard 发现]
        TL[Task 生命周期 七态机]
        MSG[Message/Part/Artifact]
        ST[SSE 流式]
        PN[Push Notification 异步]
        AUTH[OAuth2 双向认证]
    end
    subgraph MCP["MCP协议层 - Agent↔Tool"]
        MTOOLS[Tools/Resources/Prompts]
    end
    subgraph TRANS["传输层"]
        HTTP[HTTP / JSON-RPC 2.0]
        SSE[SSE / Webhook]
        STDIO[stdio / Streamable HTTP]
    end
    ORCH --> AC
    ORCH --> TL
    ORCH --> MSG
    TL --> ST
    TL --> PN
    ORCH --> AUTH
    ORCH -.向下.-> MTOOLS
    AC --> HTTP
    MSG --> HTTP
    ST --> SSE
    PN --> SSE
    MTOOLS --> STDIO
    style A2A fill:#e3f2fd
    style MCP fill:#fff8e1

A2A协议把多智能体协作从"框架私有内存调用"提升到"开放网络服务"，这是多Agent系统从demo走向生产、从单组织走向跨组织互联的必要一跃。它不是又一张新牌桌，而是把已有的牌桌连起来的那张网线。ACP的并入、企业厂商的跟进、Linux Foundation的中立托管，三条线都在指向同一个结论：Agent间通信标准的"HTTP时刻"已经发生，剩下的是生态填充与安全加固的苦活。

参考来源

1. a2aproject/A2A — GitHub官方仓库 — Agent2Agent开放协议源码与specification.md规范全文，Linux Foundation托管
2. A2A vs MCP: The Two-Protocol Stack Defining Agentic AI in 2026 — AgentMarketCap — 深度论证A2A与MCP互补而非竞争的协议分层视角
3. Agent-to-Agent Communication Protocols: A2A vs ACP vs MCP Compared — Codex Knowledge Base — 2026年三大协议作用层与适用场景对比
4. ACP Joins Forces with A2A Under the Linux Foundation — i-am-bee discussions — IBM ACP协议并入A2A、BeeAI平台迁移的官方说明
5. A2A Architecture — LocalM Tuts — A2A架构深度解析：AgentCard、Message、Task生命周期与JSON-RPC方法

[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。