📚 本系列目录：《AI 原生架构》 当前第 6/10 篇 · 上一篇：AI原生架构（五）：上下文工程实战——提示词、RAG与记忆系统 · 下一篇：AI原生架构（七）：从单进程到分布式——A2A协议、Nacos注册中心与消息驱动

📚 系列导航

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

← 上一篇：AI原生架构（五）：上下文工程实战——提示词、RAG与记忆系统

下一篇：AI原生架构（七）：从单进程到分布式——A2A协议、Nacos注册中心与消息驱动 →

AI原生架构(六)：智能体开发从入门到进阶——单智能体、工作流与多智能体

在第五篇文章中，我们深入探讨了上下文工程的三大核心技术——提示词工程、RAG与记忆系统，理解了如何为模型提供高质量的上下文信息以提升输出效果。现在，我们将进入AI原生应用开发中最具实践性的领域之一——智能体（Agent）开发。

如果说上下文工程解决了模型"能不能理解"的问题，那么智能体开发解决的是模型"能不能行动"的问题。一个没有智能体能力的AI应用，只是一个被动的问答工具；而一个具备智能体能力的AI应用，则是一个能够自主感知、规划、决策和行动的数字化助手。从单智能体到工作流再到多智能体系统，从单进程到分布式部署，智能体的开发范式正在快速演进。本文将结合《AI原生应用架构白皮书》第三章的内容，系统性地介绍智能体的定义、开发范式、实践路径以及分布式部署方案。

一、什么是智能体？

在开始编码之前，我们需要先建立对智能体的清晰认知。白皮书给出了一个精辟的定义：

我们可以将智能体（Agent）理解为一个具备自主理解、规划、记忆和工具使用能力的数字化实体。

想象一个高度智能的个人助理，你只需告诉他"帮我规划下周三去北京的出差行程"，他就能自动理解你的意图，查询日历、预订机票和酒店、规划行程、生成行程单——整个过程无需你一步步指令。

智能体的四种核心能力

白皮书将智能体的核心能力归纳为四点：

1. 自主理解（Perception）：能够理解自然语言、图像、语音等多种输入形式，准确捕捉用户的真实意图。
2. 自主规划（Planning）：能够将复杂任务分解为多个子任务，制定执行计划。
3. 自主记忆（Memory）：能够记住历史交互、积累经验，支持跨会话的连贯性。
4. 自主工具使用（Tool Use）：能够调用外部工具（如API、数据库、搜索）完成任务。

二、AI应用的四种形态：从简单LLM到多智能体

白皮书将AI应用的形态划分为四个层次，这是一个从简单到复杂的演进路径。

1. 简单LLM应用

这是最基础的形态，即直接调用模型API实现内容生成的应用。在大模型刚刚面世之时，各类Generative AI概念的Chat应用大部分都属于这类。它们完全依赖模型服务实现内容生成，不具备工具调用、记忆等能力。虽然实现简单，但能力边界非常有限。

2. 单智能体（Single Agent）

相比于直接调用模型API的应用，单智能体应用是一种增强型LLM应用（Augmented LLM Application）。它的核心理念是为普通LLM应用增加RAG、Tool、Memory等能力，让模型具备与特定环境交互的能力。

典型的单智能体架构如下：

用户 → LLM → 工具/检索/记忆 → 响应

白皮书对这种架构有一个非常精辟的评价："这是最简单的智能体应用，同时也是最高级的智能体应用。" 说它简单，是因为开发者不需要做过多的智能体拆分编排工作，只需要把工具等上下文都给到模型，一切都由模型驱动。说它高级，是因为整个应用由模型作为大脑来驱动和决策，不论任何问题，我们都预期模型能够正确地推理、规划和调用工具来解决问题。

3. 工作流（Workflow）

当单智能体无法满足复杂业务流程的需求时，工作流提供了一种结构化的编排方式。白皮书介绍了两种典型的工作流模式：

链式工作流（Chain）：将复杂任务分解为一系列较小的、清晰的子任务，每一步由一个独立的LLM调用完成，并将上一阶段的输出作为下一阶段的输入。典型应用包括先生成营销文案，再翻译成另一种语言，或先写文章大纲、检查大纲是否满足要求，再基于大纲完整撰写文章。

