跳转至

Agent2Agent (A2A) 协议

概述

Agent2Agent（A2A）协议是由 Google 发布的智能体（Agent）互操作标准，专注于智能体之间的直接通信与协调。A2A 通过提供标准化机制，使智能体能够相互发现、通信并协作，与 MCP 等协议形成互补。

Agent2Agent (A2A) protocol overview showing the standard for agent interoperability and communication

来源：A2A Protocol Documentation

协议发布

发布信息

战略愿景

A2A 代表了 Google 对标准化生态的构想——让 AI 智能体能够跨平台、跨厂商地无缝交互、共享能力，并协调复杂工作流。

核心设计原则

智能体互操作

  • 跨平台通信：不同平台的智能体可无缝通信
  • 厂商中立：协议设计兼容各类智能体实现，不绑定特定厂商
  • 能力发现：智能体之间相互发现能力的标准化机制
  • 服务注册：用于智能体服务发现的通用注册表模式

标准化通信

  • 消息格式：智能体通信的标准化消息格式
  • 协议语义：对不同类型智能体交互定义清晰语义
  • 错误处理：标准化的错误处理与恢复机制
  • 安全模型：内置安全与认证机制

可扩展架构

  • 分布式系统：面向分布式多智能体环境而设计
  • 性能优化：针对高吞吐量智能体通信进行优化
  • 容错性：能够承受单个智能体的故障
  • 负载均衡：支持跨多个智能体实例的负载均衡

技术架构

核心组件

智能体注册表（Agent Registry）

  • 服务发现：集中式或分布式智能体发现机制
  • 能力广播：智能体主动广播自身能力与服务
  • 健康监控：监控智能体的健康状态与可用性
  • 负载均衡：将请求分发至可用的智能体实例

通信层

  • 消息路由：智能体之间消息的智能路由
  • 协议转换：不同通信协议之间的转换
  • 服务质量（QoS）：针对不同类型通信的 QoS 保障
  • 监控：通信监控与分析

安全框架

  • 认证：智能体身份验证与鉴权
  • 授权：细粒度的智能体交互访问控制
  • 加密：敏感通信的端到端加密
  • 审计日志：用于安全合规的完整审计追踪

协议栈

A2A versus MCP protocol comparison showing the complementary relationship between the two standards

来源：A2A Protocol Documentation

应用层： - 智能体应用：高层次智能体应用与工作流 - 业务逻辑：特定领域的业务逻辑与规则 - 用户界面：人类与智能体系统交互的界面

A2A 协议层： - 智能体通信：标准化的智能体间通信 - 工作流协调：多智能体工作流编排 - 能力协商：动态能力发现与协商

传输层： - 网络协议：HTTP/HTTPS、WebSockets、gRPC - 消息队列：异步消息队列系统 - 事件流：实时事件流平台

与其他协议的集成

A2A 与 MCP 的关系

A2A and MCP integration architecture showing how the protocols work together

A2A 与 MCP 互补架构

互补角色： - A2A 侧重：智能体间的通信与协调 - MCP 侧重：向 LLM 提供来自外部资源的上下文 - 组合收益：兼具协调能力与上下文能力的完整智能体生态

集成模式： - 混合架构：以 A2A 负责智能体协调，以 MCP 负责上下文供给 - 协议桥接：在 A2A 与 MCP 之间建立桥接层 - 统一平台：同时支持两种协议的平台 - 分层方案：协调层使用 A2A，上下文层使用 MCP

Google ADK 集成

Google ADK with MCP integration showing the combined protocol implementation

Google ADK 与 MCP 集成

原生集成： - ADK 支持：Google Agent Development Kit 原生支持 A2A - MCP 兼容：ADK 同样支持 MCP 以提供上下文 - 统一开发：同一开发环境同时支持两种协议 - 最佳实践：Google 推荐的协议使用模式

应用场景

多智能体工作流

  • 任务拆解：将复杂任务分解为子任务并分配给不同智能体
  • 并行处理：协调多个智能体的并行执行
  • 结果聚合：将多个智能体的结果合并为统一输出
  • 错误恢复：处理多智能体场景中的故障与恢复

智能体市场

  • 服务发现：智能体发现并消费其他智能体提供的服务
  • 能力匹配：将智能体能力与任务需求进行匹配
  • 动态组合：根据可用性动态组合智能体工作流
  • 质量保障：确保智能体服务的质量与可靠性

企业级集成

  • 遗留系统集成：将智能体与现有企业系统集成
  • 跨部门协调：跨部门协调多个智能体
  • 合规与治理：在多智能体环境中确保合规性
  • 审计与监控：监控并审计多智能体的交互

