A2A 协议详解：与 MCP 的区别、协作机制和接入时机

当智能体需要把工作交给另一个独立运营的智能体时，可以使用 A2A 协议；需要调用工具或访问数据时，则使用 Model Context Protocol（MCP）。A2A v1.0 改变了系统对接的约定，因此，选型时既要看这次调用跨越了怎样的系统边界，也要看两端支持哪些协议版本。

MCP 与 A2A 协议有什么区别：工具调用与任务委派

MCP 让智能体获得所需能力，A2A 则让它把一项工作交给另一个智能体负责。 两者可以在同一个系统中配合使用。

Model Context Protocol（MCP）为 AI 应用连接外部系统提供了统一方式，连接对象包括工具和数据源。Agent2Agent（A2A）则规范独立智能体之间的通信。官方文档将二者定位为互补关系。参见 MCP 简介、A2A 与 MCP。

MCP 场景：查询订单

假设客服智能体正在回答配送问题。MCP 服务器提供一个订单查询工具，智能体传入订单标识，拿到订单数据，再组织语言回复客户。

这带来的业务价值，是可以复用与订单系统的连接。只是读取一条记录，无须再引入一个智能体。MCP 服务器指南讨论的就是这类工具连接问题。

A2A 场景：委派供应商筛选任务

假设采购助手需要一份符合要求的供应商候选名单。另一个供应商运营着独立的寻源智能体，由它负责调研流程。采购助手发送需求，在对方追问交付要求时补充信息，最后收到一份结构化的候选名单。

采购助手无须了解寻源智能体如何搜索、使用哪个模型，也无须知道它怎样安排内部步骤。双方需要的是约定好的请求方式和有用的结果。A2A 要支持的，正是这种跨边界协作。

寻源智能体内部仍然可以通过 MCP 读取目录数据。在这种架构中，A2A 负责委派工作，MCP 负责访问数据。

区别在于你需要什么接口。MCP 工具背后也可能有复杂的实现逻辑。如果希望对方以智能体的形式提供服务，支持能力发现和工作生命周期管理，就应考虑 A2A。判断依据是对外接口，而不是内部实现看起来有多智能。

A2A 协议是什么？

A2A 为不同厂商、不同框架构建的智能体提供了一套通用通信约定。 调用方无须访问对方的内部记忆、工具或决策逻辑，就能与之交互。协议官网将这些内部细节描述为不透明。参见 A2A 概览。

调用方是 A2A 客户端；接收请求的系统是 A2A 服务端，也称远程智能体。对希望采购专业能力的创业者来说，这意味着可以围绕服务接口完成集成，而无须重新实现对方的专业系统。

A2A 由谁开发，现在由谁治理？

官网对此有明确表述：“A2A 最初由 Google 开发，随后捐赠给 Linux Foundation。”官网还说明，项目由 Technical Steering Committee（技术指导委员会）维护。因此，项目治理已不再局限于最初的开发方。参见治理与开源。

a2aproject/A2A 仓库是查找协议规范、SDK 链接和示例的项目入口。A2A 本身是一项协议；用什么软件构建和运行智能体，仍需自行选择。

读懂 A2A 协议规范，先分清这些概念

核心是区分沟通过程、需要跟踪的工作，以及工作交付物。 将三者分开，围绕协议做系统设计就会清晰得多。

Agent Card：客户端如何了解智能体的能力

Agent Card 是一份 JSON 元数据文档，描述智能体的身份、技能、能力、连接信息和身份验证要求。客户端据此判断是否联系这个智能体，以及如何连接。参见核心概念。

在寻源示例中，卡片可以声明智能体具备供应商调研技能。它是开始集成的依据，并不能证明最终名单符合你的采购标准。

文档规定的标准发现路径是 /.well-known/agent-card.json。客户端也可以通过直接配置或经过筛选管理的注册中心获取卡片。A2A 并未为这类注册中心规定标准 API。参见智能体发现。

任务、消息、Part 与产物各管什么？

**任务（task）**是带有标识和生命周期的有状态工作单元。**消息（message）**是一次通信。Part 承载实际的文本、文件内容或引用，以及结构化数据。**产物（artifact）**则是任务执行过程中生成的具体输出。参见核心概念。

在供应商示例中，“需要配送到哪个地区？”属于沟通；被跟踪的寻源工作是任务；完成的候选名单是产物。采购流程应直接使用这份交付物，而不是从对话记录里寻找一段看起来像最终结果的内容。

智能体可以直接返回一条完整独立的消息，也可以创建任务。相关交互通过 contextId 归组。任务一旦进入终态，后续修改就应开启新任务，而不是重新启动原任务。参见任务生命周期。

采购方在交付后变更需求时，这种区分尤其重要。应保留原始候选名单的明确标识，并把修订视为新工作，方便下游使用者确认自己批准的是哪一版结果。

传输与协议绑定：同一套约定如何传递

