从 AI 生产实践谈 A2A 原理与意义

2025 年上半年大模型 AI 应用领域的新技术、新框架层出不穷，MCP、A2A 的出现似乎也给 AI 能走向生产应用提供了“土壤”。互联网相关技术视频与文章很多，但大多是介绍技术本身的功能实现，而忽略了我们为什么要使用该协议，该协议技术原理是什么，该协议为我们带来了什么。本文以企业 AI 应用技术架构的生产实践为背景，和大家分享我们对于 A2A 的理解。

一、企业 AI 应用架构中的 A2A

企业级 AI 应用逻辑架构一般大体上可以分为四层，分别为数据资产、AI 组件、智能体、AI 应用，这四层其实是依据技术组织归属划分，主要想体现的核心理念是分层架构，强调的是智能体与 AI 组件的分层与解耦，这也是我们根据前期实际生产出现的问题而选择进行架构升级的核心原因之一。

● 数据资产：企业会将现有生产系统中数据资产进行抽象与封装供上层 AI 组件调用，这些数据资产其实大多来源于存量生产系统中，包括大数据分析类、实时业务接口类、流程自动化类、领域知识类等；

● AI 组件：AI 组件是智能体构建过程中能够应用的内外部资源，其中包括①向量知识库，主要纳管数据资产中知识库；②MCP，主要纳管数据资产中大数据分析、实时业务接口、流程自动化等操作的接口；③模型，主要纳管大小模型，为智能体构建提供“大脑”；

● 智能体：智能体包括了依托智能体平台构建的低代码智能体和依托开发框架构建的高代码智能体，智能体向下通过 AI 组件实现业务智能化升级，向上为 AI 应用提供智能体服务支撑。

● AI 应用：AI 应用为智能体应用统一入口，实现智能体调度与管理，根据用户不同的用户需求匹配最合适智能体进行任务处理与协同，展现形式如自动驾驶、AI 助手等。

A2A(Agent2Agent)，本质是一个协议，可基于该协议实现智能体通信与协同。在企业 AI 应用逻辑架构中应该处于 AI 应用层与智能体层间，一方面为 AI 应用提供智能体服务接口，一方面为智能体之间协作提供一种标准化可能。

二、A2A 核心元素

A2A 核心元素包括 AgentCard、Agent 服务端、Agent 客户端等组件，通过 Task、Message、TaskStatusUpdate、TaskArtifactUpdate、等消息类型传递交互数据，实现任务处理的分布式协调与透明化管理，支持灵活、可扩展的多代理协作模式。

A2A 核心组件：

● Agent Card：用于封装 A2A 智能体元数据信息，包括智能体名称、功能描述、技能列表、服务地址等，标准化智能体定义、识别、调用。

● A2A 服务端：负责接收 A2A 客户端提交的智能体任务，处理并返回结果。响应内容包括任务执行状态、每个阶段的具体结果。

● A2A 客户端：根据 Agent Card 匹配场景最优 A2A 智能体，作为客户端封装智能体交互请求，发送任务至服务端并接收结果。

A2A 消息类型：

● Task（任务）：一个智能体交互任务，可以为单智能体调用，也可以为多智能体协同调用。

● Message（消息）：作为智能体交互基本通信单元，用于封装执行智能体任务的请求与响应。

● TaskStatusUpdate（任务状态更新）：实时标识任务处理过程的状态变化。

● TaskArtifactUpdate（任务输出更新）：智能体执行过程中每个阶段的内容输出。

三、为什么选择 A2A

在 AI 应用架构设计时，大家总会思考到底选哪种技术栈进行应用，以 A2A 为例，在智能体协同与交互时，选不选 A2A，有没有替代方案，最后哪种技术栈的生态会更长久，这些问题其实在飞快发展的 AI 领域一直困扰着大家。通过对 A2A 协议研究，最终我们选择应用，并通过实践证明可行，下面和大家分享在架构设计层面我们为什么会应用 A2A。

● 异构智能体调度与协同：现阶段不同智能体平台（如 coze、n8n）、智能体框架（如 langgraph、autogen）暴露智能体服务协议不同，对于异构智能体调度与协同带来智能体对接与处理复杂性；

● 智能体声明与服务解耦：AgentCard 描述智能体能处理业务范围以及技能列表，AI 应用可以快速获取相关智能体声明信息，更好的进行智能体识别与应用；

● 任务调度的全生命周期：协议规范了智能体执行的全生命周期状态。会按照预定义生命周期对其进行处理，在运行过程中传递进度信息并在需要时请求输入，直至任务进入中断状态（如需要输入、需要鉴权）或终止状态（如已完成、已取消、已拒绝、已失败）。

● 支持多模态兼容与扩展：协议兼容了多模态，如文字、图片、视频、iframe 等，同时可以进行扩展，满足行业主流输出格式；

