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 关键字段说明

字段必填说明
name✅Agent 名称
description✅Agent 功能描述
url✅A2A 服务端点 URL
version✅Agent 版本号
skills✅Agent 技能列表(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/send 或 tasks/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 任务都会快速完成,没有处理超时、重试和失败恢复
    • 正确做法:为长时间运行任务实现完整的错误处理——设置超时、配置重试策略、处理 failed 和 cancelled 状态
  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