传输方式或协议绑定规定了操作如何通过连接传递。规范定义了 JSON-RPC、gRPC 和 HTTP+JSON/REST 绑定。Agent Card 中的接口信息会列出端点、绑定方式和协议版本。参见 A2A 规范。

轮询、流式传输和推送通知解决的是如何接收任务更新，与选择哪种绑定是两回事。采购看板可能只需轮询，交互式体验则可能需要增量更新。围绕这些能力设计界面之前，先确认实际端点支持哪些功能。

A2A v1.0 有哪些变化？

现有集成需要检查兼容性，只修改版本号并不够。 官方更新说明对比了 v0.3.0 与 v1.0，列出以下变化：

• 统一的定义来源： a2a.proto 成为协议定义的权威依据，各协议绑定也有了正式规范。
• 传输数据结构变化： 统一的 Part 取代了分立的内容类型；以成员名称取代 kind 判别字段，枚举值采用 SCREAMING_SNAKE_CASE。
• Agent Card 结构调整： supportedInterfaces 集中组织连接信息，协议版本在各接口中分别声明。
• 操作更新： message/send 改为 SendMessage；新增 ListTasks，支持带筛选条件的列表查询和游标分页。
• 企业集成变化： 租户字段、Agent Card 签名验证规则及 OAuth 流程更新，都会影响集成设计。

上述变化已于 2026 年 10 月 12 日对照项目的 v1.0 更新说明核实。

检查现有连接器时，应把请求序列化、响应解析、卡片发现以及实际使用的操作放在一起审视。连接能够建立，并不代表每一种交互都仍然按预期工作。

哪些框架和平台支持 A2A？

已有多种实现提供了文档，但版本和功能覆盖范围并不相同。 应按工作流所需的实际行为选型。以下支持情况与限制已于 2026 年 10 月 12 日对照各厂商公开文档核实，未进行登录后的产品实测。

Google Agent Development Kit

Google Agent Development Kit（ADK）是一个智能体开发框架，其文档提供了 to_a2a，用于将智能体对外开放并生成 Agent Card。Python A2A 集成被标记为实验性（Experimental）。文档支持 a2a-sdk 0.3.x 和 1.x.x，并建议新集成采用 1.x.x。参见 ADK 对外提供智能体服务指南。

ADK 文档还提供了用于调用远程智能体的 RemoteA2aAgent，因此开发者可以在委派双方找到相应的接入方式。即使封装用起来方便，部署决策也应考虑其仍处于实验阶段。参见 ADK 调用远程智能体指南。

通过 LangSmith Agent Server 接入 LangGraph

LangSmith Agent Server 是 LangGraph 部署文档中的服务层，在 /a2a/{assistant_id} 提供 A2A 端点。其文档明确采用 v1.0 JSON-RPC 绑定，同时接受 v0.3 的方法名。图的状态中需要包含 messages 字段。参见 LangSmith A2A 文档。

同一页面也列出了限制：尚未实现 gRPC 和 HTTP+JSON，也暂不支持 SubscribeToTask 和推送通知配置。虽然支持消息流式传输，但这并不意味着所有订阅或通知操作都已具备。因此，在确定后台任务方案前，需要核对具体支持哪些操作。

CrewAI 与 CrewAI AMP

CrewAI 是用于协调智能体的框架，其文档提供了 A2AClientConfig 来委派远程任务，以及 A2AServerConfig 来对外提供智能体服务。同一个智能体可以同时配置这两种角色。参见 CrewAI 任务委派文档。

其部署平台 CrewAI AMP 将 A2A 服务端智能体标记为早期发布阶段，列出的协议版本是 0.2 和 0.3。文档还说明，它以持久化分布式存储取代开源实现中的内存状态。不能因为 CrewAI 支持 A2A，就认定 AMP 端点也支持 v1.0。参见 AMP 上的 A2A。

Microsoft Foundry Agent Service

Microsoft Foundry Agent Service 是一个托管智能体平台。根据文档，支持协议 1.0 的 a2a 工具类型已正式可用；较早的 a2a_preview 工具类型支持 0.3，仍处于预览阶段。Microsoft 建议新集成使用正式可用的类型。参见 Foundry A2A 文档。

该页面还明确指出，作为调用目标的 Foundry 智能体仅支持文本，不支持流式响应。如果工作流需要以流式方式交付多媒体内容，就必须考虑这一限制。协议允许哪些内容类型，并不等于每个托管平台都已实现这些类型。

更广泛的框架选型可参考 AI 智能体框架对比。这里的集成说明只回答一个更具体的问题：负责提供服务的系统，在文档中承诺了怎样的 A2A 接口？

对开发者、运维人员和采购方意味着什么？

A2A 的价值是让跨系统接口更容易复用，前提是新增服务值得投入运营成本。 不同决策角色需要关注的问题也不同。

开发者： 在增加传输机制之前，先明确委派的工作。“生成一份附有来源和推荐理由的候选名单”划定的是服务边界；“调用这个数据库查询”划定的是工具边界。即使两者最终都会触发模型调用，也应保留这种区分。

