A2A Protocol 技术文档
A2A Protocol 常见问题（FAQ）

A2A Protocol 常见问题（FAQ）

这里汇总了开发者接触 A2A 协议时最常问的问题。每个回答都给出了简短结论，并链接到对应专题，便于继续深入。

基础概念

A2A 是什么？由谁维护？

A2A（Agent2Agent）是智能体之间通信与协作的开放标准：无论智能体由哪个厂商、用哪个框架构建，只要实现 A2A，就能互相发现、委派任务并交换结果，而不必暴露内部记忆、工具或专有逻辑。

A2A 最初由 Google 开发，后捐赠给 Linux Foundation，现为 Agentic AI Foundation（AAIF）的成长期项目，由技术指导委员会（TSC）维护，采用 Apache License 2.0。详见什么是 A2A 协议 与社区中心 。

A2A 和 MCP 是什么关系？需要二选一吗？

不需要二选一，两者互补。MCP 是纵向的，让单个智能体连接工具和数据；A2A 是横向的，让智能体与其他智能体协作。一个智能体应用可以用 A2A 与其他智能体通信，同时在每个智能体内部用 MCP 访问各自的工具和资源。详见 A2A 与 MCP 。

A2A 和 LangGraph、CrewAI、ADK 这些智能体框架有什么关系？

A2A 是通信协议，与构建智能体所用的框架无关。无论是 LangGraph、CrewAI、ADK 还是自研方案，只要实现 A2A，就能与其他智能体协作；协议本身不依赖也不偏向任何单一框架。已内置 A2A 集成的框架名单见社区中心 。

使用 A2A 需要暴露智能体的内部实现吗？

不需要。A2A 坚持“不透明执行”：协作双方只基于声明的能力和共享的上下文协作，不暴露各自的内部逻辑、记忆或工具。对客户端而言，远程智能体是黑盒。详见核心概念 。

协议与设计

智能体如何被发现？Agent Card 放在哪里？

智能体通过 Agent Card 描述自己，包括身份、服务接口、能力、认证要求和技能。协议定义了三种发现策略：

  • Well-Known URI：服务器把 Agent Card 托管在自己域名下的标准路径 /.well-known/agent-card.json；
  • 注册中心：由中心化的目录管理 Agent Card，客户端按技能、标签等条件查询。当前 A2A 规范没有规定注册中心的标准 API；
  • 直接配置：客户端通过配置文件、环境变量或私有 API 直接获得 Agent Card 信息。

详见智能体发现 与协议规范：智能体发现 。

A2A 支持哪些传输方式（协议绑定）？

A2A 定义了三种协议绑定：JSON-RPC 2.0、gRPC 和 HTTP+JSON/REST。它们共享同一份以 Protocol Buffers 定义的规范数据模型（a2a.proto 是唯一的规范性来源），智能体通过 Agent Card 的 supportedInterfaces 声明自己支持哪些接口，客户端从中选择。详见协议规范 。

能传输文件、图片和结构化数据吗？

可以。消息和产出物的内容放在 Part 中，一个 Part 必须且只能包含 text（文本）、raw（内联二进制）、url（外部文件地址）、data（结构化 JSON）之一，并可携带 mediaType、filename 与 metadata。因此 A2A 与模态无关。详见核心概念 。

Artifact 和 Message 有什么区别？

Message 是客户端与智能体之间的一次交流，带有角色（用户或智能体），用来传达指令、上下文、提问、回答或状态更新，不一定是正式的交付物。Artifact（产出物）则是智能体在任务中生成的具体成果，例如文档、图片或结构化数据，有唯一的 artifactId 和名称，内容同样由一个或多个 Part 组成，与任务生命周期紧密关联，并且可以增量地流式发送给客户端。任务结果应当通过 Artifact 返回，而不是依赖消息传递关键信息。详见核心概念 。

可以扩展 A2A 吗？

可以。扩展由 URI 标识，智能体在 Agent Card 中声明支持哪些扩展，客户端通过 A2A-Extensions 头在请求中选择启用。扩展可以增加新的数据、要求、RPC 方法和状态机。详见扩展 与扩展与协议绑定治理 。

可以在其他传输方式（如 WebSocket、MQTT）上使用 A2A 吗？

可以，方法是自定义协议绑定。扩展改变的是交互的行为，自定义绑定改变的则是传输层本身，例如用 WebSocket 实现低延迟双向通信，或在连接受限的物联网环境中使用 MQTT。自定义绑定在 Agent Card 的 supportedInterfaces 中声明，protocolBinding 应是能唯一标识该绑定的 URI。它必须支持抽象操作层定义的全部核心操作，保持与规范数据模型功能等价（JSON 序列化使用 camelCase 字段名，时间戳为 UTC 的 ISO 8601 字符串），并让语义相同的请求在任何绑定下得到语义相同的结果。客户端按顺序解析 supportedInterfaces 并选用第一个自己支持的传输，因此应按偏好顺序列出。详见自定义协议绑定 。