云原生部署

  • 微服务架构：将智能体以微服务形式部署，通过 A2A 进行通信
  • 容器编排：使用 Kubernetes 等平台进行智能体部署
  • 服务网格：与服务网格技术集成以实现高级网络功能
  • 自动扩缩容：根据需求自动扩缩智能体部署规模

实施指南

快速开始

面向智能体开发者： 1. 协议实现：在你的智能体框架中实现 A2A 协议 2. 服务注册：将智能体能力注册到 A2A 注册表 3. 通信配置：与其他智能体建立通信通道 4. 测试：与其他符合 A2A 规范的智能体进行互操作测试

面向平台提供商： 1. 注册表搭建：搭建符合 A2A 规范的智能体注册表 2. 协议网关：实现 A2A 通信的协议网关 3. 安全配置：配置认证与授权机制 4. 监控：为智能体通信搭建监控与分析体系

开发最佳实践

协议合规： - 规范遵循：严格遵守 A2A 协议规范 - 版本兼容：确保跨协议版本的兼容性 - 错误处理：实现健壮的错误处理与恢复逻辑 - 测试：与其他 A2A 实现进行全面的互操作测试

性能优化： - 连接池：使用连接池提升性能 - 缓存：实施合适的缓存策略 - 异步通信：采用异步通信模式 - 负载均衡：将负载分发至多个智能体实例

安全注意事项： - 认证：实现强身份认证机制 - 授权：使用细粒度授权控制 - 加密：对所有敏感通信进行加密 - 审计日志：记录所有智能体交互以供安全审计

与其他协议的对比

A2A 与 MCP 对比

维度 A2A 协议 MCP 协议
核心定位 智能体间通信 向 LLM 提供上下文
通信模式 智能体对等交互 客户端-服务端资源访问
应用场景 多智能体协调 外部资源集成
复杂度 较高（分布式系统） 较低（客户端-服务端）
可扩展性 智能体横向扩展 资源纵向扩展

A2A 与传统 API 对比

A2A 的优势： - 语义理解：对智能体能力有丰富的语义理解 - 动态发现：动态发现并组合智能体服务 - 工作流协调：内置多智能体工作流支持 - 标准化：智能体通信的行业标准协议

传统 API 的优势： - 简洁：请求-响应模式更简单 - 成熟度：生态系统与工具链更成熟 - 性能：针对高性能场景优化 - 兼容性：与现有系统兼容性更广

未来路线图

近期开发

  • 规范定稿：完成正式协议规范
  • 参考实现：开发参考实现
  • 生态建设：构建 A2A 合规智能体生态
  • 互操作测试：开展全面的互操作性测试

长期愿景

  • 行业采用：在智能体生态中实现广泛普及
  • 高级特性：引入智能体学习与自适应等高级功能
  • 集成标准：与其他新兴标准进行整合
  • 全球标准化：通过标准机构推动国际标准化

社区与生态

开发社区

  • 开放开发：面向社区开放的开发流程
  • 工作组：针对不同议题的技术工作组
  • 反馈机制：定期收集社区反馈
  • 贡献指南：明确的社区贡献规范

行业合作

  • 技术伙伴：与主要科技公司的合作关系
  • 标准机构：与国际标准组织的协作
  • 学术研究：与学术研究机构的合作
  • 开源项目：与主要开源项目的集成

关键区分：A2A 与 MCP

A2A 与 MCP 是互补关系，而非竞争关系——二者运行在不同的抽象层次上。

协议 领域 交互类型 类比
MCP 工具与资源 具有结构化输入/输出的无状态函数调用 "执行这个具体操作"
A2A 智能体 能够推理、规划并维护状态的系统之间的有状态协作 "实现这个复杂目标"

何时使用 MCP：需要获取天气数据或查询数据库等简单的无状态函数时。

何时使用 A2A：需要委托复杂目标时，例如"分析上季度的客户流失情况并推荐三项干预策略"——这类任务需要推理、规划和多轮交互。

最适合需要持久服务合约的正式跨团队集成场景。 对于单个应用内部高度耦合的任务，轻量级本地子智能体往往更为高效。

A2A 协议：实现

Agent Cards（服务发现）

Agent Card 是标准化的 JSON 规范——每个智能体的"名片"。它描述了智能体的能力、安全要求、技能以及访问地址（URL）。生态中的任何智能体都可以通过 Agent Cards 发现其他智能体。

