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 成立 AAIF | MCP、A2A 等项目获得统一治理 |
| 2026 年 | A2A v1.0 稳定版发布 | 协议进入生产成熟期 |
2. A2A 核心架构
设计原则
A2A 协议基于五大设计原则:
- 拥抱 Agent 能力:Agent 以自然、非结构化的方式协作,无需共享内存、工具或内部上下文
- 基于现有标准:使用 HTTP、SSE 和 JSON-RPC——与现有基础设施无缝集成
- 默认安全:内置认证、授权和零信任架构模式支持
- 支持长时间运行任务:任务可运行数小时甚至数天,支持流式进度更新和推送通知
- 模态无关:支持文本、文件、结构化数据,可扩展到音频和视频流
架构概览
┌─────────────────────────────────────────────────────┐
│ A2A 协议架构 │
│ │
│ ┌──────────┐ HTTP/JSON-RPC ┌──────────┐ │
│ │ Client │◄──────────────────►│ Remote │ │
│ │ Agent │ │ Agent │ │
│ │ │ SSE (流式) │ │ │
│ │ ┌──────┐ │◄────────────────── │ ┌──────┐ │ │
│ │ │ MCP │ │ │ │ MCP │ │ │
│ │ │Tools │ │ Push Notification │ │Tools │ │ │
│ │ └──────┘ │◄────────────────── │ └──────┘ │ │
│ └──────────┘ └──────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────┐ │
│ │Agent Card│ │Agent Card│ │
│ │(发现) │ │(发现) │ │
│ └──────────┘ └──────────┘ │
└─────────────────────────────────────────────────────┘核心概念一览
| 概念 | 说明 | 类比 |
|---|---|---|
| Agent Card | JSON 元数据文档,描述 Agent 的能力、认证要求和交互模式 | 数字名片 |
| Task(任务) | 工作单元,具有完整生命周期:submitted → working → completed/failed | HTTP 请求的增强版 |
| 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 |
working | Agent 正在处理任务 | Agent 开始执行 |
input-required | Agent 需要额外输入才能继续 | 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 │
└─────────────────────────────────────────────┘核心差异对比
| 维度 | MCP | A2A |
|---|---|---|
| 集成方向 | 垂直:AI 模型 → 工具/数据 | 水平:Agent → Agent |
| 核心类比 | AI 的 USB 接口 | AI Agent 的 HTTP |
| 创建者 | Anthropic | |
| 架构模式 | 客户端-服务器 | 对等通信 |
| 关键抽象 | Tools、Resources、Prompts | Agent 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 | 开放标准治理、社区协作、中立仲裁 | 防止厂商锁定,确保标准开放演进 |
| 协作层 | A2A | Agent 发现、通信、任务委托 | 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 双协议架构的几个关键优势:
- 关注点分离:每个 Agent 专注自己的领域,通过标准协议协作
- 跨组织协作:物流和支付 Agent 由第三方运营,通过 A2A 标准接口集成
- 灵活替换:更换物流合作方只需更新 Agent Card URL,无需修改业务逻辑
- 安全隔离:每个 Agent 通过 OAuth 独立认证,遵循最小权限原则
避坑指南
❌ 常见错误
-
把 A2A 当成 MCP 的替代品
- 问题:试图用 A2A 解决工具集成问题,或用 MCP 解决 Agent 间通信问题
- 正确做法:MCP 用于垂直集成(Agent → 工具/数据),A2A 用于水平协作(Agent → Agent),两者互补使用
-
忽略 Agent Card 的安全声明
- 问题:Agent Card 是自声明的,直接信任未验证的第三方 Agent Card
- 正确做法:在跨组织场景中,通过 Agent Gateway 统一管控外部 Agent 的接入,验证 Agent 身份和能力声明
-
在简单场景中过度使用 A2A
- 问题:只有 2-3 个内部 Agent 且紧密耦合时,仍然引入完整的 A2A 协议栈
- 正确做法:内部紧耦合 Agent 可以直接使用框架内置的通信机制(如 LangGraph 的状态图),A2A 更适合跨组织、跨框架的松耦合场景
-
忽视长时间运行任务的错误处理
- 问题:假设所有 A2A 任务都会快速完成,没有处理超时、重试和失败恢复
- 正确做法:为长时间运行任务实现完整的错误处理——设置超时、配置重试策略、处理
failed和cancelled状态
-
跨域认证链路中的 Token 泄露风险
- 问题:在多跳 Agent 链中(Agent 1 → Agent 2 → Agent 3),中间 Agent 可能滥用委托的 Token
- 正确做法:使用 OBO 模式限制 Token 范围,每一跳都重新申请最小权限的 Token;考虑使用 DPoP(Demonstrating Proof of Possession)绑定 Token 到密钥对
✅ 最佳实践
- 从 Agent Card 设计开始:在编写任何代码之前,先设计好 Agent Card——明确 Agent 的技能、输入输出模式和认证要求
- MCP + A2A 分层使用:工具和数据访问用 MCP,Agent 间协作用 A2A,不要混淆两者的职责
- 使用 Agent Gateway 管控外部 Agent:在企业环境中,通过网关统一管理外部 A2A Agent 的接入、认证和审计
- 为长时间任务设计完整的状态处理:处理所有可能的任务状态(working、input-required、failed、cancelled),不要只关注 completed
- 渐进式采用:先在内部 Agent 间使用 A2A,验证可行后再扩展到跨组织场景
相关资源与延伸阅读
- A2A 协议官方规范 — A2A 协议的完整技术规范和教程
- Google ADK 文档 — Google Agent Development Kit 官方文档,包含 A2A 集成指南
- MCP 协议官方规范 — Model Context Protocol 完整规范,理解 A2A 的互补协议
- AAIF 官方公告 — Linux Foundation 成立 Agentic AI Foundation 的官方新闻
- A2A GitHub 仓库 — A2A 协议源码和示例代码
- AgentGateway — 支持 A2A 和 MCP 的统一 Agent 网关
- MCP vs A2A 完整指南 — 两大协议的详细对比和协同使用指南
- 详见 08a-MCP概念入门 了解 MCP 协议基础
- 详见 10a-多Agent协作概述 了解多 Agent 协作的整体背景
- 详见 10b-框架对比 了解主流多 Agent 框架的选择
参考来源
- Google A2A Protocol Official Announcement — Google 官方发布 A2A 协议(2025 年 4 月)
- A2A Protocol Specification (2025 年 4 月发布,持续更新)
- Linux Foundation Announces AAIF (2025 年 12 月)
- MCP vs A2A: The Complete Guide to AI Agent Protocols in 2026 (2026 年 2 月)
- Understanding A2A: Google’s Agent-to-Agent Protocol Explained (2025 年)
- A2A Protocol Agent Card Specification (2025 年)
- An Engineer’s Guide to Google’s A2A Protocol — WorkOS (2025 年 4 月)
- How to Enhance Agent2Agent Security — Red Hat (2025 年 8 月)
- Agentic AI Production 2026: Interoperability Guide (2026 年 1 月)
- Amazon Bedrock AgentCore A2A Protocol Contract (2025 年)
📖 返回 总览与导航 | 上一节:10b-框架对比 | 下一节:10d-Agent通信模式