A2A

一、A2A 协议的架构由哪些核心组件组成？

1. Agent Card（智能体名片）

Agent Card 是一个 JSON 格式的元数据文档，通常发布在智能体服务域名的 /.well-known/agent.json 路径下。它描述了智能体的身份信息（名称、描述、服务提供方）、服务端点 URL、支持的协议版本、能力声明（是否支持流式响应、推送通知）、技能列表（智能体可执行的具体能力及其输入输出模式）以及安全要求（认证方案、权限需求）。客户端通过解析 Agent Card 来判断某个智能体是否适合执行特定任务以及如何安全通信。

2. Task（任务）

Task 是 A2A 协议中的核心动作单元，代表一项需要跟踪的工作。每个 Task 拥有唯一标识符（id）、所属上下文（contextId）、当前状态（status）、产出物（artifacts）和交互历史（history）。Task 的生命周期由明确的状态机定义：SUBMITTED（已提交）→ WORKING（执行中）→ COMPLETED（已完成）→ FAILED（已失败）→ CANCELED（已取消）→ REJECTED（已拒绝）→ INPUT_REQUIRED（等待输入）→ AUTH_REQUIRED（等待认证）。一旦 Task 进入终态（COMPLETED / FAILED / CANCELED / REJECTED），便不可重启，后续操作必须在同一 contextId 下创建新的 Task。

3. Message（消息）

Message 表示客户端与智能体之间的一次通信，包含一个角色标识（role），值为 "user"（客户端发送）或 "agent"（服务端发送），以及一个或多个 Part 对象。每个 Message 拥有唯一标识符（messageId），用于传达指令、上下文、问题、回答或状态更新。Message 是 Task 生命周期中的交互载体。

4. Part（内容单元）

Part 是 Message 或 Artifact 中的基本内容的单位，每个 Part 具有特定类型，可以携带不同种类的数据：TextPart 包含纯文本内容；FilePart 表示文件，可通过内联 base64 编码字节或 URI 引用传输，包含文件名和媒体类型等元数据；DataPart 携带结构化 JSON 数据，适用于表单、参数或任何机器可读信息。

5. Artifact（产出物）

Artifact 代表远程智能体在执行任务过程中生成的有形输出或结果，例如生成的文档、图像、电子表格、结构化数据结果或任何其它自包含的信息片段。Task 处于 COMPLETED 状态时，应使用 Artifact 对象将生成结果返回给客户端。Artifact 由一个或多个 Part 对象组成，支持增量流式传输。

二、A2A 协议支持哪些传输协议和通信方式？

1. JSON-RPC 2.0 over HTTP(S)

这是 A2A 协议的主要数据传输格式。所有请求和响应（不包括 SSE 流包装器）必须符合 JSON-RPC 2.0 规范。HTTP 请求的 Content-Type 头必须设为 application/json。方法名称遵循 {类别}/{动作} 模式，例如 message/send、tasks/get。该绑定最为通用，可穿透大多数防火墙，适合跨网络通信。

2. gRPC over HTTP/2

智能体可选择支持 gRPC 传输绑定。该方式使用 Protocol Buffers 版本 3 进行消息序列化，必须实现 A2AService gRPC 服务定义中声明的所有方法，行为须与其它受支持传输方式功能等效。gRPC 绑定利用 HTTP/2 多路复用减少连接开销，提供原生双向流支持，适合高性能、低延迟的内部网络场景。

3. HTTP+JSON/REST

智能体可选择支持 REST 风格的 HTTP+JSON 传输绑定。该方式使用适当的 HTTP 动词（GET 表示查询、POST 表示动作、PUT 表示更新、DELETE 表示移除），URL 模式遵循各方法章节中定义的路径（例如 /v1/message:send、/v1/tasks/{id}）。该绑定与现有 Web 基础设施兼容，适合 Web 原生应用场景。

4. Server-Sent Events（SSE）流式传输

A2A 协议支持通过 SSE 实现流式响应。当使用 message/stream 或 tasks/resubscribe 等方法时，服务端以一个保持打开的 HTTP 连接响应，通过该连接推送 Server-Sent Events 流。每个 SSE 的 data 字段包含一个完整的 JSON-RPC 2.0 Response 对象（具体为 SendStreamingMessageResponse）。SSE 传输适用于需要实时进度更新的长时间运行任务。

5. Webhook 推送通知