{
  "name": "check_prime_agent",
  "version": "1.0.0",
  "description": "An agent specialized in checking whether numbers are prime",
  "capabilities": {},
  "securitySchemes": {
    "agent_oauth2_0": { "type": "oauth2" }
  },
  "defaultInputModes": ["text/plain"],
  "defaultOutputModes": ["application/json"],
  "skills": [
    {
      "id": "prime_checking",
      "name": "Prime Number Checking",
      "description": "Check if numbers are prime using efficient algorithms",
      "tags": ["mathematical", "computation", "prime"]
    }
  ],
  "url": "http://localhost:8001/a2a/check_prime_agent"
}

Agent Cards 通过智能体 URL 下的 /.well-known/agent-card.json 路径提供服务。

ADK 实现

通过 A2A 暴露现有智能体（单次函数调用）：

from google.adk.a2a.utils.agent_to_a2a import to_a2a

root_agent = Agent(name='hello_world_agent', ...)
a2a_app = to_a2a(root_agent, port=8001)

# Serve with uvicorn: uvicorn agent:a2a_app --host localhost --port 8001
# Or via Vertex AI Agent Engine runtime

通过 A2A 调用远程智能体：

from google.adk.agents.remote_a2a_agent import RemoteA2aAgent

prime_agent = RemoteA2aAgent(
    name="prime_agent",
    description="Agent that handles checking if numbers are prime.",
    agent_card="http://localhost:8001/a2a/check_prime_agent/.well-known/agent-card.json"
)

层级组合——根编排者同时使用本地子智能体和远程 A2A 智能体：

# Local sub-agent
roll_agent = Agent(name="roll_agent", instruction="You are an expert at rolling dice.")

# Remote A2A agent
prime_agent = RemoteA2aAgent(
    name="prime_agent",
    agent_card="http://localhost:8001/.well-known/agent-card.json"
)

# Root orchestrator combining both
root_agent = Agent(
    name="root_agent",
    instruction="Delegate rolling dice to roll_agent, prime checking to prime_agent.",
    sub_agents=[roll_agent, prime_agent]
)

A2A 的强制性技术要求

A2A 交互本质上是有状态且分布式的，因此以下两项要求为必须满足的刚性条件：

  1. 分布式链路追踪：每个请求必须携带唯一的追踪 ID，以在多个智能体之间维护完整的审计追踪。这对于调试多智能体工作流至关重要。
  2. 健壮的状态管理：需要一套完善的持久化层，用于跨智能体边界追踪进度并确保事务完整性。

注册表架构

在规模较大的场景中，发现和管理智能体与工具需要集中式注册表。

工具注册表（Tool Registry）

工具注册表使用 MCP 等协议对所有工具进行编目。它无需为智能体开放数千个工具的全量访问权，而是支持精细化的访问列表管理：

智能体类型 访问模式
通用型智能体 完整目录——以速度/精度换取覆盖范围
专业型智能体 预定义子集——在特定任务上性能更高
动态型智能体 运行时查询注册表以适应新工具

主要价值在于人工发现——开发者在重复造轮子之前能先找到现有工具，安全团队可审计工具访问权限，产品负责人可了解系统能力边界。

智能体注册表（Agent Registry）

智能体注册表将同样的理念应用于智能体管理，使用 A2A 的 AgentCards 等格式。它帮助团队发现并复用已有智能体，减少重复建设，并为自动化的智能体间委托奠定基础。

决策框架：

注册表 何时构建
工具注册表 工具发现成为瓶颈，或安全需求要求集中审计
智能体注册表 多个团队需要发现并复用专业智能体，且不希望产生强耦合

建议先不引入注册表，待生态规模扩大到需要集中管理时再按需构建。

AWS 指南：多智能体系统中的 MCP 与 A2A

AWS 对这两种协议作出了明确区分，并警示了误用风险：

协议 接口 模式 AWS 指导建议
MCP 智能体 → 工具 客户端-服务端；智能体始终是客户端，工具服务端始终是响应方 多智能体 MCP：服务端必须在服务端层面实现按智能体的访问控制，而非在系统提示词中实现。工具 schema 的质量直接决定智能体行为质量。对各智能体配置中的 MCP 服务端版本进行版本控制，生产环境更新前须先测试。
A2A 智能体 → 智能体 对等协议；任何智能体均可发起或接收——与 MCP 的客户端-服务端模型不同，A2A 是对称的 A2A 会扩大攻击面：需对 task 对象进行 schema 校验；在每个 A2A 边界处应用 Amazon Bedrock Guardrails。不要用 MCP 进行智能体间委托——这是错误的抽象层次。

参见