A2A 协议是一套开放通信标准，让不同框架、不同厂商、不同组织构建的 AI Agent 能够互相发现能力、委派任务并交换结果。它不训练模型，不替代 Agent 框架，也不把远程 Agent 降级成一个普通工具，而是补上多 Agent 协作中最容易缺失的一层，跨系统通信。
2025 年 4 月 9 日，Google 联合 50 多家技术合作伙伴发布 A2A。2025 年 6 月 23 日，Linux 基金会启动 Agent2Agent 项目，支持企业超过 100 家。A2A 官方规范站显示，最新发布版本为 1.0.0，于 2026 年 3 月发布。代码仓库在 2026 年 5 月又发布了 1.0.1 修订。对正在评估多 Agent 协作的企业来说，这些时间点说明一件事，A2A 已经从厂商提案走进了有中立治理和版本规范的阶段。
一、A2A 协议是什么？
A2A 官方规范给出的定义很直接，它是一套开放标准，用于促进独立、可能不透明的 AI Agent 系统之间的通信与互操作。
这里的关键词是独立和不透明。独立，意味着两个 Agent 可以由不同团队开发，运行在不同云上，使用不同框架。不透明，意味着双方不需要开放内部推理过程、记忆和工具实现，只通过声明过的能力和交换的信息完成协作。
A2A 把远程 Agent 当成 Agent，而不是工具。 这是它和普通 API 调用最根本的区别。工具通常是无状态的、结构化的、一次性的调用。Agent 可以多轮对话，可以反问，可以处理长任务，也可以在执行过程中更新状态。A2A 要保留这些能力。
可以用排除法理解它不是什么。
- 不是大模型。 A2A 不提供推理能力，模型仍然由各个 Agent 自己选择。
- 不是 Agent 框架。 LangGraph、CrewAI、ADK 负责构建 Agent，A2A 负责让构建好的 Agent 互相通信。
- 不是 MCP 的替代品。 MCP 连接 Agent 与工具、数据，A2A 连接 Agent 与 Agent，两者解决的是不同层的问题。
A2A 主要标准化四件事。能力发现通过 Agent Card 完成，任务协作围绕 Task 展开，内容交换使用 Message 和 Part，结果交付使用 Artifact。把这四件事说清楚，基本就理解了 A2A 的骨架。
它最适合的场景，是 Agent 需要跨团队、跨厂商、跨组织协作的时候。如果企业只有一个团队、一套框架、一个 Agent 集群，内部编排通常更简单。A2A 的价值不在单 Agent 内部，而在边界之外。
二、为什么多 Agent 协作需要通信标准？
多 Agent 系统最先遇到的麻烦，往往不是模型不够聪明，而是连接成本失控。
假设一家企业有客服、计费、物流三个 Agent。客服接到退款请求，需要计费 Agent 确认订单，再让物流 Agent 确认签收状态。三个 Agent 来自三个团队，使用三种框架，部署在三套云环境。如果没有统一协议，每一条协作链路都要单独写适配，N 个 Agent 两两对接，集成数量会迅速膨胀。点对点集成越多，系统越难维护，也越难替换供应商。
另一种常见做法，是把远程 Agent 包装成工具，暴露一个函数接口。这样能跑通简单任务，却丢掉了 Agent 的多轮协商和长任务状态。对方不能反问，不能在执行中请求补充信息，也不能在处理几个小时后主动推送进度。把 Agent 降级成工具，等于放弃了 Agent 最有价值的部分。
A2A 的设计原则就是围绕这些问题展开的。官方规范列出五条原则，简单、企业可用、异步优先、模态无关、不透明执行。简单，指复用 HTTP、JSON-RPC 2.0、Server-Sent Events 等成熟标准。企业可用，指认证、授权、安全、隐私、追踪和监控要能接进企业现有体系。异步优先，指长任务和人工介入是常态。模态无关，指文本、文件、结构化数据都可以交换。不透明执行，指协作双方不必共享内部记忆和工具实现。
这些原则带来的直接好处是模块化和可替换性。企业可以把不同厂商的 Agent 组合进同一条业务流程，而不必把每家的实现细节都吃透。但也要看清楚，A2A 只解决通信和任务协作，不解决任务怎么规划、结果是否正确、业务规则是否合理。 规划、工具调用、质量验收仍然由 Agent 自身和业务系统负责。
三、A2A 协议如何工作？
一次完整的 A2A 协作，通常经过发现、认证、委派、执行、交付五个阶段。理解这五个阶段，比记住一堆术语更有用。
1、核心对象有哪些？
| 对象 | 作用 |
|---|---|
| Agent Card | JSON 格式的能力名片，描述 Agent 身份、服务端点、技能和认证要求 |
| Task | 有状态的工作单元，带唯一 ID 和完整生命周期 |
| Message | 一轮通信，包含角色和一个或多个 Part |
| Part | 内容容器，可承载文本、文件引用或结构化数据 |
| Artifact | 任务产物，例如文档、图片或结构化结果 |
| Context | 关联多个任务和消息的上下文标识 |
Agent Card 是协作入口。客户端先拿到这张名片，才能判断对方能不能做、怎么调用、需要什么认证。Task 是协作主体，适合长任务和多轮交互。Message 负责传递指令、上下文、问题和状态更新。Part 让协议不局限于文本。Artifact 是最终交付物，和普通消息分开，便于验收和追踪。
2、一次任务怎么走完？
- 能力发现。 客户端读取远程 Agent 的 Agent Card。规范使用 `/.well-known/agent-card.json` 作为发现地址，卡片里会写明服务端点、技能、支持的传输方式和认证方案。
- 认证授权。 客户端根据 Agent Card 里的安全方案获取凭据。常见方式包括 OAuth 2.0、OpenID Connect、mTLS 和 API Key。凭据通常通过 HTTP 头传递，不放进 A2A 消息体。
- 发送消息。 客户端调用 SendMessage 或 SendStreamingMessage，把任务和上下文发给远程 Agent。消息可以包含文本、文件引用和结构化数据。
- 执行任务。 远程 Agent 可以立即返回一条消息，也可以创建一个 Task 异步处理。任务会经历提交、处理中、需要补充输入、需要重新认证、完成、失败、取消、拒绝等状态。长任务可以通过 SSE 实时推送进度，也可以在客户端断开后通过 Webhook 推送通知。
- 交付产物。 任务完成后，远程 Agent 通过 Artifact 返回结果。客户端可以用 contextId 把相关任务串起来，也可以按需读取历史消息。
这套流程的重点不是接口长什么样，而是任务状态和交付物被标准化了。不同厂商的 Agent 只要遵守同一套状态和对象定义，理论上就可以互相接。
3、三层规范结构
A2A 1.0.0 把规范分成三层。
- 规范数据模型。 用 Protocol Buffers 定义 Task、Message、AgentCard、Part、Artifact 等核心对象，`a2a.proto` 是规范性来源。
- 抽象操作。 定义 SendMessage、SendStreamingMessage、GetTask、ListTasks、CancelTask、SubscribeToTask 等能力，不绑定具体传输协议。
- 协议绑定。 把抽象操作映射到 JSON-RPC 2.0、gRPC 和 HTTP+JSON/REST 等具体传输方式。
这种分层的好处是，核心语义不随传输方式变化。企业现有系统用 REST，可以走 HTTP 绑定。内部服务追求性能，可以走 gRPC。需要兼容现有 JSON-RPC 工具链，也可以保持 JSON-RPC。A2A 没有要求企业推翻现有技术栈，而是尽量复用已有标准。
四、A2A 和 MCP 有什么区别？
一句话概括，MCP 让 Agent 会用工具，A2A 让 Agent 会找 Agent。
A2A 官方文档用一个方向比喻解释得很清楚。MCP 是垂直的，它向下加深单个 Agent 的能力，把数据库、API、文件系统等工具和数据源接进来。A2A 是水平的，它横向连接不同 Agent，让它们跨团队、跨部门、跨组织协作。
| 维度 | MCP | A2A |
|---|---|---|
| 连接方向 | 垂直，Agent 到工具和数据 | 水平，Agent 到 Agent |
| 交互特征 | 结构化、通常无状态、偏单次调用 | 多轮、有状态、可协商 |
| 核心对象 | 工具、资源、提示 | 远程 Agent、任务、消息、产物 |
| 典型场景 | 查询数据库、调用 API、读取文件 | 跨团队任务委派、跨厂商流程编排 |
| 关系 | 互补 | 互补 |
一个常见的误解，是认为 A2A 会取代 MCP。实际不是。A2A 连接 Agent 与 Agent，MCP 连接 Agent 与工具，两者解决的是不同层的问题。 一个数据分析 Agent 可以用 MCP 查询企业数仓，再用 A2A 向营销 Agent 询问活动背景，最后把分析结果交给运营 Agent 执行。MCP 让它把事做深，A2A 让它把事做大。
从落地顺序看，企业通常先把单个 Agent 的工具接入做好，再考虑跨 Agent 协作。工具层没打通，协作层就会出现大量空转。先有可用的 Agent，再谈 Agent 之间的协议，顺序不能反。
五、企业落地 A2A 要先回答什么？
A2A 不难理解，难的是判断企业现在该不该用。落地前先回答三个问题。
第一，是否真的存在跨边界协作。 如果所有 Agent 都在一个团队、一套框架、一个运行时里，内部编排通常够用。只有当 Agent 分属不同团队、不同厂商、不同组织，或者需要跨云、跨系统协作时，A2A 的标准化价值才会显现。
第二，身份、权限和审计是否准备好了。 Agent Card 会把能力暴露出去，这既是发现机制，也是攻击面。企业需要明确谁能调用哪个 Agent、能访问哪些数据、调用记录如何留痕、异常行为如何阻断。最小权限、租户隔离、白名单、人工审批和全链路审计，都要提前设计。A2A 规范提供了认证和授权的接口，但企业自己的治理规则不能外包给协议。
第三，任务契约和验收标准是否清楚。 A2A 定义了任务状态和产物，但没有定义业务语义。输入格式、输出质量、超时时间、重试策略、幂等要求、失败补偿、人工接管条件，都需要在业务层写清楚。否则协议跑通了，结果仍然不可用。
一个稳妥的实施路径是，先盘点企业内部有哪些 Agent 和哪些跨团队任务，再为其中一个低风险、边界清晰的任务编写 Agent Card，做一次跨 Agent 试点。试点跑通后，再补可观测性和评估指标，最后逐步扩大范围。不要一上来就做全公司 Agent 互联，先用一个真实任务验证协作链路。
在平台能力上，ThinkingAI 的 Agentic Engine 支持企业创建和管理多个 Agent，并把多 Agent 协作纳入统一底座。相关实践中，A2A 通信与任务协作被用来支持不同 Agent 与应用能力共同完成复杂任务。对企业的意义不是多了一个协议名词，而是可以把分散的 Agent 能力接进同一条业务链路，再通过运行数据和效果评估持续优化。
六、A2A 的边界和风险
A2A 很有价值，但它不是多 Agent 协作的全部答案。
它不负责任务规划。一个 Agent 该不该把任务拆给另一个 Agent，怎么拆，拆完怎么合并，仍然是编排层和业务逻辑要解决的问题。它也不负责结果质量。远程 Agent 返回的产物是否准确，需要验收机制、评估数据和人工复核。它更不负责商业契约。跨组织调用涉及的数据使用、责任归属和结算方式，协议本身不会替企业定义。
安全风险也需要单独看。跨边界任务会把外部输入带进内部 Agent，提示注入、能力伪造、权限过宽、数据泄露都可能发生。A2A 规范把认证、授权、隐私、追踪和监控列为企业级要求，但规范给出的是能力边界，不是现成的安全方案。企业需要把每个远程 Agent 当成不可信外部系统来设计，而不是当成内网服务。
版本兼容同样不能忽略。A2A 规范站当前标注的最新发布版本是 1.0.0，代码仓库在 2026 年 5 月发布了 1.0.1 修订。生态仍在快速演进，不同平台对版本和扩展的支持程度并不一致。选型时要确认对方支持的规范版本、传输绑定和安全方案，不要只看一句支持 A2A。
不适合用 A2A 的场景也很明确。单 Agent 能完成的任务，不需要。同一框架内的 Agent 编排，优先用框架自带能力。简单的 API 调用，用普通接口更直接。A2A 解决的是异构 Agent 之间的协作问题，不是所有集成问题的万能钥匙。
七、常见问题
1、A2A 协议是哪个公司提出的？
A2A 由 Google 在 2025 年 4 月 9 日发布，最初获得 50 多家技术合作伙伴支持。2025 年 6 月 23 日，Linux 基金会启动 Agent2Agent 项目，A2A 转为厂商中立的开源项目，支持企业超过 100 家。
2、A2A 和 MCP 是竞争关系吗？
不是。MCP 负责 Agent 与工具、数据之间的连接，A2A 负责 Agent 与 Agent 之间的通信和任务协作。一个向内加深单 Agent 的能力，一个向外扩展多 Agent 的协作范围，两者可以同时使用。
3、A2A 协议收费吗？
A2A 项目采用 Apache 2.0 许可证，协议规范和代码可以公开使用。具体 SDK、商业平台和托管服务是否收费，取决于提供方，不取决于协议本身。
4、A2A 支持哪些传输方式？
A2A 1.0.0 定义了 JSON-RPC 2.0、gRPC 和 HTTP+JSON/REST 等协议绑定，底层基于 HTTP 和 Server-Sent Events。企业可以根据现有技术栈选择合适的方式。
5、A2A 能解决多 Agent 的任务规划问题吗？
不能。A2A 标准化的是发现、消息、任务状态和产物交付。任务怎么拆、交给谁、结果是否合格，仍然由编排逻辑、Agent 自身和业务验收机制负责。
6、企业什么时候应该考虑 A2A？
当 Agent 需要跨团队、跨厂商、跨组织协作，并且涉及多轮对话、长任务或异构框架时，可以开始评估 A2A。单团队、单框架、单运行时的场景，优先做好内部编排和工具接入。
7、A2A 最新版本是多少？
截至 2026 年 10 月，A2A 官方规范站标注的最新发布版本为 1.0.0，代码仓库在 2026 年 5 月发布了 1.0.1 修订。实际选型时要以对方平台支持的版本为准。