对于无法或不愿维持持久连接的客户端（如移动客户端或无服务器函数），A2A 支持通过推送通知实现异步更新。客户端在发起任务时提供 webhook URL（或通过调用 tasks/pushNotificationConfig/set 设置），当任务状态发生重大变化（如完成、失败或需要输入）时，服务端主动向该 webhook 发送异步通知（HTTP POST 请求）。

6. A2A over MQTT（腾讯云 TDMQ 创新实现）

除了标准的 HTTP/JSON-RPC 传输绑定外，腾讯云 TDMQ（消息队列）提供了基于 MQTT 的 A2A 传输实现，为智能体通信提供了异步消息队列能力。与标准的 HTTP 传输不同，A2A over MQTT 通过 MQTT broker 实现智能体发现和任务传递：智能体在启动时将其 Agent Card 发布为 MQTT 保留消息到发现主题（Discovery Topic），其他智能体通过订阅该主题动态发现可用智能体；任务请求通过 MQTT 发布到目标智能体的任务主题（Task Topic），智能体订阅该主题接收任务请求。这种基于消息队列的传输方式适合长时间运行任务、跨网络场景以及需要异步通信的应用场景，避免了传统 HTTP 请求可能出现的超时和断连问题。

三、A2A 协议如何实现异步任务处理？

1. 流式传输（Server-Sent Events）

对于生成增量结果（如生成长文档或流式媒体）或提供持续状态更新的任务，A2A 使用 Server-Sent Events（SSE）支持实时通信。客户端使用 message/stream RPC 方法发送初始消息并同时订阅该任务的更新。服务端在 Agent Card 中通过设置 capabilities.streaming: true 声明其支持流式能力。服务端通过 SSE 流推送的事件类型包括：Task（任务状态）、TaskStatusUpdateEvent（任务状态变更通知）、TaskArtifactUpdateEvent（新产出物或更新产出物通知）。流终止通过 TaskStatusUpdateEvent 中设置 final: true 来发出信号。

2. 推送通知（Webhook）

对于运行时间极长（数分钟、数小时甚至数天）的任务，或客户端无法维持持久连接的场景，A2A 支持通过推送通知进行异步更新。该机制允许 A2A 服务端在发生重要任务更新时，主动向客户端提供的 webhook 端点发送通知。推送通知配置可以通过初始 message/send 或 message/stream 请求中的 PushNotificationConfig 参数提供，也可以通过调用 CreateTaskPushNotificationConfig 方法单独设置。同一任务可以关联多个 PushNotificationConfig 对象，以支持向多个端点发送通知。

3. 轮询获取任务状态

对于不支持流式传输或推送通知的场景，客户端可以周期性调用 tasks/get 方法来轮询任务状态，直到任务达到终态（如 completed、failed）。该方式适合简单的客户端实现，但会引入轮询延迟，且增加了服务端的请求负载。

4. 断线重连（Resubscription）

如果客户端的 SSE 连接在任务仍然活动时过早断开（且服务端尚未为该阶段发送 final: true 事件），客户端可以尝试使用 tasks/resubscribe RPC 方法重新连接到流。服务端在断开连接期间丢失事件的行为（例如是否回填或仅发送新更新）取决于具体实现。

5. 阻塞与非阻塞执行模式

SendMessageConfiguration 中的 blocking 字段控制 SendMessage 是否等待任务完成：blocking: true 时操作等待任务达到终态后再返回；blocking: false 时操作立即返回任务进行中的状态。需要注意的是，blocking 字段对流式操作（始终实时返回更新）或推送通知配置（独立运行）没有影响。

四、A2A 协议适用于哪些应用场景？

1. 跨部门智能体协作

在企业内部，不同部门通常各自构建了针对其业务场景的智能体。A2A 协议使这些智能体能够跨部门协作。例如，销售智能体在接收到客户需求后，可以自动将需求细节转发给技术智能体进行评估；技术智能体完成评估后自动通知销售智能体，形成全自动化的跨部门协作链条。

2. 供应链管理系统

供应链管理涉及采购、库存、物流等多个环节的协调。通过 A2A 协议，采购智能体、库存智能体和物流智能体可以形成自动化协作链条：采购智能体根据库存智能体提供的库存水平数据决策采购计划，物流智能体根据采购计划安排配送，各环节智能体通过 A2A 协议交换数据和状态更新，实现端到端的供应链自动化管理。

3. 智能客服升级

在客户服务场景中，A2A 协议使对话智能体能够在无法回答用户问题时，自动协调到专业智能体进行处理，而用户对此过程无感知。例如，当用户咨询账单问题时，对话智能体通过 A2A 协议将问题委托给账单智能体，账单智能体处理完成后将结果返回给对话智能体，由对话智能体以统一的交互界面向用户呈现结果。

