一、Spring AI Alibaba 简介
Spring AI Alibaba 是一个开源项目，面向 Java 开发者提供人工智能应用开发框架。本文主要介绍 Graph 组件，该组件用于解决工作流与多位 Agent 的问题，主要包括两部分内容：一是介绍 Graph 组件的工作机制及基本原理；二是通过三个示例进行讲解。
我们将从一个简单的 Spring AI Alibaba 示例开始说明。实际上，使用该框架开发 Java 智能体（Agent）应用或 AI 应用的过程较为简便。由于其基于 Spring 生态体系，无论是新建一个专用于智能体的 Spring AI 项目，还是在已有 Spring Boot 或 Spring Cloud 项目中集成，操作方式均保持一致。开发者只需引入相关依赖包，并在 application.properties 文件中配置 OpenAI 或通义千问的 API 密钥，即可完成基础环境设置。
最后一步也是本文的重点之一，即对 ChatClient 抽象类的调用。若采用 Spring AI 开发的应用，注入 ChatClient 实例是区别于传统 Spring Boot 应用的关键所在。ChatClient 在 Spring AI 框架中作为单智能体的核心抽象接口，可视为 Single Agent 的基础组件。尽管此处未展示其完整定义过程，但其内部通常包含系统提示词（System Prompt）、可用工具集的注入、以及针对私域数据所构建的 RAG（Retrieval-Augmented Generation）检索模块等内容。当调用 ChatClient 的 call 方法或流式调用方法时，整个过程即相当于该智能体执行任务的过程，包括私域数据检索、工具调用等关键环节均已启动运行。这正是 Spring AI 提供的基础能力之一。
二、ChatClient 的能力与限制
对于一些相对简单的业务场景下的 AI 应用，应是可以满足需求的。例如，仅需实现聊天机器人（Chatbot）或多轮对话功能，均可借助 ChatClient 完成。此外，文生图、文生语音等功能也可通过该接口实现。这也是 Spring AI Alibaba 框架的一项优势所在，即支持模型服务的灵活切换。借助接口与实现分离的设计理念，开发者可在不修改上层代码的前提下，自由切换底层模型服务，如 OpenAI、通义千问等。
聊天记忆管理、工具声明与注入、以及 RAG 功能也均可实现。一个具有代表性的应用场景，即门店视频或图像分析。例如判断食品瓶盖是否闭合、水龙头是否关闭等。此类任务可通过调用 ChatClient 接口，将多模态输入传递给大模型，从而获得分析结果，完成目标识别。
综上所述，ChatClient 可有效应对典型的具体应用场景。其所依托的基本架构核心在于与模型的交互过程。在此过程中，开发者可为其提供私域数据（通过 Retriever 模块）及所需的工具集合，由智能体驱动整个流程。然而，模型在何时调用何种工具、如何检索私域数据等决策过程均由模型自主完成，开发者无法直接干预。
为何难以介入？这主要受限于 ChatClient 的设计机制。虽然开发者可向其注入各类工具及检索模块，但在发起调用后，具体的执行路径、角色切换时机等均由模型自主决定，开发者无法在中间环节进行人工确认或干预。例如，在某个图像识别任务中，开发者可能希望对模型生成的参数进行验证，但由于流程封闭性，这一操作无法实现。因此，亟需一种更为灵活的框架结构，以支持开发者在流程中插入自定义逻辑或确认节点。
上述讨论揭示了 ChatClient 在设计层面存在的局限性，也反映出单智能体模式在实际应用中的一些不足。理论上，若模型具备足够强大的推理与决策能力，且任务交互逻辑简单，则当前架构足以应对大多数 AI 应用场景。然而，现实情况是模型能力仍存在一定限制。例如，若为单一智能体配置过多工具，可能导致模型在选择工具时效果下降；又如，处理复杂问题时需多次交互，消息上下文长度随之增加，进而导致 Token 消耗量显著上升。
此外，在某些特定业务场景中，还需引入领域专用组件辅助解决问题，例如科学计算、图像生成、代码编写等。这些任务若完全交由单个智能体完成，其实现难度较高。因此，为解决上述问题，业界提出了两种主流方案：Workflow（工作流）与 Multi-Agent（多智能体）。接下来将结合 Spring AI Alibaba 的实现方式，分别探讨这两种模式的应用实践。
三、Workflow 示例解析
首先介绍 Workflow 中的一种典型模式——链式结构。该模式适用于无法一次性完成任务的情况，通过将流程拆分为多个节点，前一节点输出作为下一节点输入，各节点由不同的系统提示词驱动，共同完成任务目标。此类工作流结构具有预定义特性，流程走向及分支判断标准均为固定设定。
另一种工作流模式则允许根据条件动态选择后续节点，尽管选项数量及判断逻辑仍为预设。上述两类工作流能否通过 Spring AI Alibaba 框架实现？答案是肯定的。例如，使用 ChatClient 即可实现链式或路由型工作流。代码实现简洁明了：链式结构中，每个节点对应一个系统提示词，依次调用模型并传递输入；路由结构则依据预设规则进行路径选择。
然而，随着业务复杂度提升，工作流设计可能变得异常繁琐，代码编排方式难以有效支撑复杂逻辑。对此，当前开源社区及商业平台已提出相应解决方案。例如，开源项目 Dify 及阿里云百炼 AI 平台支持低代码可视化流程编排。用户可在画布上拖拽组件，直观构建业务流程，并实现快速部署。该方式优势在于“所见即所得”，降低学习门槛，提高开发效率。
当然，此类平台亦存在局限性。例如，功能扩展受限于平台提供的组件库，灵活性较低；同时，与企业内部系统的集成也可能面临一定挑战。
四、Multi-Agent 示例解析
关于 Multi-Agent 模式，目前主流实现方式多样，其核心理念在于任务分解与协作。即将复杂任务拆解为若干子任务，每个子任务由独立智能体负责，多个智能体之间按照既定策略协同工作，最终完成整体目标。例如 Voltage 架构即为代表性模式之一，其通过预定义协作机制，实现高效的任务分配与执行。
因时间有限，本文不对 Multi-Agent 的具体实现细节展开详述，读者可参考网络资料进一步了解。目前已有多种开源框架支持 Multi-Agent 开发，本文仅列举部分代表性项目。值得一提的是，文中所示架构图系由 GPT 生成，旨在说明 Multi-Agent 模式在解决实际问题方面的有效性，并凸显其在工程实践中的广泛应用前景。
综上所述，本节回顾了从单智能体到工作流再到多智能体的典型开发模式，为后续 Graph 组件的介绍奠定基础。
五、Graph 示例演示
接下来我们将重点介绍 Spring AI Alibaba 中的 Graph 组件。我们通过几个具体示例来展示该组件所能实现的功能。第一个示例是基于工作流构建的一个客户评价处理系统。该系统的业务场景如下：某厂商销售商品后，用户可通过系统提交反馈评价，系统需对这些评价数据进行分析并提取有价值的信息。
简要概括，该系统的目标是对用户评价进行分类处理。首先将评价划分为正面与负面两类。对于正面评价，直接存入数据库并结束流程；而对于负面评价，则进一步细分为质量、售后、运输等类别，并根据分类结果分别入库处理。
通过对该示例的分析可以看出，这是一个典型的工作流应用场景。数据流入后，流转路径明确，判断标准清晰。为了便于理解，我们尝试以图形方式展示该工作流的结构：即根据评价结果决定流程走向——正向评价进入存储节点并终止流程；负向评价则继续分类处理，随后入库。
值得一提的是，本示例是通过画布绘制完成的。如果听众曾使用过类似 Dify 开源平台或百炼平台，应该对此类操作较为熟悉。我们在绘制过程中添加了若干节点，这些节点均为框架内预设的可用功能模块。无论构建何种复杂的工作流，均只能使用平台提供的预定义节点进行绘制。
例如，在本示例中，“问题分类”功能在 Spring AI Alibaba 框架中对应一个名为 QuestionClassifier 的节点。该节点内部封装了分类逻辑，开发者在使用时只需构建新节点，指定输入来源（如用户问题），并设定分类类型即可。
除问题分类节点外，Dify 及百炼平台上所见的各类节点，在框架中均有对应的预制节点，可用于简化开发过程。因此，基于这些预定义节点，开发者可以较为便捷地绘制出所需的工作流图谱。
此外，值得强调的是“条件边”（Conditional Edge）的概念。所谓条件边，是指从某个节点出发，依据特定条件决定流向哪一个后续节点。例如，若评价为 positive，则进入正面评价处理节点；若为 negative，则进入负面评价处理节点。这种机制构成了 Graph 工作流开发的基本形式。开发者只需编写少量代码即可实现完整的流程控制，无需额外操作。
同时，开发者也可将代码实现的工作流导出为可视化图表。例如，可导出为 PlantUML 或 Mermaid 等描述语言格式，随后将其粘贴至可视化展示界面，即可呈现完整的工作流结构图。
六、ReAct Agent 示例
第二个示例是一个 ReAct Agent 的实现案例。ReAct Agent 是一种经典的智能体架构模式，其基本原理结合推理（Reasoning）与行动（Action）两个关键环节。我们首先绘制其架构图，其主要包括两个节点：Agent 节点用于与大模型进行交互，Tool 节点则挂载一个或多个工具模块。整个工作流程基于用户的输入，在 Agent 节点与 Tool 节点之间循环运行，每次循环后设置检查点，用于判断是否满足退出条件。
该示例的功能是实现天气预报查询。虽然此场景并不能充分体现 ReAct Agent 架构的优势，但作为一个演示用例仍然具有代表性。为了体现多轮查询效果，例如用户提出“帮我查北京、上海、深圳三地的天气”，系统需要对每个城市调用一次工具接口。待三次查询完成后，模型整合结果并在检查点处判断是否满足退出条件，从而终止流程。
七、OpenMenus Multi-Agent 示例
第三个示例是一个典型的 Multi-Agent 实现案例。OpenMenus 是一个开源项目，其架构设计体现了 Multi-Agent 模式的典型特征。在未引入 Graph 模块之前，我们曾提供了一个 Java 版本的实现方案，当时并未采用任何工作流或 Graph 模式进行开发，而是基于已有的 Spring AI Alibaba 代码手动编写逻辑。尽管这种方式可以实现 OpenMenus 功能，但如果未来出现另一个 Multi-Agent 的需求，几乎无法复用现有代码。
而在引入 Graph 抽象机制后，我们得以基于 Graph 模块重构 OpenMenus，并将其拓展至其他 Multi-Agent 场景中，显著提升了代码的可复用性与扩展性。
OpenMenus 在 Graph 模块下的实现架构如下：首先是 Planning Agent，其本身是一个嵌套结构，本质上属于 ReAct Agent，展开后可见其挂载了一个用于任务规划的工具模块。Planner Agent 主要负责任务规划，规划完成后交由 Controller Agent 进行监督执行。Controller Agent 不执行具体任务，而是将任务分发给 Executor Agent 执行。Executor Agent 同样为 ReAct 架构，其内部挂载了多个实用工具，包括浏览器操作、本地文件操作、脚本执行等功能模块。
由于 ReAct Agent 已被内置于框架中，开发者在实现这三个节点时仅需实例化即可。查看完整代码后可以发现，整个规划与执行结构的实现仅需数行代码即可完成。其中，Supermarket Agent（监督节点）需自行编写，其余节点均可通过框架自动处理。
我们声明了三个节点，并组织其之间的流转关系。一旦结构定义完成，即可通过 PlantUML 导出其可视化表示，便于后续维护与展示。
八、设计理念与优势总结
Graph 模块的优势在于其对 Workflow 与 Multi-Agent 模式的统一抽象能力。接下来我们进一步阐述其设计理念及其所解决的关键问题。
当前市面上存在多种支持 Multi-Agent 开发的开源框架，总体可分为两大类：
- 一类为面向流程的框架，如 LongGraph，要求开发者显式声明流程中的节点及其关联关系；
- 另一类为面向结果的框架，如 AutoGPT，不强制要求节点关系的显式定义，仅需部署多个 Agent 即可。
Spring AI Alibaba Graph 的设计在很大程度上借鉴了 LongGraph 的理念，其 API 接口设计亦高度相似，但在应用层面及内核实现方面进行了优化。
Graph 框架解决了以下关键问题：
- 提供声明式编程接口；
- 统一上下文管理机制；
- 支持消息记忆与持久化；
- 支持人工确认节点；
- 支持流式输出；
- 支持并行节点与嵌套结构。
上述特性使其成为构建复杂 AI 应用的理想选择。
九、未来展望
未来，我们将推出低代码平台并与百炼平台深度合作，以支持流程的可视化编排与工程导出。用户可通过拖拽方式构建 AI 流程，并一键导出完整的 Spring AI Alibaba 工程，便于在本地进行调试与部署。
