2025 年 4 月,Google Cloud 在 Google Cloud Next 2025 大会上正式发布了 A2A(Agent-to-Agent)协议。短短一年间,这个开源协议已从初始版本演进到 v1.0 稳定版,获得超过 150 家组织的生产级采用,被 AWS Bedrock、Azure AI Foundry、Google Vertex AI 三大云平台原生集成,并交由 Linux 基金会旗下的 Agentic AI Foundation(AAIF)治理。本文将从协议起源、核心概念、架构设计、与 MCP 的关系、代码实战、生产级部署到行业应用,全方位拆解 A2A 协议。
目录
- [一、为什么需要 A2A:智能体协作的痛点](#一、为什么需要 A2A:智能体协作的痛点)
- [二、A2A 协议的诞生与发展历程](#二、A2A 协议的诞生与发展历程)
- [三、A2A 核心概念深度解析](#三、A2A 核心概念深度解析)
- [3.1 Agent Card:智能体的"电子名片"](#3.1 Agent Card:智能体的"电子名片")
- [3.2 Task:带状态机的工作单元](#3.2 Task:带状态机的工作单元)
- [3.3 Message:智能体间的对话载体](#3.3 Message:智能体间的对话载体)
- [3.4 Artifact:任务的最终交付物](#3.4 Artifact:任务的最终交付物)
- [3.5 Transport:通信传输层](#3.5 Transport:通信传输层)
- [四、A2A 协议架构与完整工作流程](#四、A2A 协议架构与完整工作流程)
- [五、A2A vs MCP:互补而非竞争](#五、A2A vs MCP:互补而非竞争)
- 六、四大多智能体协作编排模式
- [七、代码实战:从零构建 A2A 服务端与客户端](#七、代码实战:从零构建 A2A 服务端与客户端)
- [7.1 环境准备与依赖安装](#7.1 环境准备与依赖安装)
- [7.2 构建 A2A 服务端(Agent Server)](#7.2 构建 A2A 服务端(Agent Server))
- [7.3 构建 A2A 客户端(Agent Client)](#7.3 构建 A2A 客户端(Agent Client))
- [7.4 流式响应与多轮交互](#7.4 流式响应与多轮交互)
- [7.5 完整电商订单履约多 Agent 协作案例](#7.5 完整电商订单履约多 Agent 协作案例)
- 八、生产级部署:安全、可观测与高可用
- [8.1 安全体系:OAuth 2.1、TLS 与最小权限](#8.1 安全体系:OAuth 2.1、TLS 与最小权限)
- [8.2 Kubernetes 部署架构](#8.2 Kubernetes 部署架构)
- [8.3 可观测性:日志、指标与链路追踪](#8.3 可观测性:日志、指标与链路追踪)
- [8.4 生产环境常见故障与应对](#8.4 生产环境常见故障与应对)
- 九、行业应用场景与真实案例
- [十、A2A 生态系统全景](#十、A2A 生态系统全景)
- [十一、常见问题 FAQ](#十一、常见问题 FAQ)
- 十二、总结与展望
- 参考资料
一、为什么需要 A2A:智能体协作的痛点
在深入 A2A 协议之前,我们先回答一个根本问题:为什么 AI Agent 之间需要一个专门的通信协议?
1.1 单智能体时代的局限
2023-2024 年,AI 应用开发的主流范式是"单 Agent + 工具调用"。开发者使用 LangChain、LlamaIndex 等框架,将一个大语言模型(LLM)与若干工具(数据库查询、API 调用、文件读写)组合起来,构建能够完成特定任务的智能体。
这种模式在简单场景下工作良好,但随着业务复杂度提升,问题逐渐暴露:
- 能力边界受限:单个 Agent 不可能精通所有领域。一个擅长代码审查的 Agent 未必懂财务分析,一个擅长客服对话的 Agent 未必能做数据挖掘。
- 上下文窗口瓶颈:将所有领域知识和工具描述塞进一个 Agent 的 System Prompt,会迅速耗尽 LLM 的上下文窗口,导致注意力分散和性能下降。
- 团队协作缺失:现实中的复杂任务(如"完成一次完整的市场调研并生成报告")天然需要多个专业角色协作,单 Agent 难以模拟这种分工。
- 跨组织协作不可能:企业 A 用 LangChain 构建了销售 Agent,企业 B 用 AutoGen 构建了物流 Agent,两者之间没有标准接口,无法直接对话。
1.2 早期多智能体方案的困境
为了解决这些问题,社区涌现了一批多智能体框架:AutoGen、CrewAI、MetaGPT、LangGraph 等。这些框架各有特色,但存在一个共同缺陷:框架锁定。
- AutoGen 的 Agent 只能和 AutoGen 的 Agent 对话;
- CrewAI 的 Crew 成员只能在 CrewAI 生态内协作;
- 不同框架之间的 Agent 互操作性为零,集成需要编写大量定制化"胶水代码"。
这就像互联网诞生之前,每个计算机厂商都有自己的网络协议,IBM 的机器无法和 DEC 的机器直接通信。直到 TCP/IP 成为统一标准,互联网才真正爆发。
A2A 协议要做的,就是 AI Agent 世界的 TCP/IP。
1.3 A2A 要解决的核心问题
A2A 协议的设计目标可以概括为四点:
| 目标 | 说明 |
|---|---|
| 互操作性 | 让不同框架、不同厂商、不同云平台构建的 Agent 能够无缝通信 |
| 能力发现 | 提供标准化的 Agent 能力描述机制,让 Agent 能自动发现并理解彼此 |
| 任务协作 | 定义带状态机的任务生命周期,支持多轮协商、异步执行和结果交付 |
| 安全可信 | 内置身份认证、授权和传输加密,确保跨组织协作的安全性 |
二、A2A 协议的诞生与发展历程
2.1 时间线
2025.04.09 Google Cloud Next 2025 大会,Google 正式发布 A2A 协议并开源
2025.04 首个 Python SDK 和 TypeScript SDK 发布,社区开始探索
2025.06 IBM 的 Agent Communication Protocol(ACP)宣布合并入 A2A
2025.09 v0.2.0 规范发布,完善企业级安全特性
2025.11 AWS Bedrock AgentCore 宣布原生支持 A2A
2025.12 Microsoft Semantic Kernel 和 Copilot Studio 集成 A2A
2026.03 A2A Protocol v1.0.0 正式发布,标记为生产就绪
2026.04 Linux 基金会宣布 A2A 获得 150+ 组织生产级采用
2026.04 Microsoft Agent Framework for .NET 发布 A2A v1 支持
2026.06 DeepLearning.AI 推出 A2A 认证课程
2.2 治理结构
A2A 协议目前由 Linux 基金会 旗下的 Agentic AI Foundation(AAIF) 治理。AAIF 同时治理 MCP(Model Context Protocol),这确保了两个协议在设计上的协同而非冲突。
关键治理原则:
- 开源开放:Apache License 2.0 协议,任何人可自由使用、修改和贡献
- 厂商中立:不绑定任何特定云平台或模型供应商
- 社区驱动:规范演进通过公开的 RFC 流程,由社区共同决策
2.3 v1.0 的关键突破
2026 年 3 月发布的 v1.0 是 A2A 协议的里程碑版本,核心改进包括:
- 无状态 HTTP 核心:早期版本依赖持久化 JSON-RPC 会话,在负载均衡器后面会出现会话粘连问题。v1.0 改为无状态 HTTP/REST 绑定,可以直接部署在标准 HTTP 基础设施上。
- 稳定的规范承诺:v1.0 之后的变更将保持向后兼容,企业可以放心投入生产。
- 完善的安全模型:正式纳入 OAuth 2.1 + PKCE 认证流程,支持扩展认证卡片(Authenticated Extended Card)。
- 推送通知机制:支持服务端向客户端 Webhook 推送任务状态更新,适配移动端和 Serverless 场景。
三、A2A 核心概念深度解析
A2A 协议的设计围绕五个核心概念展开:Agent Card、Task、Message、Artifact、Transport。理解这五个概念,就掌握了 A2A 的 80%。

3.1 Agent Card:智能体的"电子名片"
3.1.1 什么是 Agent Card
Agent Card 是一个 JSON 格式的元数据文档,类似于网站的 robots.txt 或 OpenAPI 规范,它描述了一个 A2A Agent 的身份、能力、接口和安全要求。
按照约定,Agent Card 发布在标准化路径:
GET https://your-agent-domain.com/.well-known/agent.json
其他 Agent 通过访问这个 URL,就能"认识"这个 Agent------它叫什么、能做什么、怎么联系它、需要什么认证。
3.1.2 Agent Card 完整结构
一个完整的 Agent Card 包含以下字段:
json
{
"name": "CodeReviewAgent",
"description": "自动化代码审查智能体,支持安全漏洞检测和代码风格分析",
"version": "1.2.0",
"url": "https://agents.example.com/code-review/a2a",
"provider": {
"organization": "Example Corp",
"url": "https://example.com"
},
"capabilities": {
"streaming": true,
"pushNotifications": true,
"stateTransitionHistory": true
},
"securitySchemes": {
"oauth2": {
"type": "oauth2",
"flows": {
"authorizationCode": {
"authorizationUrl": "https://auth.example.com/authorize",
"tokenUrl": "https://auth.example.com/token",
"scopes": {
"code_review:read": "读取代码审查结果",
"code_review:write": "提交代码审查任务"
}
}
}
}
},
"supportsAuthenticatedExtendedCard": true,
"skills": [
{
"id": "review_pr",
"name": "审查 Pull Request",
"description": "对 GitHub PR 进行安全和风格审查",
"inputSchema": {
"type": "object",
"properties": {
"repo": { "type": "string", "description": "仓库地址" },
"pr_number": { "type": "integer", "description": "PR 编号" },
"focus_areas": {
"type": "array",
"items": { "type": "string" },
"description": "重点关注领域"
}
},
"required": ["repo", "pr_number"]
},
"outputSchema": {
"type": "object",
"properties": {
"score": { "type": "number" },
"issues": { "type": "array" },
"summary": { "type": "string" }
}
}
}
],
"defaultInputModes": ["text"],
"defaultOutputModes": ["text"]
}
3.1.3 关键字段说明
| 字段 | 类型 | 必填 | 说明 |
|---|---|---|---|
name |
string | 是 | Agent 的人类可读名称 |
description |
string | 是 | Agent 功能描述,帮助其他 Agent 判断是否适合委派任务 |
version |
string | 是 | 语义化版本号,如 1.2.0 |
url |
string | 是 | A2A 通信端点 URL |
provider |
object | 否 | 提供方组织信息 |
capabilities |
object | 否 | 能力标志:streaming、pushNotifications 等 |
securitySchemes |
object | 否 | 认证方案定义(OAuth2、Bearer Token 等) |
skills |
array | 否 | Agent 提供的技能列表,每个技能有输入/输出 Schema |
defaultInputModes |
array | 否 | 默认输入模态:text、image、audio 等 |
defaultOutputModes |
array | 否 | 默认输出模态 |
3.1.4 发现机制
A2A 支持三种 Agent 发现方式:
- 直接配置:客户端硬编码目标 Agent 的 URL,适用于紧密耦合的内部系统
- Agent Card 注册表:使用集中式注册表(如 EMQX 6.2 的 A2A 注册表)存储和查询 Agent Card
- 动态发现 :通过域名的
/.well-known/agent.json路径自动发现,类似于 WebFinger
3.2 Task:带状态机的工作单元
3.2.1 Task 的本质
Task 是 A2A 协议中最核心的抽象。它代表一个从客户端 Agent 发送到服务端 Agent 的工作请求,拥有完整的生命周期和状态管理。
与 HTTP 的"请求-响应"模式不同,A2A Task 是有状态的、长生命周期的。一个代码审查任务可能需要运行 20 分钟,一个研究任务可能需要多轮信息补充。Task 的状态机设计正是为了支持这种复杂的异步协作。
3.2.2 Task 对象结构
json
{
"id": "task_abc123xyz",
"sessionId": "session_789",
"status": {
"state": "working",
"message": "正在分析代码安全漏洞...",
"timestamp": "2026-09-03T12:00:00Z"
},
"message": {
"role": "user",
"parts": [
{ "type": "text", "text": "请审查这个 PR 的安全性" }
]
},
"artifacts": [],
"history": [
{
"role": "user",
"parts": [{ "type": "text", "text": "请审查这个 PR 的安全性" }],
"messageId": "msg_001"
}
],
"metadata": {
"priority": "high",
"tenant_id": "tenant_001"
}
}
3.2.3 Task 状态机

A2A Task 的完整状态枚举如下:
| 状态 | 说明 | 可转换到 |
|---|---|---|
SUBMITTED |
任务已提交,等待处理 | WORKING、REJECTED |
WORKING |
任务正在处理中 | COMPLETED、FAILED、CANCELED、INPUT_REQUIRED、AUTH_REQUIRED |
INPUT_REQUIRED |
需要客户端补充信息 | WORKING(补充后恢复) |
AUTH_REQUIRED |
需要重新认证 | WORKING(认证后恢复) |
COMPLETED |
任务成功完成 | 终态 |
FAILED |
任务执行失败 | 终态 |
CANCELED |
任务被取消 | 终态 |
REJECTED |
任务被拒绝(如权限不足) | 终态 |
关键设计亮点 :INPUT_REQUIRED 和 AUTH_REQUIRED 是两个"暂停态",允许服务端 Agent 在执行过程中向客户端请求补充信息或重新认证,而不是直接失败。这对于需要多轮交互的复杂任务至关重要。
3.2.4 Task 相关 RPC 方法
A2A 协议定义了以下 Task 管理方法:
| 方法 | 说明 |
|---|---|
tasks/send |
提交新任务(同步返回初始状态) |
tasks/sendSubscribe |
提交任务并订阅流式更新(SSE) |
tasks/get |
查询任务当前状态 |
tasks/cancel |
取消正在执行的任务 |
tasks/resubscribe |
重新订阅任务更新(断线重连场景) |
tasks/pushNotificationConfig/set |
设置推送通知 Webhook |
tasks/pushNotificationConfig/get |
获取推送通知配置 |
3.3 Message:智能体间的对话载体
3.3.1 Message 结构
Message 是 Agent 之间单次通信的内容载体,每个 Message 包含角色和一个或多个 Part:
json
{
"role": "user",
"messageId": "msg_001",
"parts": [
{
"type": "text",
"text": "请分析以下代码的安全性:"
},
{
"type": "data",
"data": {
"language": "python",
"content": "import os\nos.system(user_input)"
}
},
{
"type": "file",
"file": {
"name": "auth.py",
"mimeType": "text/x-python",
"bytes": "base64encodedcontent..."
}
}
]
}
3.3.2 Part 类型
A2A Message 支持三种 Part 类型:
| Part 类型 | 说明 | 典型用途 |
|---|---|---|
TextPart |
纯文本内容 | 自然语言指令、对话消息 |
DataPart |
结构化 JSON 数据 | 技能参数、结构化输入输出 |
FilePart |
文件内容(内联 bytes 或 URI 引用) | 代码文件、图片、文档、音视频 |
FilePart 支持两种文件传递方式:
- 内联传递 :
bytes字段直接包含 Base64 编码的文件内容,适合小文件 - URI 引用 :
uri字段指向可访问的文件 URL,适合大文件,减少传输开销
3.3.3 角色定义
user:消息由客户端 Agent(任务发起方)发送agent:消息由服务端 Agent(任务执行方)发送
注意:这里的 user 不是指人类用户,而是指 A2A 交互中的客户端角色。
3.4 Artifact:任务的最终交付物
Artifact 是 Task 完成后产生的结构化输出。与 Message(对话性的、中间性的)不同,Artifact 是最终交付物------一份生成的报告、一个重构后的代码文件、一份数据分析 CSV、一张渲染好的图片。
json
{
"artifacts": [
{
"artifactType": "text/plain",
"parts": [
{
"type": "text",
"text": "## 代码审查报告\n\n### 安全评分: 7.5/10\n\n发现 3 个安全问题..."
}
],
"metadata": {
"title": "代码审查报告",
"createdAt": "2026-09-03T12:30:00Z"
}
}
]
}
Artifact 同样由 Parts 组成,支持文本、结构化数据和文件,与 Message 的 Part 类型一致。
3.5 Transport:通信传输层
3.5.1 传输协议
A2A v1.0 支持以下传输绑定:
| 传输方式 | 说明 | 适用场景 |
|---|---|---|
| HTTPS + JSON-RPC 2.0 | 最常用的绑定,基于 HTTPS 的 JSON-RPC 调用 | 通用场景,生产环境推荐 |
| HTTPS + REST/JSON | v1.0 新增的无状态 REST 风格绑定 | 标准 HTTP 基础设施,负载均衡友好 |
| SSE(Server-Sent Events) | 用于流式任务更新 | 实时状态推送、长任务监控 |
| gRPC | 高性能二进制传输 | 内部高吞吐量场景 |
3.5.2 流式传输
对于长时间运行的任务,A2A 提供 tasks/sendSubscribe 方法,通过 SSE 实时推送:
-
TaskStatusUpdateEvent:任务状态变更通知
-
TaskArtifactUpdateEvent:任务产出增量 Artifact
data: {"state":"working","message":"开始分析..."}
data: {"partialResult":{"progress":"30%"}}
data: {"state":"completed","artifacts":[...]}
3.5.3 推送通知
当客户端无法保持长连接时(如移动端 App、Serverless 函数),可以配置 Push Notification Webhook:
json
{
"url": "https://client.example.com/webhooks/a2a-updates",
"headers": {
"Authorization": "Bearer <client_token>"
}
}
服务端 Agent 在任务状态变更时,向该 Webhook 发送 POST 请求,客户端收到后再通过 tasks/get 获取详细信息。
四、A2A 协议架构与完整工作流程
4.1 典型交互流程
下面以"用户请求旅行规划 Agent 预订一次国际旅行"为例,展示 A2A 协议的完整交互流程:
客户端 Agent(旅行规划) 服务端 Agent(航班预订)
| |
|--- 1. GET /.well-known/agent.json ------>| 获取 Agent Card
|<-- 2. 返回 Agent Card -------------------| 了解能力和认证要求
| |
|--- 3. OAuth 2.1 认证流程 --------------->| 获取访问令牌
|<-- 4. 返回 access_token ----------------|
| |
|--- 5. POST /tasks/send ----------------->| 提交任务
| {message: "预订9月15日北京到东京的航班"} |
|<-- 6. 返回 Task(state=submitted) --------|
| |
|--- 7. POST /tasks/sendSubscribe -------->| 订阅流式更新
|<-- 8. SSE: state=working ---------------|
|<-- 9. SSE: state=input_required --------| 需要补充信息
| "请提供乘客姓名和护照号" |
| |
|--- 10. POST /tasks/send (补充信息) ------>| 发送乘客信息
|<-- 11. SSE: state=working --------------|
|<-- 12. SSE: state=completed ------------| 返回预订确认 Artifact
| {artifacts: [{确认单PDF, 航班信息}]} |
4.2 协议方法详解
4.2.1 message/send
最简单的消息发送方法,适用于不需要复杂任务管理的快速交互:
json
// 请求
{
"jsonrpc": "2.0",
"id": 1,
"method": "message/send",
"params": {
"message": {
"role": "user",
"parts": [{"type": "text", "text": "10美元等于多少人民币?"}]
}
}
}
// 响应
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"message": {
"role": "agent",
"parts": [{"type": "text", "text": "10美元约等于72.5元人民币"}]
}
}
}
4.2.2 tasks/send
提交一个带状态管理的任务,适用于需要异步执行、多轮交互的场景:
json
// 请求
{
"jsonrpc": "2.0",
"id": 2,
"method": "tasks/send",
"params": {
"id": "task_001",
"message": {
"role": "user",
"parts": [{"type": "text", "text": "对项目进行全面安全审计"}]
},
"pushNotificationConfig": {
"url": "https://client.example.com/webhook"
}
}
}
// 响应
{
"jsonrpc": "2.0",
"id": 2,
"result": {
"id": "task_001",
"status": {
"state": "working",
"message": "安全审计已开始,预计需要15分钟"
},
"artifacts": []
}
}
4.2.3 tasks/get
查询任务当前状态:
json
// 请求
{
"jsonrpc": "2.0",
"id": 3,
"method": "tasks/get",
"params": {
"id": "task_001"
}
}
// 响应
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"id": "task_001",
"status": {
"state": "completed",
"message": "安全审计完成"
},
"artifacts": [
{
"artifactType": "text/markdown",
"parts": [{"type": "text", "text": "# 安全审计报告\n\n发现5个高危漏洞..."}]
}
]
}
}
五、A2A vs MCP:互补而非竞争
这是社区中最常见的困惑:A2A 和 MCP 到底是什么关系?我应该用哪个?
答案是:几乎总是两者都用。 它们工作在协议栈的不同层次,解决不同的问题。

5.1 核心区别对比表
| 维度 | MCP(Model Context Protocol) | A2A(Agent-to-Agent Protocol) |
|---|---|---|
| 核心目的 | Agent 与工具/资源的连接 | Agent 与 Agent 之间的协作 |
| 通信方向 | 垂直(Agent → Tool) | 水平(Agent ↔ Agent) |
| 关系模型 | 主从(Host/Client) | 对等(Peer-to-Peer) |
| 核心抽象 | Tool、Resource、Prompt | Agent Card、Task、Message、Artifact |
| 交互模式 | 无状态函数调用 | 有状态任务生命周期 |
| 自主性 | 工具被动执行,无推理能力 | Agent 自主推理、规划、协商 |
| 发现机制 | 静态服务器配置 | 动态 Agent Card 发现 |
| 传输协议 | JSON-RPC over stdio/SSE/HTTP | JSON-RPC/REST over HTTPS + SSE |
| 多轮对话 | 不支持(单次调用) | 原生支持(INPUT_REQUIRED 状态) |
| 典型场景 | 查数据库、读文件、调 API | 多 Agent 分工、任务委派、跨组织协作 |
| 治理方 | Linux Foundation AAIF | Linux Foundation AAIF |
| 发起方 | Anthropic(2024.11) | Google(2025.04) |
5.2 一个生动的类比:汽车维修店
想象一个自动化的汽车维修店:
- MCP 是工具:诊断扫描仪、维修手册数据库、举升机。这些工具没有自主意识,你调用它,它执行一个具体操作并返回结果。
- A2A 是技工之间的对话:店长 Agent 和维修技工 Agent 讨论故障现象,技工 Agent 和配件供应商 Agent 协商零件库存。
完整的工作流程是:
- 客户(用户) 通过 A2A 向店长 Agent 描述问题:"我的车有异响"
- 店长 Agent 通过 A2A 与维修技工 Agent 进行多轮诊断对话
- 维修技工 Agent 通过 MCP 调用诊断扫描仪工具读取故障码
- 维修技工 Agent 通过 MCP 查询维修手册数据库获取维修步骤
- 维修技工 Agent 通过 A2A 向配件供应商 Agent 询问零件库存
- 配件供应商 Agent 通过 MCP 查询自己的库存数据库
MCP 解决"Agent 怎么干活",A2A 解决"Agent 怎么一起干活"。
5.3 三层 Agentic 架构
在生产环境中,典型的智能体应用采用三层架构:
┌─────────────────────────────────────────────────────────┐
│ A2A 层:Agent-to-Agent 协调 │
│ (任务委派、多 Agent 工作流、跨组织协作) │
│ "这个任务该交给谁?" │
├─────────────────────────────────────────────────────────┤
│ MCP 层:工具与上下文访问 │
│ (数据库、API、文件系统、第三方服务) │
│ "我需要用什么工具?" │
├─────────────────────────────────────────────────────────┤
│ 模型层:LLM 推理 │
│ (Gemini、Claude、GPT、DeepSeek、本地模型) │
│ "我如何思考和推理?" │
└─────────────────────────────────────────────────────────┘
每一层各司其职,共同构成完整的智能体应用栈。
5.4 A2A Agent 作为 MCP 资源
值得注意的是,一个 A2A 服务端 Agent 可以将其部分简单技能(Skill)以 MCP 兼容的方式暴露为 Tool。这样,其他 Agent 既可以通过 A2A 进行复杂的任务协作,也可以通过 MCP 进行简单的函数式调用。但 A2A 的核心优势始终在于其支持有状态、多轮、协商式的 Agent 协作。
六、四大多智能体协作编排模式
A2A 协议为多种多智能体编排模式提供了统一的通信基础。以下是四种生产环境中最常用的模式。

6.1 模式一:Supervisor-Worker(主管-工人模式)
架构描述:一个中央主管 Agent(Supervisor)接收用户的复杂任务,进行任务分解,然后通过 A2A 将子任务委派给各个专业工人 Agent(Worker)。主管 Agent 维护全局状态,收集各 Worker 的结果并整合输出。
适用场景:
- 任务可以明确分解为已知的子任务
- 需要统一的结果整合和质量把控
- 典型案例:"构建一个全栈 Web 应用" → 分解为前端、后端、数据库、测试
A2A 交互流程:
用户 → Supervisor Agent
├─ A2A → 研究 Agent(收集资料)
├─ A2A → 编码 Agent(生成代码)
├─ A2A → 测试 Agent(运行测试)
└─ 整合结果 → 用户
优点 :控制力强,结果可预测,易于调试和监控
缺点:主管 Agent 可能成为瓶颈,单点故障风险
6.2 模式二:Fan-Out/Fan-In(扇出-扇入模式)
架构描述:客户端 Agent 将同一个任务并行发送给多个专业 Agent,收集所有结果后进行整合、比较或投票。
适用场景:
- 需要多方意见的评估任务(如"请三个安全专家分别审查这段代码")
- A/B 测试或多模型对比
- 共识决策场景
A2A 交互流程:
客户端 Agent
├─ A2A → 安全 Agent A ──┐
├─ A2A → 安全 Agent B ──┼─→ 整合/投票 → 最终结果
└─ A2A → 安全 Agent C ──┘
优点 :并行执行速度快,多视角提高结果质量
缺点:资源消耗大,结果整合逻辑可能复杂
6.3 模式三:Pipeline(流水线模式)
架构描述:任务按照固定顺序流经一系列 Agent,每个 Agent 的输出成为下一个 Agent 的输入,形成处理流水线。
适用场景:
- 内容生产流水线(研究 → 起草 → 编辑 → SEO 优化 → 发布)
- 数据处理管道(采集 → 清洗 → 分析 → 可视化 → 报告)
- 有明确先后依赖的工作流
A2A 交互流程:
研究 Agent → 写作 Agent → 编辑 Agent → SEO Agent → 发布 Agent
优点 :结构清晰,每个 Agent 职责单一,易于独立优化
缺点:串行执行延迟较高,中间环节失败会影响全链路
6.4 模式四:Peer-to-Peer(对等网络模式)
架构描述:没有中央协调者,所有 Agent 通过 Agent Card 互相发现,直接协商和协作。任务在 Agent 网络中动态路由。
适用场景:
- 大规模跨组织 Agent 网络
- 没有任何单一实体控制全局编排的去中心化场景
- 动态变化的 Agent 生态(如 Agent Marketplace)
优点 :去中心化,可扩展性强,容错性好
缺点:协调复杂度高,结果可预测性较低,调试困难
6.5 模式选择指南
| 场景特征 | 推荐模式 |
|---|---|
| 任务可明确分解,需要统一把控 | Supervisor-Worker |
| 需要多方评估或共识 | Fan-Out/Fan-In |
| 有明确先后顺序的处理流程 | Pipeline |
| 跨组织、动态、去中心化 | Peer-to-Peer |
| 复杂企业级工作流 | Supervisor-Worker + Pipeline 混合 |
七、代码实战:从零构建 A2A 服务端与客户端
理论讲完了,现在进入实战环节。我们将使用官方 Python SDK 构建一个完整的 A2A 应用。
7.1 环境准备与依赖安装
bash
# 创建虚拟环境
python -m venv a2a-env
source a2a-env/bin/activate
# 安装官方 A2A Python SDK
pip install a2a
# 或使用 uv(推荐,更快)
uv pip install a2a fastapi uvicorn
验证安装:
bash
python -c "import a2a; print(a2a.__version__)"
7.2 构建 A2A 服务端(Agent Server)
我们将构建一个"代码审查 Agent"服务端,它能够接收代码审查任务,分析代码并返回报告。
python
# code_review_agent.py
import asyncio
import uuid
from typing import Any
from a2a import A2AServer, Task, TaskState, TaskStatus
from a2a.types import (
Message,
TextPart,
FilePart,
Artifact,
SendTaskRequest,
SendTaskResponse,
GetTaskRequest,
GetTaskResponse,
)
class CodeReviewAgent(A2AServer):
"""代码审查 A2A Agent 服务端"""
def __init__(self):
super().__init__()
# 内存存储任务(生产环境应使用 Redis 或数据库)
self.tasks: dict[str, Task] = {}
async def on_send_task(self, request: SendTaskRequest) -> SendTaskResponse:
"""处理任务提交"""
task_id = request.params.id or str(uuid.uuid4())
# 创建任务,初始状态为 submitted
task = Task(
id=task_id,
status=TaskStatus(state=TaskState.SUBMITTED),
message=request.params.message,
artifacts=[],
history=[request.params.message],
)
self.tasks[task_id] = task
# 异步执行审查逻辑
asyncio.create_task(self._run_review(task_id))
return SendTaskResponse(
id=request.id,
result=task,
)
async def _run_review(self, task_id: str):
"""执行代码审查(模拟)"""
task = self.tasks[task_id]
# 更新状态为 working
task.status = TaskStatus(
state=TaskState.WORKING,
message="正在分析代码安全性和风格...",
)
# 模拟审查过程
await asyncio.sleep(3)
# 从消息中提取代码
code_text = ""
for part in task.message.parts:
if isinstance(part, TextPart):
code_text += part.text
elif isinstance(part, FilePart):
code_text += f"\n[文件: {part.file.name}]\n"
# 模拟审查结果
review_report = self._analyze_code(code_text)
# 生成 Artifact
artifact = Artifact(
artifactType="text/markdown",
parts=[TextPart(text=review_report)],
)
# 完成任务
task.status = TaskStatus(
state=TaskState.COMPLETED,
message="代码审查完成",
)
task.artifacts = [artifact]
def _analyze_code(self, code: str) -> str:
"""简单的代码分析逻辑(实际应调用 LLM)"""
issues = []
score = 10.0
if "os.system" in code or "eval(" in code:
issues.append("- **高危**: 发现命令注入风险(os.system/eval)")
score -= 3.0
if "password" in code.lower() and "getpass" not in code:
issues.append("- **中危**: 可能存在硬编码密码")
score -= 2.0
if "TODO" in code or "FIXME" in code:
issues.append("- **低危**: 存在未完成的 TODO/FIXME")
score -= 0.5
if not issues:
issues.append("- 未发现明显安全问题")
return f"""# 代码审查报告
## 安全评分: {max(score, 0)}/10
## 发现问题
{chr(10).join(issues)}
## 建议
1. 对所有外部输入进行严格校验和转义
2. 使用参数化查询替代字符串拼接 SQL
3. 敏感信息应通过环境变量或密钥管理服务注入
"""
async def on_get_task(self, request: GetTaskRequest) -> GetTaskResponse:
"""查询任务状态"""
task_id = request.params.id
if task_id not in self.tasks:
raise ValueError(f"Task {task_id} not found")
return GetTaskResponse(id=request.id, result=self.tasks[task_id])
if __name__ == "__main__":
import uvicorn
agent = CodeReviewAgent()
uvicorn.run(agent.app, host="0.0.0.0", port=8080)
启动服务端:
bash
python code_review_agent.py
服务启动后,Agent Card 可以通过以下地址访问:
GET http://localhost:8080/.well-known/agent.json
7.3 构建 A2A 客户端(Agent Client)
python
# a2a_client.py
import asyncio
from a2a import A2AClient
from a2a.types import Message, TextPart, SendTaskParams
async def main():
# 创建 A2A 客户端,连接到代码审查 Agent
async with A2AClient(base_url="http://localhost:8080") as client:
# 1. 获取 Agent Card,了解服务端能力
card = await client.get_agent_card()
print(f"连接到 Agent: {card.name} v{card.version}")
print(f"描述: {card.description}")
# 2. 提交代码审查任务
task = await client.send_task(
SendTaskParams(
message=Message(
role="user",
parts=[
TextPart(
text="""
import os
def run_command(user_input):
os.system(user_input)
password = "admin123"
# TODO: 添加错误处理
"""
)
],
)
)
)
print(f"\n任务已提交: {task.id}")
print(f"初始状态: {task.status.state}")
# 3. 轮询任务状态
while task.status.state in ["submitted", "working"]:
await asyncio.sleep(1)
task = await client.get_task(task.id)
print(f"当前状态: {task.status.state} - {task.status.message or ''}")
# 4. 获取结果
if task.status.state == "completed":
print("\n=== 审查结果 ===")
for artifact in task.artifacts:
for part in artifact.parts:
if isinstance(part, TextPart):
print(part.text)
else:
print(f"任务失败: {task.status.message}")
if __name__ == "__main__":
asyncio.run(main())
运行客户端:
bash
python a2a_client.py
预期输出:
连接到 Agent: CodeReviewAgent v1.0.0
描述: 自动化代码审查智能体
任务已提交: task_abc123
初始状态: submitted
当前状态: working - 正在分析代码安全性和风格...
当前状态: completed - 代码审查完成
=== 审查结果 ===
# 代码审查报告
## 安全评分: 4.5/10
## 发现问题
- **高危**: 发现命令注入风险(os.system/eval)
- **中危**: 可能存在硬编码密码
- **低危**: 存在未完成的 TODO/FIXME
## 建议
...
7.4 流式响应与多轮交互
7.4.1 流式订阅
对于长时间运行的任务,使用 send_task_subscribe 方法通过 SSE 实时获取更新:
python
async def stream_review():
async with A2AClient(base_url="http://localhost:8080") as client:
async for event in client.send_task_subscribe(
SendTaskParams(
message=Message(
role="user",
parts=[TextPart(text="审查整个项目的安全性")],
)
)
):
if isinstance(event, TaskStatusUpdateEvent):
print(f"[状态] {event.status.state}: {event.status.message}")
elif isinstance(event, TaskArtifactUpdateEvent):
print(f"[产物] 收到新 Artifact")
7.4.2 处理 INPUT_REQUIRED(多轮交互)
当服务端 Agent 需要更多信息时,任务会进入 INPUT_REQUIRED 状态,客户端需要补充信息后任务才能继续:
python
async def multi_turn_interaction():
async with A2AClient(base_url="http://localhost:8080") as client:
# 提交初始任务
task = await client.send_task(
SendTaskParams(
message=Message(
role="user",
parts=[TextPart(text="帮我预订机票")],
)
)
)
# 轮询直到需要输入或完成
while task.status.state not in ["completed", "failed", "canceled"]:
if task.status.state == "input_required":
# 服务端需要补充信息
print(f"需要补充信息: {task.status.message}")
# 发送补充信息
task = await client.send_task(
SendTaskParams(
id=task.id, # 必须指定同一个 task id
message=Message(
role="user",
parts=[TextPart(text="北京到东京,9月15日,经济舱")],
),
)
)
else:
await asyncio.sleep(1)
task = await client.get_task(task.id)
7.5 完整电商订单履约多 Agent 协作案例
下面是一个更贴近真实业务的案例:电商订单履约系统,涉及库存、物流、风控、客服四个专业 Agent 的协作。
7.5.1 系统架构
用户下单
│
▼
订单协调 Agent (Supervisor)
├── A2A → 库存 Agent:查询并锁定库存
├── A2A → 风控 Agent:识别异常订单
├── A2A → 物流 Agent:匹配承运商、生成运单
└── A2A → 客服 Agent:发送订单确认通知
7.5.2 订单协调 Agent 核心代码
python
# order_coordinator.py
class OrderCoordinator(A2AServer):
"""订单履约协调 Agent"""
def __init__(self):
super().__init__()
self.inventory_client = A2AClient(base_url="http://inventory-agent:8080")
self.risk_client = A2AClient(base_url="http://risk-agent:8080")
self.logistics_client = A2AClient(base_url="http://logistics-agent:8080")
self.cs_client = A2AClient(base_url="http://cs-agent:8080")
async def on_send_task(self, request: SendTaskRequest) -> SendTaskResponse:
task_id = request.params.id or str(uuid.uuid4())
task = Task(
id=task_id,
status=TaskStatus(state=TaskState.WORKING, message="开始处理订单..."),
message=request.params.message,
)
self.tasks[task_id] = task
asyncio.create_task(self._fulfill_order(task_id))
return SendTaskResponse(id=request.id, result=task)
async def _fulfill_order(self, task_id: str):
task = self.tasks[task_id]
order_data = self._parse_order(task.message)
try:
# 步骤1:风控检查(并行启动)
task.status = TaskStatus(state=TaskState.WORKING, message="风控检查中...")
risk_task = await self.risk_client.send_task(
SendTaskParams(message=Message(role="user", parts=[
DataPart(data=order_data)
]))
)
# 步骤2:库存锁定
task.status = TaskStatus(state=TaskState.WORKING, message="锁定库存中...")
inventory_task = await self.inventory_client.send_task(
SendTaskParams(message=Message(role="user", parts=[
DataPart(data={"items": order_data["items"]})
]))
)
# 等待风控和库存结果
risk_result = await self._wait_for_completion(self.risk_client, risk_task.id)
inventory_result = await self._wait_for_completion(self.inventory_client, inventory_task.id)
if risk_result.status.state == "failed":
raise Exception("风控检查未通过")
# 步骤3:物流调度
task.status = TaskStatus(state=TaskState.WORKING, message="调度物流中...")
logistics_task = await self.logistics_client.send_task(
SendTaskParams(message=Message(role="user", parts=[
DataPart(data={"address": order_data["address"]})
]))
)
logistics_result = await self._wait_for_completion(self.logistics_client, logistics_task.id)
# 步骤4:客服通知
await self.cs_client.send_task(
SendTaskParams(message=Message(role="user", parts=[
DataPart(data={
"order_id": order_data["order_id"],
"tracking_no": self._extract_tracking(logistics_result)
})
]))
)
# 完成
task.status = TaskStatus(state=TaskState.COMPLETED, message="订单履约完成")
task.artifacts = [Artifact(
artifactType="application/json",
parts=[DataPart(data={
"order_id": order_data["order_id"],
"status": "fulfilled",
"tracking_number": self._extract_tracking(logistics_result)
})]
)]
except Exception as e:
task.status = TaskStatus(state=TaskState.FAILED, message=str(e))
这个案例展示了 A2A 在真实业务中的价值:每个专业 Agent 可以独立开发、独立部署、独立升级,通过标准化的 A2A 协议无缝协作。
八、生产级部署:安全、可观测与高可用
将 A2A 应用从 Demo 推向生产,需要解决安全、部署、可观测性和故障处理四大问题。
8.1 安全体系:OAuth 2.1、TLS 与最小权限
8.1.1 传输安全
A2A 规范对生产环境的传输安全有明确要求:
| 要求 | 说明 |
|---|---|
| HTTPS 强制 | 所有生产环境的 A2A 通信必须通过 HTTPS |
| TLS 版本 | 推荐 TLS 1.2 及以上版本,使用强密码套件 |
| 证书验证 | 客户端必须验证服务端 TLS 证书,禁止跳过证书校验 |
| mTLS(可选) | 高安全场景可启用双向 TLS 认证 |
8.1.2 身份认证
A2A v1.0 推荐使用 OAuth 2.1 + PKCE 进行身份认证:
客户端 Agent 认证服务器 服务端 Agent
| | |
|--- 1. 授权请求 (code_challenge) --->| |
|<-- 2. 授权码 -----------------------| |
|--- 3. 用授权码换取 token ---------->| |
|<-- 4. access_token + refresh_token | |
| | |
|--- 5. 携带 access_token 调用 A2A -------------------------------->|
| | |
对于简单的内部场景,也可以使用 Bearer Token,但需要注意:
- Token 应有过期时间
- 支持 Token 轮换机制
- 不要在代码中硬编码 Token
8.1.3 授权与权限控制
python
# 服务端权限校验中间件
from fastapi import Request, HTTPException
async def verify_scope(request: Request, required_scope: str):
auth_header = request.headers.get("Authorization", "")
if not auth_header.startswith("Bearer "):
raise HTTPException(status_code=401, detail="Missing token")
token = auth_header.split(" ")[1]
claims = verify_jwt(token) # 验证 JWT 签名和过期时间
if required_scope not in claims.get("scopes", []):
raise HTTPException(status_code=403, detail=f"Missing scope: {required_scope}")
return claims
8.1.4 安全最佳实践清单
- 所有通信使用 HTTPS(TLS 1.2+)
- 实现 OAuth 2.1 + PKCE 认证
- 验证 Agent Card 发布者身份(签名 Agent Card)
- 对所有输入进行 Schema 校验
- 实现速率限制,防止 Agent 循环调用
- Agent 代码在沙箱中运行,限制系统权限
- 每个 Agent 连接使用最小权限原则
- 记录完整的审计日志
- 敏感数据进行脱敏处理
- 定期轮换密钥和证书
8.2 Kubernetes 部署架构
8.2.1 部署配置
yaml
# a2a-agent-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: code-review-agent
labels:
app: a2a-agent
agent-type: code-review
spec:
replicas: 3
selector:
matchLabels:
app: a2a-agent
template:
metadata:
labels:
app: a2a-agent
agent-type: code-review
spec:
containers:
- name: agent
image: registry.example.com/a2a/code-review-agent:1.2.0
ports:
- containerPort: 8080
env:
- name: A2A_BASE_URL
value: "https://agents.example.com/code-review"
- name: REDIS_URL
valueFrom:
secretKeyRef:
name: a2a-secrets
key: redis-url
- name: OIDC_ISSUER
value: "https://auth.example.com"
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "2"
memory: "2Gi"
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 30
readinessProbe:
httpGet:
path: /.well-known/agent.json
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
name: code-review-agent
spec:
selector:
app: a2a-agent
ports:
- port: 80
targetPort: 8080
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: a2a-agent-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: code-review-agent
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
8.2.2 任务状态外部化
由于 A2A v1.0 支持无状态 HTTP,任务状态应存储在外部存储中(如 Redis),确保多副本部署时状态一致:
python
import redis
import json
class RedisTaskStore:
def __init__(self, redis_url: str):
self.redis = redis.from_url(redis_url)
async def save_task(self, task: Task):
key = f"a2a:task:{task.id}"
self.redis.setex(key, 3600, task.model_dump_json()) # 1小时过期
async def get_task(self, task_id: str) -> Task | None:
key = f"a2a:task:{task_id}"
data = self.redis.get(key)
if not data:
return None
return Task.model_validate_json(data)
8.3 可观测性:日志、指标与链路追踪
8.3.1 关键指标
| 指标 | 说明 | 告警阈值建议 |
|---|---|---|
a2a_tasks_total |
任务总数(按状态标签) | - |
a2a_task_duration_seconds |
任务执行耗时直方图 | P99 > 300s 告警 |
a2a_task_failure_rate |
任务失败率 | > 5% 告警 |
a2a_agent_card_requests_total |
Agent Card 请求数 | - |
a2a_authentication_failures_total |
认证失败数 | 突增告警 |
a2a_active_tasks |
当前活跃任务数 | > 容量 80% 告警 |
8.3.2 Prometheus 指标埋点
python
from prometheus_client import Counter, Histogram, Gauge
tasks_total = Counter("a2a_tasks_total", "Total tasks", ["state", "agent"])
task_duration = Histogram("a2a_task_duration_seconds", "Task duration", ["agent"])
active_tasks = Gauge("a2a_active_tasks", "Active tasks", ["agent"])
class ObservableAgent(A2AServer):
async def on_send_task(self, request):
active_tasks.labels(agent=self.name).inc()
start = time.time()
try:
response = await super().on_send_task(request)
tasks_total.labels(state="submitted", agent=self.name).inc()
return response
finally:
task_duration.labels(agent=self.name).observe(time.time() - start)
active_tasks.labels(agent=self.name).dec()
8.3.3 分布式链路追踪
使用 OpenTelemetry 为每个 A2A Task 创建 Trace,跨 Agent 传播 Trace Context:
python
from opentelemetry import trace
from opentelemetry.propagate import inject, extract
tracer = trace.get_tracer("a2a-agent")
async def on_send_task(self, request):
# 从请求头提取 Trace Context
context = extract(dict(request.headers))
with tracer.start_as_current_span("a2a.task", context=context) as span:
span.set_attribute("a2a.task_id", request.params.id)
span.set_attribute("a2a.agent_name", self.name)
# ... 处理逻辑
8.4 生产环境常见故障与应对
| 故障模式 | 原因 | 应对策略 |
|---|---|---|
| Agent Card 过期 | 能力已变更但 Agent Card 未更新 | Agent Card 加入版本号和缓存控制头,变更时自动失效缓存 |
| 任务超时级联 | 一个慢 Agent 阻塞下游所有 Agent | 设置合理的任务超时,实现熔断机制(如使用 Dapr) |
| Auth Token 过期 | 长任务执行中 OAuth Token 过期 | 实现 Token 自动刷新,AUTH_REQUIRED 状态支持重新认证 |
| Schema 漂移 | 输入 Schema 变更但调用方未同步 | Agent Card 中声明 Schema 版本,客户端做兼容性检查 |
| Agent 循环调用 | A 调用 B,B 又调用 A,形成死循环 | 调用链中加入最大深度限制,检测循环依赖 |
| SSE 连接断开 | 网络波动导致流式更新中断 | 客户端实现断线重连,使用 tasks/resubscribe 恢复订阅 |
| 大文件传输超时 | FilePart 内联大文件导致 HTTP 超时 | 大文件使用 URI 引用,配合预签名 URL |
九、行业应用场景与真实案例
9.1 金融服务:跨机构反欺诈协作
场景:银行 A 的交易监控 Agent 检测到可疑交易,需要与银行 B 的客户身份验证 Agent、征信机构的信用评估 Agent 协作,完成反欺诈调查。
A2A 的价值:
-
各机构的 Agent 运行在各自的安全域内,不暴露内部算法和数据
-
通过 A2A 协议安全地交换结构化信息和分析结论
-
任务生命周期支持多轮调查和人工审核介入
银行A交易监控 Agent
├─ A2A → 银行B身份验证 Agent(验证交易对手身份)
├─ A2A → 征信机构信用评估 Agent(获取信用评分)
└─ A2A → 监管报告 Agent(自动生成合规报告)
9.2 医疗健康:患者数据安全共享
场景:患者在 A 医院的检查结果需要被 B 医院的专科医生 Agent 访问,同时需要药房 Agent 审核药物相互作用。
A2A 的价值:
- 患者数据不离开原始机构,Agent 之间只交换分析结论
- 细粒度的授权控制,患者可授权特定 Agent 访问特定数据
- 完整的审计日志,满足 HIPAA / 等保合规要求
9.3 电商:全链路订单履约
如本文 7.5 节所述,电商订单履约涉及库存、风控、物流、客服等多个专业 Agent 的协作。A2A 使得每个环节可以由最擅长的供应商提供,通过标准协议无缝集成。
9.4 软件开发:CI/CD 智能体流水线
场景:代码提交后,多个 Agent 协作完成自动化代码审查、测试、安全扫描和部署。
代码提交 → 审查 Agent → 测试 Agent → 安全扫描 Agent → 部署 Agent → 通知 Agent
每个 Agent 可以由不同团队维护,使用不同的技术栈,但通过 A2A 协议在流水线中协作。
9.5 客户服务:多部门智能体协作
场景:客户咨询一个复杂问题(如"我的订单为什么还没到,能退款吗?"),客服总控 Agent 需要协调订单 Agent、物流 Agent、退款 Agent 共同回答。
- 客服 Agent 通过 A2A 向订单 Agent 查询订单状态
- 向物流 Agent 查询包裹位置
- 向退款 Agent 评估退款资格
- 整合所有信息,给客户一个完整的答复
9.6 旅行规划:跨服务商智能体网络
场景:用户说"帮我规划一次东京五日游",旅行规划 Agent 需要协调航班、酒店、景点、餐饮、交通等多个服务商的 Agent。
每个服务商(航空公司、酒店集团、景点)都可以暴露自己的 A2A Agent,旅行规划 Agent 通过 Agent Card 发现它们,动态组合最优方案。
十、A2A 生态系统全景
10.1 云平台支持
| 云平台 | 支持情况 |
|---|---|
| Google Cloud | Vertex AI Agent Engine 原生支持,ADK(Agent Development Kit)内置 A2A |
| AWS | Bedrock AgentCore 原生支持 A2A 协议 |
| Microsoft Azure | Azure AI Foundry、Copilot Studio、Semantic Kernel 集成 A2A |
10.2 框架支持
| 框架 | A2A 支持 |
|---|---|
| LangGraph / LangChain | 官方集成,可将 LangGraph 应用暴露为 A2A 服务端 |
| CrewAI | 支持 Crew 成员间通过 A2A 通信 |
| AutoGen (AG2) | 支持 A2A 作为 Agent 间通信层 |
| Semantic Kernel | Microsoft 官方支持 A2A v1 |
| Microsoft Agent Framework (.NET) | 原生 A2A 客户端和服务端支持 |
| Spring AI (Java) | 原生 A2A 协议支持,含 Google Maps grounding |
10.3 企业软件厂商
截至 2026 年中,已宣布支持 A2A 的企业包括:
- Salesforce:将 A2A 用于 Einstein Agent 间协作
- ServiceNow:Now Assist 智能体通过 A2A 互联
- SAP:业务流程智能体支持 A2A
- Workday:HR 和财务智能体集成 A2A
- Cisco:网络运维智能体使用 A2A
- Atlassian:Jira 和 Confluence 智能体支持 A2A
- Box:内容管理智能体暴露 A2A 接口
10.4 基础设施与中间件
| 项目 | 说明 |
|---|---|
| EMQX 6.2 | 内置 A2A 注册表,支持基于 MQTT 的 A2A 通信 |
| Dapr | 为 A2A 提供 mTLS、Secret 管理、可观测性等企业级能力 |
| Apache Camel | A2A Component,支持与 300+ 中间件系统集成 |
| Tyk / Kong / Apigee | API 网关支持 A2A 协议代理和安全策略 |
| DeepLearning.AI | 推出 A2A 认证课程 |
10.5 SDK 语言支持
| 语言 | SDK | 状态 |
|---|---|---|
| Python | a2a(官方) |
稳定 |
| TypeScript/JavaScript | @a2a-protocol/sdk(官方) |
稳定 |
| Java | Spring AI 集成 | 稳定 |
| .NET/C# | Microsoft Agent Framework | 稳定 |
| Go | 社区 SDK | 开发中 |
| Rust | 社区 SDK | 开发中 |
十一、常见问题 FAQ
Q1:A2A 和 MCP 是竞争关系吗?我应该选哪个?
不是竞争关系,而是互补关系。 MCP 解决 Agent 如何连接工具和数据(垂直集成),A2A 解决 Agent 之间如何协作(水平协调)。生产环境中的多 Agent 系统几乎总是同时使用两者:Agent 内部用 MCP 访问工具,Agent 之间用 A2A 通信。
Q2:A2A 只能用于云端 Agent 吗?本地 Agent 可以用吗?
可以。 A2A 基于标准 HTTP 协议,任何能运行 HTTP 服务的环境都可以使用,包括本地开发机、边缘设备、企业内网。本地 Agent 只需在 localhost 上暴露 Agent Card 和 A2A 端点即可。
Q3:A2A v1.0 支持哪些传输协议?
三种绑定:
- JSON-RPC 2.0 over HTTPS(最常用)
- REST/JSON over HTTPS(v1.0 新增,无状态,负载均衡友好)
- gRPC(高性能内部场景)
流式更新使用 SSE(Server-Sent Events)。
Q4:Agent 之间如何发现彼此?
三种方式:
- 直接配置:硬编码目标 Agent URL(内部系统常用)
- Agent Card 注册表:集中式注册表存储和查询(如 EMQX A2A 注册表)
- 动态发现 :通过
/.well-known/agent.json路径自动发现
Q5:A2A 会取代 REST API 吗?
不会。 A2A 是 Agent 层协议,工作在现有 REST/gRPC API 之上。你的微服务仍然应该暴露标准 API,A2A Agent 作为智能层调用这些 API 并与其他 Agent 协作。
Q6:如何处理长时间运行的任务?
A2A 提供三种机制:
- 轮询 :客户端定期调用
tasks/get查询状态 - 流式订阅 :通过
tasks/sendSubscribe使用 SSE 实时接收更新 - 推送通知:配置 Webhook,服务端主动推送状态变更
Q7:A2A 的安全性如何保障?
- 传输层:强制 HTTPS + TLS 1.2+
- 认证层:OAuth 2.1 + PKCE
- 授权层:基于 Scope 的细粒度权限控制
- 数据层:支持签名 Agent Card、敏感数据脱敏
- 审计层:完整的任务和消息审计日志
Q8:生产环境中最常见的失败模式有哪些?
- Agent Card 与实际能力不一致(Schema 漂移)
- 长任务中 OAuth Token 过期
- 慢 Agent 导致超时级联
- Agent 间循环调用
- SSE 连接断开后未正确重连
- 大文件内联传输导致超时
详见本文 8.4 节的应对策略。
Q9:A2A 协议的版本兼容性如何?
v1.0 是第一个稳定版本,承诺向后兼容。版本号遵循语义化版本规范,Agent Card 中包含版本字段,客户端可以根据版本进行兼容性协商。
Q10:我可以在哪里学习和试用 A2A?
- 官方文档:https://a2a-protocol.org
- GitHub 仓库:https://github.com/google-a2a/A2A
- Python SDK:
pip install a2a - Google Cloud 官方 Codelab:"Purchasing Concierge" 示例
- DeepLearning.AI A2A 认证课程
十二、总结与展望
12.1 核心要点回顾
- A2A 是 AI Agent 世界的 TCP/IP:它解决了不同框架、不同厂商构建的 Agent 之间无法互操作的根本问题。
- 五个核心概念:Agent Card(能力发现)、Task(有状态工作单元)、Message(对话载体)、Artifact(交付物)、Transport(通信层)。
- 与 MCP 互补:MCP 管工具,A2A 管协作,两者共同构成三层 Agentic 架构。
- 四种编排模式:Supervisor-Worker、Fan-Out/Fan-In、Pipeline、Peer-to-Peer,适用于不同业务场景。
- 生产就绪:v1.0 稳定版已获 150+ 组织采用,三大云平台原生支持,完善的安全和可观测性体系。
12.2 未来趋势展望
短期(2026-2027):
- A2A Agent Marketplace 涌现,企业可以像调用 API 一样调用第三方 Agent
- Agent Card 签名和信誉体系成熟,解决"该信任哪个 Agent"的问题
- 低代码/无代码 A2A 编排工具普及,非技术人员也能搭建多 Agent 工作流
中期(2027-2028):
- A2A 与 Agent 经济系统结合,支持 Agent 间的自动计费和结算
- 跨语言、跨模态的 Agent 协作成为常态(文本 Agent 调用图像生成 Agent、语音 Agent)
- 监管框架逐步完善,明确 Agent 间协作的法律责任归属
长期(2028+):
- 全球 Agent 网络形成,数以百万计的专业 Agent 通过 A2A 协议互联
- Agent 自主组建临时团队解决复杂问题,人类只需设定目标和约束
- A2A 成为像 HTTP 一样无处不在的基础协议
12.3 行动建议
对于开发者和技术团队:
- 立即开始:在你的下一个 AI 项目中尝试使用 A2A,哪怕只是将一个现有 Agent 暴露为 A2A 服务端
- 分层设计:按照"模型层 → MCP 工具层 → A2A 协作层"的三层架构规划系统
- 关注安全:从第一天就实施 OAuth 认证、TLS 加密和审计日志
- 拥抱标准:避免被单一框架锁定,优先选择支持开放标准(A2A、MCP)的技术栈
- 参与社区:A2A 仍在快速演进,参与社区讨论和贡献能让你站在技术前沿
A2A 协议不是未来的技术,而是现在的标准。 当你的竞争对手还在用定制胶水代码拼接 Agent 时,你已经可以用标准化的 A2A 协议构建可扩展、可互操作的多智能体系统。基础设施已经就绪,剩下的就是想象力。
参考资料
1 A2A Protocol 官方网站. https://a2a-protocol.com/
2 A2A Protocol v0.2.0 规范文档. https://a2a-protocol.org/v0.2.0/specification/
3 A2A and MCP: Detailed Comparison. https://a2a-protocol.org/latest/topics/a2a-and-mcp/
4 Google A2A GitHub 仓库. https://github.com/google-a2a/A2A
5 Linux Foundation. A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms, and Sees Enterprise Production Use in First Year. 2026-04-09. https://www.linuxfoundation.org/press/a2a-protocol-surpasses-150-organizations-lands-in-major-cloud-platforms-and-sees-enterprise-production-use-in-first-year
6 Essa Mamdani. The Complete Guide to A2A Protocol in 2026: Building the HTTP for Agent-to-Agent Communication. 2026-06-07. https://essamamdani.com/blog/complete-guide-a2a-protocol-2026
7 Microsoft. A2A v1 Is Here: Cross-Platform Agent Communication in Microsoft Agent Framework for .NET. 2026-04-28. https://devblogs.microsoft.com/agent-framework/a2a-v1-is-here-cross-platform-agent-communication-in-microsoft-agent-framework-for-net/
8 腾讯云开发者社区. 什么是A2A_A2A简介_A2A的优势以及应用场景. https://cloud.tencent.com/developer/techpedia/2631
9 稀土掘金. A2A over MQTT:基于 EMQX 构建生产级智能体协同网络. 2026-07-16. https://juejin.cn/post/7662826906895892521
10 CSDN. A2A 协议深度实战:Java 后端如何构建企业级 Agent-to-Agent 协作基础设施. 2026-08-24. https://blog.csdn.net/qq_36021478/article/details/163995000
11 arXiv. Building A Secure Agentic AI Application Leveraging Google's A2A Protocol. https://arxiv.org/pdf/2504.16902v2
12 arXiv. A Study on the MCP × A2A Framework for Enhancing Interoperability of LLM-based Autonomous Agents. https://arxiv.org/pdf/2506.01804.pdf
13 Diagrid. Making Agent-to-Agent (A2A) Communication Secure and Reliable with Dapr. 2025-11-24. https://www.diagrid.io/blog/making-agent-to-agent-a2a-communication-secure-and-reliable-with-dapr
14 AutoGPT. MCP vs A2A: The Two AI Agent Protocols Explained. 2026-09-02. https://autogpt.net/mcp-vs-a2a/
15 Awesome A2A (Agent2Agent Protocol). https://github.com/ai-boost/awesome-a2a/
版权声明:本文为原创技术文章,欢迎转载,转载请注明出处。文中涉及的协议规范以官方最新版本为准。
最后更新:2026 年 9 月 3 日