A2A协议与Agent生态全景
前面咱们学了 MCP（Model Context Protocol），它是一个让 AI 发现和调用工具的标准化协议，本质上解决的是垂直方向的问题——一个 Agent 如何获取和使用外部能力。
但现实世界中的工作不是一个人完成的，而是团队协作的结果。随着 Agent 在各行各业的部署，一个新问题浮出水面：当多个 Agent 需要互相通信、协商、协作时，它们之间用什么"语言"？
这就是 A2A（Agent-to-Agent Protocol）要解决的问题。
从单人干活到团队协作
先想一个场景。你是一家电商公司的技术负责人，公司已经部署了三个 Agent：
- 客服 Agent：处理用户咨询、退货退款
- 仓储 Agent：管理库存、发货、入库
- 物流 Agent：对接快递公司、追踪包裹
之前它们各干各的，没问题。但有一天，一个用户问客服："我前天买的蓝牙耳机怎么还没到？"
客服 Agent 能查到订单，但查不到包裹位置——那是物流 Agent 的地盘。客服 Agent 需要去问物流 Agent："订单 #12345，帮我查下物流状态。"物流 Agent 查完回一句："快递员正在派送中，预计下午 3 点前到。"
Agent 和 Agent 之间的这条通信链路，就是 A2A 来标准化的事情。
你可能会问："这不就是 API 调用吗？客服 Agent 调一下物流 Agent 的 API 不就行了？"
这里有一个关键区别。
为什么 API 调用不够用
普通的 API 调用是结构化、预定义的：
POST /logistics/track
Body: {"orderId": "12345"}
Response: {"status": "delivering", "eta": "2026-05-15 15:00"}
这在工作流程完全确定时够用。但 Agent 之间的交互往往是非结构化的、上下文相关的、需要协商的。比如：
- 任务协商："这个需求我一个人搞不定，你能帮忙做 A 部分吗？"
- 信息澄清："你说的'那个客户'是指张三还是李四？最近两天都在和他们沟通。"
- 结果确认："我分析出了三种方案，你帮我看看哪个更合适？"
- 能力发现："我没有翻译功能，哪个 Agent 能做中译英？"
- 进度同步："我已经完成了数据清洗，可视化部分转交给谁？"
这些交互的特点是：不确定的、上下文敏感的、像人和人之间的对话。而传统 API 是为确定性的机器间通信设计的，不太适合这种场景。
A2A 是什么
A2A（Agent-to-Agent Protocol） 是 Google 于 2025 年 4 月发布的开放协议，定义了 AI 智能体之间如何进行标准化的任务协调、信息交换和能力发现。
把它和我们已经学过的概念放在一起看，层次关系就清楚了：
A2A（水平协作）
Agent ←──→ Agent ←──→ Agent
↓ ↓ ↓
MCP MCP MCP（垂直能力）
↓ ↓ ↓
工具/API 工具/API 工具/API
- MCP：Agent 向下获取能力（调用工具、读取资源）
- A2A：Agent 之间横向协作（任务委托、信息交换、能力发现）
两者不是竞争关系，而是互补关系。
A2A 的核心设计
A2A 基于几个关键设计理念：
1. 基于"Agent Card"的能力发现
每个 Agent 发布一张"名片"（Agent Card），描述自己能做什么：
{
"name": "物流追踪Agent",
"description": "负责查询快递物流状态、计算预计送达时间、处理物流异常",
"url": "https://logistics-agent.company.com/a2a",
"capabilities": {
"streaming": true,
"pushNotifications": false
},
"skills": [
{
"id": "track_package",
"name": "追踪包裹",
"description": "根据订单号查询包裹的实时物流状态"
},
{
"id": "estimate_delivery",
"name": "预计送达",
"description": "计算预计送达时间，支持多快递公司"
},
{
"id": "report_exception",
"name": "物流异常上报",
"description": "上报丢件、破损、滞留等物流异常情况"
}
],
"defaultInputModes": ["text", "file"],
"defaultOutputModes": ["text"]
}
当客服 Agent 需要查询物流时，它先看物流 Agent 的 Agent Card，发现它有 track_package 技能，然后发起任务。Agent Card 让 Agent 能自动发现"谁可以做什么"，而不需要人工配置调用关系。
2. 任务（Task）为核心
A2A 的通信以"任务"（Task）为单位，不是一次性的 API 调用。一个 Task 有其生命周期：
创建（Created）→ 处理中（Processing）→ 完成（Completed）
→ 失败（Failed）
→ 需要澄清（NeedsClarification）
这比 API 请求-响应模型更灵活。比如物流 Agent 处理到一半发现订单号模糊，它可以把 Task 状态设为"NeedsClarification"，附带一个澄清问题。客服 Agent 收到后，去问用户，然后把澄清信息补上，Task 继续。
3. 多模态通信
A2A 支持文本、文件、图片、视频等多种内容格式。Agent 之间不仅能"说话"，还能共享文件、传图片、交换结构化数据。
4. 流式和非流式支持
Agent 的推理和操作可能需要时间。A2A 支持流式返回中间状态，让请求方知道任务在进展中，而不是干等。
A2A 的任务生命周期
理解了 Task 的概念后，我们走一遍完整的 Task 生命周期：
阶段1: 任务创建
客服Agent → 物流Agent:
"帮我查订单 #12345 的物流状态"
Task状态: Created
阶段2: 任务处理中
物流Agent:
1. 解析订单号
2. 调用快递公司 API
3. 等待结果返回...
Task状态: Processing
阶段2.1: [可能的] 需要澄清
物流Agent → 客服Agent:
"订单 #12345 对应两个快递单号：SF123 和 YT456，你要查哪个？"
Task状态: NeedsClarification
客服Agent → 用户 → 客服Agent → 物流Agent:
"查 SF123"
Task状态: Processing（继续）
阶段3: 任务完成
物流Agent → 客服Agent:
{
"status": "派送中",
"courier": "顺丰快递",
"current_location": "上海分拣中心",
"eta": "2026-05-15 15:00",
"tracking_url": "https://sf-express.com/track/SF123"
}
Task状态: Completed
注意 Task 和 API Call 的关键区别：Task 是有状态的、长生命周期的、可能需要多次交互的。 API Call 是一次请求一次响应就结束了。A2A 的 Task 可以跨越多轮对话、多次人员介入、多个 Agent 的协作。
A2A vs MCP vs Function Call
这可能是你最关心的问题：学了 Function Call，学了 MCP，现在又来个 A2A，它们三个到底怎么区分？
| 维度 | Function Call | MCP | A2A |
|---|---|---|---|
| 通信方向 | LLM → 工具 | Agent → 工具服务 | Agent ←→ Agent |
| 解决的问题 | "该调哪个函数，传什么参数" | "如何标准化管理和发现工具" | "Agent 之间怎么协作" |
| 核心单位 | 一次工具调用 | 一个工具服务器 | 一个任务（Task） |
| 有状态吗 | 否（单次调用） | 否（连接有状态，调用无状态） | 是（Task 有完整生命周期） |
| 谁定义的 | 各 LLM 厂商各自实现 | Anthropic | |
| 协议层 | 不是协议，是 LLM 功能 | JSON-RPC 2.0 | HTTP + SSE + JSON |
| 类比 | 人的"动手能力" | USB Type-C 标准接口 | 团队协作工作流 |
它们在同一个系统中的位置
想象一个完整的 Agent 系统：
用户: "帮我分析竞品A的价格策略，然后生成一份报告发到老板邮箱"
↓
┌─────────────────────────────────────────┐
│ 编排Agent（使用 A2A 协调子Agent） │
│ ┌──────┐ A2A ┌──────┐ A2A ┌──────┐ │
│ │数据 │←────→│分析 │←────→│报告 │ │
│ │Agent │ │Agent │ │Agent │ │
│ └──┬───┘ └──┬───┘ └──┬───┘ │
│ │MCP │MCP │MCP │
│ ↓ ↓ ↓ │
│ [爬虫工具] [统计工具] [邮件工具] │
│ [数据库] [图表工具] [文档模板] │
└─────────────────────────────────────────┘
- 编排 Agent 通过 A2A 把子任务分派给数据 Agent、分析 Agent、报告 Agent
- 每个子 Agent 通过 MCP 调用自己需要的工具
- 工具内部使用 Function Call 机制让 LLM 决定调用哪个函数
三者互不冲突，协同工作。
A2A 的 Java 实践
虽然没有 Spring AI 官方的 A2A 支持，但你可以基于 HTTP 和 JSON 实现 A2A 的核心机制：
Agent Card 的定义
@Data
public class AgentCard {
private String name;
private String description;
private String url;
private Map<String, Boolean> capabilities;
private List<Skill> skills;
@Data
public static class Skill {
private String id;
private String name;
private String description;
}
}
Agent Card 端点
@RestController
@RequestMapping("/a2a")
public class A2AController {
private final AgentCard myCard;
public A2AController() {
this.myCard = new AgentCard();
myCard.setName("物流追踪Agent");
myCard.setDescription("负责查询快递物流状态");
myCard.setUrl("https://logistics-agent.company.com/a2a");
myCard.setSkills(List.of(
new AgentCard.Skill("track_package", "追踪包裹", "根据订单号查询物流"),
new AgentCard.Skill("estimate_delivery", "预计送达", "计算预计送达时间")
));
}
// Agent Card 端点：任何 Agent 都可以访问
@GetMapping("/.well-known/agent-card.json")
public AgentCard getAgentCard() {
return myCard;
}
// Task 端点：接收其他 Agent 的任务
@PostMapping("/tasks")
public ResponseEntity<TaskResponse> createTask(@RequestBody TaskRequest request) {
// 根据请求中的 skill ID 路由到具体处理逻辑
String skillId = request.getSkillId();
String result = switch (skillId) {
case "track_package" -> trackPackage(request.getParameters());
case "estimate_delivery" -> estimateDelivery(request.getParameters());
default -> throw new IllegalArgumentException("Unknown skill: " + skillId);
};
return ResponseEntity.accepted().body(new TaskResponse("processing", result));
}
}
Agent 间调用
@Service
public class AgentCollaborationService {
private final RestClient restClient;
public AgentCollaborationService(RestClient.Builder builder) {
this.restClient = builder.build();
}
/**
* 发现其他 Agent 的能力
*/
public AgentCard discoverAgent(String agentBaseUrl) {
return restClient.get()
.uri(agentBaseUrl + "/.well-known/agent-card.json")
.retrieve()
.body(AgentCard.class);
}
/**
* 向另一个 Agent 发起任务
*/
public TaskResponse delegateTask(AgentCard targetAgent,
String skillId,
Map<String, Object> params) {
TaskRequest request = new TaskRequest();
request.setSkillId(skillId);
request.setParameters(params);
return restClient.post()
.uri(targetAgent.getUrl() + "/tasks")
.body(request)
.retrieve()
.body(TaskResponse.class);
}
}
Agent 生态全景图（2026 年 5 月）
学完这么多概念，你可能需要一个全景视角。以下是当前 AI Agent 生态的整体格局：
基础设施层
| 组件 | 代表技术 | 作用 |
|---|---|---|
| 大模型 | GPT-5.x, Claude 4.5, Gemini 3.1, DeepSeek-V3.2/R1 | 提供理解和推理能力 |
| 推理模型 | o3, R1, Qwen3-Slow | 提供深度推理能力 |
| 嵌入模型 | text-embedding-v3, bge-m3 | 向量化文本，支撑 RAG |
| 向量数据库 | Milvus, Qdrant, PGVector | 存储和检索向量 |
协议与标准层
| 协议 | 发布时间 | 发起方 | 解决问题 |
|---|---|---|---|
| Function Call | 2023 | OpenAI | LLM 如何输出工具调用指令 |
| MCP | 2024.11 | Anthropic | Agent 如何标准化管理工具 |
| A2A | 2025.04 | Agent 之间如何协作通信 | |
| AGENTS.md | 2025 | 社区 | 项目如何向 AI 描述自己 |
框架与运行时层
| 框架 | 语言 | 特点 |
|---|---|---|
| Spring AI | Java | Spring 生态，企业级 |
| Spring AI Alibaba | Java | 增强版，Graph 工作流 + 百炼集成 |
| LangChain | Python/JS | 最成熟，生态最丰富 |
| LangGraph | Python | 有状态工作流编排 |
| CrewAI | Python | 多 Agent 协作，角色扮演 |
| AutoGen | Python | 微软，自主对话 Agent |
| Dify | 低代码 | 可视化编排，快速搭建 |
产品与平台层
| 产品 | 类型 | 核心能力 |
|---|---|---|
| OpenClaw（龙虾） | 自托管 Agent 运行时 | 7×24 自主执行，多平台集成 |
| Paperclip | Agent 编排平台 | 创建完整 AI"公司" |
| Claude Code | AI IDE/CLI | 终端中的 AI 编程助手 |
| Cursor | AI IDE | 集成 AI 的代码编辑器 |
| Codex CLI | AI CLI | OpenAI 的命令行 AI 工具 |
| Operator | AI 浏览器操作 | OpenAI 的网页操作 Agent |
这个格局告诉我们的几件事
1. 协议统一正在进行
2024-2025 年，MCP 和 A2A 分别解决了 Agent 的"向下获取能力"和"水平协作"的标准化问题。虽然它们来自不同的厂商（Anthropic 和 Google），但社区已经在同时采纳两者。未来的 Agent 系统大概率是 MCP + A2A 的组合。
2. 从"框架"到"平台"
2023-2024 年的主题是框架（LangChain、Spring AI、CrewAI），让开发者能搭建 Agent。2025-2026 年的主题是平台（OpenClaw、Paperclip、Dify），让 Agent 能长期运行、自我管理。这类似于软件工程从"写代码"到"运维"的演进——Agent 也需要 DevOps。
3. Agent 正在"向下扎根"
Agent 不再只是对话界面后面的一个后端服务。它正在进入操作系统层面——Claude Code 在你的终端里，OpenClaw 在你的桌面上，Operator 在你的浏览器里。Agent 越接近操作系统，它能做的事情就越多，但也越需要安全边界的约束。
4. Skills 成为可复用单元
Skills（技能包）成为一个跨框架的概念。Spring AI、Claude Code、OpenClaw、Codex CLI 都有自己的 Skills 体系。虽然格式还没统一，但理念基本一致：目录结构、声明式元数据、渐进式加载、按需执行。Skills 可能成为 Agent 时代的"npm 包"或"App Store"。
小结
A2A 是什么：Google 发布的 Agent 间通信协议，解决 Agent 如何发现彼此能力、发起任务、协调协作的问题
和 MCP 的关系：互补而非竞争
- MCP = 垂直（Agent → 工具）
- A2A = 水平（Agent ←→ Agent）
Task 为核心：A2A 以有状态、长生命周期的 Task 为单位，而非一次性 API 调用，支持澄清、协商、中断恢复
技术选型参考：
- 单个 Agent + 少量工具 → Function Call 就够了
- 大量工具 + 跨团队复用 → 加 MCP
- 多 Agent 协作 → 加 A2A
- 需要 7×24 自主运行 → 上 OpenClaw 类平台
Agent 生态趋势：
- 协议统一（MCP + A2A 组合）
- 从框架到平台（Agent DevOps）
- Agent 向下扎根（进入 OS 层面）
- Skills 成为可复用单元
下一篇咱们来聊聊 Vibe Coding 与 AI 驱动的开发新范式——当 AI 不只是辅助编码，而是彻底改变软件开发的方式。
企业级项目导航：⬅️ 05-进阶特性与源码探秘 | 01-A2A协议与Agent生态全景 | ➡️ 02-AI驱动开发新范式：VibeCoding与智能IDE
💬 评论