4. 金融服务协同

金融服务涉及多个系统和严格的合规要求。A2A 协议使不同金融机构的智能体能够安全协作：风险评估智能体分析客户信用风险，反欺诈智能体实时监测异常交易，合规智能体验证操作符合监管要求，各智能体通过 A2A 协议交换风险评估结果和合规验证信息，在保障数据安全的前提下实现跨机构的智能协作。

5. 智能家居与车家互联

在消费电子领域，A2A 协议已被应用于智能家居场景。家电智能体与手机智能体通过 A2A 协议实现互联，用户可以通过手机语音助手控制家电设备；同时，车家互联场景也在快速发展，汽车智能体与智能家居智能体通过 A2A 协议交换信息，实现"人-车-家"全生态的智能协同体验。

6. 智能运维场景

在 IT 运维领域，A2A 协议使智能运维平台能够协调多个专用智能体完成复杂的诊断和修复任务。例如，腾讯云 Cloud Mate AI Agent Platform 使用 A2A 协议实现分布式智能体架构：基础设施监控智能体检测异常后，通过 A2A 协议将诊断任务委托给日志分析智能体；日志分析智能体完成分析后，将结果返回给修复建议智能体；修复建议智能体生成修复方案后，通过 A2A 协议将执行指令发送给自动化运维智能体。整个流程无需人工干预，实现了从故障检测到自动修复的完整闭环。

五、A2A 协议在跨组织协作中如何发挥作用？

1. 基于 Agent Card 的能力发现机制

A2A 协议通过 Agent Card 实现去中心化的智能体发现。每个智能体在其服务域名的 /.well-known/agent.json 路径下发布一个 JSON 格式的元数据文档，描述其身份、能力、认证方案和技能列表。客户端智能体通过获取并解析远程智能体的 Agent Card，了解对方能执行哪些任务、如何构造请求以及如何安全通信，从而实现对外部智能体能力的可编程发现，无需中心化注册表。

2. 不透明执行模型（Opaque Execution）

A2A 协议的设计理念是：客户端智能体不需要了解远程智能体的内部工作方式、记忆状态或工具调用细节。远程智能体对于客户端而言是一个"不透明"的系统。客户端只需通过 Agent Card 了解远程智能体能提供哪些能力，然后通过标准协议发送任务请求，远程智能体自主决定如何完成任务。这种不透明执行模型保护了各组织的知识产权和系统集成细节，同时实现了跨组织的智能体协作。

3. 有状态的任务生命周期管理

A2A 协议为跨组织任务提供了明确的状态生命周期管理。任务从提交（SUBMITTED）开始，经过执行中（WORKING）、等待输入（INPUT_REQUIRED）、等待认证（AUTH_REQUIRED）等中间状态，最终达到完成（COMPLETED）、失败（FAILED）、取消（CANCELED）或拒绝（REJECTED）等终态。跨组织协作中的各参与方智能体通过跟踪任务状态，了解任务的执行进展和结果，实现可靠的跨组织工作流编排。

4. 安全通信与身份认证

A2A 协议在协议层面定义了完善的安全机制，保障跨组织通信的安全性。Agent Card 中的 securitySchemes 字段声明智能体支持的认证方案（API Key、HTTP Bearer Token、OAuth 2.0、OpenID Connect、Mutual TLS 等）。客户端必须使用与服务端匹配的认证方案获取访问凭证，并在每次请求中通过 HTTP 头传递该凭证。此外，A2A v1.0 引入了 Signed Agent Cards 特性，允许智能体对其 Agent Card 进行加密签名，防止在开放网络中智能体冒充攻击。

5. 企业级多租户支持

A2A v1.0 引入了企业级多租户支持，使同一智能体服务能够安全地同时为多个租户（组织）提供隔离的服务。多租户架构确保每个租户的数据和任务状态相互隔离，防止跨租户数据泄露。这对于SaaS形态的智能体服务尤其重要，使智能体服务提供者能够在保障安全隔离的前提下，利用 A2A 协议向多个企业客户提供智能体协作能力。

六、如何在项目中实现 A2A 协议？

1. 选择并安装官方 SDK

A2A 项目为多种编程语言提供了官方 SDK，开发者应优先使用 SDK 而非从零实现协议。Python 开发者可以通过 pip install a2a-sdk 安装 SDK；若需要 HTTP 服务器、gRPC、数据库等扩展功能，可以安装对应的扩展包（如 pip install "a2a-sdk[all]"）。其它语言的 SDK 包括：Go（a2a-go）、Java（a2a-java）、JavaScript/TypeScript（a2a-js）、C#/.NET（a2a-dotnet）、Rust（a2a-rs）。SDK 处理了协议机制（消息序列化、HTTP 传输、事件流），使开发者能够专注于智能体逻辑实现。

