A2A 协议详解：让 AI 智能体学会"互相说话"
摘要：A2A（Agent2Agent）协议是一个开放标准，专门解决不同 AI 智能体之间的通信与协作问题。本文将从问题出发，带你完整理解 A2A 是什么、解决什么痛点、如何工作，以及它与 MCP 协议的关系。
背景：AI 智能体时代的”语言壁垒”
想象这样一个场景：你对 AI 助手说”帮我规划一次东京之旅”。
这个任务并不简单——它需要多个专业智能体协同完成：
- ✈️ 航班智能体：搜索并预订机票
- 🏨 酒店智能体：推荐并预订住宿
- 💱 换汇智能体：查询汇率、建议换汇策略
- 🗺️ 导游智能体：规划景点路线和当地体验
问题来了——这些智能体可能来自不同的公司，用 LangGraph、CrewAI、Semantic Kernel 等完全不同的框架构建。它们根本不知道怎么和彼此”说话”。
这就是 A2A 协议要解决的核心问题。
什么是 A2A 协议？
A2A（Agent2Agent Protocol） 是一个开放标准，为 AI 智能体之间的通信提供统一语言，让来自不同开发者、不同框架、不同组织的智能体能够无缝协作。
- 发起方：Google
- 现归属：Linux 基金会（开源治理）
- 协议版本：当前为 v1.0
- 底层技术：HTTP、JSON-RPC、Server-Sent Events（SSE）
用一句话概括：A2A 是 AI 智能体世界的”互联网”，让彼此孤立的智能体能够发现、连接、协作.
没有 A2A 时，会有哪些问题？
在没有统一协议的情况下，开发者面临以下挑战：
| 问题 | 描述 |
|---|---|
| 定制集成成本高 | 每一对智能体之间都需要编写专属的点对点通信代码 |
| 扩展困难 | 智能体数量增长后，集成复杂度呈指数级上升 |
| 创新受阻 | 大量精力耗在”如何连接”，而非”提供什么价值” |
| 安全隐患 | 临时拼凑的通信方式缺乏一致的安全机制 |
| 能力受限 | 将智能体包装成”工具”来调用，无法发挥其完整的推理和协作能力 |
最后一点尤为关键。智能体不是工具——它有状态、能推理、能多轮交互、能主动协商。把它压缩成一个无状态的函数调用，是对其能力的根本性浪费。
A2A 的解决方案
A2A 通过标准化的协议层，让智能体可以：
- 互相发现：通过”Agent Card”（智能体名片）声明自己的能力
- 安全认证：基于标准 Web 认证机制（如 OpenID Connect）
- 发送任务：通过统一 API 委托子任务给其他智能体
- 流式响应：支持长时间运行的任务，实时推送进度
- 多轮交互：智能体之间可以像人一样来回协商、澄清、确认
1
2
3
4
5
6
7
8
9
10
11
12
用户
│
▼
主协调智能体（Client Agent）
│ │ │ │
▼ ▼ ▼ ▼
✈️ 航班 🏨 酒店 💱 换汇 🗺️ 导游
智能体 智能体 智能体 智能体
（任何框架，通过 A2A 协议互通）
│
▼
返回整合后的完整旅行计划
A2A 的五大核心设计原则
1. 简洁性（Simplicity）
A2A 不重新发明轮子。它建立在开发者已经熟悉的标准之上：
- HTTP：通信传输
- JSON-RPC：消息格式
- Server-Sent Events（SSE）：流式推送
学习门槛低，现有工程基础设施可以直接复用。
2. 企业级就绪（Enterprise Readiness）
A2A 从设计之初就考虑了企业场景：
- 标准 Web 认证与授权（OAuth 2.0、OpenID Connect）
- 完整的安全、隐私、追踪与监控支持
- 可与企业现有基础设施集成
3. 异步优先（Asynchronous）
智能体任务往往耗时较长（搜索、预订、等待外部 API 响应）。A2A 原生支持：
- 流式传输：边处理边推送结果
- 推送通知：任务完成后主动通知
- 断线重连：客户端不需要始终在线
4. 模态无关（Modality Independent）
智能体之间传递的不只是文字。A2A 支持多种内容类型，包括文本、结构化数据、文件、图片等，适应丰富多样的交互场景。
5. 不透明执行（Opaque Execution）
这是 A2A 最重要的安全特性之一：
智能体只需声明自己能做什么，而不需要暴露自己怎么做的。
内部逻辑、私有数据、专有工具——全部对外不可见。智能体的知识产权得到充分保护。
A2A 的工作流程
一次完整的 A2A 交互分为四个阶段：
第一阶段：智能体发现
每个 A2A 智能体都在固定路径发布一张”Agent Card”（智能体名片）：
1
GET /.well-known/agent.json
Agent Card 用 JSON 描述该智能体的能力、支持的任务类型、认证方式等信息。客户端通过读取这张名片来决定是否调用该智能体。
第二阶段：身份认证
客户端解析 Agent Card 中的 securitySchemes 字段，向认证服务器请求 JWT 令牌，用于后续 API 调用的身份验证。
第三阶段：发送任务（同步）
1
2
3
4
5
6
7
8
9
POST /sendMessage
Authorization: Bearer <JWT>
{
"message": {
"role": "user",
"parts": [{ "text": "帮我搜索从上海到东京的航班" }]
}
}
服务端处理并返回任务结果。
第四阶段：流式任务（异步）
1
POST /sendMessageStream
服务端通过 SSE 逐步推送任务进度：
1
2
3
4
5
→ Task (Submitted)
→ TaskStatusUpdateEvent (Working...)
→ TaskArtifactUpdateEvent（中间结果 A）
→ TaskArtifactUpdateEvent（中间结果 B）
→ TaskStatusUpdateEvent (Completed)
A2A 与 MCP：互补而非竞争
很多人会把 A2A 和 MCP（Model Context Protocol）搞混，其实两者是不同层次的协议，相互补充：
| 维度 | MCP | A2A |
|---|---|---|
| 连接对象 | 智能体 ↔ 工具/数据 | 智能体 ↔ 智能体 |
| 交互模式 | 无状态函数调用 | 有状态、多轮协作 |
| 适用场景 | 调用 API、查数据库、执行搜索 | 委托子任务、协商、分布式推理 |
| 关键特征 | 工具是被动响应的 | 智能体是主动推理的 |
一个形象的比喻：
- MCP 是”给智能体装上各种工具”（扳手、计算器、搜索引擎）
- A2A 是”让装好工具的智能体互相协作，像一个团队一样工作”
两者结合，才构成完整的智能体技术栈：
1
2
3
4
5
A2A 协议层 ← 智能体之间的协作通道
│
MCP 协议层 ← 智能体与工具/数据的连接
│
LLM（大语言模型） ← 智能体的推理大脑
生态支持
A2A 得到了广泛的行业支持，主流框架均可与之集成：
- LangGraph（LangChain）
- CrewAI
- Semantic Kernel（Microsoft）
- ADK（Google Agent Development Kit）
- Cisco agntcy
官方 SDK 已覆盖主流语言：Python、JavaScript、Java、C#/.NET、Go
总结
A2A 协议的出现，标志着 AI 智能体从”单打独斗”迈向”团队协作”的关键一步。
它的价值不在于技术复杂度，而在于建立了一套所有人都愿意遵守的规则——就像 HTTP 让所有网站能在同一个互联网上运行一样，A2A 让所有智能体能在同一个”智能体网络”上协作。
对于开发者来说，现在正是参与这个生态的好时机：协议已经成熟（v1.0），SDK 齐全，Linux 基金会背书，行业认可度高。
延伸阅读
本文基于 A2A Protocol v1.0 官方文档整理撰写。