Skip to Content

10c - A2A 协议详解

本文是《AI Agent 实战手册》第 10 章第 3 节。 上一节:10b-框架对比 | 下一节:10d-Agent通信模式

概述

当多个 AI Agent 需要跨框架、跨厂商协作时,缺乏统一通信标准是最大的障碍。Google 于 2025 年 4 月在 Cloud NEXT 2025 大会上发布了 Agent-to-Agent(A2A)协议——一个开放的互操作性标准,让不同平台构建的 Agent 能够相互发现、认证和协作。本节将系统讲解 A2A 协议的架构设计、Agent Card 规范、任务生命周期、与 MCP 的互补关系,以及 A2A + MCP + AAIF 如何共同构成 2026 年 Agent 互操作性技术栈。


1. A2A 协议背景与动机

为什么需要 A2A

在 A2A 出现之前,连接不同 AI 系统需要为每种组合编写定制集成。10 个 AI 应用和 100 个工具意味着可能需要 1,000 种不同的集成——这就是”M × N 问题”。每个 AI 厂商都构建了自己的工具调用系统(OpenAI 的 GPT Actions、Anthropic 的 Tool Use、Google 的 Function Calling),彼此不兼容。

工具推荐

工具用途价格适用场景
Google ADK A2A 协议的官方参考实现框架免费(开源)构建和部署 A2A Agent
a2a-protocol.org A2A 协议官方规范和文档免费(开源)协议学习和参考
Amazon Bedrock AgentCore AWS 的 A2A 协议集成运行时按使用量计费企业级 A2A 部署
AgentGateway A2A/MCP 统一网关免费(开源)多协议统一接入和安全管控

A2A 协议关键里程碑

时间事件意义
2025 年 4 月Google 在 Cloud NEXT 2025 发布 A2A首个 Agent 间通信开放标准诞生
2025 年 6 月A2A 捐赠给 Linux Foundation从厂商项目转为社区治理
2025 年 9 月IBM ACP 协议合并入 A2A行业整合,减少碎片化
2025 年 12 月Linux Foundation 成立 AAIFMCP、A2A 等项目获得统一治理
2026 年A2A v1.0 稳定版发布协议进入生产成熟期

2. A2A 核心架构

设计原则

A2A 协议基于五大设计原则:

  1. 拥抱 Agent 能力:Agent 以自然、非结构化的方式协作,无需共享内存、工具或内部上下文
  2. 基于现有标准:使用 HTTP、SSE 和 JSON-RPC——与现有基础设施无缝集成
  3. 默认安全:内置认证、授权和零信任架构模式支持
  4. 支持长时间运行任务:任务可运行数小时甚至数天,支持流式进度更新和推送通知
  5. 模态无关:支持文本、文件、结构化数据,可扩展到音频和视频流

架构概览

┌─────────────────────────────────────────────────────┐ │ A2A 协议架构 │ │ │ │ ┌──────────┐ HTTP/JSON-RPC ┌──────────┐ │ │ │ Client │◄──────────────────►│ Remote │ │ │ │ Agent │ │ Agent │ │ │ │ │ SSE (流式) │ │ │ │ │ ┌──────┐ │◄────────────────── │ ┌──────┐ │ │ │ │ │ MCP │ │ │ │ MCP │ │ │ │ │ │Tools │ │ Push Notification │ │Tools │ │ │ │ │ └──────┘ │◄────────────────── │ └──────┘ │ │ │ └──────────┘ └──────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ │ │ │Agent Card│ │Agent Card│ │ │ │(发现) │ │(发现) │ │ │ └──────────┘ └──────────┘ │ └─────────────────────────────────────────────────────┘

核心概念一览

概念说明类比
Agent CardJSON 元数据文档,描述 Agent 的能力、认证要求和交互模式数字名片
Task(任务)工作单元,具有完整生命周期:submitted → working → completed/failedHTTP 请求的增强版
Message(消息)任务执行期间 Agent 之间交换的通信单元对话中的一条消息
Part(部分)消息中的内容载体,支持文本、文件附件和结构化数据邮件中的附件
Artifact(产物)任务执行产生的输出结果工作交付物

3. Agent Card 详解

