📚 本系列目录：《AI 原生架构》 当前第 7/10 篇 · 上一篇：AI原生架构（六）：智能体开发从入门到进阶——单智能体、工作流与多智能体 · 下一篇：AI原生架构（八）：AI网关——连接应用与大模型的智能总调度中心

📚 系列导航

《AI 原生架构》共 10 篇，本篇是第 7 篇。

← 上一篇：AI原生架构（六）：智能体开发从入门到进阶——单智能体、工作流与多智能体

下一篇：AI原生架构（八）：AI网关——连接应用与大模型的智能总调度中心 →

AI原生架构(七)：从单进程到分布式——A2A协议、Nacos注册中心与消息驱动

在第六篇文章中，我们系统学习了从单智能体到工作流再到多智能体系统的开发模式，并初步探讨了分布式部署的必要性和A2A协议的基本概念。但这些讨论主要集中在概念层面，对于如何在实际工程中实现分布式智能体的注册、发现、通信与编排，还需要更深入的技术细节。本文将结合《AI原生应用架构白皮书》第三章后半部分的内容，全面拆解分布式智能体的核心技术栈：A2A协议的完整工作流、Agent Card的发现机制、Nacos作为A2A注册中心的实践，以及RocketMQ消息驱动的智能体协作模式，为读者提供一份可落地的分布式Agent架构指南。

一、为什么必须走向分布式？

回顾微服务架构的演进历程，几乎所有的企业都经历了从单体应用到微服务的转型。核心驱动力并非单纯的技术偏好，而是组织架构和业务复杂度的必然结果——当团队规模扩大、服务需要独立迭代、技术栈需要异构集成时，单体架构的耦合性成为瓶颈。白皮书明确指出："随着智能体在企业内的广泛应用，智能体也会走向分布式。这将由企业组织机构、业务需求、成本考量等多方面因素共同决定。"

在单个智能体应用内，当多智能体系统中的子Agent数量增加到一定程度，就会面临与微服务类似的问题：每个子Agent可能有不同的发布节奏（一个需要紧急修复，另一个正在稳定运行），如果所有子Agent都在同一个进程中，一次发布就会影响整个系统。此外，不同子Agent可能由不同团队开发，采用不同的技术栈（Python、Java、Go等），强耦合在一个进程内既不现实也不高效。

因此，将子Agent进行独立部署，通过远程调用代替内存调用，成为分布式智能体的核心思路。这要求建立一套标准的通信协议和注册发现机制——这正是A2A协议与Nacos A2A Registry要解决的问题。

二、A2A协议：分布式智能体的通信语言

2.1 协议背景与定位

A2A（Agent-to-Agent）协议由Google在2025年提出并开源，是一项开放标准。它的目标非常明确：让由不同团队开发、采用不同技术构建、甚至归属于不同组织的AI智能体能够高效通信与协作。如果没有统一协议，每两个智能体之间的集成都可能变成定制化的点对点方案，导致系统难以扩展和维护。

A2A协议的设计哲学是"黑盒协作"：客户端（Client Agent）无需了解远端智能体（Remote Agent）的内部逻辑、记忆或工具集，只需要通过标准化的HTTP端点与之交互。协议基于现有的Web标准（HTTP、SSE、JSON、OAuth等），降低了学习成本和集成难度。

2.2 核心角色

A2A协议定义了三个核心角色：

• 用户（User）：发起请求的最终使用者，可以是人类或自动化服务。
• A2A客户端（Client Agent）：代表用户向远端智能体发起请求的应用、服务或其他AI智能体。客户端通过A2A协议通信，不依赖远端智能体的具体实现。
• A2A服务端（Remote Agent）：实现了A2A协议HTTP端点的AI智能体或智能系统，负责接收请求、处理任务并返回结果或状态。从客户端视角看，远端代理以"黑盒"形式运行。

2.3 协议元素详解

A2A协议定义了五种核心数据结构，在一次完整的工作流中会多次出现：

（1）Agent Card（智能体卡片）

Agent Card是A2A服务端的数字名片，一个JSON格式的元数据文档，通常托管在固定URL（如/.well-known/agent-card.json）。它包含以下关键信息：

• 身份信息：名称、描述、服务提供方。
• 服务端点：完整的访问URL。
• 协议能力：支持的协议功能（如流式传输streaming、推送通知pushNotifications）。
• 认证方式：交互所需的鉴权机制（如Bearer令牌、OAuth2）。
• 技能列表：智能体可执行的任务或功能（每个技能包含ID、名称、描述、输入/输出模式及示例）。

