A2A 实战系列：从 Agent 互连到企业级协作
本系列共 6 篇，从认识 A2A 到企业级多 Agent 治理，层层递进。每篇独立可读，又前后衔接。
⚠️ 版本与事实声明（发布前必读）
关于 A2A 协议
- A2A（Agent2Agent Protocol）由 Google 于 2025 年 4 月 联合 50+ 企业发布，2025 年 6 月 捐赠给 Linux 基金会。本文写"发布"和"捐赠"两个时间点，不混为一谈。
- 协议规范仍在演进。本文基于 2025 年中后期的公开规范 编写，具体字段、状态、方法以 官方规范仓库 为准。
- Agent Card 路径：新实现优先使用
/.well-known/agent-card.json；早期规范使用/.well-known/agent.json。兼容旧客户端时可同时提供两者。
关于 Java SDK
- A2A Java SDK 仍在早期，包名（
io.a2a/io.a2a.sdk/dev.a2a都可能出现）和类名会随版本变化。本文示例的 import 仅为示意，以 官方 Java SDK 仓库 和 Maven Central 当前版本为准。 - 文中出现的
AgentCard、AgentExecutor、A2AServer、DefaultRequestHandler、InMemoryTaskStore、A2AClient等类名，请以当前 SDK 版本 README 为准。 - MCP Java SDK 类名（如
WebFluxSseClientTransport）同样以当前版本为准。
系列导读
| 篇 | 标题 | 核心交付 | 适合 |
|---|---|---|---|
| 1 | 认识 A2A：Agent 之间的 HTTP | 概念、架构、与 MCP 的关系、反模式、传输 | 所有人 |
| 2 | A2A 核心概念：Agent Card、Task、Message、Artifact | 协议数据模型、状态机、JSON-RPC 方法、错误码 | 要写 Agent 的开发者 |
| 3 | Java 实战：用官方 SDK 写第一个 A2A Agent | 可运行 Agent + Client + 单测 + 集成测试骨架 | Java 开发者 |
| 4 | 多 Agent 协作：多轮、流式、推送、编排 | 长任务、流式、编排、超时、部分失败、重试 | 架构设计者 |
| 5 | A2A + MCP：Agent 既是 Server 也是 Client | 双协议组合、工具层与协作层、反模式 | 平台开发者 |
| 6 | 企业级 A2A 治理：注册中心、网关、安全、可观测 | Registry + Gateway + OAuth2 + 缓存 + 防循环 | 企业架构师 |
阅读路径：
- 快速建立认知：1 → 2
- 写第一个 Agent：1 → 2 → 3
- 多 Agent 协作：1 → 2 → 3 → 4
- 平台化落地：全系列
第 1 篇：认识 A2A------Agent 之间的 HTTP
📍 系列导航 ：1. 认识 A2A ｜ 2. 核心概念 ｜ 3. Java 实战 ｜ 4. 多 Agent 协作 ｜ 5. A2A + MCP ｜ 6. 企业治理
1.1 一个真实痛点
假设你有一个销售 Agent，能查销售数据；一个人事 Agent，能查员工信息；一个财务 Agent，能查发票。用户问：
"帮我分析一下华东区销售团队的业绩，结合人事的团队构成和财务的费用数据。"
传统做法：
- 写一个超级 Agent，把所有能力塞进去 → 上下文爆炸、权限混乱、团队耦合。
- 写胶水代码：销售 Agent 调人事 Agent 的 HTTP API → 再调财务 Agent 的 API → 自己解析、拼接。
- 每个 Agent 之间点对点集成，N 个 Agent 需要 N×(N-1) 套胶水。
💡 问题不是"Agent 之间不能调"，而是"Agent 之间没有标准说话方式"。
A2A 就是来解决这个的。
1.2 A2A 是什么
A2A（Agent2Agent Protocol）是一个开放协议，用来标准化 AI Agent 之间的发现、通信与协作。
时间线：
- 2025 年 4 月：Google 联合 50+ 企业发布 A2A 协议。
- 2025 年 6 月：捐赠给 Linux 基金会，进入开放治理。
- 此后：规范、SDK、生态持续演进。
一句话：
A2A 是让 Agent 发现彼此、委派任务、交换结果的通用协议。
类比：
| 类比 | 说明 |
|---|---|
| HTTP | 让浏览器和服务器说话 |
| MCP | 让 Agent 和工具/数据源说话 |
| A2A | 让 Agent 和 Agent 说话 |
1.3 A2A 和 MCP 是什么关系
这是最容易混淆的点。先给结论：
💡 MCP 是垂直方向（Agent → 工具），A2A 是水平方向（Agent ↔ Agent）。两者互补，不是竞争。
text
┌─────────────┐
│ User │
└──────┬──────┘
│
┌──────▼──────┐
│ Orchestrator│
│ Agent │
└──┬───┬───┬──┘
│ │ │ A2A（水平协作）
┌─────▼┐ ┌▼───┐ ┌▼─────┐
│Sales │ │HR │ │Finance│
│Agent │ │Agent│ │Agent │
└──┬───┘ └─┬──┘ └──┬───┘
│ │ │ MCP（垂直调用）
┌──▼──┐ ┌──▼──┐ ┌──▼───┐
│ DB │ │ HR │ │ ERP │
│ │ │ API │ │ │
└─────┘ └─────┘ └──────┘| 维度 | MCP | A2A |
|---|---|---|
| 方向 | Agent → 工具/数据 | Agent ↔ Agent |
| 核心原语 | Tool / Resource / Prompt | Task / Message / Artifact |
| 交互模型 | 调用-返回 | 任务生命周期、多轮、流式 |
| 发现机制 | Server 配置 / 注册中心 | Agent Card |
| 状态 | 通常无状态 | Task 有状态 |
| 典型场景 | 查数据库、读文件 | 委派任务、多 Agent 协作 |
一个 Agent 可以同时是 MCP Client（调工具）和 A2A Server（被其他 Agent 调）。 第 5 篇会展开。
反面案例：什么时候不该用 A2A
❌ 反模式：把"查数据库"包装成 A2A Agent。
查数据库是确定性函数调用，没有推理、没有多轮、没有任务生命周期。用 MCP 包一个 Tool 就够了。硬套 A2A 会带来：
- 不必要的 Task 状态管理
- 额外的网络跳转和序列化开销
- 调用方要处理
input-required等本不需要的复杂度
判断标准：能力是"确定性函数"→ MCP；能力是"会思考、要委派、有多轮"的 Agent → A2A。
1.4 A2A 的架构
text
┌─────────────────────────────────────────┐
│ Client Agent（调用方） │
│ 1. 获取 Agent Card │
│ 2. 发 message/send 或 message/stream │
│ 3. 跟踪 Task 状态 │
│ 4. 接收 Artifact │
└───────────────┬─────────────────────────┘
│ A2A（HTTP + JSON-RPC 2.0）
┌───────────────▼─────────────────────────┐
│ Server Agent（被调方） │
│ 1. 发布 Agent Card │
│ 2. 接收 Message │
│ 3. 创建/更新 Task │
│ 4. 返回 Message / Artifact │
└─────────────────────────────────────────┘两个角色：
- Client Agent：发起任务的一方。
- Server Agent：接收任务、执行、返回结果的一方。
和 MCP 不同，A2A 的双方都是 Agent，都可能具备推理能力。A2A 不规定 Agent 内部怎么实现，只规定它们怎么说话。
1.5 A2A 的核心原语
| 原语 | 是什么 | 谁控制 | 例子 |
|---|---|---|---|
| Agent Card | Agent 的"名片"，描述能力、端点、认证 | Server Agent 发布 | /.well-known/agent-card.json |
| Task | 一次任务，有生命周期 | 双方共同推进 | task-123：分析华东业绩 |
| Message | 任务中的一条消息 | 双方发送 | "请补充时间范围" |
| Part | 消息/产物的内容片段 | 消息携带 | 文本、文件、结构化数据 |
| Artifact | 任务产出物 | Server Agent 生成 | 分析报告 PDF |
| Skill | Agent 声明的能力 | Server Agent 声明 | sales_analysis |
📌 配图建议：发布时配一张 Agent Card → Task → Message → Artifact 的关系图，展示一次完整交互。
1.6 传输方式
A2A 基于 HTTP + JSON-RPC 2.0：
| 能力 | 说明 |
|---|---|
| 同步调用 | message/send，返回 Task 或 Message |
| 流式 | message/stream，SSE 流式返回状态和产物 |
| 推送通知 | tasks/pushNotificationConfig/set，长任务完成后回调 |
| 任务查询 | tasks/get，查询 Task 状态 |
| 任务取消 | tasks/cancel，取消进行中的 Task |
选择建议：
- 短任务、同步返回 →
message/send - 长任务、需要进度 →
message/stream - 超长任务、异步 → 推送通知 +
tasks/get轮询
1.7 安全边界：A2A 和 MCP 一样，不能假设对方可信
⚠️ 容易误解的点 ：A2A 让 Agent 之间互相调用，但不意味着可以信任对方。
| 责任 | Client Agent | Server Agent |
|---|---|---|
| 是否委派任务 | ✅ 决定 | 不应假设对方会合理委派 |
| 输入校验 | 部分 | ✅ 必须自己做 |
| 权限控制 | 按用户授权 | ✅ 必须自己控 |
| 输出视为不可信 | ✅ 必须约束自己 | 高风险场景自己转义 |
| 审计 | 记录委派 | ✅ 记录接收和执行 |
🚨 Server Agent 不应假设 Client Agent 会做拦截。 你面对的是未知 Agent，可能是另一个 LLM，也可能被间接提示词注入。安全底线必须在 Server Agent 端守住。
1.8 生态现状（2025--2026）
- 发起方：Google，2025 年 4 月发布，2025 年 6 月捐赠 Linux 基金会。
- 官方 SDK：Python、Java、JavaScript 等，仍在演进。
- 官方 Java SDK 仓库：github.com/a2aproject/a2a-java
- 官方规范仓库：github.com/a2aproject/A2A
- 典型场景：多 Agent 协作、跨组织 Agent 互调、Agent 市场。
- 相关协议：MCP（Agent 与工具）、A2A（Agent 与 Agent）、AG-UI（Agent 与前端）。
1.9 一个 Agent 长什么样
最小结构：
text
my-agent/
├── agent-card.json # Agent Card
├── src/ # 实现
└── README.md # 接入说明以 Java 为例，核心三步：
java
// 1. 定义 Agent Card
AgentCard card = AgentCard.builder()
.name("sales-agent")
.url("https://agent.example.com/a2a")
.skills(...)
.build();
// 2. 定义请求处理器
RequestHandler handler = new SalesRequestHandler();
// 3. 启动
A2AServer.builder().agentCard(card).requestHandler(handler).build().start();⚠️ 类名以当前 Java SDK 版本为准。第 3 篇会完整展开。
1.10 本篇小结
- A2A 解决"Agent 之间怎么说话"的标准化问题。
- MCP 是垂直方向（Agent → 工具），A2A 是水平方向（Agent ↔ Agent），互补。
- 反模式：确定性函数调用（查数据库）不要包装成 A2A Agent，用 MCP。
- 核心原语：Agent Card、Task、Message、Part、Artifact、Skill。
- 传输：HTTP + JSON-RPC 2.0，支持同步、流式、推送。
- 安全底线在 Server Agent 端：输入校验、权限控制、输出不可信。
下一篇：深入 A2A 核心概念------Agent Card、Task 生命周期、Message、Artifact、错误码。