2. 定义 Agent Card

Agent Card 是智能体的"数字名片"，是一个 JSON 文档，通常发布在 /.well-known/agent.json 路径下。开发者需要定义 Agent Card 的各个字段：基本信息（name、description、version）、服务端点 URL（url）、能力声明（capabilities，如是否支持流式传输和推送通知）、默认输入输出模式（defaultInputModes、defaultOutputModes）、技能列表（skills，每个技能包含 id、name、description、tags、examples、inputModes、outputModes）以及认证信息（authentication）。Agent Card 是外部智能体发现和了解本智能体的主要途径。

3. 实现 AgentExecutor

AgentExecutor 是一个抽象基类，开发者通过子类化它并实现 execute() 和 cancel() 方法来定义智能体的核心逻辑。execute() 方法接收两个参数：RequestContext（提供请求详情，如传入消息和当前任务状态）和 EventQueue（用于让执行器入队响应，包括 Message、Task 或流式事件）。在 execute() 方法中，开发者编写智能体处理任务的具体逻辑：从 RequestContext 中获取用户输入，进行推理或调用工具，然后通过 EventQueue 报告任务状态更新和最终结果。

4. 配置任务存储（Task Store）

A2A 协议支持有状态的任务管理，需要任务存储后端来持久化任务状态、消息历史和产出物。SDK 提供了 InMemoryTaskStore 作为默认的内存任务存储，适合开发和测试场景。对于生产环境，开发者应选择持久化的任务存储后端，如基于 PostgreSQL、MySQL 或 SQLite 的任务存储实现。在创建请求处理器（DefaultRequestHandler）时，传入已配置的任务存储实例，确保任务状态在智能体重启后仍然可用。

5. 部署 A2A 服务器

对于 Python 实现，可以使用 A2AStarletteApplication（基于 Starlette 和 Uvicorn）或 A2AFastAPIApplication（基于 FastAPI）来部署 A2A 服务器。开发者将定义好的 Agent Card 和 AgentExecutor 实例传入应用程序构造器，然后启动 HTTP 服务器。服务端启动后，其他智能体就可以通过获取 Agent Card 并调用 A2A 协议定义的方法（如 message/send、message/stream）来与本智能体进行交互。

七、A2A 协议目前支持哪些编程语言和 SDK？

1. Python SDK（a2a-python）

Python SDK 是 A2A 项目的官方参考实现，提供最全面的功能抽象集合，适合快速构建和验证 A2A 智能体。a2a-sdk PyPI 包支持 Python 3.10+，提供多个扩展安装选项：[http-server] 支持 HTTP 服务器部署（基于 FastAPI 或 Starlette），[grpc] 支持 gRPC 传输绑定，[telemetry] 支持 OpenTelemetry 追踪，[encryption] 支持 Signed Agent Cards 加密验证，[sql] 支持所有 SQL 数据库驱动，[postgresql]、[mysql]、[sqlite] 分别支持对应的数据库后端。开发者可以通过 pip install a2a-sdk 安装核心 SDK。

2. Go SDK（a2a-go）

Go SDK 针对高性能和并发任务处理进行了优化，适合构建需要高吞吐量的智能体服务。Go 语言的原生并发支持（goroutines）使 Go SDK 能够高效处理大量并发的 A2A 任务请求。该 SDK 遵循 A2A 协议规范，实现了 JSON-RPC 2.0、gRPC 和 HTTP+JSON/REST 三种传输绑定，并提供与 Python SDK 功能等效的智能体构建抽象。

3. Java SDK（a2a-java）

Java SDK 面向企业环境设计，支持与企业现有基础设施集成，如使用 Keycloak 实现安全认证、与 Java EE / Spring Boot 应用程序集成等。Java 生态在企业级应用中占据重要地位，该 SDK 使拥有 Java 技术栈的企业能够在现有系统中平滑引入 A2A 协议支持。示例实现包括"Weather Agent"（使用 MCP 服务器）和基于 Keycloak 的安全实现。

4. JavaScript/TypeScript SDK（a2a-js）

JavaScript/TypeScript SDK 使前端开发者能够在 Node.js 环境和浏览器环境中构建 A2A 兼容的智能体。该 SDK 对于需要将智能体能力集成到现有 Web 应用程序中的场景尤其有用。TypeScript 类型定义提供了开发时的类型检查支持，减少了集成错误。SDK 同时支持在服务端构建 A2A 智能体，以及在客户端调用远程 A2A 智能体。

