本文基于 A2A 协议官方规范及源码，系统梳理协议的设计目标、核心构件、交互模型、企业级特性与扩展机制，为读者建立对 A2A 协议的完整认知框架。

一、背景与动机

随着大语言模型（LLM）驱动的 AI Agent 在各行业的广泛部署，一个关键问题日益凸显：由不同框架构建、不同组织运营、部署在不同服务器上的 Agent，如何以"Agent 对 Agent"的方式进行协作？

现有的做法通常是将 Agent 封装为工具（Tool）暴露给其他 Agent 调用。然而，这种方式本质上将 Agent 降级为无状态的函数调用，无法体现 Agent 的自主推理、多轮协商和长期任务管理能力。

Agent2Agent（A2A）协议正是为解决这一问题而设计的开放标准。它由 Google 贡献，现托管于 Linux Foundation，采用 Apache 2.0 许可证。A2A 的核心理念是：Agent 是自主的协作伙伴，而非被调用的工具。

二、协议定位：A2A 在 Agent 技术栈中的位置

在完整的 Agent 技术栈中，A2A 占据的是 Agent 间通信层：

层级 代表技术 职责
模型层 GPT、Gemini、Claude 等 LLM 提供推理与生成能力
框架层 ADK、LangGraph、CrewAI 等 提供 Agent 构建工具包
工具连接层 MCP（Model Context Protocol） 连接 Agent 与外部工具/数据源
Agent 协作层 A2A（Agent2Agent Protocol） 标准化 Agent 间的通信与协作

A2A 与 MCP 的关系是互补而非竞争的：

维度 A2A MCP
连接对象 Agent ↔ Agent Agent ↔ 工具/资源
交互特征 多轮、有状态、协商式 单次调用、无状态、结构化输入输出
典型场景 客服 Agent 委托计费 Agent 处理退款 Agent 调用数据库查询 API
设计哲学 Agent 是自主的协作伙伴 工具是被调用的能力原语

在实际系统中，Agent 之间通过 A2A 协议进行协作，而每个 Agent 内部通过 MCP 调用其专属的工具和资源。

三、核心角色模型

A2A 协议定义了三个核心角色：

User（终端用户：人类操作者或自动化服务）
  │
  ▼ 发起请求
A2A Client（客户端 Agent：代表用户发起通信）
  │
  ▼ A2A 协议通信（HTTP/JSON-RPC 2.0）
A2A Server（远程 Agent：实现 A2A 协议的 HTTP 端点）

其中，A2A Server 对客户端而言是不透明的（Opaque）——客户端无法也无需了解远程 Agent 的内部实现、记忆状态或工具集合。这一设计原则在保护知识产权的同时，也天然契合了标准的客户端-服务端安全范式。

四、五大基本构件

A2A 协议围绕五个核心数据结构组织通信：

4.1 Agent Card：Agent 的数字名片

Agent Card 是一个 JSON 文档，充当 Agent 的自描述清单。客户端通过解析 Agent Card 来判断某个 Agent 是否适合执行特定任务、如何构造请求以及如何安全通信。

Agent Card 包含以下关键信息：

  • 身份标识：名称（name）、描述（description）、服务提供方（provider）
  • 服务端点：支持的接口列表（supportedInterfaces），每个接口声明 URL、协议绑定方式（JSON-RPC / gRPC / HTTP+JSON）和协议版本
  • 能力声明：是否支持流式响应（streaming）、推送通知（pushNotifications）、扩展（extensions）
  • 安全要求：认证方案（securitySchemes）与安全需求（securityRequirements）
  • 技能列表：Agent 能执行的具体能力（skills），每个技能包含 ID、名称、描述、标签、示例、支持的输入/输出媒体类型

4.2 Task：有状态的工作单元

Task 是 A2A 协议中的核心动作单元，代表一项需要跟踪的工作。每个 Task 拥有唯一标识符（id）、所属上下文（contextId）、当前状态（status）、产出物（artifacts）和交互历史（history）。

Task 的生命周期由以下状态机定义：

SUBMITTED ──→ WORKING ──→ COMPLETED（终态）
                │
                ├──→ FAILED（终态）
                ├──→ CANCELED（终态）
                ├──→ REJECTED（终态）
                ├──→ INPUT_REQUIRED（中断态，等待用户输入）
                └──→ AUTH_REQUIRED（中断态，等待认证）