客户端通过解析Agent Card判断远端智能体是否适配当前任务、如何构建请求以及安全通信方式。

（2）Task（任务）

当客户端需要远端智能体完成一个状态化流程（如生成报告、预订航班）时，智能体会创建一个唯一的任务ID，并维护其生命周期：提交→处理中→需输入→完成→失败。任务支持多次客户端与服务端的交互，涵盖复杂场景的多轮通信。

（3）Message（消息）

客户端与服务端单次通信的基本单元，包含角色（user或agent）、消息ID、内容块（Part）。主要用于同步请求的单次调用回复。

（4）Artifact（产出物）

任务完成后返回的实体化结果（如文档、图片、结构化数据），由多个Part构成，支持流式增量传输。

（5）Part（内容块）

Message或Artifact中的最小内容单元，支持多类型数据：

• TextPart：纯文本内容。
• FilePart：文件数据（通过Base64内联或URI引用），含文件名、媒体类型等元数据。
• DataPart：结构化JSON数据。

2.4 三种交互机制

A2A协议定义了三种交互机制，适用于不同的延迟和响应需求：

轮询（Polling）：通过传统的请求/响应方式实现。客户端发起请求（如调用message/send RPC方法），服务端返回即时响应。对于长任务，服务端可能返回"处理中"状态，客户端需周期性调用tasks/get轮询获取状态更新，直至任务完成或失败。适用于后台任务或同步请求场景。

流式传输（Streaming）：通过SSE（Server-Sent Events）方式实现。客户端通过message/stream发起交互，服务端保持HTTP连接开放，持续发送SSE事件流（包括Task、Message、状态变更的TaskStatusUpdateEvent或产出物更新的TaskArtifactUpdateEvent）。适用于需要增量生成结果或实时进度反馈的任务，如流式文本生成。前置条件：服务端需在Agent Card中声明流式传输支持能力。

推送通知（Push Notifications）：通过WebHook方式实现。客户端在任务初始化时提供回调URL，当任务状态变更（完成、失败或需输入）时，服务端向该URL异步发送HTTP POST通知。适用于超长耗时任务或SSE长连接不可行的场景。前置条件：服务端需在Agent Card中声明推送通知支持能力。

2.5 A2A工作流完整步骤

一次典型的A2A交互分为三个主要步骤：

第一步：发现Agent Card

A2A客户端需要获取目标远端智能体的Agent Card。获取方式包括直接配置、固定URI和注册中心三种。这一步完成后，客户端拥有了与服务端通信所需的所有元信息。

第二步：授权与认证

一些智能体需要访问鉴权。A2A协议遵循标准Web安全实践：认证要求在Agent Card中声明，凭据（如OAuth令牌、API密钥）通过HTTP请求头传递，与协议消息体分离。客户端按Agent Card中声明的认证方式获取token并附加到后续请求中。

第三步：发起A2A请求

根据选择的交互机制，分为同步请求和流式请求：

• 同步请求（轮询）：客户端调用message/send发送请求，服务端返回包含初始Task的响应。如果任务未完成，客户端定期调用tasks/get轮询直到任务完成或失败。
• 流式请求（Streaming）：客户端调用message/stream，通过SSE实时接收任务状态更新和产出物增量。这种方式适用于对实时性要求高的场景，如对话式AI。

三、Agent Card的发现方式：从静态到动态

Agent Card的发现是A2A工作流的起点。白皮书介绍了三种主要的发现方式，各有适用场景：

3.1 直接配置

最简单的获取方式，直接在A2A客户端通过硬编码、配置文件或环境变量构建Agent Card。例如：

AgentCard agentCard = new AgentCardBuilder()
    .name("testAgent")
    .description("Only test")
    .url("http://127.0.0.1/")
    .capabilities(...)
    .skills(...)
    .build();

A2aClient client = new A2aClientBuilder().agentCard(agentCard).build();

优点：简单高效，适用于已知或静态的智能体关系，如开发测试环境。 缺点：灵活性低，Agent Card变更需要客户端重新配置，不适合动态变化的分布式环境。

3.2 固定URI（Well-Known URI）

遵循RFC 8615标准，将Agent Card托管在域名的标准化路径https://{智能体服务域名}/.well-known/agent-card.json。客户端通过服务域名自动发现Agent Card。