什么是 Agent Card

Agent Card 是 A2A 协议的核心发现机制——每个 A2A Agent 发布一个 JSON 文档,描述自己能做什么以及如何与之交互。它类似于 OpenAPI 规范对 REST API 的作用,但面向的是 Agent。

Agent Card 发现方式

  • Well-Known URL/.well-known/agent.json(标准发现端点)
  • 直接 URL:已知 Agent 的具体地址
  • 注册中心查找:通过 Agent 注册表搜索

Agent Card 结构示例

{ "name": "Travel Booking Agent", "description": "搜索并预订航班和酒店", "url": "https://travel-agent.example.com", "version": "1.0.0", "defaultInputModes": ["text/plain"], "defaultOutputModes": ["text/plain", "application/json"], "capabilities": { "streaming": true, "pushNotifications": true, "stateTransitionHistory": true }, "skills": [ { "id": "book-flight", "name": "Book Flight", "description": "搜索并预订航班", "tags": ["travel", "flight", "booking"], "examples": ["帮我订一张从北京到上海的机票", "查询明天的航班"] }, { "id": "book-hotel", "name": "Book Hotel", "description": "搜索并预订酒店", "tags": ["travel", "hotel", "booking"], "examples": ["帮我在上海找一家酒店"] } ], "securitySchemes": { "oauth2": { "type": "oauth2", "flows": { "clientCredentials": { "tokenUrl": "https://auth.example.com/token", "scopes": { "agent:invoke": "调用 Agent 服务" } } } } }, "supportsAuthenticatedExtendedCard": true }

Agent Card 关键字段说明

字段必填说明
nameAgent 名称
descriptionAgent 功能描述
urlA2A 服务端点 URL
versionAgent 版本号
skillsAgent 技能列表(AgentSkill 数组)
capabilities支持的 A2A 特性(streaming、pushNotifications 等)
defaultInputModes默认输入 MIME 类型
defaultOutputModes默认输出 MIME 类型
securitySchemes认证方案(OAuth 2.0、API Key 等)
supportsAuthenticatedExtendedCard是否支持认证后获取扩展 Card

⚠️ 注意:Agent Card 是自声明的——Agent 声称自己的能力,协议本身不提供验证机制。在跨组织场景中,需要额外的信任机制(如 Verifiable Credentials)来验证 Agent 声明的真实性。


4. 任务生命周期

任务状态机

A2A 中的任务(Task)是 Agent 间协作的核心抽象。与简单的 API 调用不同,任务建模了需要时间、可能需要来回交互的真实工作。

┌──────────┐ │SUBMITTED │ ← 客户端创建任务 └────┬─────┘ ┌────▼─────┐ ┌────►│ WORKING │◄────┐ │ └────┬─────┘ │ │ │ │ │ ┌─────▼──────┐ │ │ │ INPUT │ │ └────┤ REQUIRED ├────┘ └─────┬──────┘ ┌─────────────┼─────────────┐ │ │ │ ┌─────▼────┐ ┌────▼─────┐ ┌────▼──────┐ │COMPLETED │ │ FAILED │ │ CANCELLED │ └──────────┘ └──────────┘ └───────────┘ ┌─────▼──────┐ │ REJECTED │ └────────────┘

任务状态详解

状态说明触发条件
submitted任务已提交,等待处理客户端发送 tasks/sendtasks/sendSubscribe
workingAgent 正在处理任务Agent 开始执行
input-requiredAgent 需要额外输入才能继续Agent 遇到需要人工确认或补充信息的情况
auth-required需要额外认证Agent 需要访问受保护资源
completed任务成功完成Agent 完成所有工作并返回结果
failed任务执行失败发生不可恢复的错误
cancelled任务被取消客户端主动取消
rejected任务被拒绝Agent 无法或不愿处理该任务

任务交互模式

A2A 支持三种任务交互模式:

1. 同步请求-响应(短任务)

Client Remote Agent │ │ │── POST /tasks/send ────────────►│ │ │ (处理) │◄── 200 OK + Task(completed) ────│ │ │

2. 流式更新(SSE)

