从孤岛到互联：深入理解 AI 智能体间的“通用语言”——A2A 协议
前言
2025 年 4 月，Google 发布了一项看似低调却意义深远的技术——A2A（Agent-to-Agent）协议。
短短数月后，Linux 基金会正式宣布将其纳入旗下，超过 100 家领先科技公司加入生态支持，微软、AWS、IBM 等巨头纷纷推出配套 SDK。
与此同时，德意志电信与 Google Cloud 联合开发的 MINDR 多智能体系统宣布将采用 A2A 协议进行智能体间协调，西班牙电信与诺基亚合作测试 A2A 与 MCP 协议的协同应用。
这些密集的动作，传递出一个清晰的信号：AI 智能体正在从“单打独斗”走向“群体协作”，而 A2A 协议正站在这场变革的枢纽位置。本文将从背景、原理、架构到应用，循序渐进地带你全面了解这一协议。
一、为什么要有一个“智能体之间”的协议？
要理解 A2A 的价值，首先要看到当前 AI 智能体生态面临的真实困境。
今天的 AI 智能体百花齐放：有的用 LangChain 构建，有的跑在 CrewAI 框架上，有的封装在 Google ADK 中，还有大量企业自研的定制化智能体。它们各自出色，却彼此“语言不通”——每个智能体有自己的一套 API 约定、消息格式和交互假设，像一个一个的信息孤岛。
于是，一个尴尬的局面出现了：你想让一个负责订机票的智能体和一个负责订酒店的智能体协同完成一次旅行规划？对不起，它们互不认识，也“听不懂”彼此在说什么。
传统做法是为每一对需要协作的智能体编写定制化的代码—不仅开发成本高昂，而且随着智能体数量的增长，集成的复杂度呈指数级爆炸。
这正是 A2A 要解决的核心问题：定义一套所有智能体都能“听懂”的通用语言。它不关心智能体内部用了什么框架、什么模型，只规定它们如何在外围“握手”、如何发送请求、如何跟踪任务状态。
二、A2A 是什么？
A2A，全称 Agent-to-Agent Protocol，是由 Google 于 2025 年 4 月推出的一项开放、厂商中立的通信协议。它的目标非常明确：让不同框架、不同厂商构建的 AI 智能体能够安全、标准化地相互发现、通信和协作。
这里有两个关键词值得特别注意：
第一，“开放与厂商中立”。 A2A 不是 Google 的私有。2025 年 6 月，Google 将 A2A 协议捐赠给了 Linux 基金会，使其成为一个由社区共同治理的开放标准项目。任何组织和个人都可以免费使用、贡献甚至基于它构建商业产品，不必担心被锁定在某一家厂商的生态中。
第二，“互操作而非暴露内部”。 A2A 的设计遵循一个重要的原则：不透明执行（Opaque Execution）。智能体之间协作时，双方不需要知晓对方的内部状态、记忆结构或模型架构——它们只需要通过 Agent Card（智能体名片）了解彼此“能做什么”，然后通过标准化消息请求对方“帮忙做某事”即可。这种设计既保护了每个智能体的知识产权和内部隐私，又让它们能够无缝协作。
可以这样理解：A2A 就是一套共同维护的规范。有了这套规范，不同的智能体就能高效协作，而不需要把自己内部的一切摊开给对方看。
三、A2A 是如何工作的？
A2A 的工作机制可以拆解为三个层面：底层技术栈、核心数据模型、以及典型交互流程。接下来我们逐一展开。
3.1 技术底座：站在巨人肩膀上
A2A 并没有“重新发明轮子”。它的设计哲学之一就是复用成熟、可靠、广泛部署的现有技术标准：
- HTTP/HTTPS 作为基础传输协议，保证通信的可靠性和广泛的网络兼容性；
- JSON-RPC 2.0 作为统一的消息格式，所有请求和响应都遵循这一规范；
- Server-Sent Events（SSE） 支持流式响应，让智能体能够实时推送任务进展；
- OAuth 2.1 等企业级认证机制，确保通信的安全性。
这种“站在巨人肩膀上”的策略，使得 A2A 的集成门槛极低——任何支持 HTTP 和 JSON 的系统都可以快速接入。与此同时，A2A 也预留了扩展空间，例如在电信领域，华为等厂商正在基于 RocketMQ 构建 A2A 的异步通信增强方案，以支持更大规模、更高可靠性的多智能体系统。
3.2 核心数据模型：四个关键对象
理解 A2A，必须掌握它的四个核心数据对象：
1. Agent Card（智能体名片）
这是 A2A 的“自我介绍”机制。每个 A2A 智能体都在一个固定路径（/.well-known/agent-card.json）下发布一份 JSON 格式的名片，其中包含智能体的身份标识、能力描述、支持的消息格式（文本、文件、音频、视频等）、服务端点 URL，以及认证要求。其他智能体通过读取这张名片，就能知道它能做什么、如何与它通信，而不需要任何预先配置。
2. Task（任务） 任务是 A2A 中最核心的工作单元。当客户端智能体请求远程智能体执行某项工作时，就会创建一个 Task。每个 Task 拥有唯一 ID，并经历一系列明确的状态流转：从“已提交”（submitted）到“处理中”（working），再到“需要输入”（input-required）、“已完成”（completed）、“失败”（failed）或“取消”（canceled）。任务状态可追踪、可查询，这让长时间的复杂协作变得透明可控。
3. Message（消息） 消息是智能体之间的对话载体。每条消息包含一个角色标识（“user”代表客户端，“agent”代表远程智能体），以及一个或多个 Part 组成的内容体。
4. Part（内容单元）与 Artifact（工件） Part 是消息内容的最小组成单元。A2A 支持三种类型的 Part：
- TextPart：纯文本内容；
- FilePart：文件内容（可内嵌字节流或引用外部 URI）；
- DataPart：结构化 JSON 数据（如表单提交）。
而 Artifact 则代表任务执行过程中产生的输出结果——比如一份生成的报告文档、一段分析视频、或一组结构化数据。Artifact 同样由 Part 构成，是协作成果的载体。
3.3 交互流程：一次完整的协作长什么样？
有了以上模型，我们来看一次典型的 A2A 协作流程：
步骤 1：能力发现。 客户端智能体首先通过 HTTP 请求获取远程智能体的 Agent Card，读取其能力描述和支持的交互模式。
步骤 2：任务发起。 客户端构造一条 Message（比如“请帮我查询明天从北京到上海的航班”），封装为 JSON-RPC 请求，发送到远程智能体的任务端点。
步骤 3：任务处理与状态更新。 远程智能体收到请求后创建 Task，并开始执行。对于短时任务，它可能直接返回结果；对于长时任务，它可以通过 SSE 持续推送状态更新，客户端也可以随时查询任务进展。
步骤 4：结果返回。 任务完成后，远程智能体将输出以 Artifact 的形式返回，客户端接收并使用这些结果。
值得注意的是，整个过程完全建立在标准化消息之上。远程智能体不需要知道客户端用了什么框架，客户端也不需要知道远程智能体内部如何运作——它们只需遵守 A2A 的“外交礼仪”，协作就能顺利完成。
3.4 架构解耦：通信层与智能体逻辑分离
A2A 最精妙的设计，在于它将通信层与智能体逻辑彻底解耦。这意味着：
- 团队可以独立地升级智能体的内部模型，而不会影响它与其它智能体的协作；
- 智能体可以替换底层工具、调整内部算法，只要保持 Agent Card 声明的能力不变，外部调用方就感知不到任何变化；
- 同样的智能体逻辑可以通过 A2A 服务于多种客户端，无需为每个场景编写定制集成代码。
这种解耦为 AI 系统的增量演进和规模化部署提供了关键支撑。
四、A2A 与 MCP：两种协议的分工与协作
在讨论 A2A 时，不可避免地会涉及到另一个频繁出现的名词——MCP（Model Context Protocol）。很多人在初次接触时会困惑：这两个协议有什么区别？它们是竞争关系吗？
答案是：它们是互补关系，而非竞争关系。
MCP 由 Anthropic 于 2024 年提出，解决的核心问题是 “AI 模型如何标准化地调用外部工具和数据源” 。它像一个标准化的“USB-C 接口”，让模型可以统一地连接数据库、API、文件系统等外部资源，而不必为每个工具写定制代码。
而 A2A 解决的是另一个维度的问题—— “智能体之间如何标准化地协作” 。它关注的是智能体与智能体之间的水平通信。
在实际应用中，二者常常协同工作。
比如，一个“旅行规划”智能体通过 A2A 把订机票的任务委派给“航班查询”智能体；而“航班查询”智能体则通过 MCP 连接航空公司的 API 来执行查询。
总结
A2A 协议解决的是一个看似简单却至关重要的问题：让 AI 智能体能够像人类团队一样协同工作。它通过标准化的 Agent Card 实现能力发现，通过 Task 模型管理复杂工作流，通过 JSON-RPC 和 SSE 实现可靠的同步与异步通信——而这一切都建立在开放、厂商中立的原则之上。
如果你正在构建 AI 智能体系统，A2A 是值得尽早关注的技术。它不是锦上添花的选项，而是让智能体从“孤岛”走向“互联”的基础设施。
