2025 年以来，随着 AI Agent 从单点工具演化为多 Agent 协作系统，如何让不同厂商、不同框架构建的 Agent 互相发现、通信和协调，成为工程上的核心挑战。A2A（Agent2Agent Protocol）正是为解决这一问题而生的开放标准。
本研报前三章（公开）覆盖 A2A 的定义、核心架构和与 MCP 的对比；Pro 部分深入 A2A vs ACP 历史、当前生态版图、开源实现选型，以及对企业工程团队可直接执行的落地建议。
A2A 是什么
Google 提出的开放 Agent 通信协议——从诞生到治理结构全貌
Agent2Agent（A2A）是 Google 于 2025 年 4 月发布的开放协议，专为 AI Agent 之间的通信与协作设计。[2] 2025 年 6 月，该项目贡献给 Linux Foundation，由新成立的 Agentic AI Foundation（AAIF）负责管理，六大创始成员为 OpenAI、Anthropic、Google、Microsoft、AWS 和 Block。[5]
1.1 当前版本与支持规模
支持组织涵盖 Atlassian、Salesforce、SAP、ServiceNow、PayPal 等主流企业软件厂商，覆盖 Python、JavaScript、Java、Go、.NET 五种语言的官方 SDK。[1]
1.2 五大设计原则
-
拥抱 Agent 能力Agent 以自然、非结构化方式协作，不强制要求共享内存或工具调用接口格式。
-
基于现有标准传输层采用 HTTP、SSE、JSON-RPC、gRPC，与现有基础设施兼容，无需引入新的网络栈。
-
默认安全原生支持 OAuth2、mTLS、API Key 等企业级认证授权机制，不依赖网络隔离作为唯一安全手段。
-
支持长任务任务生命周期从秒级到数天均可管理，原生支持人工介入（input-required 状态）。
-
模态无关Part 原子内容单元支持文本、文件引用和结构化数据，扩展后可承载音频和视频流。
核心架构
三层架构、五个核心概念、七个操作原语——A2A 协议的完整技术图景
2.1 三层架构
A2A 协议在逻辑上分为三层，自上而下职责分明：[1]
传输协议绑定：JSON-RPC over HTTP、gRPC、REST。同一操作可通过不同传输协议暴露，客户端按需选择。
操作原语层：SendMessage、GetTask、SubscribeToTask 等七个核心操作，定义了 Agent 间所有可能的交互模式。
数据模型层：Task、Message、Part、AgentCard、Artifact 五个核心概念，构成协议的语义基础。
2.2 五个核心概念
| 概念 | 说明 |
|---|---|
| AgentCard | Agent 的自描述 JSON 清单，发布于 /.well-known/agent-card.json，声明名称、能力、技能列表和认证方式。客户端可通过标准 URI 自动发现。 |
| Task | 工作单元，具有完整生命周期：working → completed / failed / canceled / rejected / input-required。每个 Task 有全局唯一 ID，支持跨 Agent 追踪。 |
| Message | 通信单元，角色为 "user" 或 "agent"，包含一个或多个 Part。是 Agent 间对话的载体。 |
| Part | 原子内容单元，可以是文本、文件引用（URI + MIME 类型）或结构化数据（JSON object）。多个 Part 组成一条 Message。 |
| Artifact | Agent 产出的输出物，由 Part 组成，支持版本控制和增量更新。流式场景下可逐步追加内容。 |
2.3 七个操作原语
| 操作 | 说明 | 适用场景 |
|---|---|---|
SendMessage | 发起任务或在已有 Task 下追加消息 | 同步短任务 |
SendStreamingMessage | 发起任务并实时接收流式响应（SSE） | 长文本生成、进度汇报 |
GetTask | 轮询指定 Task 的当前状态和输出 | 异步任务状态查询 |
ListTasks | 分页查询当前 Agent 的 Task 列表 | 任务管理后台 |
CancelTask | 幂等取消任务，返回最终状态 | 超时处理、用户撤销 |
SubscribeToTask | 持久流订阅任务更新（gRPC 双向流） | 长时间运行的 Agent 任务 |
| Push Notifications | Agent 主动向调用方 Webhook 推送状态变更 | 跨服务器异步通知 |
2.4 AgentCard 示例
以下是一个标准 AgentCard 的 JSON 结构，发布于 https://agent.example.com/.well-known/agent-card.json：
"name": "AI Insight Agent",
"description": "AI 资讯查询与研报摘要 Agent",
"version": "1.0.0",
"url": "https://ai-insight.org/a2a",
"protocolVersions": ["0.3.0"],
"capabilities": {
"streaming": true,
"pushNotifications": true
},
"skills": [
{
"name": "search_news",
"description": "搜索 AI 资讯，支持关键词和日期范围",
"inputModes": ["text"],
"outputModes": ["text", "data"]
}
],
"securitySchemes": {
"bearer": { "type": "http", "scheme": "bearer" }
}
}
任何支持 A2A 的客户端或编排框架，只需请求 /.well-known/agent-card.json 即可自动发现该 Agent 的能力，无需手动配置。这与 MCP 需要显式注册 Server 的方式形成鲜明对比。
A2A vs MCP 对比
两个协议不是竞争关系——搞清楚各自边界，才能正确组合使用
MCP（Model Context Protocol）由 Anthropic 提出，解决的是 Agent 如何调用外部工具和数据源的问题——数据库查询、文件读写、API 调用。A2A 解决的是 Agent 如何与其他 Agent 协作的问题——发现彼此、委托任务、同步结果。[6]
| 维度 | MCP | A2A |
|---|---|---|
| 定位 | Agent → 工具/数据 | Agent → Agent |
| 提出者 | Anthropic | |
| 协议 | JSON-RPC over stdio/SSE | JSON-RPC / gRPC / HTTP REST |
| 发现机制 | 手动配置 MCP Server 列表 | AgentCard 自动发现（/.well-known/） |
| 任务模型 | 无（工具调用即完成） | 完整生命周期（working→completed/failed） |
| 长任务 | 不原生支持 | 原生支持（小时/天级） |
| 流式 | SSE | SSE + gRPC streaming |
| 推送通知 | 无 | Webhook push notification |
| 认证 | 简单（stdio 本地信任） | 企业级（OAuth2/mTLS/API Key） |
| 多模态 | 主要文本 | 文本/文件/结构化数据（可扩展音视频） |
| 生态规模 | 数千个 MCP Server | 150+ 组织支持 |
| 治理 | Linux Foundation AAIF | Linux Foundation AAIF |
- Agent 需要读写文件系统
- Agent 需要查询数据库
- Agent 需要调用本地工具（代码执行、浏览器控制）
- 单机本地开发环境
- 需要协调多个专用 Agent 完成复杂任务
- Agent 跨服务器、跨组织部署
- 任务需要分配给远程 Agent 并等待结果
- 需要与第三方 Agent 服务对接
— AI Insight 研究观察，2026-04