A2A 中的核心概念和组件¶
A2A 使用一组核心概念来定义代理如何交互。理解这些核心构建块有助于开发 A2A 兼容系统或与之集成。
A2A 交互中的核心参与者¶
- 用户：最终用户，可以是人工操作员或自动化服务。用户发起请求或定义需要一个或多个 AI 代理协助的目标。
- A2A 客户端（客户端代理）：代表用户操作的应用程序、服务或另一个 AI 代理。客户端使用 A2A 协议发起通信。
- A2A 服务器（远程代理）：一个 AI 代理或一个代理系统，它公开一个实现 A2A 协议的 HTTP 端点。它接收来自客户端的请求，处理任务，并返回结果或状态更新。从客户端的角度来看，远程代理作为不透明（黑盒）系统运行，这意味着其内部工作、内存或工具不会暴露。
基本通信要素¶
下表描述了 A2A 中的基本通信要素
| 要素 | 描述 | 主要目的 |
|---|---|---|
| 代理卡 | 一个 JSON 元数据文档，描述代理的身份、能力、端点、技能和身份验证要求。 | 使客户端能够发现代理并了解如何安全有效地与它们交互。 |
| 任务 | 由代理发起的一个有状态工作单元，具有唯一 ID 和定义的生命周期。 | 便于跟踪长时间运行的操作，并实现多轮交互和协作。 |
| 消息 | 客户端和代理之间的一次通信回合，包含内容和角色（“用户”或“代理”）。 | 传达指令、上下文、问题、答案或状态更新，这些不一定是正式的工件。 |
| 部分 | 消息和工件中使用的基本内容容器（例如，TextPart、FilePart、DataPart）。 | 为代理在消息和工件中交换各种内容类型提供了灵活性。 |
| 工件 | 代理在任务期间生成的有形输出（例如，文档、图像或结构化数据）。 | 交付代理工作的具体结果，确保结构化和可检索的输出。 |
交互机制¶
A2A 协议支持各种交互模式，以适应不同的响应性和持久性需求。这些机制确保代理可以高效可靠地交换信息，无论任务的复杂性或持续时间如何
- 请求/响应（轮询）：客户端发送请求，服务器响应。对于长时间运行的任务，客户端会定期轮询服务器以获取更新。
- 使用服务器发送事件 (SSE) 进行流式传输：客户端发起流式传输，以通过开放的 HTTP 连接从服务器接收实时、增量结果或状态更新。
- 推送通知：对于非常长时间运行的任务或断开连接的场景，当发生重要的任务更新时，服务器可以主动向客户端提供的 webhook 发送异步通知。
有关流式传输和推送通知的详细探讨，请参阅流式传输和异步操作文档。
代理卡¶
代理卡是一个 JSON 文档，用作初始发现和交互设置的数字名片。它提供有关代理的基本元数据。客户端解析此信息以确定代理是否适合给定任务、如何构造请求以及如何安全通信。关键信息包括身份、服务端点（URL）、A2A 功能、身份验证要求和技能列表。
消息和部分¶
消息代表客户端和代理之间的一次通信回合。它包括一个角色（“用户”或“代理”）和一个唯一的messageId。它包含一个或多个 Part 对象，这些对象是实际内容的细粒度容器。这种设计使 A2A 能够独立于模态。
主要的部分类型是
TextPart：包含纯文本内容。FilePart：表示一个文件。它可以通过内联（Base64 编码）或通过 URI 传输。它包括“name”和“mimeType”等元数据。DataPart：携带结构化的 JSON 数据。这对于表单、参数或任何机器可读信息都很有用。
工件¶
工件表示远程代理在任务处理期间生成的有形输出或具体结果。与一般消息不同，工件是实际的可交付成果。工件具有唯一的artifactId、人类可读的名称，并由一个或多个部分对象组成。工件与任务生命周期紧密相关，可以增量地流式传输到客户端。
代理响应：任务或消息¶
代理响应可以是一个新的Task（当代理需要执行长时间运行的操作时）或一个Message（当代理可以立即响应时）。
有关更多详细信息，请参阅任务生命周期。
其他重要概念¶
- 上下文 (
contextId)： 服务器生成的标识符，可用于逻辑上将多个相关的Task对象分组，为一系列交互提供上下文。 - 传输和格式： A2A 通信通过 HTTP(S) 进行。JSON-RPC 2.0 用作所有请求和响应的负载格式。
- 身份验证和授权： A2A 依赖于标准的 Web 安全实践。身份验证要求在代理卡中声明，凭据（例如，OAuth 令牌、API 密钥）通常通过 HTTP 标头传递，与 A2A 协议消息本身分开。有关更多信息，请参阅企业级功能。
- 代理发现： 客户端查找代理卡以了解可用的 A2A 服务器及其功能的过程。有关更多信息，请参阅代理发现。
- 扩展： A2A 允许代理在其代理卡中声明自定义协议扩展。有关更多信息，请参阅扩展。