为什么需要 A2A：Agent 互操作性的困境
2025 年，多智能体系统（MAS）从学术概念走向生产实践。然而，一个根本性问题很快暴露出来：不同框架、不同厂商开发的 Agent 无法直接通信。
LangChain 的 Agent 不认识 AutoGen 的 Agent，CrewAI 的 Worker 无法调用 Google 的 Agent。每个框架都有自己的 Agent 定义、消息格式和通信机制。开发者不得不在单一框架内构建所有 Agent，或者花费大量精力编写适配器。
这就是「Agent 孤岛」困境——与 2010 年代初期移动 App 的「数据孤岛」如出一辙。
与此同时，MCP（Model Context Protocol）成功解决了 Agent 与外部工具之间的互操作性问题（Agent-to-Tool），但 Agent 与 Agent 之间（Agent-to-Agent）的通信问题仍然悬而未决。
2025 年 4 月，Google 在 Cloud Next 大会上正式发布了 A2A（Agent-to-Agent Protocol），一个专为 AI Agent 之间的互操作性设计的开放标准。
MCP 解决的是「Agent 接世界的标准接口」问题，A2A 解决的是「Agent 与 Agent 通信的标准语言」问题。两者不是竞争关系，而是构成 Agent 通信协议栈的上下两层——分别对应「工具层」和「Agent 层」。
设计哲学：让 Agent 像人类团队一样协作
A2A 协议的设计灵感来源于人类团队的协作方式。Google 在协议设计文档中明确指出，Agent 之间的协作应该模仿人类的工作模式，而非机器间的 RPC 调用。这体现在三个关键设计决策上：
决策一：基于能力的发现，而非基于接口的描述
传统微服务架构中的服务发现是基于接口的——服务 A 声明自己实现了某个 gRPC 接口，服务 B 直接调用。但 Agent 的能力无法被「接口」描述清楚。一个「文档分析 Agent」的能力范围可能是总结、翻译、提取关键信息、检查合规性……每一种能力都涉及复杂的上下文理解。
A2A 采用「能力卡」（Agent Card）机制：每个 Agent 发布一份 JSON 格式的能力声明，描述它能做什么、需要什么输入、返回什么输出、服务水平协议如何。其他 Agent 通过能力卡来决定是否与该 Agent 协作。
决策二：以任务为单位的异步协作
Agent 完成任务的过程通常不是线性的。一个 Agent 可能需要查询多个数据源、调用多个工具、等待用户输入。A2A 不要求 Agent 实时返回结果，而是采用任务（Task）模型——客户端 Agent 提交一个任务，服务端 Agent 异步执行，通过多种方式（polling、push notification、SSE 流式）返回进度和结果。
决策三：开放的 Agent 视角
A2A 不关心服务端 Agent 的内部实现——它是单 Agent 还是多 Agent 系统、使用哪个 LLM、是否依赖外部工具——只关心它能否完成任务并返回结果。这种「黑盒」设计使得不同框架、不同厂商的 Agent 能够无缝协作。
核心架构：三层角色模型
A2A 协议定义了三种基本角色：
| 角色 | 名称 | 职责 | 示例 |
|---|---|---|---|
| 用户 | User | 发起任务请求的人类或自动化系统 | 用户说「帮我规划下周出差行程」 |
| 客户端 Agent | Client Agent | 解析用户需求，构造 A2A 请求，分发给合适的远程 Agent | 用户的主 Agent，理解意图并调度子 Agent |
| 远程 Agent | Remote Agent / Server | 执行具体任务并返回结果的智能服务 | 航班查询 Agent、酒店预订 Agent、行程规划 Agent |
这种角色分离的逻辑是：用户的意图往往是模糊的、跨领域的（「出差」涉及航班、酒店、会议、天气等多个子任务），客户端 Agent 负责理解意图、分解任务、协调执行，远程 Agent 负责专注执行单一领域任务。
三阶段协作模式深度拆解
阶段 1：能力发现
客户端 Agent 通过获取远程 Agent 的「能力卡」（Agent Card）来决定是否与之协作。能力卡是一个符合 JSON 标准的元数据文档，包含：
- 基本信息：名称、描述、图标、提供者
- 能力列表：Agent 能完成的任务类型，每个能力包含输入参数、输出格式、示例请求
- 端点信息：HTTP 端点 URL、支持的传输协议（HTTPS/SSE/WebSocket）
- 安全策略：支持的认证方案（OAuth 2.0、API Key、JWT 等）
- SLA：响应时间、可用性保证等
能力卡通常托管在 Agent 提供者的 /.well-known/agent.json 路径下，便于自动发现。
阶段 2：任务提交
客户端 Agent 确认远程 Agent 有能力完成任务后，通过 A2A 的任务提交规范（tasks/send）提交任务。任务对象包含：
- 任务 ID：由客户端生成的唯一标识
- 指令：格式为自然语言，附带必要的上下文数据
- 内容类型：文本、结构化数据、文件引用等
- 优先级：任务紧急程度
- 截止时间：期望完成的时间
通信采用 JSON-RPC 2.0 格式，所有请求和响应都是标准化的 JSON 结构。
阶段 3：结果获取
A2A 提供了三种结果获取方式：
- Polling（轮询）：客户端 Agent 定期调用 tasks/get 接口查询任务状态。适合简单、短期任务。
- Push（推送）：服务端 Agent 在任务完成后，向客户端注册的回调 URL 推送结果。适合需要实时通知的场景。
- Streaming（流式）：通过 SSE（Server-Sent Events）实时推送任务进度和中间结果。适合长时间运行的复杂任务。
A2A 的流式结果获取方式（SSE）是生产环境中最重要的特性之一。它允许一个 Agent 在进行复杂分析时，逐步返回中间结果——客户端 Agent 可以在收到部分结果后就开始处理，大幅减少端到端延迟。
JSON-RPC 通信规范与技术细节
API 方法集
A2A 协议定义了以下核心 API 方法：
| 方法 | 用途 | 描述 |
|---|---|---|
| tasks/send | 提交新任务 | 客户端向远程 Agent 提交一个任务 |
| tasks/get | 获取任务状态 | 查询指定任务的最新状态和结果 |
| tasks/cancel | 取消任务 | 客户端主动取消一个正在执行的任务 |
| tasks/pushNotification | 注册推送 | 客户端注册回调 URL，远程 Agent 完成后推送 |
| agent/getCard | 获取能力卡 | 获取远程 Agent 的能力描述文档 |
消息格式示例
{
"jsonrpc": "2.0",
"method": "tasks/send",
"params": {
"id": "task-20260617-001",
"sessionId": "session-abc-123",
"input": {
"instructions": "分析这份 PDF 合同的合规性风险",
"content": [
{
"type": "file",
"file": {
"name": "contract.pdf",
"mimeType": "application/pdf",
"bytes": "base64_encoded_content..."
}
}
]
},
"metadata": {
"priority": "high",
"deadline": "2026-06-17T12:00:00Z"
}
},
"id": "req-001"
}任务状态机
一个任务在其生命周期内经历以下状态：submitted（已提交）→ working（执行中）→ completed（已完成）/ failed（失败）/ canceled（已取消）。远程 Agent 通过更新任务状态来同步进度。支持部分结果（partial result）——即使任务尚未完全完成，也可以返回阶段性成果。
能力发现：Agent 如何知道对方能做什么
A2A 的能力发现机制是协议设计的亮点之一。与传统的 API 服务注册不同，Agent 的能力是无法用接口签名来描述的。
Google 引入了一种「一句话声明」的策略：每个 Agent 用自然语言描述自己能做什么。例如：
- 「我是一家合规审查 Agent，可以分析合同和法律文件中的合规风险，支持 10 种常见监管框架。」
- 「我是一个航班查询 Agent，可以查询全球 5000+ 城市的实时航班信息和价格，支持 20 种货币报价。」
能力卡中还包含一个 skills 数组，用结构化的方式描述每项能力的输入和输出。客户端 Agent 通过比对用户需求的能力描述和能力卡中的技能列表，决定是否调用该 Agent。
能力卡的发现方式有两种：
- 直接发现：直接请求 Agent 的 /agent/getCard 端点
- 目录发现：通过 Agent 目录服务（如 Google 的 Agent Directory）搜索和发现合作伙伴 Agent
安全模型：企业级认证与授权
A2A 协议本身不定义具体的安全实现，而是支持对接现有的企业级安全方案。协议层安全包括：
- 传输层安全：所有 A2A 通信必须通过 HTTPS 进行，确保数据传输加密
- 认证：支持 OpenAPI 标准认证方案，包括 OAuth 2.0、API Key、JWT Bearer Token
- 授权：每个 Agent 可以定义自己的授权策略，控制哪些客户端和用户有权调用其能力
- 审计：所有任务交互记录可被审计，支持合规性追查
A2A 协议目前没有内置「恶意 Agent 检测」机制。如果一个远程 Agent 被攻陷，它可以向客户端返回恶意结果。这需要在上层应用层解决——例如建立 Agent 信任评分体系或 Agent 行为验证机制。
MCP vs A2A：两个协议如何分工协作
| 维度 | MCP（Model Context Protocol） | A2A（Agent-to-Agent Protocol） |
|---|---|---|
| 解决的核心问题 | Agent ↔ 外部工具、数据源 | Agent ↔ Agent 通信与协作 |
| 类比 | USB 接口（设备接入） | HTTP + TCP/IP（网络通信） |
| 发起方 | Anthropic（2024.11） | Google（2025.04） |
| 通信模式 | 客户端-服务端（C/S） | 对等网络（P2P） |
| 消息格式 | JSON-RPC | JSON-RPC 2.0 |
| 传输协议 | stdio / Streamable HTTP | HTTPS + SSE / WebSocket |
| 数据模型 | Resources / Tools / Prompts | Agent Card / Task / Artifact |
| 状态管理 | 无状态（每次请求独立） | 有状态（任务持续跟踪） |
| 协作方式 | 单次调用 | 多阶段异步协作 |
| 适用范围 | 工具调用、数据检索 | 复杂多步骤任务、跨系统编排 |
| 安全 | 无内置安全模型（需应用层实现） | 支持 OAuth 2.0 / API Key 等企业级认证 |
| 生态支持 | 广泛（300+ 客户端、1500+ 工具） | 50+ 技术合作伙伴 |
MCP 和 A2A 不是竞争关系，而是互补关系。一个完整的 Agent 系统需要同时使用两种协议：MCP 让 Agent 连接文件、数据库、API 等外部工具；A2A 让 Agent 与其他 Agent 协作完成跨领域复杂任务。
Google 在 A2A 规范中明确建议：A2A Server 内部可以使用 MCP 来连接自己的工具集，而对外则通过 A2A 接口与其他 Agent 通信。换句话说，MCP 是 Agent 的「内部总线」，A2A 是 Agent 的「网络协议」。
生态进展：50+ 合作伙伴的产业布局
截至 2026 年 6 月，A2A 协议已经获得了 50+ 技术合作伙伴的支持，涵盖 Agent 框架、云服务商、企业软件和行业 ISV 等多个领域。
| 类别 | 合作伙伴 | 集成方式 |
|---|---|---|
| Agent 框架 | LangChain, CrewAI, AutoGen, Dify | 框架原生支持 A2A 协议 |
| 云服务商 | Google Cloud, Salesforce, SAP, ServiceNow | 云平台 Agent 生态接入 |
| 企业软件 | Atlassian, Box, Freshworks | 企业级 Agent 协作网络 |
| 行业 ISV | 金融、医疗、法律垂直领域 ISV | 行业专用 Agent 接入 |
| 安全厂商 | Palo Alto Networks, CrowdStrike | Agent 安全监控与审计 |
特别值得关注的是 A2A 在金融服务领域的进展。Google Cloud 预测 2026 年将出现多步骤的 Agent 合规系统，能够监控监管变化、识别受影响政策、更新内部流程并创建完整审计链。Agent Payments Protocol（AP2）的推出进一步扩展了 A2A 的能力边界——当 AI Agent 代替人类发起支付时，AP2 负责验证用户授权、确保请求准确性、明确责任归属。PayPal 已开始采用这一协议。
总结与展望
A2A 协议的五大技术贡献
- Agent 互操作性标准：首次解决了不同框架、不同厂商 Agent 之间的通信问题
- 能力卡发现机制：以自然语言声明能力，比传统 API 接口更灵活、更语义化
- 三阶段异步协作：能力发现 → 任务提交 → 结果获取，覆盖完整的 Agent 协作生命周期
- 企业级安全：支持 OAuth 2.0、JWT 等标准认证，可直接嵌入现有企业安全体系
- 与 MCP 互补：与 MCP 协议共同构成了 Agent 通信的完整协议栈
未来挑战
- Agent 信任问题：如何验证远程 Agent 返回的结果是否可信？A2A 目前缺乏内置的 Agent 信任验证机制
- 协议竞争：Anthropic 的 MCP 和 Google 的 A2A 是否会走向融合？行业期待一个统一的互联互通标准
- 规模化挑战：当 Agent 网络中同时有数千个 Agent 在协作，能力发现、负载均衡和故障隔离如何实现？
- 安全攻击面：恶意 Agent 投毒、Agent 身份伪造、任务劫持等新的攻击向量需要行业共同应对
展望
A2A 协议标志着多智能体系统从「封闭框架」走向「开放网络」的关键一步。2026 年下半年，随着更多行业 Agent 的接入和企业级安全方案的完善，Agent 之间的协作将从「演示级」走向「生产级」。对于企业架构师来说，理解 A2A 的设计哲学和技术细节，是实现 Agent 规模化落地的必修课。