路由工作流（Routing）：通过对输入进行分类，将它们分派到专门设计的下游任务或处理路径（通常也叫做意图识别），以实现关注点分离与更精准的响应。例如，在客服系统中，可以将普通咨询、退款请求、技术支持等不同类型的用户问题路由到不同的处理流程与工具。

4. 多智能体系统（Multi-Agent）

多智能体系统更偏向一种自治协作模式。在这种模式下，系统由多个具备一定自治能力的Agent组成，每个Agent有自己的角色、能力或工具使用范围。它们之间可以通过消息或上下文进行交互，协同完成复杂目标。

这种方式更接近团队合作，而不是预先定义好的流程。优点是灵活性和适应性强，尤其在任务边界不清晰、需要动态规划时表现突出，比如研究型问答、复杂数据分析或跨领域问题求解。但多智能体系统的挑战在于难以预测和控制的特性，对系统设计和调试能力要求更高。

三、ReAct模式：智能体的"思考-行动-观察"循环

白皮书详细介绍了智能体的核心运行机制——**ReAct（Reasoning and Acting）**模式。这是当前最广泛使用的Agent设计模式，其核心是一个"思考→行动→观察"的循环：

1. 思考（Reasoning）：模型分析用户请求，理解当前任务的目标和环境状态。
2. 行动（Acting）：模型决定调用哪个工具（如搜索API、查数据库），生成工具调用的参数。
3. 观察（Observation）：工具执行完成后，返回结果给模型。
4. 循环迭代：智能体接收到这个观察结果后，会将其与之前的"思考"和任务目标结合起来，进入新一轮的思考阶段。它会评估上一步行动的结果是否使其更接近最终目标，并据此规划下一步的行动。

这个循环会一直持续下去，直到智能体判断任务已经完成，然后它会生成最终的答案并结束循环。

四、开发实践：从零构建智能体

1. 快速定义一个简单的Agent

在创建任何智能体之前，首先需要明确定义它的身份和目标。这构成了智能体的基础配置，决定了它的核心功能以及在多智能体系统中如何与其他成员协作。

关键配置包括：

• Name（名称，必填）：每个智能体都需要一个唯一的字符串标识符。建议选择一个能清晰反映其功能的描述性名称（如writer_agent、reviewer_agent）。
• Description（描述，可选，但在多智能体中强烈推荐）：为智能体的能力提供一个简明扼要的摘要。这个描述主要供其他大语言模型智能体使用，以判断是否应将某个任务路由给当前智能体。
• Model（模型，必填）：指定驱动该智能体进行推理的底层大语言模型，例如"qwen-max"。

2. 引导Agent的行为：设置指令（Prompt）

在框架中，指令（Prompt）是引导智能体行为的核心手段。一个典型的Prompt包含：

• 任务描述：智能体需要完成什么任务。
• 行为约束：在什么情况下应该做什么、不应该做什么。
• 工具说明：有哪些工具可用，以及何时应该调用哪个工具。

示例Prompt结构：

You are a capital city assistant. Your task:
1. Identify the country name from the user's query.
2. Use the get_capital_city tool to find the capital.
3. Respond clearly to the user, stating the capital city.
Example Query: "What's the capital of {country}?"
Example Response: "The capital of France is Paris."

关于如何编写高效指令的技巧，白皮书给出了几个关键原则：

• 清晰具体：避免模糊不清的表述，明确地陈述期望的动作和结果。
• 使用Markdown：对于复杂的指令，可以使用标题、列表等Markdown格式来提高可读性。
• 提供示例（Few-Shot Learning）：对于复杂的任务或特定的输出格式，直接在指令中包含一两个示例会非常有帮助。
• 引导工具使用：不要仅仅罗列工具有哪些，更要解释智能体何时以及为何应该使用它们。

3. 配置工具与模型参数

工具赋予ReactAgent获得模型预训练数据之外的能力，可以与本地私域数据、业务系统很好地结合。在Spring AI Alibaba中，工具列表中的每一项可以是：

• 一个原生函数或方法（包装为ToolCallback）。
• 另一个智能体的实例（AgentTool），这使得智能体之间的任务委托成为可能。

大语言模型会根据当前的对话内容和自身的指令，利用工具的函数名称、描述以及参数结构来决定调用哪一个工具。

五、工作流与多智能体：应对复杂业务场景