Client Remote Agent │ │ │── POST /tasks/sendSubscribe ───►│ │ │ │◄── SSE: status=working ─────────│ │◄── SSE: artifact(部分结果) ─────│ │◄── SSE: artifact(更多结果) ─────│ │◄── SSE: status=completed ───────│ │ │

3. 推送通知(长时间运行任务)

Client Remote Agent │ │ │── POST /tasks/send ────────────►│ │◄── 200 OK + Task(submitted) ────│ │ │ (长时间处理...) │ │ │◄── Push: status=working ────────│ │◄── Push: status=completed ──────│ │ │ │── GET /tasks/{id} ─────────────►│ │◄── 200 OK + Task + Artifacts ───│ │ │

5. A2A 认证与安全

认证机制

A2A 不重新发明认证,而是委托给现有标准。Agent Card 的 securitySchemes 字段声明所需的认证方式:

认证方式适用场景说明
OAuth 2.0企业级 Agent 间通信支持 Client Credentials 和 Authorization Code 流程
OpenID Connect需要用户身份传递的场景在 OAuth 基础上增加身份层
API Key简单的服务间调用适合内部或低安全要求场景
HTTP Basic/Bearer通用认证标准 HTTP 认证头
mTLS高安全要求的双向认证双方都需要证书

On-Behalf-Of(OBO)模式

当 Agent 代表用户行动时,推荐使用 Token Exchange(RFC 8693)的 OBO 模式:

用户 ──登录──► Agent 1 ──OBO Token Exchange──► Auth Server 签发新 Token (sub=alice, act=agent1) Agent 2 ◄──── 携带 OBO Token ───────┘ ├── 知道是 Alice 发起的请求 ├── 知道是通过 Agent 1 转发的 └── 可以执行用户级别的权限控制

操作步骤

步骤 1:发布 Agent Card

在你的 Agent 服务中,配置 /.well-known/agent.json 端点返回 Agent Card:

from a2a.types import AgentCard, AgentSkill, AgentCapabilities skill = AgentSkill( id="data-analysis", name="数据分析", description="分析数据集并生成可视化报告", tags=["data", "analysis", "visualization"], examples=["分析这份销售数据", "生成月度报告"], ) agent_card = AgentCard( name="Data Analysis Agent", description="专业数据分析 Agent", url="https://data-agent.example.com", version="1.0.0", default_input_modes=["text", "application/json"], default_output_modes=["text", "application/json", "image/png"], capabilities=AgentCapabilities( streaming=True, push_notifications=True, ), skills=[skill], )

步骤 2:实现任务处理

from a2a.server import A2AServer, TaskHandler from a2a.types import Task, TaskState, Message, Part class DataAnalysisHandler(TaskHandler): async def handle_task(self, task: Task) -> Task: # 更新状态为 working task.state = TaskState.WORKING await self.send_update(task) # 解析用户请求 user_message = task.messages[-1] query = user_message.parts[0].text # 执行分析(通过 MCP 访问数据源) result = await self.analyze_data(query) # 返回结果 task.artifacts = [result] task.state = TaskState.COMPLETED return task # 启动 A2A 服务 server = A2AServer( agent_card=agent_card, handler=DataAnalysisHandler(), port=9999, ) server.start()

步骤 3:作为客户端调用远程 Agent

from a2a.client import A2AClient # 发现远程 Agent client = A2AClient() card = await client.discover("https://travel-agent.example.com") print(f"Agent: {card.name}") print(f"Skills: {[s.name for s in card.skills]}") # 发送任务 task = await client.send_task( url=card.url, message="帮我查询明天从北京到上海的航班", ) # 流式接收结果 async for update in client.subscribe_task(task.id): if update.state == "working": print(f"处理中... {update.progress}") elif update.state == "completed": for artifact in update.artifacts: print(f"结果: {artifact}")

提示词模板

你是一个 A2A 协议集成专家。请帮我设计一个多 Agent 系统的 A2A 集成方案。 系统需求: - 参与的 Agent 类型:[列出 Agent 及其职责] - 通信模式:[同步/异步/流式] - 安全要求:[认证方式、数据敏感度] - 部署环境:[云平台、内部网络] 请提供: 1. 每个 Agent 的 Agent Card 设计 2. 任务流转的状态机设计 3. 认证方案选择和配置 4. 错误处理和重试策略 5. 监控和可观测性方案