5. C#/.NET SDK（a2a-dotnet）

C#/.NET SDK 面向 .NET 生态系统，使 Windows 平台和企业 .NET 应用程序能够接入 A2A 协议生态。该 SDK 支持 .NET 6+，提供与其它语言 SDK 功能一致的智能体构建和调用能力，适合已经使用 .NET 技术栈的企业和开发者。

6. Rust SDK（a2a-rs）

Rust SDK 提供了高性能、内存安全的 A2A 协议实现，适合对性能和安全性要求严格的场景。Rust 的所有权模型和编译时内存安全检查，使该 SDK 能够构建高可靠性的 A2A 智能体服务。

八、哪些主流云平台和框架已经原生支持 A2A？

1. Google Cloud 平台

Google Cloud 将 A2A 协议作为智能体编排层深度集成到其 AI 产品矩阵中。Vertex AI Agent Engine 提供托管式 A2A 智能体部署能力；Agent Development Kit (ADK) 原生支持 A2A 协议，使用 ADK 构建的智能体可以自动发布 Agent Card 并接受 A2A 请求；Google Cloud 还提供了 AgentSpace 平台，支持企业构建和部署符合 A2A 标准的智能体。Google 作为 A2A 协议的的最初贡献者，其云平台提供了最完整的 A2A 原生支持。

2. Microsoft Azure 平台

Microsoft 将 A2A 协议集成到 Azure AI Foundry 和 Copilot Studio 中。Azure AI Foundry 中的智能体可以发布和消耗 A2A 端点，使每个 Copilot Studio 客户都能成为潜在的 A2A 参与者。Microsoft 还将其 Copilot 平台全面支持 A2A 和 MCP 协议，使得企业可以在 Microsoft 365 生态中自由编排智能体，Azure 上的智能体可以原生理解 A2A 消息，第三方智能体可以无缝接入 Teams 和 SharePoint。

3. AWS（Amazon Web Services）平台

AWS 通过 Amazon Bedrock AgentCore Runtime 增加了对 A2A 协议的显式支持。任何在 AgentCore 上运行的框架（包括 Strands、LangGraph、OpenAI Agents SDK、Google ADK）都会被包装 with an A2A ingress and an outbound A2A client。Bedrock AgentCore Runtime 通过 IAM 支持的身份、Cognito 或 Entra 处理 OAuth，使用 CloudWatch 进行遥测，使在 AWS 上部署的智能体能够与其它平台的 A2A 智能体无缝协作。

4. 企业级软件平台

多家企业级软件平台已原生支持 A2A 协议：Salesforce 的 Agentforce 平台使 Salesforce 智能体能够通过 A2A 协议与其它平台的智能体通信；SAP 将其企业资源管理软件与 A2A 协议集成，实现跨组织的工作流自动化；ServiceNow 在其 IT 服务管理平台上支持 A2A 协议，使 IT 运维智能体能够跨系统协调任务。

5. 开源智能体框架

主流的开源多智能体框架已原生支持 A2A 协议：LangChain 在 v0.3 版本中新增了 A2A 集成模块，支持将 LangChain 智能体接入 A2A 网络；CrewAI 在 v3.0 版本中原生支持 A2A，可以让不同团队构建的 Crew 互相协作；AutoGen 在 v0.4 版本中重构了整个多智能体架构，完全基于 A2A 协议实现；Dify 和 Coze 在 2026 年 Q2 发布了 A2A 插件，支持平台内的智能体与外部 A2A 智能体通信。

6. 腾讯云平台

腾讯云通过多种产品和服务支持 A2A 协议生态。TDMQ（腾讯云消息队列）提供了基于 MQTT 的 A2A 传输实现（A2A over MQTT），使智能体能够通过异步消息队列进行通信，适合长时间运行任务和跨网络场景。Agent 网关服务（Agent Gateway）提供了统一的流量控制平面，支持 A2A 路由协同、多智能体系统对内治理和对外开放，兼容 MCP、A2A 等 AI 生态协议。此外，腾讯开源的 tRPC-Agent-Go 框架已原生支持 A2A 协议，使开发者能够构建符合 A2A 标准的智能体服务，并可部署在腾讯云等云平台上。

九、如何发布和发现 A2A 兼容的智能体？

1. 发布 Agent Card 到 well-known URL