掌握了如何开发一个简单的智能体之后，接下来要面对的是更复杂的实际业务场景。白皮书指出，在多智能体系统开发过程中，有几个关键考量：

1. 从一个简单的双智能体系统入手，例如先定义一个编写者，再定义一个评论者，让它们协作完成一篇短文。
2. 为每个智能体定义独特的角色、能力和明确的职责，设计清晰的通信协议和工作流程。
3. 利用主流框架来简化开发，这些框架提供了智能体通信、状态管理和任务编排的工具。

1. Spring AI Alibaba中的多智能体类型

Spring AI Alibaba中的Agent定义与类继承关系总体上分为三种Agent类型：

• ReactAgent：框架中对于Agent的基本定义，多智能体通常是指如何编排多个ReactAgent互相协作解决复杂问题。
• FlowAgent：包含有多个ReactAgent，它们按照特定的流程相互协作。包括SequentialAgent（串行执行）、ParallelAgent（并行执行）、LoopAgent（循环执行）。
• LlmRoutingAgent：由大模型决策执行哪个智能体。

这三种类型在核心特性、流程编排和确定性上各有不同：

2. SequentialAgent：串行工作流

SequentialAgent的典型架构是Agent依次执行，上一个Agent的输出会作为下一个Agent的输入。白皮书以文章协作助手为例，展示了如何开发一个包含writer_agent和reviewer_agent的SequentialAgent。

在这个示例中，SequentialAgent作为RootAgent（总入口），需要明确声明state（在整个Agent链路中用到的所有参数）和subAgents（关联的子Agent）。writer_agent负责生成文章，reviewer_agent负责审核并给出修改意见，两者依次执行，形成一个完整的文章协作流程。

3. ParallelAgent：并行工作流

ParallelAgent是并行执行的工作流模式。白皮书以智能搜索助手为例，展示了如何开发一个包含多个研究Agent的并行工作流。

在这个示例中，ResearchAgent1（擅长AI Agent领域）和ResearchAgent2（擅长微服务领域）同时进行搜索，然后将各自的输出传递给MergerAgent进行合并汇总。通过SequentialAgent将ResearchAgent和MergerAgent串联到一起，形成一个完整的工作流。

值得注意的是，SequentialAgent与ParallelAgent之间可以互相作为subAgent嵌套组成更复杂的工作流，这为构建复杂的业务场景提供了极大的灵活性。

4. LoopAgent：循环工作流

LoopAgent是另一个工作流模式的智能体，它在循环中执行其子代理。它在指定的迭代次数内重复运行一系列代理，或者直到满足终止条件。

例如，可以配置一个LoopAgent，让它循环执行writer_agent和reviewer_agent三次，每次根据reviewer的反馈修改文章，直到达到满意的质量。

5. LlmRoutingAgent：模型驱动的路由

LlmRoutingAgent是多智能体系统中的一种重要模式，它与前面讲到的工作流模式最大的区别在于：它通过模型决策下一个子智能体的走向，而不是由开发者预先定义流程。

RoutingAgent内置的Prompt会告诉模型：你的职责是任务路由，你有以下可用的子Agent，每个子Agent有各自的能力描述，请根据用户的请求决定将任务委托给哪个子Agent。

例如，可以定义一个RoutingAgent，它包含prose_writer_agent（写散文）和poem_writer_agent（写现代诗）两个子Agent。当用户说"写一篇关于春天的散文"时，模型会自动将任务路由到prose_writer_agent；当用户说"写一首关于秋天的诗"时，模型会路由到poem_writer_agent。

这种模式非常适合任务类型多样、需要动态判断的场景。

六、从单进程到分布式：A2A协议与Nacos注册中心

通过前面的学习，我们已经掌握了从单智能体到多智能体的开发模式与实践方案，但这些讨论都还限定在单个应用、单个进程范围内。那么，如何将智能体拓展到分布式场景呢？

1. 为什么需要分布式智能体？

回顾微服务时代，几乎所有的企业都经历了从单体架构到微服务架构的技术演进。这其中有企业组织架构、文化方面的非技术因素，也有可扩展性、维护复杂度、性能等技术因素。白皮书指出："我们相信随着智能体在企业内的广泛应用，智能体也会走向分布式。"

