概述
A2A（Agent2Agent）v1.0 是首个正式宣称“production-ready”的 A2A 版本。它要解决的问题不是“一个 Agent 怎么调用工具”，而是“多个 Agent 怎么发现彼此、验证身份、委托任务、回传结果，并且在不同厂商和不同组织之间还能互通”。
这件事在 2026 年变得更重要，是因为越来越多团队已经不满足于单 Agent + 一堆工具的模型，而是在尝试：
- 一个前台 Agent 对接用户
- 多个专业 Agent 分工处理不同子任务
- 不同团队、不同平台甚至不同公司之间交换 Agent 能力
A2A 的定位很清晰：给 Agent 与 Agent 的协作建立一个正式底座。
A2A vs MCP：解决的是两层完全不同的问题
这是理解 A2A 最关键的一点，也是这篇文章最重要的判断：
┌─────────────────────────────────┐
│ A2A：Agent ↔ Agent 协作层 │ ← 发现、信任、任务委托
│ (跨 Agent 编排) │
├─────────────────────────────────┤
│ MCP：Model ↔ Tool 连接层 │ ← 工具调用、数据访问
│ (单 Agent 内部能力) │
└─────────────────────────────────┘
| 维度 | MCP | A2A |
|---|---|---|
| 解决的问题 | Agent 如何使用工具和数据 | Agent 如何与其他 Agent 协作 |
| 通信方向 | 单 Agent 内（模型→工具） | 跨 Agent（Agent→Agent） |
| 核心原语 | Tools / Resources / Prompts | Agent Cards / Tasks / Messages |
| 使用场景 | 给 Agent 装上"手脚" | 让多个 Agent 组成"团队" |
| 关系 | Agent 内部使用 | Agent 之间使用 |
两者互补而非替代：A2A 官方文档已经明确把这个关系写死了。一个 Agent 很可能内部通过 MCP 接数据库、API、浏览器工具；对外再通过 A2A 跟别的 Agent 协作。企业场景里通常两者都要。
v1.0 关键特性
1. 签名 Agent Card
Agent Card 是 A2A 的核心概念——Agent 的"名片"：
- 加密签名：通过密码学验证 Agent 身份，防止伪造
- 机器可读：标准化的能力描述和元数据
- 跨组织验证：不同公司的 Agent 可以互相验证身份
- well-known URI 变更：从
agent.json改为agent-card.json
2. 多协议绑定
v1.0 定义了规范的 Protobuf 模型，并提供多种协议绑定：
- JSON/HTTP：最常见的 Web 集成方式
- gRPC：高性能内部服务间通信
- JSON-RPC：兼容现有 MCP 等生态
3. 企业级安全
- mTLS 支持：双向 TLS 加密
- OAuth2 元数据：通过 metadata URL 发现认证配置
- Skill 级安全声明：每个 Skill 可以声明自己的安全要求
4. 任务生命周期标准化
Task Created → In Progress → Completed / Failed / Cancelled
↕
Sub-task Delegation
- 服务器生成 ID：任务 ID 由服务器分配，避免冲突
- 标准化操作命名：不同实现使用统一的状态流转
- 流式完成语义：不再依赖
final字段判断完成
5. 多租户与基础设施
- 单端点多 Agent：一个端点可以托管多个 Agent
- 版本协商：Agent 可以声明支持的协议版本，渐进迁移
- 传输枚举：明确支持的传输方式
这些能力拼起来说明了一件事：v1.0 的重点不是炫技，而是把“企业能不能放心上”这件事补完整。
2026 年最值得关注的新信号：多语言 SDK 正在补齐
A2A 现在比很多人印象里更成熟的一点，是官方 SDK 已经不只是“有一个 Python demo”。
当前官方 SDK 页面列出的语言包括：
| 语言 | 官方仓库 |
|---|---|
| Python | a2a-python |
| Go | a2a-go |
| Java | a2a-java |
| JavaScript | a2a-js |
| C#/.NET | a2a-dotnet |
| Rust | a2a-rs |
同时，官方还给出了独立的 a2a-samples 仓库。这意味着 2026 年的 A2A 已经从“概念讨论”进入“你真的可以挑语言开始接”的阶段。
对知识库读者来说，这比抽象讨论更有价值：A2A 现在已经值得工程团队纳入技术雷达，而不是只当 Google 提的新概念。
v0.x → v1.0 的 Breaking Changes
| 变化 | 影响 | 迁移动作 |
|---|---|---|
Agent Card URI 从 agent.json → agent-card.json |
所有发现逻辑失效 | 更新 well-known 端点路径 |
| Protobuf 成为规范定义 | JSON 字段名可能变化 | 使用官方 SDK 而非手写序列化 |
| 流式完成语义变更 | 依赖 final 字段的客户端需要修改 |
使用新的完成判断逻辑 |
| 通知配置重命名 | 字段名变更 | 更新配置结构 |
| 安全模式增强 | mTLS、OAuth2 元数据为新增字段 | 渐进添加，旧字段保持兼容 |
官方同时强调，AgentCard 本身支持同时声明旧版和 v1.0 协议能力，因此迁移不一定要“一刀切”。这对平台团队很重要。
为什么这个版本在 2026 年特别重要？
1. 企业要求终于被写进了协议本体
v1.0 公告里最醒目的表述不是“更聪明”，而是“delivering on enterprise requirements”。这说明 A2A 的目标用户已经明显从 demo 开发者扩展到了真正要上生产的团队。
2. 官方明确把 A2A 和 MCP 的边界讲清了
过去很多人会把所有 Agent 协议混成一团。现在 A2A 官方文档已经把 A2A 与 MCP 的关系写得非常清楚，这对架构设计帮助很大：
- MCP：Agent 使用工具与资源
- A2A：Agent 与 Agent 协作
3. 多语言 SDK 让它开始具备生态势能
协议能不能普及，不只看规范，还看 SDK 和 samples。A2A 现在最积极的信号就是官方正在把这块铺平。
v1.0 后的 Roadmap：从协议发布到规模化落地
A2A v1.0 发布后，路线图重心已经从"把规范写完"转向"让它真正跑起来"。截至 2026 年 5 月，最值得关注的方向是：
Signed Agent Cards
- 加密签名成为标准：v1.0 已定义签名机制，v1.0 后的重点是让主流平台都支持验证
- canonical hosting path：
/.well-known/agent-card.json成为 Agent Card 的标准发布路径 - 对开发者的意义：发布 Agent 时需要同时配置 well-known 路径和签名
SDK 成熟化
| 语言 | 状态 | 仓库 |
|---|---|---|
| Python | 官方支持，重点优化 | a2a-python |
| JavaScript | 官方支持 | a2a-js |
| Java | 官方支持 | a2a-java |
| C#/.NET | 官方支持 | a2a-dotnet |
| Go | 开发中 | a2a-go |
| Rust | 社区维护 | a2a-rs |
Python SDK 是当前重点优化方向，官方文档明确提到 client-side SDK 支持在持续改进。
Registry 与验证工具
- Agent Registry：长期路线图中的关键项目，目标是让 Agent 能被自动发现和验证
- A2A Inspector：官方合规性检查工具，帮助开发者确认实现是否符合协议规范
- TCK（Technology Compatibility Kit）：自动化一致性测试套件
扩展机制
- A2A Extensions：协议开始支持标准化的扩展声明，允许在不修改核心协议的情况下添加能力
- SDK 集成：SDK 将原生支持扩展声明和协商
生态扩展
- 50+ 合作伙伴：覆盖云平台、框架、企业 SaaS 和开发者工具
- Linux Foundation 治理：协议已捐赠给 Linux Foundation，由工作组推进标准
- 季度审查机制：路线图按季度审查和更新
判断：A2A 正在从"协议发布"走向"生态扩张和运维加固"。如果你在做多 Agent 系统，现在最务实的做法是：先用官方 SDK 接入 v1.0 核心，同时关注 Agent Card 签名和 Registry 的进展，为后续升级留好接口。
谁在用？
v1.0 发布时已获得 150+ 支持组织：
| 类别 | 代表厂商 |
|---|---|
| 云平台 | Google Cloud、AWS、Azure/Bedrock |
| 框架 | LangChain、Google ADK、Cohere |
| 企业 SaaS | Atlassian、Salesforce、SAP、ServiceNow、Workday |
| 开发者工具 | MongoDB、PayPal |
| Agent 平台 | 多家 Agent 编排和部署平台 |
实际应用场景
| 场景 | 怎么用 A2A |
|---|---|
| 客服 Agent 集群 | 前端问答 Agent 通过 A2A 委托给专业领域 Agent |
| 多团队协作 | 不同团队开发的 Agent 通过 Agent Card 发现彼此能力 |
| 跨平台 Agent 编排 | GCP 上的 Agent 调用 AWS 上的 Agent 处理数据 |
| 企业 Agent 市场 | 内部 Agent 注册表，各部门发布和消费 Agent 能力 |
对开发者的实际影响
你需要关注吗？
| 角色 | 是否需要关注 | 原因 |
|---|---|---|
| Agent 框架开发者 | 是 | 需要实现 A2A 协议支持 |
| 企业 AI 平台团队 | 是 | 多 Agent 编排需要 A2A |
| 单 Agent 应用开发者 | 暂时不需要 | 单个 Agent 不需要 A2A |
| MCP Server 开发者 | 间接相关 | 了解 A2A 可以帮助设计更好的工具架构 |
| Claude Code 用户 | 暂时不需要 | 等生态成熟后有更多 Agent 间协作场景 |
实践建议
- 先判断你是不是在做多 Agent 问题：如果不是，先别急着上 A2A。
- 优先用官方 SDK，不要手写协议层：v1.0 之后协议细节会更适合由 SDK 吸收。
- 把 A2A 和 MCP 分层写进架构文档：一个管 tools，一个管 agents。
- MCP 先行，但不要混用边界：如果你现在连工具层都没理顺，先把 MCP 做好；如果已经在做跨 Agent 协作，A2A 就该进雷达。
与 MCP 的配合策略
对于大多数开发者，推荐的学习和使用路径是：
1. 先掌握 MCP（给 Agent 装工具）
2. 再了解 A2A（让 Agent 之间协作）
3. 实际项目中按需引入
不是二选一，而是分层使用：
- 单个 Agent 项目：MCP 够用
- 多 Agent 系统：MCP + A2A 配合
- 企业级 Agent 平台：两者都是基础设施
一句话结论
A2A v1.0 的意义，不是让你立刻重写现有 Agent 应用，而是告诉你：多 Agent 协作这件事，终于开始有一个可迁移、可版本协商、可多语言接入的正式协议底座。 如果你还在做单 Agent，先继续把 MCP 用好；如果你已经要做跨团队、跨平台、跨组织的 Agent 协作，A2A 现在值得认真看了。