Agent2Agent（A2A）协议

Agent2Agent（A2A）协议是用于独立智能体系统之间交换信息、委派工作和跟踪任务的开放协议。它面向可能由不同框架、语言或供应方构建的系统，约定双方如何描述能力、发出消息、表示任务状态，以及交付文本、文件或结构化结果。A2A 的目标是让一个智能体能与远端智能体协作，同时仍可将自己的内部实现保持为黑箱。

A2A 最初由 Google 于 2025 年 4 月发起；Linux Foundation 于 2025 年 6 月 23 日宣布 A2A 项目加入并由其托管。2026 年 8 月 17 日，Agentic AI Foundation（AAIF）宣布 A2A 将作为托管项目加入其开放智能体栈；8 月 27 日，A2A 项目方确认该协议已被正式接纳为 AAIF 的 Growth Stage 项目。A2A 社区于 2026 年 3 月 12 日发布 v1.0.0，公告称这是首个稳定、面向生产环境的版本；v1.0.1 的 GitHub 发布说明将版本条目标注为 2026 年 5 月 26 日，而 GitHub 发布页显示该 release 于 5 月 28 日发布。本文按 v1.0.1 版本化规范说明协议，不把设计目标等同于每个实现都具备的功能。

发行标签与协议协商字段也要区分：文中引用的规范发行标签是 v1.0.1，而卡片接口中的 protocolVersion 以及请求中的 A2A-Version 使用主、次版本格式 1.0；规范说明，补丁号不参与线上协议版本协商。讨论某个实现的兼容性时，应先分清指的是规范发行号还是双方实际协商的协议版本。

A2A 描述的是智能体之间的应用层交互约定，不规定智能体使用哪种模型、如何推理、怎样保存记忆，或内部如何调用工具。协议有意让参与者只交换完成协作所需的信息，而不要求披露内部计划、提示词或工具实现。它可以为委派任务提供共同的线格式和生命周期，但任务分解、路由、执行策略以及结果是否正确，仍取决于具体系统。

A2A 将交互双方称为客户端和服务器。客户端是代表用户或其他系统发起请求的应用或智能体；服务器是公开 A2A 端点、接收请求并返回响应或处理任务的远端智能体系统。客户端与服务器是一次交互中的协议角色，不意味着只能由某种固定产品担任。智能体系统可以在不同连接中分别作为客户端和服务器。

服务器须提供 Agent Card，即以 JSON 表示的智能体资料。卡片用于说明身份、描述、服务能力、技能、接口地址和认证要求；它还可声明如流式更新、推送通知等可选能力，以及服务器接受的协议绑定、版本和安全方案。卡片或单项技能也能声明可接收和输出的媒体类型，帮助客户端检查内容格式是否匹配。客户端可据此了解远端声明提供什么，以及如何连接。卡片是能力与连接资料，不是对能力质量、任务成功率或安全性的背书。

规范列出几种获得卡片的方式：读取标准发现地址 /.well-known/agent-card.json，查询人工维护或策划的目录，也可使用预配置的卡片地址或内容。A2A 因此给出可互操作的卡片格式和一种惯用发现路径，但并不要求所有参与者使用同一个全球目录，也不替部署者自动筛选可信智能体。卡片可以使用 JSON Web Signature 签名，帮助客户端验证内容完整性和来源声明；签名是可选的，信任密钥的来源与验证策略仍需客户端自行管理。部分服务还可在认证后提供扩展卡片，公开更详细的技能或设置。

消息（Message）表示客户端与远端智能体之间的一次通信，具有消息标识、发送角色、内容部件，并可关联上下文或某项任务。协议中的角色主要是 user（客户端发出的消息）和 agent（服务器发出的消息）。上下文标识可把若干相关交互归在一起；任务标识则指向一次有状态的工作。二者让客户端能够区分一轮对话中的多项工作，而不要求把所有信息塞进单条文本。

任务（Task）是 A2A 管理的工作单位，通常由服务器分配唯一标识，记录当前状态、相关消息历史和输出制品（Artifact）。发送消息后，服务器可以为需要跟踪的工作创建任务，也可以对简单交互直接返回一条消息。任务状态包括已提交、处理中、已完成、失败、已取消、等待补充输入、被拒绝和需要认证等。补充输入或认证是中断状态，表示客户端需先提供后续信息；成功、失败、取消或拒绝则是终结状态。客户端可查询任务、列出任务或请求取消，但取消操作的结果并非总能保证。