运维人员： 明确任务移交后由谁负责。在采购示例中，如果寻源智能体要求补充信息、停止响应，或返回的名单不符合验收标准，都需要有人决定如何处理。统一消息格式并不能自动解决责任划分。

采购方和创业者： 要求对方明确支持的协议版本、绑定方式、操作、内容类型，以及当前部署成熟度，再逐项对照自己的工作流需求。只有“兼容”这一表述，没有这些细节，还不足以作出集成承诺。

如何估算 A2A 部署预算？

A2A 没有一套统一的部署配置可用于计算月度账单。采购托管的专业服务，与自行运营服务，成本构成并不相同；协议文档也没有给出通用的平台价格。

可以在相同预算周期内，按以下等式估算：

集成净收益 = 节省的连接器成本 − 迁移成本 − 新增基础设施成本 − 持续运营成本。

运营成本应包括模型用量、托管、任务存储、监控，以及故障处置责任带来的投入。每一项都应使用自己的实际成本。只有省下的重复集成工作足以覆盖新增服务边界的维护成本，A2A 才值得引入。

关于 A2A，哪些期待被夸大了？

采用通用协议，不会自动让陌生智能体变得可信，也不会让分布式工作天然可靠。 标准化有其价值，但应用层决策仍然需要自己负责。

Agent Card 声明服务提供哪些能力；是否信任运营方、是否接受其输出，仍由你决定。A2A 的企业实施指南将身份验证和授权的执行责任交给具体实现，其中也包括对底层操作的权限控制。参见企业实施指南。

在寻源工作流中，可以允许智能体开展调研，但不能因此默认授予采购权。返回推荐与实际下单，应在应用中分别授权。

返回的产物、对应的任务状态，以及应用自己的验收记录，应分别管理。在允许受委派的工作流创建采购订单之前，先明确应用如何识别重复业务操作，以及如何从结果不确定的状态中恢复。

另一种过度使用，是给每次内部子智能体调用都加上 A2A。项目对自身范围有明确界定：它不负责规定智能体内部如何调用子智能体或工具。如果这些组件本就在同一套应用约定之下，框架原生的组合机制可能已经够用。参见 A2A 的范围。

该选 A2A、MCP，还是两者一起用？

先看产品今天实际存在什么系统边界。

当智能体需要通过可复用的工具接口访问业务系统、文件或 API 时，选择 MCP。如果需要自己对外提供某项能力，可以参考 Python MCP 服务器搭建指南。当问题进一步变成如何统一治理这些连接的访问权限时，MCP 网关详解讨论的就是这一层。

当另一个独立运营的智能体负责一项实质性工作，而你需要统一的方式来发现其接口、交换指令并跟踪工作进展时，选择 A2A。如果集成需求已经存在，且两端文档确认支持兼容的功能，就可以着手接入。

当你的智能体将工作委派给专业智能体，而后者又需要工具和数据时，可以同时使用两者。寻源示例正是如此：A2A 承载受委派的调研工作，MCP 则用于智能体内部的目录数据访问。

如果外部专业智能体还只是设想，可以暂缓引入 A2A。一个依靠现有工具就能胜任工作的智能体，不会因为出现了新的智能体间协议就需要改造。也不必为每次内部函数调用都套用这两种标准。应选择能解决实际集成问题的连接约定。

下一步，先把交接规则写清楚

在迁移周边技术栈之前，先围绕一个范围明确的业务结果，写清任务交接约定。 对采购助手来说，可以从供应商候选名单做起，暂时不把采购执行纳入初始范围。

1. 1

   明确什么样的产物可以验收

   列出候选名单必须包含的信息、哪些情况不予接受，以及由哪个应用记录验收结果。给远程智能体划定清晰的责任范围。

2. 2

   核对文档中的接口是否匹配

   记录客户端与服务端的协议版本、绑定方式、身份验证要求和必需操作。确认工作流是否需要流式传输或推送，以及两端是否都支持。

3. 3

   设计工作未能完成时的处理方式

   明确补充信息、超时、拒绝，以及重试后响应仍不确定时分别由谁处理。定义任务等待期间用户会看到什么，以及修订后的产物如何替换旧版本。

这份约定能为是否引入 A2A 提供具体依据。如果写到这里才发现，所谓的专业智能体其实只是读取一条记录，那就先做好工具连接。

接入 A2A 前的常见问题

不用 MCP，也能使用 A2A 吗？

可以。A2A 不规定远程智能体如何访问自己的工具和数据。当你也需要标准化的工具连接时，MCP 才能发挥相应作用。参见两者如何协作。

两个智能体必须使用同一个框架吗？

不必。跨框架互操作是 A2A 的核心目标之一。需要对齐的是对外接口，以及本次交互所需的功能，而不是智能体的内部实现。参见 A2A 概览。

想了解如何构建实用的智能体系统，可以订阅邮件通讯，获取实践指南。