Task 不可变性原则：一旦 Task 进入终态（COMPLETED / FAILED / CANCELED / REJECTED），便不可重启。后续的修改或细化操作必须在同一 contextId 下创建新的 Task。这一设计带来了清晰的工作单元边界、可靠的输入输出映射以及简化的实现逻辑。

4.3 Message：通信的基本单位

Message 表示客户端与 Agent 之间的一次通信。每条 Message 包含：

  • 角色（role）：user（客户端→服务端）或 agent（服务端→客户端）
  • 唯一标识（messageId）
  • 内容（parts）：一个或多个 Part 对象
  • 关联信息：可选的 contextId、taskId、referenceTaskIds

4.4 Part：内容的原子容器

Part 是消息和产出物中内容的最小载体，采用 oneof 结构，支持以下四种内容类型：

类型 字段 说明
文本 text 纯文本字符串
原始字节 raw 二进制文件数据（JSON 序列化时为 Base64）
URL 引用 url 指向外部文件内容的 URI
结构化数据 data 任意 JSON 值（对象、数组、字符串、数字等）

每个 Part 还可附带 mediaType（MIME 类型）、filename（文件名）和 metadata（自定义元数据）。这一设计使 A2A 协议具备了模态无关性——Agent 之间可以交换文本、图片、视频、结构化数据等任意类型的内容。

4.5 Artifact：Task 的产出物

Artifact 代表 Agent 在执行 Task 过程中生成的具体交付物（如文档、图片、结构化数据）。与一般的 Message 不同，Artifact 是正式的工作成果。每个 Artifact 拥有唯一标识（artifactId）、人类可读的名称（name）和描述（description），并由一个或多个 Part 组成。

五、交互模型

A2A 协议支持三种交互模式，以适应不同的响应性和持久性需求：

5.1 同步请求/响应（轮询）

最基本的交互模式。客户端通过 SendMessage 方法发送请求，服务端返回响应。对于长时间运行的任务，客户端可通过 GetTask 方法周期性轮询任务状态。

适用场景：简单的即时交互，或对实时性要求不高的场景。

5.2 SSE 流式传输

客户端通过 SendStreamingMessage 方法发起流式连接，服务端通过 Server-Sent Events（SSE）实时推送增量结果和状态更新。

流式传输中，服务端推送的事件类型包括：

  • Task：当前任务的完整状态
  • TaskStatusUpdateEvent：任务状态变更通知（如从 WORKING 变为 COMPLETED）
  • TaskArtifactUpdateEvent：产出物的增量更新，支持通过 append 和 lastChunk 字段进行分块传输

当任务进入终态或中断态时，服务端关闭流连接。若连接意外断开，客户端可通过 SubscribeToTask 方法重新订阅。

适用场景：实时进度监控、大型产出物的增量接收、低延迟的交互式对话。

5.3 Push 推送通知

针对超长时间运行的任务（分钟、小时甚至天级别），或客户端无法维持持久连接的场景（如移动端、Serverless 函数），A2A 支持服务端主动向客户端提供的 Webhook 地址发送推送通知。

客户端通过 PushNotificationConfig 配置推送地址、认证信息和验证令牌。服务端在任务发生重要状态变更时触发推送。

推送通知涉及严格的安全要求：

  • 服务端：需验证 Webhook URL 的合法性（防止 SSRF），并按配置的认证方案向 Webhook 进行身份认证
  • 客户端：需验证推送来源的真实性（如 JWT 签名验证），并防范重放攻击（时间戳校验、Nonce 机制）

六、上下文管理与任务编排

6.1 contextId：逻辑会话标识

contextId 是由服务端生成的标识符，用于将多个 Task 和独立 Message 逻辑分组，提供跨交互的连续性。Agent 内部（尤其是基于 LLM 的 Agent）利用 contextId 管理其对话状态或 LLM 上下文。

工作流程：

  1. 客户端首次发送消息时，服务端在响应中返回新的 contextId
  2. 客户端在后续消息中携带相同的 contextId，表示延续同一会话
  3. 客户端可选择性地附带 taskId，表示继续特定的 Task