● 支持流式输出异步处理：协议兼容同步与异步方式，同步可以实时得到智能体反馈结果，如处理文字类内容；异步以通知方式得到智能体反馈结果，如处理文件类内容。在输出的方式同时支持流式输出与全内容输出；

● 支持智能体间协同交互：AI 应用可以处理单智能体、多智能体任务，协议支持 react 方式和 planning 方式，通过 task 与 message 关联，实现智能体交互与数据流通。

在 AI 应用架构设计中其实核心考虑的就是智能体的调用与智能体协作，当时是否选择 A2A 协议在团队内部也产生了分歧，一部人秉持 A2A 生态不一定能维持下去的想法，但是最终我们换位思考，如果不使用 A2A 我们在智能体交互与 AI 应用前后端交互两部分协议的设计是否有更科学的设计，最终我认为 A2A 协议在现阶段考虑比较全面且有一定的扩展性，所以我们最终选择采用 A2A 协议，更为重要的是我们核心智能体平台已经具备发布 A2A 协议能力与条件。

四、有 MCP 是否还需要 A2A

有很多人拿 A2A 和 MCP 进行技术横向对比，其实从单纯技术上来讲，A2A 协议与 MCP 协议都是 API 层接口协议，但通过实践经验我觉得核心差异体现在分层架构中所处的不同层级以及应用上的用户感知，核心逻辑如下图。A2A 是 AI 应用层协议，MCP 是智能体层协议，MCP+LLM 可以实现构建智能体，智能体对外暴露的是 A2A 协议接口。智能体为有状态交互，能够基于用户的输入动态响应，例如返回“需要输入”状态以请求更多信息，同时也能够通过上下文信息维护和推断多个请求之间的关系，从而实现更连贯、更具语境感知能力的多轮协作。

针对两种协议标准在领域层级、研发感知、参数情况、实现效果等进行了要点的对比与分析，具体见下表。

五、  A2A 场景化示例

以一个协作智能体和三个领域内远程智能体为例和大家分享在 A2A 协议下多智能体协同场景与流程。

A2A 用于两个智能体之间的通信。在多智能体协作场景中，远程智能体通过 HTTP 端点以 A2A 协议对外提供服务。在初始化阶段，协作智能体能够获取所有可调用远程智能体的 AgentCard，从而感知智能体能力信息。在协作阶段，基于用户输入，协作智能体可自主决策并编排调用最合适的远程智能体执行相应任务，并且将结果根据需要作为输入传给下一个智能体。

智能体之间通过 A2A 协议进行通信，智能体一般可输出两类消息：一是中间状态（status）信息，用于表示任务执行进度，例如任务已接收并提交（submitted）、正在调用工具处理中（working），或任务已执行完成（completed）；二是智能体的实际输出内容（Artifact），支持多种类型，包括普通文本（TextPart）、文件（FilePart）以及其他数据格式（DataPart）。其中，DataPart 可扩展为多种富文本格式，如 HTML 网页、Markdown 文本、ECharts 图表等，具备丰富的结构化与可视化表达能力。

以上图用户分析智能体为例讲解给大家分析下智能体之间的协作，案例中用户信息、订购信息、产品信息均为模拟场景样例数据。

● 用户分析智能体收到消息后向客户端返回“任务提交（TaskSubmitted）”的 status 消息，表明自己已经收到这个任务。

● 自主规划要调用套餐查询工具（可以是 MCP 或其他工具），并返回工具调用内容，支持文字与图标方式。

● 根据场景需求可以判断是否调用用户画像查询工具等，得到更详细的用户信息。

● 将工具返回的消息加工后，以流式格式返回给客户端。

● 当所有消息体都返回信息后向客户端返回了（TaskCompleted）状态消息。

六、A2A 能走多远

通过以上技术预研以及企业级 AI 生产实践，我们得出基于 A2A 智能体协作协议构建 AI 应用统一入口整体架构具备可实施性与可扩展性，但最早设计该架构时团队讨论的技术发展方向的担忧还存在，主要如下。

● 技术生态：虽然 A2A 协议在 Google、Adobe、AWS、Red Hat、LangChain 等企业和组织推动和协作下发展，但行业内公开 A2A 智能体集不多，且 A2A 协议影响力暂时还没有覆盖 100%主流 AI 研发框架。

● 技术成熟度：A2A 本质上是协议，协议客观来讲与业务逻辑不是强相关，A2A 如果想发展更稳健就应该提高 SDK 稳定性与兼容性，让不同的 AI 研发框架引入及可用。

最后，我们一直在问自己“如果让我们设计一套智能体协作标准协议，且做到对异构智能体接口协议兼容，我们和 A2A 的差异性体现在哪”，最终我们没有得到令自己满意答案。