消息偏重沟通与补充说明，制品用于承载任务输出，例如文档、图像或结构化数据。规范区分二者，是为了让客户端能单独读取任务进度和结果。需要多轮交互时，客户端可向既有任务发送后续消息，并用上下文标识把相关任务与消息归组；服务器如何继承先前上下文仍由具体实现决定。任务历史是否保存每条消息、服务器保留多久、任务执行期间如何处理用户授权等，也有实现与部署层面的差异；客户端不应把协议对象的存在误认为远端系统一定持久保存了全部对话内容。

消息和制品都由一个或多个 Part 组成。v1.0.1 的数据模型允许一个部件承载文本、原始字节、指向文件的 URL，或 JSON 结构化数据，并可附带文件名、MIME 媒体类型及元数据。一个 Part 只选择其中一种内容形式。这样的统一容器可表达纯文本、文件以及结构化负载；图像、音频或视频等可以作为文件内容或引用来传递。它并不意味着任一接收方都能读取或处理所有媒体类型。客户端应结合 Agent Card 与技能声明判断支持情况，服务器也可以因内容类型不受支持而拒绝请求。

交互既可以是简短的请求—响应，也可以是长任务。普通发送消息操作可返回直接 Message，或返回一个 Task 以便后续查询。若服务器声明并支持流式能力，客户端可通过流式消息操作接收初始任务、状态变化和逐步到达的制品片段；对既有任务也可订阅更新。另一种选择是在服务支持时注册 webhook 接收 HTTP 推送，或定期查询任务。推送和流式能力不是每个 A2A 端点都必须提供的共同保证；客户端要检查卡片中的能力声明，并准备适当的轮询或错误处理方式。

规范把数据模型、抽象操作和传输绑定分层定义，使不同绑定可以映射到相同的核心语义。v1.0.1 规定 JSON-RPC、gRPC 和 HTTP+JSON/REST 绑定，并给出增加自定义绑定的指南。Agent Card 中的 supportedInterfaces 可列出服务实际支持的接口与偏好顺序；客户端依照双方支持的接口选择连接。因此，实现不必支持所有绑定，声称双方兼容之前仍应核对协议版本、绑定、可选能力、扩展及具体媒体类型。

安全也有明确边界。生产部署必须对 HTTP 通信使用 HTTPS、对 gRPC 使用 TLS；客户端应验证服务器证书。Agent Card 可公布 API Key、HTTP 认证或 OAuth 等安全方案，客户端应通过该方案的带外流程获得凭据，再按绑定要求发送。服务器负责验证凭据，并依照自身的身份、技能、数据访问规则或授权策略批准请求。协议规定了可用的数据结构和交互要求，但不会替部署者建立信任关系、分配权限或保证远端行为安全。Agent Card 签名可用于发现阶段的完整性验证，仍不能替代传输加密、密钥信任和访问控制。

A2A 与 Model Context Protocol（MCP）解决的是不同层次的问题。A2A 的重点是独立智能体之间如何发现彼此、协商交互方式、管理任务并交换上下文或结果；MCP 的重点是模型或智能体如何连接工具、API、数据源等外部资源，并用结构化方式传递工具输入和输出。A2A 规范将两者描述为互补：一个智能体可以通过 A2A 委派工作，而受托智能体在自身内部使用 MCP 调用工具。这个组合是可能的系统架构，不是两种协议自动互通或自动转换的承诺。

因此，A2A 不是智能体框架、工具目录、统一的模型接口或全局身份系统，也不会自动让两个能力描述相似的智能体理解对方的业务语义。它统一的是一组通信对象、操作和绑定约定；实际互操作仍取决于实现是否符合对应版本、双方声明的能力是否重合、认证与授权是否完成，以及交付内容是否对接收方有意义。理解这一区分，才能把 A2A 看作多智能体系统中的通信层，而不是对应用逻辑、安全治理或实际效果的替代。