6.2 Agent 的响应策略

Agent 收到消息后，可选择两种响应方式：

  • 返回 Message：适用于即时的、无状态的交互（如能力协商、简单问答）
  • 返回 Task：适用于需要长时间处理、状态跟踪的工作

据此，Agent 可分为三类：

类型 行为 适用场景
纯 Message Agent 始终返回 Message 简单的 LLM 封装、轻量工具调用
纯 Task Agent 始终返回 Task 统一的工作流管理
混合 Agent 先用 Message 协商，再用 Task 跟踪执行 复杂的多轮协作场景

6.3 并行任务与任务细化

A2A 支持在同一 contextId 下创建多个并行 Task，并通过 referenceTaskIds 建立任务间的依赖关系。例如：

Task 1: 预订飞往赫尔辛基的航班
Task 2: 基于 Task 1 的结果，预订酒店
Task 3: 基于 Task 1 的结果，预订雪地摩托活动
Task 4: 基于 Task 2 的结果，为酒店添加 SPA 预约

当需要对已完成 Task 的产出物进行修改时，客户端在同一 contextId 下发起新的 Task，并通过 referenceTaskIds 引用原始 Task。服务端在生成修改版本时应保持一致的 artifact-name，以便客户端进行版本追踪。

七、Agent 发现机制

客户端需要先发现并理解远程 Agent 的能力，才能发起协作。A2A 定义了三种发现策略：

7.1 Well-Known URI

遵循 RFC 8615 规范，Agent 将其 Agent Card 托管在标准化路径：

https://{agent-server-domain}/.well-known/agent-card.json

客户端通过 HTTP GET 请求获取 Agent Card。此方式适用于公开 Agent 或域内广泛发现的场景。

7.2 注册中心（Catalog）

在企业环境或公共市场中，Agent Card 由中央注册服务统一管理。客户端通过注册中心的 API 按技能、标签、提供方等条件检索 Agent。此方式支持集中治理和基于能力的发现，但需要额外部署和维护注册服务。

7.3 直接配置

在紧耦合系统、私有 Agent 或开发环境中，客户端通过硬编码、配置文件或环境变量直接获取 Agent Card 信息。此方式简单直接，但缺乏动态发现能力。

7.4 Agent Card 的安全与缓存

对于包含敏感信息的 Agent Card，A2A 推荐使用认证扩展 Agent Card（Extended Agent Card）机制，仅在客户端通过认证后返回完整信息。同时，Agent Card 应遵循标准的 HTTP 缓存语义（Cache-Control、ETag），在减少不必要请求的同时确保客户端最终获取到更新后的信息。

八、企业级特性

A2A 协议在设计之初便将企业级需求纳入考量，而非事后补充：

8.1 传输安全

  • 生产环境强制使用 HTTPS
  • 推荐 TLS 1.2 及以上版本
  • 客户端应验证服务端的 TLS 证书

8.2 认证与授权

  • 认证：通过 Agent Card 的 securitySchemes 声明支持的认证方案（API Key、HTTP Bearer、OAuth 2.0、OpenID Connect、mTLS）
  • 凭证通过标准 HTTP Header 传输，不嵌入协议载荷
  • 授权：按技能粒度控制访问权限，遵循最小权限原则
  • 支持任务内二次认证（AUTH_REQUIRED 状态）

8.3 可观测性

  • 支持 OpenTelemetry 分布式追踪（W3C Trace Context）
  • 推荐记录 taskId、contextId、关联 ID 等关键信息
  • 服务端应暴露请求速率、错误率、任务处理延迟等运营指标

8.4 API 治理

对于对外暴露的 A2A 服务，推荐集成 API 管理方案，实现集中策略执行、流量管理、分析报告和开发者门户等能力。

九、扩展机制

A2A 协议通过 Extension 机制支持在不破坏核心规范的前提下扩展协议能力。

9.1 扩展的类型

类型 说明 示例
数据扩展 在 Agent Card 中暴露新的结构化信息 GDPR 合规声明
Profile 扩展 对核心请求/响应施加额外约束 要求所有消息使用特定 Schema 的 DataPart
方法扩展 添加全新的 RPC 方法 tasks/search 方法用于检索历史任务
状态机扩展 为 Task 状态机添加新状态或转换 自定义子状态