优点：标准化，支持自动化发现，只需维护服务域名列表。 缺点：当客户端依赖大量远端Agent时，需要维护和遍历所有域名；如果Agent Card含敏感信息，端点需额外鉴权。

3.3 注册中心（Registry）

这是最接近微服务治理的发现方式。通过一个中心化的注册中心统一管理所有Agent Card，客户端只知晓注册中心的地址即可按条件检索目标Agent。白皮书明确指出："如同微服务架构中的服务发现体系，通过一个中心化的注册中心对远端Agent的AgentCard进行统一集中管理，是目前所有方案中灵活度和可控性最高的一种发现方案。"

注册中心的工作流程：

1. A2A服务端向注册中心提交Agent Card。
2. 客户端调用注册中心API（如"查找支持流式传输且具备图像生成技能的智能体"）。
3. 注册中心返回匹配的Agent Card列表。
4. 客户端根据返回的卡片信息发起A2A通信。

四、Nacos A2A Registry：企业级分布式Agent的基石

随着Nacos 3.1.0的发布，Nacos正式支持作为A2A协议的注册中心，统一进行Agent的管理、注册、发现和按需检索。白皮书对此的定位是："Nacos除了作为A2A的注册中心，还可以作为MCP服务的注册中心，以及Prompt的动态管理中心，帮助用户从Agent应用视角管理所有Agent应用开发过程中的动态配置、工具和远端Agent依赖内容，从而使用户像开发微服务应用一样简单地开发分布式Agent应用架构和服务体系。"

4.1 核心能力

• 注册与发现：A2A服务端通过Nacos SDK向注册中心提交Agent Card；A2A客户端通过Nacos查询目标Agent（支持按技能、名称、标签等条件检索），获取实时Agent Card。
• 版本管理与灰度发布：Agent Card版本号支持精细化控制，可以对不同版本的Agent进行灰度引流，新版本上线后如有问题可快速回滚。
• 健康检查与故障转移：Nacos通过心跳机制监控Agent状态，当某个远端Agent不可用时，客户端可以从注册中心获取其他健康实例，实现故障自动转移。
• 统一管理：在同一个Nacos控制台，不仅可以管理A2A Agent Card，还可以管理MCP工具注册和Prompt动态模板，形成Agent应用的统一控制台。

4.2 与微服务治理的类比

白皮书将分布式Agent治理与微服务治理进行了类比，使开发者更容易理解：

这种类比使得熟悉微服务架构的团队可以快速上手分布式Agent的治理。

4.3 实践建议

在实际企业环境中，建议将Nacos部署为A2A Registry，并与其他组件（MCP Registry、动态配置中心）共享同一个Nacos集群，降低运维复杂度。开发时，可以使用Nacos提供的Agent SDK或OpenAPI来动态注册和发现Agent，实现与微服务一致的开发体验。

五、消息驱动的智能体协作：RocketMQ的深度参与

A2A协议解决了"如何通信"的问题，但在实际的分布式智能体系统中，还需要处理"何时通信"和"如何高效调度资源"的问题。白皮书专门讨论了消息驱动的智能体开发模式，指出传统消息队列在AI场景下的局限性，并提出了RocketMQ的创新解决方案。

5.1 传统消息队列的局限

AI应用呈现截然不同的业务特征：推理耗时长（分钟级）、上下文数据大（上百MB）、多轮对话需长期维护状态、多Agent协同依赖复杂异步编排，且严重依赖昂贵的GPU资源。传统消息队列暴露出明显局限：无法高效支持百万级长会话隔离、缺乏对大消息的优化传输、难以实现消费速度的精细控制，更不具备优先级调度与资源导向的智能负载均衡能力。

5.2 轻量级消息模型（Lite-Topic）

RocketMQ针对AI场景提出的核心创新是为每个会话或问题动态创建一个独立的轻量级主题（Lite-Topic）。以客户端与AI服务建立会话为例，系统自动创建一个以SessionID命名的专属队列（如chatbot/{sessionID}），所有会话历史、上下文和中间结果均以消息形式在该主题中有序流转。

这种架构的四大核心能力：