在单个的智能体应用内，随着拆分的Multi-Agent增加、子智能体（Sub-Agent）的更新和发布，会伴随组织架构的膨胀，沟通成本的上升导致AI应用的迭代效率及稳定性降低。通过将Sub-Agent进行独立部署和维护，多个Sub-Agent间通过远程调用代替内存调用，可以实现各个Sub-Agent独立迭代和维护，避免不同的Sub-Agent节奏不同导致的效率和稳定性降低问题。

2. A2A协议的核心概念

洞察到分布式智能体的趋势后，Google迅速跟进，在开源社区中推出了分布式智能体之间的通信协议——Agent2Agent协议（A2A协议）。

A2A协议是一项开放标准，旨在解决如何让由不同团队开发、采用不同技术构建、归属于不同组织的AI智能体实现高效通信与协作的问题。

A2A协议中主要包含以下关键角色：

• 用户（User）：发起请求或目标的最终使用者。
• A2A客户端（Client Agent）：代表用户向远端智能体发起操作或信息请求的应用、服务或其他AI智能体。
• A2A服务端（Remote Agent）：实现了A2A协议HTTP端点的AI智能体或智能系统，负责接收请求、处理任务并返回结果或状态。

A2A协议中主要包含以下几种元素：

• Agent Card（智能体卡片）：一个JSON格式的元数据文档，用于描述A2A服务端的能力，包含智能体身份、服务端点URL、版本号、支持的A2A功能、技能列表等信息。
• Task（任务）：当客户端向智能体发送请求时，若需通过状态化流程完成任务，智能体会创建唯一任务ID并维护其生命周期。
• Message（消息）：客户端与服务端单次通信的基本单元。
• Artifact（产出物）：任务完成后返回的实体化结果。

A2A协议主要使用三种交互机制：

• 轮询（Polling）：通过传统的请求/响应方式实现，客户端周期性轮询获取任务状态更新。
• 流式传输（Streaming）：通过SSE（Server-Send Events）方式实现，适用于需增量生成结果或实时进度反馈的任务。
• 推送通知（Push Notification）：服务端主动向客户端推送任务状态更新。

3. Nacos注册中心：Agent的"服务治理"

白皮书指出："Nacos除了作为A2A的注册中心，还可以作为MCP服务的注册中心，以及Prompt的动态管理中心，帮助用户从Agent应用视角管理所有Agent应用开发过程中的动态配置、工具和远端Agent依赖内容，从而使用户像开发微服务应用一样简单地开发分布式Agent应用。"

通过Nacos注册中心，可以实现：

• Agent的注册与发现：每个Agent启动时自动注册到Nacos，客户端可以动态发现可用Agent。
• 健康检查：Nacos定期检查Agent的心跳，确保只将请求路由到健康的Agent实例。
• 负载均衡：支持多种负载均衡策略，避免单点过载。
• 配置管理：集中管理Agent的配置，支持动态更新。

4. RocketMQ：AI场景的消息驱动

在AI应用场景中，消息队列需要解决一个独特的挑战：会话状态管理与海量临时消息的处理。

针对这一挑战，RocketMQ提出了一种创新的轻量化架构——其核心理念是：为每个会话或问题动态创建一个独立的轻量级主题（Lite-Topic）。以客户端与AI服务建立会话为例，系统自动创建一个以SessionID命名的专属队列，所有会话历史、上下文和中间结果均以消息形式在该主题中有序流转。

这一创新架构的实现，依托于RocketMQ为AI场景深度优化的四大核心能力：

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

此外，RocketMQ还提供了基于消息驱动的智能化资源调度能力，包括天然削峰填谷保护AI算力、定速消费精准控制算力使用、优先级调度实现智能资源分配等。

七、结语

从单智能体到工作流，从多智能体到分布式部署，智能体开发代表了AI原生应用从"被动应答"到"主动行动"的关键跃迁。

• 单智能体让我们学会了如何赋予模型工具使用和上下文记忆的能力；
• 工作流提供了编排多个LLM节点的结构化方法；
• 多智能体系统将分散的Agent组织成协作团队；
• A2A协议与Nacos则将这套体系从单进程扩展到分布式，使企业级Agent应用成为可能。

在下一篇文章中，我们将深入探讨A2A协议、Nacos注册中心和RocketMQ消息驱动的更具体实现细节，以及如何将这些组件在实际项目中落地，敬请期待。