9.2 扩展的生命周期

扩展遵循严格的治理流程：

提案阶段 → Maintainer 赞助 → 实验性开发 → 毕业为官方扩展 → （可选）提升为核心协议特性

9.3 扩展的激活

扩展默认处于非激活状态。客户端通过在 HTTP 请求中包含 A2A-Extensions Header（逗号分隔的扩展 URI 列表）来请求激活特定扩展。服务端在响应中回显成功激活的扩展列表。

9.4 扩展的限制

扩展不允许修改核心数据结构的定义（如添加/删除字段）或向枚举类型添加新值。自定义属性应放置在核心数据结构的 metadata 字段中。

十、协议规范的技术基础

A2A 协议的通信基于以下技术标准：

  • 传输层：HTTP(S)
  • 载荷格式：JSON-RPC 2.0
  • 接口定义：Protocol Buffers（proto3），支持 JSON-RPC、gRPC、HTTP+JSON 三种协议绑定
  • 流式传输：Server-Sent Events（SSE）
  • 异步通知：Webhook + HTTP POST

协议的完整接口定义位于 specification/a2a.proto 文件中，定义了 A2AService 服务及其所有 RPC 方法：

RPC 方法 功能
SendMessage 向 Agent 发送消息
SendStreamingMessage 发送流式消息，实时接收状态更新
GetTask 获取任务的最新状态
ListTasks 按条件列出任务
CancelTask 取消进行中的任务
SubscribeToTask 订阅任务更新（SSE 重连）
CreateTaskPushNotificationConfig 创建推送通知配置
GetTaskPushNotificationConfig 获取推送通知配置
ListTaskPushNotificationConfigs 列出推送通知配置
DeleteTaskPushNotificationConfig 删除推送通知配置
GetExtendedAgentCard 获取认证后的扩展 Agent Card

十一、A2A 协议源码仓库与 Python SDK 的关系

理解 A2A 生态需要区分两个核心仓库：

维度 A2A（协议规范仓库） a2a-python（Python SDK）
性质 协议标准定义 协议的 Python 语言实现
核心内容 proto 定义 + 文档 + 治理文件 可安装的 pip 包（a2a-sdk）
包含代码 无可运行代码 完整的客户端/服务端实现
传输支持 定义了三种协议绑定 实现了 JSON-RPC、REST、gRPC 三种传输
可选集成 — FastAPI/Starlette、OpenTelemetry、SQL 数据库
当前版本 1.0 规范已发布 稳定版实现 v0.3，1.0 alpha 开发中

两者的关系类似于 HTTP 规范与 requests 库、OpenAPI 规范与 FastAPI 框架的关系。

十二、总结

A2A 协议为 AI Agent 生态提供了一套完整的协作通信标准。其设计遵循以下核心原则：

  • 简洁性：基于 HTTP、JSON-RPC、SSE 等成熟技术，降低采纳门槛
  • 不透明性：Agent 间协作无需暴露内部实现，保护知识产权
  • 企业就绪：认证、授权、可观测性、API 治理等能力内建于协议设计
  • 异步优先：原生支持长时间运行任务、流式传输和推送通知
  • 模态无关：支持文本、文件、结构化数据等任意内容类型的交换
  • 可扩展：通过 Extension 机制支持领域特定的定制，不破坏核心规范

参考资料：

# 人工智能
Logo
龙虾开发者社区

小龙虾开发者社区是 CSDN 旗下专注 OpenClaw 生态的官方阵地，聚焦技能开发、插件实践与部署教程，为开发者提供可直接落地的方案、工具与交流平台，助力高效构建与落地 AI 应用

更多推荐

cover

OpenClaw部署和使用心得

avatar 龙虾开发者社区

AI 龙虾 | 对学习工作的影响和未来前瞻

AI 龙虾（OpenClaw）是能自主操控设备、完成全流程任务的 AI 智能体，核心是 “动口即执行”，正从工具升级为数字生产力单元，深刻重塑学习与工作模式。

avatar 龙虾开发者社区
cover

动手写个agent（四）：实现接入MCP 协议

avatar 龙虾开发者社区