一个端点可以托管多个智能体或多个租户吗？

可以。协议不规定具体的路由实现，提供三种互补的做法：

  • 基于 URL 的路由：每个智能体使用不同的 URL 前缀，并在各自 Agent Card 的 supportedInterfaces 中声明自己的 url；
  • 基于认证信息的路由：多个智能体共用同一 URL 时，网关根据请求中已有的认证凭据（例如令牌中的声明，或与 API Key 的映射）决定转发目标；
  • 基于 tenant 字段的路由：请求消息中有一个可选的 tenant 字段，取值是由服务运营方自行定义的不透明字符串。该值在 AgentInterface 的 tenant 中声明，客户端必须在每个请求中原样回传；未声明时必须省略该字段。

三种做法可以组合使用。详见多租户与多智能体路由 。

任务与交互

智能体什么时候返回 Message，什么时候返回 Task？

  • Message：适合即时、自包含的交互，完成后没有需要继续管理的状态；
  • Task：适合需要较长时间、可跟踪的实质性工作，有明确的生命周期，可汇报进度、请求输入或产出结果。

智能体可以只返回消息、总是返回任务，或两者混合：先用消息协商工作范围，再创建任务跟踪执行。详见任务的生命周期 。

多轮对话和后续跟进怎么做？contextId 与 taskId 是什么关系？

contextId 把相关的 Task 和 Message 逻辑上分组，让一系列交互保持连续；taskId 标识具体的任务，始终由服务端生成。

  • 首次发送消息时，智能体返回新的 contextId（若创建了任务，同时返回 taskId）；客户端一般不应自行生成 contextId；
  • 后续消息带上同一个 contextId，就是在已有会话中继续；只带 contextId 而不带 taskId，表示在该会话上下文中开启新任务；
  • 消息中带 taskId，表示继续那个具体的任务，它必须指向已存在的任务，否则返回 TaskNotFoundError；contextId 与 taskId 不匹配时，服务端必须拒绝；
  • 同一 contextId 下可以并行存在多个任务，referenceTaskIds 用于显式引用相关任务。

详见任务的生命周期 与核心协议规范 。

任务完成后还能继续修改吗？

任务一旦进入终态（TASK_STATE_COMPLETED、TASK_STATE_FAILED、TASK_STATE_CANCELED、TASK_STATE_REJECTED），就不能重启。后续的细化或跟进要在同一个 contextId 内发起新任务，并通过 referenceTaskIds 引用原任务。这样每个任务都是不可变的工作单元，便于追溯。

智能体执行到一半需要更多信息怎么办？

任务会进入 TASK_STATE_INPUT_REQUIRED 状态，表示需要客户端补充输入。它和 TASK_STATE_AUTH_REQUIRED 一样属于中断状态，而不是终态，任务并没有结束：客户端用同一个 taskId 与 contextId 发送新消息补充输入，即可继续。当智能体对要引用的产出物有歧义时，也应通过 input-required 向客户端请求澄清。详见任务的生命周期 。

SendMessage 会等任务完成才返回吗？

默认会。SendMessageConfiguration 的 returnImmediately 默认为 false，此时操作必须等到任务进入终态或中断状态（TASK_STATE_INPUT_REQUIRED、TASK_STATE_AUTH_REQUIRED）才返回，并带回最新的任务状态与全部产出物。设为 true 则在创建任务后立即返回，之后由调用方用 GetTask 轮询、SubscribeToTask 订阅，或通过推送通知获取更新。该字段不影响直接返回 Message 的情况，也不影响流式操作（始终实时返回更新）和已配置的推送通知。详见数据结构 与核心协议规范 。

如何取消任务？

调用 CancelTask 请求取消进行中的任务，但取消不保证成功。任务处于不可取消的状态（例如已进入终态）时，服务端返回 TaskNotCancelableError。取消操作是幂等的，重复取消可能返回 TaskNotFoundError（任务已取消并被清除）。详见核心协议规范 。

支持长时间运行的任务吗？流式传输和推送通知怎么选？

支持，A2A 为此提供两种机制：

  • 流式传输（SSE）：客户端可以保持 HTTP 连接时使用，实时接收状态更新和增量产出物；服务端需在 Agent Card 中声明 capabilities.streaming；
  • 推送通知：耗时很长、或客户端无法保持连接（如移动端、无服务器函数）时使用，服务器在任务发生重要变化时调用客户端提供的 Webhook；服务端需声明 capabilities.pushNotifications。

此外，流式连接中断后，客户端可通过 SubscribeToTask 重新订阅仍在进行的任务。详见流式传输与异步操作 。

安全

A2A 如何做认证与授权？