A2A 协议采用去中心化的发现机制，智能体通过在其服务域名的 /.well-known/agent.json 路径下发布 Agent Card JSON 文档来宣告自身能力。该路径遵循 RFC 8615 定义的 well-known URI 规范，使任何其它智能体能够通过构造标准 URL 来发现并获取该智能体的能力描述。Agent Card 文档应包含完整的身份信息、服务端点、支持的功能、技能列表和认证要求，使客户端智能体能够全面了解该智能体的能力并决定是否需要与之交互。

2. 客户端获取并解析 Agent Card

客户端智能体通过向目标智能体的 /.well-known/agent.json 端点发送 HTTP GET 请求来获取其 Agent Card。获取到 Agent Card JSON 文档后，客户端解析其中的各个字段：检查 capabilities 字段了解该智能体支持的功能（如是否支持流式传输、推送通知）；检查 skills 数组了解该智能体提供哪些具体技能；检查 authentication 字段了解需要使用的认证方案。基于这些信息，客户端构造符合要求的 A2A 请求。

3. 企业内部的智能体目录服务

在企业内部，可以构建私有的智能体目录服务来管理企业内部所有 A2A 兼容智能体的 Agent Card。该目录服务定期爬取企业内部各智能体服务的 /.well-known/agent.json 端点，或将智能体注册接口与企业 CI/CD 流程集成，实现智能体上线时自动注册。企业内部开发者可以通过查询该目录服务来发现可供使用的智能体，而无需事先知道每个智能体的具体部署地址。

4. 版本协商与兼容性管理

A2A 协议支持版本协商机制，使客户端智能体能够与服务端智能体协商双方都支持的最高版本协议。Agent Card 中的 version 字段声明该智能体实现的 A2A 协议版本；客户端在发送请求时，在请求头中声明自己支持的协议版本。当协议发生不兼容变更时，版本协商机制使旧版客户端能够与旧版服务端继续通信，同时允许新版客户端充分利用新版协议的功能。这确保了 A2A 生态系统在协议演进过程中的平滑过渡。

十、A2A 协议如何保障通信安全？

1. 传输层安全（TLS）

A2A 协议强制要求使用 TLS 1.2 或更高版本对通信内容进行加密，推荐采用 TLS 1.3+ 以获得更强的安全保障。加密的 HTTPS 连接防止任何中间方窃听或篡改智能体之间的通信内容。协议还要求服务端设置 HSTS（HTTP Strict Transport Security）头，强制客户端始终使用安全连接与服务端通信，防止降级攻击。

2. 双向 TLS（mTLS）认证

A2A v1.0 将双向 TLS（mTLS）正式化为支持的安全方案。mTLS 要求通信双方（客户端和服务端）都出示并验证对方的 TLS 证书，实现相互身份认证。这在金融、医疗等高敏感度领域的智能体通信中提供了最高级别的身份保证。通过 mTLS，即使在不安全的网络环境中，智能体之间的通信也能保持高强度的身份认证和加密保护。

3. Signed Agent Cards（签名智能体名片）

A2A v1.0 引入了 Signed Agent Cards 特性，允许智能体对其 Agent Card 进行加密签名。客户端在获取 Agent Card 后，可以验证签名以确保该 Agent Card 确实由宣称的智能体发布，且在传输过程中未被篡改。这防止了在开放网络（如公共 A2A 网络）中的智能体冒充攻击——恶意第三方可能试图发布伪造的 Agent Card 诱骗其它智能体向其发送任务请求。

4. 推送通知安全机制

A2A 协议的推送通知机制面临服务端主动向客户端 webhook 发送 HTTP POST 请求的场景，这引入了特定的安全挑战。服务端安全方面：服务端绝不能盲目信任客户端提供的 webhook URL，防止 SSRF（服务端请求伪造）攻击——恶意客户端可能指向内部服务进行攻击；服务端必须使用 PushNotificationConfig.authentication 中指定的认证方案向 webhook 进行身份认证；服务端应实现允许列表、所有权验证或网络控制。客户端安全方面：客户端必须验证传入通知的真实性（验证签名、token）；客户端应拒绝带有旧时间戳的通知；客户端应实现 nonce/唯一 ID 验证以防止通知重放攻击。

5. 现有基础设施复用

A2A 协议的安全模型建立在行业历经 20 年加固的相同 HTTP 安全模式之上，而非重新发明轮子。企业现有的 API 网关、WAF（Web 应用防火墙）规则和速率限制策略可以直接转移到 A2A 部署中，无需修改即可工作。运维团队不需要学习新的安全模型——A2A 智能体可以像任何其它 REST API 服务一样被保护。这种与现有安全基础设施的兼容性大大降低了企业将 A2A 协议引入生产环境的门槛。