1. 百万级Lite-Topic支持：单集群可管理百万级轻量主题，为每个会话独立分配Topic，实现高并发下的会话隔离，性能无损。
2. 全自动轻量管理：Lite-Topic按需动态创建，连接断开后自动回收，彻底杜绝资源泄漏，运维零干预。
3. 大消息体传输能力：支持数十MB乃至更大消息，轻松承载长Prompt、图像、文档等AIGC典型数据负载。
4. 严格顺序消息保障：在单队列内保证消息有序，确保LLM流式输出的token顺序不乱，支撑连贯流畅的交互体验。

5.3 智能资源调度

除了会话隔离，RocketMQ还提供了基于消息驱动的智能化资源调度能力，应对AI场景下的负载不匹配和资源分配无差别问题：

• 削峰填谷：消息队列作为"流量水库"，缓存突发请求，使后端AI服务按自身处理能力自适应消费，实现负载均衡。
• 定速消费：支持为消费者组设置消费配额（quota），精准控制算力使用，防止过载或空闲。
• 优先级调度：支持抢占式优先级和权重动态分配，确保VIP请求、核心业务优先被消费，在多租户场景中平衡资源公平性。

5.4 与A2A协议的互补关系

A2A协议定义了分布式智能体之间的通信规范和交互流程，解决的是"找得到、连得上、调得通"的问题。而RocketMQ消息驱动模型解决的是"异步、可靠、可恢复"的问题——在长耗时、多轮次的复杂任务中，通过消息队列实现会话持久化、断点续传、削峰填谷，确保系统在连接断开或组件重启后仍能恢复上下文，避免昂贵的AI计算资源浪费。

两者共同构成分布式智能体的通信基础设施：A2A用于实时协作与远程调用，RocketMQ用于异步解耦与资源调度。实际应用中，一个智能体既可以实现A2A协议暴露服务，也可以内部使用RocketMQ进行任务编排。

六、统一元数据与AI协同开发模式

白皮书介绍了"基于统一元数据的AI协同开发模式"，提出了一个重要方向：将Agent应用开发中的动态配置、工具（MCP）、远端Agent依赖等统一管理，使开发者像开发微服务一样开发分布式Agent应用。Nacos作为统一控制面，将Agent Card、MCP Registry、Prompt模板等元数据集中管理，实现了：

• 动态配置：Agent的指令（Prompt）可以动态下发，无需重启。
• 工具注册：MCP Server通过Nacos注册，Agent自动发现可用工具。
• Agent发现：A2A Card通过Nacos统一管理，支持按版本路由和灰度。

七、实践要点与展望

7.1 技术选型建议

• 小型系统或开发测试：采用直接配置或固定URI发现Agent Card，快速验证A2A通信。
• 企业级生产环境：部署Nacos作为A2A Registry，统一管理Agent、MCP和配置。消息队列选用支持Lite-Topic的RocketMQ版本。
• 跨组织协作：遵循A2A协议标准，将Agent Card托管在公共URI或注册中心，支持外部Agent发现。

7.2 与现有微服务体系的融合

分布式Agent治理可以无缝融入现有微服务治理体系。Nacos已经支持同时管理微服务实例和Agent Card，运维人员可以在同一个控制台查看服务状态和Agent状态。RocketMQ同样可以作为微服务和AI应用的统一消息中间件。

7.3 未来趋势

随着Agent的广泛应用，分布式Agent将像微服务一样成为标准架构。A2A协议和Nacos Registry的组合，使得"Agent网格"成为可能——不同组织、不同技术栈的Agent可以像微服务一样相互发现和调用。同时，消息驱动的智能体协作将进一步演进，支持更复杂的编排模式（如状态机、分布式事务）和更智能的资源调度（基于模型预测的动态扩缩容）。

八、结语

从单智能体到分布式多智能体，是AI原生应用架构演进的必然之路。A2A协议提供了标准化的通信语言，Nacos A2A Registry提供了企业级的治理能力，RocketMQ提供了高效可靠的消息调度——三者共同构建了分布式智能体的基础设施。

正如白皮书所说："通过将Sub-Agent进行独立部署和维护，多个Sub-Agent间通过远程调用代替内存调用的方式，实现各个Sub-Agent独立迭代和维护。"这种架构不仅解决了组织协作的复杂性问题，也为AI应用的规模化落地提供了技术保障。

在下一篇文章中，我们将转向AI原生应用架构中的另一个关键支撑组件——AI网关，深入了解它如何连接应用与大模型，实现统一接入、成本控制、安全合规与智能路由，敬请期待。