A2A 不另造私有安全标准，而是沿用标准 Web 机制：

  • 生产环境中所有通信必须使用 HTTPS；
  • 认证方案由智能体在 Agent Card 的 securitySchemes 与 securityRequirements 中声明，与 OpenAPI 的认证方式一致；
  • 凭据（如 OAuth 2.0 令牌、API Key）通过标准 HTTP 头传递，不放在 A2A 消息载荷里；
  • 认证失败时服务器返回 401 Unauthorized，已认证但无权操作时返回 403 Forbidden；
  • 授权由服务器根据已认证的身份决定，可按技能、数据和操作分级控制，并遵循最小权限原则。

任务执行中需要额外凭据时，任务会进入 TASK_STATE_AUTH_REQUIRED 状态。进入该状态本身并不构成对任何操作的授权：所得凭据的范围由实现、凭据签发方或扩展来定义。详见认证、授权与安全考量 与企业级特性 。

推送通知会不会带来安全风险？

会，因此协议专门给出了安全建议：服务器不应盲目向客户端提供的任意 URL 发送请求（防范 SSRF 与 DDoS 放大），应校验 Webhook URL，并按约定方案向 Webhook 认证；Webhook 一侧则要验证通知确实来自合法的 A2A 服务器、防止重放，并安全管理与轮换密钥。详见流式传输与异步操作 。

Agent Card 可以防篡改吗？

可以。Agent Card 可以用 JSON Web Signature（JWS，RFC 7515）签名，签名前按 JSON Canonicalization Scheme（JCS，RFC 8785）规范化内容，客户端据此验证 Agent Card 未被篡改且来自声称的提供方。对于含敏感信息的内容，建议改用认证后才能获取的扩展 Agent Card（GetExtendedAgentCard）提供。详见智能体发现 。

版本与迁移

现在的最新版本是什么？

A2A v1.0.0 于 2026 年 3 月 12 日发布，v1.0.1 于 2026 年 5 月 28 日发布，是只包含规范层面修复的勘误版本，没有新增破坏性变更。协议版本只用 Major.Minor（如 1.0）标识，补丁版本不影响兼容性。

从 v0.3.0 升级到 v1.0 要改什么？

v1.0 有一批破坏性变更：操作改名、TextPart/FilePart/DataPart 合并为统一的 Part、枚举取值改为 SCREAMING_SNAKE_CASE、流事件不再使用 kind、Agent Card 的接口声明重构为 supportedInterfaces、HTTP 路径去掉 /v1 前缀、错误模型改用 google.rpc.Status，以及任务列表改用游标分页。完整对照与分阶段迁移建议见 A2A v1.0 有哪些变化 。

客户端与服务端如何协商协议版本？

每个 AgentInterface 通过自己的 protocolVersion 声明版本，智能体可以暴露多个接口来同时支持多个版本；客户端从 Agent Card 中选择合适的接口，并在每个请求中发送 A2A-Version 头。接口不支持所请求的版本时，服务端返回 VersionNotSupportedError。详见核心协议规范 。

上手与社区

怎样快速上手？

  1. 阅读什么是 A2A 协议 和核心概念 ；
  2. 按 Python 教程 从零构建第一个 A2A 智能体（需要 Python 3.10 或更高版本）；
  3. 需要核对协议细节时查阅协议规范 。

有哪些官方 SDK 和工具？

官方提供 Python、Go、Java、JavaScript、C#/.NET、Rust 六种语言的 SDK，另有示例仓库 a2a-samples、命令行客户端 A2A CLI，以及用于检查实现是否符合协议的 A2A Inspector 与 A2A TCK。详见官方 SDK 。

怎样参与社区或反馈问题？

可以加入 A2A Discord，在 GitHub 上参与 Discussions、提交 Issue 或贡献代码与文档，入口汇总在社区中心 。对本站内容的建议或勘误，请发送邮件至 [email protected] 。

A2A 协议由谁治理？怎样提出修改建议？

项目由技术指导委员会（TSC）负责技术层面的全部监督。TSC 目前设有九个席位，每个席位由一家公司派代表担任，名单见上游的 GOVERNANCE.md 。TSC 会议在 Linux Foundation 的会议平台上举行，并以向公众开放为目标。Discord 适合日常交流，但关于功能提案、架构或治理的重大变更，应当在 GitHub 上讨论并留出充分的通知与评论时间，项目的目标是让 GitHub 成为重大决策的事实来源。协议扩展与自定义绑定还有分层的晋升流程，见扩展与协议绑定治理 。

路线图有哪些重点？

上游路线图（最后更新于 2026 年 9 月 15 日）把近期方向定为：v1.1 协议增强与核心稳健性、双向（BiDi）流式传输、A2A CLI 与编码工具集成，以及交互补全与多轮工作流；中长期则关注治理、验证工具（A2A Inspector 与 TCK）、SDK 和社区最佳实践。详见路线图 。

来源：A2A 官方文档

参考资料