A2A Protocol 深度解析：让所有 AI Agent 说同一种语言——从 Agent Card 到任务生命周期、从跨框架协作到生产级部署的完整技术指南（2026）
作者注：2025 年 4 月，Google 在 Cloud Next 大会上发布了 A2A（Agent-to-Agent Protocol）——这是 AI Agent 发展史上的一个分水岭时刻。它解决的问题很简单，却极其深刻：让不同厂商、不同框架、不同部署环境构建的 AI Agent 能够相互发现、通信和协作。本文将深入 A2A 的技术内核，从 Agent Card 的 JSON Schema，到任务状态机的完整实现，再到生产级多 Agent 协作系统的架构设计，给你一份完整的工程指南。
目录
- 背景：AI Agent 的「巴别塔」困境
- A2A 协议核心设计哲学
- Agent Card：Agent 的「数字名片」深度解析
- 任务生命周期：从提交到完成的完整状态机
- 消息与工件：A2A 的通信原语
- 传输层设计：JSON-RPC over HTTP + SSE
- A2A vs MCP：互补而非竞争
- Python SDK 实战：构建一个完整的 A2A Agent
- TypeScript SDK 实战：前端 Agent 的无缝接入
- 多 Agent 协作架构设计
- 企业级安全：认证与授权
- Linux Foundation 托管后的生态演进
- 生产级部署最佳实践
- 真实案例：跨框架 Agent 协作系统
- 性能优化与可观测性
- 2026 年 A2A 生态全景图
- 总结与展望：A2A 如何重塑 AI 基础设施
1. 背景：AI Agent 的「巴别塔」困境
1.1 问题的本质
2024-2026 年，AI Agent 框架呈爆炸式增长。LangChain、LangGraph、CrewAI、AutoGen、Google ADK、 Anthropic Claude Code、ByteDance TRAE、OpenAI Swarm……每个框架都有自己的 Agent 定义方式、通信协议和工具调用规范。
这导致了一个严峻的现实：一个用 LangChain 构建的招聘 Agent，无法与用 CrewAI 构建的报销审批 Agent 直接协作——即使它们都在为企业解决真实的业务问题。
┌─────────────────────────────────────────────────────────────────┐
│ 企业 AI Agent 孤岛问题 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ HR Agent │ │Sales Agent│ │Finance │ │
│ │(Google ADK)│ │(LangChain)│ │Agent │ │
│ └─────┬─────┘ └─────┬─────┘ └────┬─────┘ │
│ │ │ │ │
│ │ 无法通信 │ 无法通信 │ │
│ │ ◄────────────────┼──────────────►│ │
│ │ │ │ │
│ 「我想做一个新员工入职流程，需要三个 Agent 协作」 │
│ 「答案是：你得写大量的胶水代码，处理三种不同的协议」 │
│ │
└─────────────────────────────────────────────────────────────────┘
1.2 现有方案的局限
在 A2A 之前，开发者尝试过几种方案，但都有明显缺陷：
方案 A：让所有 Agent 用同一个框架
- 缺点：不现实。企业历史遗留系统、不同团队的技术选型、第三方 SaaS 的封闭实现，都不受你控制。
方案 B：用消息队列（Kafka/RabbitMQ）硬连
- 缺点：需要暴露内部实现细节，破坏 Agent 的自主性，且消息格式没有标准。
方案 C：让一个「超级 Agent」调用其他 Agent 作为工具
- 缺点：这是 Anthropic MCP 的思路，适合工具调用，但不适合对等协作（peer-to-peer collaboration）。
1.3 A2A 的破局
A2A 协议的核心洞察是：Agent 之间的协作，应该像微服务之间的调用一样标准化。
正如 REST + OpenAPI 定义了微服务通信的标准，A2A 定义了 Agent 通信的标准：
┌──────────────────────────────────────────────────────────────────────┐
│ A2A 的愿景：Agent 的「HTTP」 │
├──────────────────────────────────────────────────────────────────────┤
│ │
│ 以前：每个框架有自己的 Agent 通信方式 │
│ 现在：所有框架的 Agent 都实现 A2A 协议 │
│ │
│ HR Agent (ADK) ──── A2A ────> Sales Agent (LangChain) │
│ │ │ │
│ └──────────── A2A ──────────────┘ │
│ │
│ 关键特性： │
│ ✓ 不暴露内部实现（黑盒协作） │
│ ✓ 支持长时任务（异步、流式更新） │
│ ✓ 企业级安全（OAuth 2.0、OpenID Connect） │
│ ✓ 基于成熟标准（HTTP、JSON-RPC、SSE） │
│ │
└──────────────────────────────────────────────────────────────────────┘
2. A2A 协议核心设计哲学
2.1 五大设计原则
A2A 协议并非简单的「消息格式定义」，而是一套完整的技术哲学。理解这些原则，才能正确实现和使用 A2A。
原则 1：Agent 即 Agent（Agent as Agent），而非工具
这是 A2A 与 MCP 最本质的区别。
- MCP（Model Context Protocol）：把外部能力暴露为「工具」，LLM 通过
tools/call主动调用。工具是无状态的、被动的。 - A2A：把协作方视为「对等 Agent」，它可以自主推理、主动请求补充信息、异步执行长时任务。
# MCP 的思路：工具调用（同步、无状态）
result = client.call_tool(
name="search_database",
arguments={"query": "SELECT * FROM users"}
)
# 立即返回结果，工具无法主动与你沟通
# A2A 的思路：Agent 协作（异步、有状态）
task = client.send_task(
agent="data-analyst-agent",
message="分析上个季度的用户增长趋势"
)
# Agent 可能回复：
# "需要你补充一下：是否包含测试账号？"
# "正在处理，当前进度 30%"
# "完成，这是分析报告（包含图表文件）"
原则 2：基于标准构建（Build on Standards）
A2A 没有发明新的传输协议，而是基于互联网最成熟的标准：
- HTTP/HTTPS：传输层
- JSON-RPC 2.0：消息格式（为什么不用 REST？因为 RPC 更适合双向、异步的场景）
- Server-Sent Events (SSE)：长时任务的流式更新
- OpenAPI / JSON Schema：Agent Card 的描述规范
这意味着：你可以直接用现有的 HTTP 服务器、负载均衡器、API 网关来部署 A2A Agent。不需要特殊的消息中间件。
原则 3：默认安全（Secure by Default）
企业环境中，Agent 可能处理薪资数据、客户信息、商业机密。A2A 从设计上支持：
- 认证：OAuth 2.0、API Key、OpenID Connect
- 授权：基于 Agent Card 中声明的
skills进行细粒度权限控制 - 审计：每个 Task 都有完整的状态变更历史
原则 4：支持长时任务（Long-Running Tasks）
AI Agent 执行的任务，可能耗时几秒（简单查询），也可能耗时几小时（深度研究、代码生成、多步推理）。
A2A 通过以下机制支持长时任务：
- 异步任务提交：
tasks/send立即返回taskId，不阻塞 - 流式进度更新：
tasks/sendSubscribe通过 SSE 推送实时进度 - 任务轮询：
tasks/get随时查询任务状态 - 断点续传：Task 状态持久化，Agent 重启后任务可恢复
原则 5：不透明协作（Collaborate without Exposure）
A2A 允许 Agent 之间协作，无需暴露内部实现细节。
这对于企业场景至关重要：
- Salesforce 不会把 CRM Agent 的提示词、工具调用链、内部知识库暴露给你
- 但你可以通过 A2A 协议，向 Salesforce CRM Agent 委派「更新客户状态」的任务
┌─────────────────────────────────────────────────────────────────┐
│ 不透明协作的精妙之处 │
├─────────────────────────────────────────────────────────────────┤
│ │
│ 你的 Agent Salesforce CRM Agent │
│ ┌───────────┐ ┌───────────────────────────┐ │
│ │ 不知道: │ │ │ │
│ │ - 用啥模型 │ A2A │ 不知道: │ │
│ │ - 提示词 │ ────────> │ - 你的业务上下文 │ │
│ │ - 工具链 │ (只交换 │ - 其他 Agent 的存在 │ │
│ │ - 知识库 │ 任务/结果) │ │ │
│ └───────────┘ └───────────────────────────┘ │
│ │ │ │
│ │ 只知道: │ 只知道: │
│ │ - Agent Card │ - 收到的任务 │
│ │ - 任务状态 │ - 需要返回的结果 │
│ │
└─────────────────────────────────────────────────────────────────┘
2.2 A2A 协议的核心抽象
A2A 定义了四个核心抽象，理解它们是掌握 A2A 的关键：
| 抽象 | 作用 | 类比 |
|---|---|---|
| Agent Card | Agent 的「数字名片」，描述能力和接入点 | 微服务的 /actuator/info + OpenAPI 文档 |
| Task | 一次协作的载体，有完整的生命周期 | HTTP 请求（但有更复杂的状态机） |
| Message | Agent 之间的对话单元 | 邮件的正文 |
| Part | Message 的基本组成（文本/文件/结构化数据） | 邮件的正文、附件、表单数据 |
3. Agent Card：Agent 的「数字名片」深度解析
3.1 Agent Card 是什么？
Agent Card 是一个标准的 JSON 文件，通常托管在 Agent 服务的 /.well-known/agent.json 路径下。
任何想要与这个 Agent 协作的客户端（或其他 Agent），首先获取它的 Agent Card，了解：
- 这个 Agent 叫什么？
- 它有什么能力（skills）？
- 怎么调用它（endpoint、认证方式）？
- 它支持流式处理吗？支持推送通知吗？
3.2 Agent Card 完整 JSON Schema
以下是一个生产级的 Agent Card 示例（包含全部关键字段）：
{
"agent_card_version": "a2a-0.3",
"name": "senior-data-analyst-agent",
"description": "资深数据分析 Agent，支持 SQL 查询、趋势分析、可视化报告生成。接受自然语言输入，自动选择数据源，输出包含图表的交互式报告。",
"version": "2.1.0",
"icon_url": "https://assets.example.com/agents/data-analyst.png",
"homepage_url": "https://data-analyst.example.com",
"capabilities": {
"streaming": true,
"push_notifications": true,
"state_transition_history": true,
"tasks_persistence": true,
"multimodal": ["text", "file", "data"],
"max_concurrent_tasks": 10
},
"skills": [
{
"id": "sql-query",
"name": "SQL 查询执行",
"description": "将自然语言转换为 SQL，在授权的数据库上执行，返回结构化结果。支持 MySQL、PostgreSQL、ClickHouse。",
"tags": ["sql", "database", "query"],
"input_modes": ["text"],
"output_modes": ["text", "data", "file"],
"examples": [
"查询上个季度的月活用户数",
"找出消费金额 top 10 的 VIP 客户"
]
},
{
"id": "trend-analysis",
"name": "趋势分析",
"description": "对时间序列数据进行趋势拟合、异常检测、未来预测。支持线性回归、ARIMA、Prophet 等算法。",
"tags": ["trend", "forecasting", "anomaly-detection"],
"input_modes": ["text", "data"],
"output_modes": ["text", "file"],
"examples": [
"分析过去一年的 GMV 增长趋势，预测下个季度"
]
},
{
"id": "report-generation",
"name": "分析报告生成",
"description": "整合查询结果和分析结论，生成包含图表、洞察建议的 HTML/PDF 报告。",
"tags": ["report", "visualization", "insights"],
"input_modes": ["text", "data"],
"output_modes": ["file"],
"examples": [
"生成 Q2 用户增长分析报告，包含趋势图和建议"
]
}
],
"endpoint": "https://data-analyst.example.com/a2a",
"authentication": {
"schemes": ["bearer", "api_key"],
"instructions": "在 Authorization header 中携带 Bearer token，或在 X-API-Key header 中携带 API Key。"
},
"default_input_modes": ["text"],
"default_output_modes": ["text", "file"],
"provider": {
"organization": "Example Corp Data Team",
"url": "https://example.com"
},
"contact": {
"name": "Data Platform Team",
"email": "data-platform@example.com"
},
"license": "proprietary",
"terms_of_service": "https://example.com/terms",
"privacy_policy": "https://example.com/privacy"
}
3.3 Agent Card 字段逐项详解
agent_card_version
协议版本号。当前最新是 a2a-0.3。客户端应根据版本号决定是否支持某些新特性。
skills[]
这是 Agent Card 最核心的字段。每个 skill 描述 Agent 的一项具体能力。
关键设计决策：skills 是语义描述，而非函数签名。这意味着：
# ❌ 错误的思路（太底层，暴露实现细节）
"skills": [{
"name": "execute_sql",
"parameters": {
"type": "object",
"properties": {
"query": {"type": "string"},
"database": {"type": "string"}
}
}
}]
# ✅ 正确的思路（语义化，关注「能做什么」）
"skills": [{
"id": "sql-query",
"name": "SQL 查询执行",
"description": "将自然语言转换为 SQL...",
"examples": ["查询上个季度的月活用户数"]
}]
capabilities
声明 Agent 支持的协议特性：
streaming: true：支持tasks/sendSubscribe，通过 SSE 推送进度push_notifications: true：支持任务完成后主动推送通知（通过 webhook）state_transition_history: true：tasks/get返回完整的状态变更历史
authentication
安全设计的精髓：Agent Card 公开声明支持的认证方式，但不包含密钥本身。这类似于 OAuth 2.0 的 Discovery Endpoint。
# 客户端发现认证方式
agent_card = requests.get("https://data-analyst.example.com/.well-known/agent.json").json()
auth_schemes = agent_card["authentication"]["schemes"]
# ["bearer", "api_key"]
# 根据本地配置的凭证，选择合适的认证方式
if "bearer" in auth_schemes:
headers["Authorization"] = f"Bearer {load_token()}"
elif "api_key" in auth_schemes:
headers["X-API-Key"] = load_api_key()
3.4 Agent Card 的发现机制
A2A 支持三种 Agent 发现方式：
方式 1：静态发现（Well-Known URL）
GET https://data-analyst.example.com/.well-known/agent.json
最适合：你知道 Agent 的域名，想直接使用。
方式 2：注册中心（Agent Registry）
企业可以搭建一个中心化的 Agent 注册中心（类似服务发现中的 Consul/Etcd）。
# 注册 Agent
POST /registry/register
{
"agent_card_url": "https://data-analyst.example.com/.well-known/agent.json",
"health_check_url": "https://data-analyst.example.com/health"
}
# 发现 Agent（按 skill tag 搜索）
GET /registry/discover?tag=sql&tag=database
方式 3：动态广播（mDNS / 企业服务网格）
在局域网或 Kubernetes 集群内，Agent 可以通过 mDNS 或 Service Mesh 的服务发现机制自动暴露。
# Kubernetes Service 定义中嵌入 Agent Card 注解
apiVersion: v1
kind: Service
metadata:
name: data-analyst-agent
annotations:
a2a.io/agent-card-path: "/.well-known/agent.json"
a2a.io/skills: "sql-query,trend-analysis,report-generation"
4. 任务生命周期：从提交到完成的完整状态机
4.1 Task 的数据结构
每个 A2A 任务用一个唯一的 taskId 标识，其完整结构如下：
{
"taskId": "task_9f8a7b6c-3d2e-4f1a-9b0c-8e7d6f5a4b3c",
"contextId": "conv_1a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d",
"status": {
"state": "working",
"timestamp": "2026-07-04T10:15:30.123Z",
"message": {
"role": "agent",
"parts": [{"type": "text", "text": "正在执行 SQL 查询，已扫描 3 张表..."}]
}
},
"history": [
{"state": "submitted", "timestamp": "2026-07-04T10:15:00.000Z"},
{"state": "working", "timestamp": "2026-07-04T10:15:05.000Z"}
],
"artifacts": [],
"metadata": {
"requester": "orchestrator-agent",
"priority": "high",
"timeout_seconds": 1800
}
}
4.2 完整的状态机
A2A Task 的状态机设计，借鉴了 Kubernetes Pod 生命周期和 HTTP 状态码的设计哲学：
┌─────────────┐
│ submitted │ 初始状态：任务已接收，但未开始处理
└──────┬──────┘
│
┌─────▼──────┐
│ working │ 处理中：Agent 正在执行任务
└─────┬──────┘
│
┌────────────────┼────────────────┐
│ │ │
┌─────▼─────┐ ┌─────▼─────┐ ┌─────▼─────┐
│ input_required │ │completed │ │ failed │
│ (需补充信息) │ │ (成功) │ │ (失败) │
└─────┬─────┘ └────────────┘ └──────┬────┘
│ │
│ ┌───────▼───────┐
│ │ cancelled │
│ │ (被取消) │
│ └───────────────┘
┌─────▼─────┐
│ (补充后 │
│ 回到 │
│ working) │
└───────────┘
状态详解
| 状态 | 含义 | 触发条件 |
|---|---|---|
submitted | 任务已提交，等待 Agent 接收 | 客户端调用 tasks/send 成功后 |
working | Agent 正在处理任务 | Agent 开始执行，或收到补充信息后恢复执行 |
input_required | Agent 需要更多信息才能继续 | Agent 发现任务描述不够明确，主动请求补充 |
completed | 任务成功完成，artifacts 可获取 | Agent 执行完毕，生成了完整结果 |
failed | 任务执行失败 | 遇到不可恢复的错误（如数据库连接失败、LLM 调用失败） |
cancelled | 任务被客户端取消 | 客户端调用 tasks/cancel |
4.3 input_required：A2A 最精妙的设计之一
传统 API 调用中，如果参数不完整，服务器直接返回 400 Bad Request。
A2A 的 input_required 状态允许 Agent 主动请求补充信息，这才是真正的「对话式协作」：
# === 场景：不完整的任务描述 ===
# 客户端发送任务
POST /a2a
{
"method": "tasks/send",
"params": {
"taskId": "task_001",
"message": {
"role": "user",
"parts": [{"type": "text", "text": "帮我分析一下用户数据"}]
}
}
}
# Agent 回复：需要补充信息
{
"taskId": "task_001",
"status": {
"state": "input_required",
"message": {
"role": "agent",
"parts": [{"type": "text", "text": "请问您想分析哪个时间范围的数据？以及关注哪些指标（如 DAU、留存率、转化率）？"}]
}
}
}
# 客户端补充信息（注意：这是同一个人机对话的延续）
POST /a2a
{
"method": "tasks/send",
"params": {
"taskId": "task_001", # 同一个 taskId
"message": {
"role": "user",
"parts": [{"type": "text", "text": "分析 Q2 季度的 DAU 和 7 日留存率"}]
---
> **温馨提示**：本文篇幅较长，已截取核心部分。完整版本请访问程序员茄子官网查看。