十一、A2A 协议支持哪些身份认证和授权机制？

1. API Key 认证

A2A 协议支持通过 HTTP 头、查询参数或 Cookie 传递 API Key 的认证方式。这是在内部服务间通信中最简单的认证方案，适合在受信任的网络环境中使用。API Key 通常由服务端预先颁发给客户端，客户端在每次 A2A 请求中携带该 Key。Agent Card 的 securitySchemes 字段声明服务端接受的 API Key 传递位置（in: "header" / "query" / "cookie"）和 Key 名称。

2. HTTP Bearer Token 认证

A2A 协议支持 HTTP Bearer Token 认证方案，客户端在 HTTP Authorization 头中携带 Bearer <token> 向服务端进行身份认证。该 Token 可以是服务端颁发的会话 Token、JWT（JSON Web Token）或其它格式的持有者令牌。Bearer Token 认证方案广泛用于 RESTful API 中，A2A 协议复用这一成熟模式，使开发者能够利用现有的 Token 管理基础设施。

3. OAuth 2.0 授权框架

A2A 协议完整支持 OAuth 2.0 授权框架，允许智能体代表用户去访问另一个服务上的受保护资源。这包括 OAuth 2.0 的多种授权模式：authorization_code（授权码模式，适用于需要用户交互授权的场景）、client_credentials（客户端凭证模式，适用于智能体之间的直接通信）、device_code（设备授权模式，适用于无浏览器界面的设备）。OAuth 2.0 通过"令牌（Token）"机制实现细粒度权限控制——令牌包含"作用域（Scopes）"信息，限定了持有该令牌的智能体可以执行的操作范围。

4. OpenID Connect（OIDC）身份层

A2A 协议将 OpenID Connect 作为 OAuth 2.0 之上的身份层支持，提供统一的身份验证和单点登录能力。通过 OIDC，智能体在完成 OAuth 2.0 授权流程的同时，还能获取用户的身份身份信息（ID Token），实现跨组织智能体身份验证。这对于需要明确用户身份的场景（如金融交易授权、医疗记录访问）尤其重要。

5. Mutual TLS（mTLS）双向证书认证

A2A v1.0 正式支持 Mutual TLS（mTLS）作为认证方案。mTLS 要求通信双方都出示并验证对方的 TLS 证书，实现相互身份认证。与仅服务端认证的普通 HTTPS 不同，mTLS 像两个特工接头——他们需要互相展示自己的证件（双向验证），确认彼此身份后，才开始在加密的信道里交换信息。mTLS 在金融、医疗等高敏感度领域的智能体通信中提供了最高级别的身份保证。

6. 动态凭证管理

A2A 协议强烈推荐在 Agent Card 中使用动态凭证（如 OAuth 2.0 Access Token、JWT），而非嵌入式静态密钥（如硬编码在配置文件中的 API Key）。动态凭证具有有效期限制，即使被截获也能在到期后自动失效，大大降低了密钥泄露带来的长期风险。此外，动态凭证还可以携带细粒度的权限作用域信息，实现智能体间通信的最小权限原则。

十二、A2A 协议与 MCP 有什么区别和联系？

1. 核心定位差异

MCP（Model Context Protocol，模型上下文协议）由 Anthropic 于 2024 年 11 月发布，解决的是"智能体到工具"的连接问题——即一个 AI 智能体如何调用外部工具、查询数据库或访问 API。MCP 定义了智能体与外部能力和数据源之间的标准接口。A2A（Agent2Agent Protocol，智能体对智能体协议）由 Google 于 2025 年 4 月发布，解决的是"智能体到智能体"的协作问题——即不同框架、不同厂商构建的智能体如何发现彼此能力、安全交换信息并协作完成复杂任务。

2. 架构模式差异

MCP 采用客户端-服务器架构：一个 AI 智能体（宿主或客户端）连接到一个或多个 MCP 服务器，这些服务器暴露标准化能力（如数据库查询、API 调用、文件访问）。通信使用 JSON-RPC 2.0，允许智能体发现可用工具、调用它们并接收结构化结果。A2A 采用对等的协作架构：智能体发布 Agent Cards（JSON 元数据）描述其技能、支持的任务和安全要求；其它智能体发现这些卡片，发起任务，并管理完整的生命周期——包括流式更新、产出物共享和状态转换——通过 HTTP/JSON-RPC，可选使用 Server-Sent Events。

3. 状态模型差异