6. A2A 与 MCP 的关系

互补而非竞争

2025 年行业已经明确:A2A 和 MCP 不是竞争关系,而是同一技术栈的互补层。

┌─────────────────────────────────────────────┐ │ 应用层 / 用户界面 │ ├─────────────────────────────────────────────┤ │ │ │ A2A 协议层(水平协作) │ │ Agent ◄──────────────► Agent │ │ "Agent 之间如何协作" │ │ │ ├─────────────────────────────────────────────┤ │ │ │ MCP 协议层(垂直集成) │ │ Agent ◄──────────────► Tools/Data │ │ "Agent 如何访问工具和数据" │ │ │ ├─────────────────────────────────────────────┤ │ 基础设施层 │ │ HTTP / SSE / JSON-RPC │ └─────────────────────────────────────────────┘

核心差异对比

维度MCPA2A
集成方向垂直:AI 模型 → 工具/数据水平:Agent → Agent
核心类比AI 的 USB 接口AI Agent 的 HTTP
创建者AnthropicGoogle
架构模式客户端-服务器对等通信
关键抽象Tools、Resources、PromptsAgent Cards、Tasks、Messages
传输协议stdio(本地)、Streamable HTTP(远程)HTTP + SSE、Push Notifications
认证OAuth 2.1、OIDC Discovery可插拔认证、零信任模式
长时间任务实验性 Tasks(轮询 + 延迟结果)一等公民支持(完整生命周期 + 流式)
发现机制Server 注册表、配置文件Agent Card(/.well-known/agent.json
生态规模10,000+ Server通过 ADK 快速增长

双协议协作示例

以企业客服系统为例,展示 MCP 和 A2A 如何协同工作:

客户提交复杂工单 ┌──────────────┐ │ 客服 Agent │──── MCP ────► CRM 数据库 │ │──── MCP ────► 订单系统 │ │──── MCP ────► 知识库 └──────┬───────┘ │ 需要技术诊断(A2A 委托) ┌──────────────┐ │ 诊断 Agent │──── MCP ────► 系统日志 │ │──── MCP ────► 监控面板 └──────┬───────┘ │ 发现计费问题(A2A 委托) ┌──────────────┐ │ 计费 Agent │──── MCP ────► 支付系统 │ │ └──────┬───────┘ │ 结果通过 A2A 回传 客户收到解决方案

Google ADK 双协议集成

Google ADK 原生支持在同一个 Agent 中同时使用 MCP 和 A2A:

from google.adk import Agent from google.adk.tools import MCPTool from google.adk.a2a import RemoteAgent agent = Agent( name="project-manager", description="项目管理协调 Agent", # MCP 工具:直接访问数据 tools=[ MCPTool(server="database-server"), MCPTool(server="calendar-server"), ], # A2A 远程 Agent:委托专业任务 remote_agents=[ RemoteAgent(url="https://research.example.com"), RemoteAgent(url="https://analytics.example.com"), ], ) # 该 Agent 现在可以: # - 通过 MCP 查询数据库 # - 通过 MCP 检查日历 # - 通过 A2A 委托研究任务给专业 Agent # - 通过 A2A 请求分析 Agent 生成报告

7. A2A + MCP + AAIF 互操作性栈

AAIF:统一治理层

2025 年 12 月,Linux Foundation 宣布成立 Agentic AI Foundation(AAIF),由 Anthropic、Block 和 OpenAI 联合创始贡献。AAIF 的核心项目包括:

  • MCP(Anthropic 贡献):Agent 到工具/数据的连接标准
  • goose(Block 贡献):开源 AI Agent 框架
  • AGENTS.md(OpenAI 贡献):Agent 行为描述标准

三层互操作性栈

┌─────────────────────────────────────────────────┐ │ │ │ AAIF(Agentic AI Foundation) │ │ ┌─────────────────────────────────────────┐ │ │ │ 治理层:开放标准、社区协作、中立治理 │ │ │ │ 项目:MCP、goose、AGENTS.md 等 │ │ │ └─────────────────────────────────────────┘ │ │ │ │ ┌──────────────────┐ ┌──────────────────┐ │ │ │ A2A 协议 │ │ ACP/ANP 等 │ │ │ │ Agent 间通信 │ │ 补充协议 │ │ │ │ (水平协作层) │ │ │ │ │ └──────────────────┘ └──────────────────┘ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ MCP 协议 │ │ │ │ Agent 到工具/数据连接(垂直集成层) │ │ │ └─────────────────────────────────────────┘ │ │ │ │ ┌─────────────────────────────────────────┐ │ │ │ 基础设施:HTTP、SSE、JSON-RPC、OAuth │ │ │ └─────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────┘

各层职责

层级协议/组织职责解决的问题
治理层AAIF开放标准治理、社区协作、中立仲裁防止厂商锁定,确保标准开放演进
协作层A2AAgent 发现、通信、任务委托Agent 之间如何找到彼此并协作
集成层MCP工具连接、数据访问、资源暴露Agent 如何访问外部工具和数据
基础设施层HTTP/SSE/JSON-RPC传输、序列化、认证底层通信和安全

为什么需要三层

单独使用任何一层都不够:

  • 只有 MCP:Agent 能访问工具,但不能与其他 Agent 协作
  • 只有 A2A:Agent 能互相通信,但各自无法标准化地访问工具
  • 没有 AAIF:协议可能走向碎片化,缺乏中立治理
  • 三层结合:Agent 既能访问工具(MCP),又能互相协作(A2A),且在开放治理下持续演进(AAIF)

实战案例:构建跨组织多 Agent 协作系统

场景描述

一家电商公司需要构建一个智能客服系统,涉及三个独立团队的 Agent:

  • 客服团队:客户交互 Agent(内部开发)
  • 物流合作方:物流查询 Agent(第三方服务)
  • 支付合作方:退款处理 Agent(第三方服务)

架构设计

# 1. 客服 Agent(协调者) from google.adk import Agent from google.adk.tools import MCPTool from google.adk.a2a import RemoteAgent customer_service_agent = Agent( name="customer-service", description="处理客户咨询、投诉和退款请求", # 内部工具(MCP) tools=[ MCPTool(server="crm-server"), # 客户关系管理 MCPTool(server="order-server"), # 订单查询 MCPTool(server="knowledge-base"), # 知识库 ], # 外部 Agent(A2A) remote_agents=[ RemoteAgent( url="https://logistics-partner.com", auth={"type": "oauth2", "client_id": "..."} ), RemoteAgent( url="https://payment-partner.com", auth={"type": "oauth2", "client_id": "..."} ), ], )
# 2. 物流 Agent 的 Agent Card(第三方发布) logistics_card = { "name": "Logistics Tracking Agent", "description": "实时物流追踪和配送状态查询", "url": "https://logistics-partner.com/a2a", "version": "2.1.0", "skills": [ { "id": "track-package", "name": "包裹追踪", "description": "根据订单号查询物流状态", "tags": ["logistics", "tracking"], }, { "id": "estimate-delivery", "name": "预计送达", "description": "预估包裹送达时间", "tags": ["logistics", "delivery", "estimate"], } ], "capabilities": {"streaming": True}, "securitySchemes": { "oauth2": { "type": "oauth2", "flows": { "clientCredentials": { "tokenUrl": "https://auth.logistics-partner.com/token", "scopes": {"tracking:read": "查询物流信息"} } } } } }
# 3. 完整的任务流转 async def handle_refund_request(customer_query: str): """处理退款请求的完整 A2A 流程""" # Step 1: 客服 Agent 通过 MCP 查询订单 order = await crm_tool.query(customer_query) # Step 2: 通过 A2A 查询物流状态 logistics_task = await a2a_client.send_task( url="https://logistics-partner.com/a2a", message=f"查询订单 {order.id} 的物流状态", ) # Step 3: 根据物流状态决定是否退款 if logistics_task.artifacts[0].data["status"] == "delivered": # Step 4: 通过 A2A 发起退款 refund_task = await a2a_client.send_task( url="https://payment-partner.com/a2a", message=f"为订单 {order.id} 发起退款,金额 {order.amount}", ) # Step 5: 流式跟踪退款进度 async for update in a2a_client.subscribe_task(refund_task.id): if update.state == "completed": return f"退款成功:{update.artifacts[0].data}" elif update.state == "input-required": # 需要额外验证 return "需要客户提供额外验证信息" return "物流显示未签收,暂不支持退款"

案例分析

这个案例展示了 A2A + MCP 双协议架构的几个关键优势:

  1. 关注点分离:每个 Agent 专注自己的领域,通过标准协议协作
  2. 跨组织协作:物流和支付 Agent 由第三方运营,通过 A2A 标准接口集成
  3. 灵活替换:更换物流合作方只需更新 Agent Card URL,无需修改业务逻辑
  4. 安全隔离:每个 Agent 通过 OAuth 独立认证,遵循最小权限原则

避坑指南

❌ 常见错误

  1. 把 A2A 当成 MCP 的替代品

    • 问题:试图用 A2A 解决工具集成问题,或用 MCP 解决 Agent 间通信问题
    • 正确做法:MCP 用于垂直集成(Agent → 工具/数据),A2A 用于水平协作(Agent → Agent),两者互补使用
  2. 忽略 Agent Card 的安全声明

    • 问题:Agent Card 是自声明的,直接信任未验证的第三方 Agent Card
    • 正确做法:在跨组织场景中,通过 Agent Gateway 统一管控外部 Agent 的接入,验证 Agent 身份和能力声明
  3. 在简单场景中过度使用 A2A

    • 问题:只有 2-3 个内部 Agent 且紧密耦合时,仍然引入完整的 A2A 协议栈
    • 正确做法:内部紧耦合 Agent 可以直接使用框架内置的通信机制(如 LangGraph 的状态图),A2A 更适合跨组织、跨框架的松耦合场景
  4. 忽视长时间运行任务的错误处理

    • 问题:假设所有 A2A 任务都会快速完成,没有处理超时、重试和失败恢复
    • 正确做法:为长时间运行任务实现完整的错误处理——设置超时、配置重试策略、处理 failedcancelled 状态
  5. 跨域认证链路中的 Token 泄露风险

    • 问题:在多跳 Agent 链中(Agent 1 → Agent 2 → Agent 3),中间 Agent 可能滥用委托的 Token
    • 正确做法:使用 OBO 模式限制 Token 范围,每一跳都重新申请最小权限的 Token;考虑使用 DPoP(Demonstrating Proof of Possession)绑定 Token 到密钥对

✅ 最佳实践

  1. 从 Agent Card 设计开始:在编写任何代码之前,先设计好 Agent Card——明确 Agent 的技能、输入输出模式和认证要求
  2. MCP + A2A 分层使用:工具和数据访问用 MCP,Agent 间协作用 A2A,不要混淆两者的职责
  3. 使用 Agent Gateway 管控外部 Agent:在企业环境中,通过网关统一管理外部 A2A Agent 的接入、认证和审计
  4. 为长时间任务设计完整的状态处理:处理所有可能的任务状态(working、input-required、failed、cancelled),不要只关注 completed
  5. 渐进式采用:先在内部 Agent 间使用 A2A,验证可行后再扩展到跨组织场景

相关资源与延伸阅读

  1. A2A 协议官方规范  — A2A 协议的完整技术规范和教程
  2. Google ADK 文档  — Google Agent Development Kit 官方文档,包含 A2A 集成指南
  3. MCP 协议官方规范  — Model Context Protocol 完整规范,理解 A2A 的互补协议
  4. AAIF 官方公告  — Linux Foundation 成立 Agentic AI Foundation 的官方新闻
  5. A2A GitHub 仓库  — A2A 协议源码和示例代码
  6. AgentGateway  — 支持 A2A 和 MCP 的统一 Agent 网关
  7. MCP vs A2A 完整指南  — 两大协议的详细对比和协同使用指南
  8. 详见 08a-MCP概念入门 了解 MCP 协议基础
  9. 详见 10a-多Agent协作概述 了解多 Agent 协作的整体背景
  10. 详见 10b-框架对比 了解主流多 Agent 框架的选择

参考来源


📖 返回 总览与导航 | 上一节:10b-框架对比 | 下一节:10d-Agent通信模式

Last updated on