MCP 的工具调用通常是无状态的——每次工具调用是独立的，输入和输出有明确的结构化定义。2025 年 11 月，MCP 新增了 Tasks 原语，为长时间运行的异步操作提供了可选的状态跟踪能力。A2A 的任务（Task）是具有完整生命周期的有状态工作单元：任务从创建到完成经历多个明确状态（SUBMITTED、WORKING、INPUT_REQUIRED、AUTH_REQUIRED、COMPLETED、FAILED、CANCELED、REJECTED），支持多轮对话和增量结果传输。

4. 发现机制差异

MCP 的发现机制是：宿主应用程序在会话启动时暴露可用的工具和资源列表，智能体通过 tools/list 方法获取可用工具清单。MCP 服务器是主动暴露能力的。A2A 的发现机制是：每个智能体在其域名的 /.well-known/agent.json 路径下发布 Agent Card，客户端智能体通过获取该 JSON 文档来发现远程智能体的能力。A2A 的发现是被动通告能力的。

5. 互补而非竞争关系

MCP 和 A2A 解决的是不同层次的问题，它们是互补的，而非竞争的。在生产系统中，MCP 和 A2A 通常一起使用：一个智能体通过 A2A 协议将任务委托给另一个智能体；接收任务的智能体内部使用 MCP 协议调用其专属的工具和数据源。可以这样理解：MCP 回答"我的智能体如何使用工具？"；A2A 回答"我的智能体如何与其它智能体对话？"。主流云服务商和开源框架正在同时支持这两种协议，使开发者能够构建同时使用 MCP 和 A2A 的完整智能体系统。

十三、A2A 协议与传统 API 调用方式相比有哪些优势？

1. 智能体作为对等协作伙伴，而非被调用的工具

传统 API 调用方式本质上将远程服务视为无状态的函数调用：调用方构造请求，服务方返回响应，每次调用是独立的、无状态的。这种方式无法体现智能体的自主推理、多轮协商和长期任务管理能力。A2A 协议的核心理念是：智能体是自主的协作伙伴，而非被调用的工具。通过 A2A，智能体之间可以进行多轮对话、协商任务执行方式、动态调整工作计划，真正实现智能体之间的对等协作。

2. 有状态的任务生命周期管理

传统 API 通常是无状态的请求-响应模式，服务端处理完请求后立即返回结果，不保留任务状态。如果任务需要较长时间完成，客户端需要自行实现轮询或回调机制。A2A 协议将有状态的任务作为一等公民：每个 Task 具有唯一 ID 和明确的生命周期状态；服务端在任务执行过程中可以通过流式传输（SSE）增量返回进度更新和中间结果；如果任务需要额外输入或认证，可以通过 INPUT_REQUIRED 和 AUTH_REQUIRED 状态暂停并等待客户端响应。这大大简化了长时间运行任务的编排逻辑。

3. 不透明执行与能力发现

传统 API 调用要求调用方了解被调用服务的接口契约（输入参数、输出格式、错误码），这导致了紧耦合的集成关系。当服务端升级接口时，调用方需要同步修改代码。A2A 协议采用不透明执行模型：客户端智能体通过 Agent Card 了解远程智能体能提供哪些能力（做什么），但不需要了解远程智能体内部如何完成任务（怎么做）。这实现了松耦合的智能体协作——远程智能体可以自由升级其内部实现（包括更换底层模型、增加工具），只要继续保持 Agent Card 中声明的能力不变，就不会影响客户端。

4. 原生的多模态内容支持

传统 API 通常专注于特定格式的数据交换（如 JSON、XML），对于多模态内容（文本、图像、文件、结构化数据）需要自行设计传输方案。A2A 协议在协议层面原生支持多模态内容：Message 和 Artifact 中的 Part 可以是 TextPart（文本）、FilePart（文件，支持内联字节或 URI 引用）或 DataPart（结构化 JSON 数据）。这意味着智能体之间可以交换丰富的多模态内容，而不仅仅是工具调用的结构化参数。

5. 跨组织、跨平台的互操作性

传统 API 集成需要调用方和被调用方就接口格式、认证方案、错误码等细节达成一致，这导致了企业 AI 部署中的平台碎片化问题——使用不同框架或部署在不同服务器上的智能体无法互操作。A2A 协议作为开放标准，使不同厂商、不同框架、不同编程语言构建的智能体能够使用共同的语言进行通信和协作。截至 2026 年，已有超过 150 家组织支持该协议，包括主流云服务商和开源框架，形成了日益增长的 A2A 生态系统。