Spring AI五种智能体模式实战：工作流与Agent区别及代码实现

本节目标：理解智能体（Agent）与工作流的区别，掌握五种基础智能体模式，学完你能用 ChatClient 组合工具、记忆、RAG 和评估，构建自己的智能体系统。

41.1 两种智能体系统

Anthropic 在《Building Effective Agents》研究里做了一个关键区分。智能体系统分两类：工作流和智能体。

工作流（Workflows）是预定义代码路径。LLM 和工具按你写好的流程执行，顺序固定，行为可预期。

智能体（Agents）相反。LLM 自己决定下一步做什么、调用哪个工具，流程在运行时才展开。

哪种更好？研究给出的答案是：视任务而定。全自主的智能体听起来厉害，但明确的任务用工作流更稳。企业场景里，可预测性和可维护性往往比”聪明”更重要。

所以构建思路应该反过来：先想清楚任务是不是固定的。固定就用工作流，不固定再考虑动态智能体。

41.2 智能体的积木

本教程前几章讲的东西，都是智能体的积木。

工具：第 24-26 章的 @Tool 与 ToolCallback，让模型能调用你的代码。
记忆：第 21-23 章的聊天记忆，让智能体记得上下文。
RAG：第 32-37 章的知识库检索，给智能体补充私有知识。
评估：第 38 章的评估体系，量化智能体回答好不好。

智能体 = 模型 + 工具 + 记忆 + RAG + 评估，用代码编排起来。本章的五个模式，就是编排的五种套路。

Note

本章示例代码来自官方 spring-ai-examples 仓库的 agentic-patterns 目录。建议先读 Anthropic 原始论文，再看实现。

41.3 模式一：链式工作流

链式工作流把复杂任务拆成顺序步骤。每一步只干一件事，输出喂给下一步。

适用场景：任务有明确顺序、每一步依赖前一步的结果、愿意用延迟换准确率。

官方示例的核心代码非常短：

public class ChainWorkflow {

    private final ChatClient chatClient;
    private final String[] systemPrompts;

    public String chain(String userInput) {
        String response = userInput;
        for (String prompt : systemPrompts) {
            String input = String.format("{%s}\n {%s}", prompt, response);
            response = chatClient.prompt(input).call().content();
        }
        return response;
    }
}

核心就是循环：把上一步的输出拼进下一步的提示。systemPrompts 数组里放每一步的指令，比如”先列大纲”、“再扩写”、“最后润色”。

这个模式的好处是结构透明。每一步职责单一，出问题能定位到具体环节，加步骤只是往数组里加一行。

41.4 模式二：并行工作流

有些任务互相独立，可以同时跑。并行工作流让多个 LLM 调用同时执行，最后把结果聚合。

适用场景：大批量相似但独立的条目、需要多个独立视角、处理时间敏感。

看官方示例的调用方式：

List<String> parallelResponse = new ParallelizationWorkflow(chatClient)
        .parallel(
            "分析市场变化将如何影响这个利益相关方群体。",
            List.of(
                "客户：……",
                "员工：……",
                "投资者：……",
                "供应商：……"
            ),
            4
        );

一次任务，四路并行，各自分析一个利益相关方。内部实现通常是 CompletableFuture 或虚拟线程。

并行模式把延迟压到单路水平，代价是 token 消耗成倍增加。任务之间必须真的独立，共享状态的任务不适合并行。

41.5 模式三：路由工作流

路由模式解决分类问题。不同输入走不同的专业化处理，每个分支有专属的系统提示词。

适用场景：输入可明确分类、不同输入需要不同处理方式、分类准确率有保障。

RoutingWorkflow workflow = new RoutingWorkflow(chatClient);

Map<String, String> routes = Map.of(
    "billing", "你是账单专家，负责解决账单问题……",
    "technical", "你是技术支持工程师，负责解决技术问题……",
    "general", "你是客服代表，负责处理一般咨询……"
);

String input = "上周我的账户被扣了两次费";
String response = workflow.route(input, routes);

路由的第一步通常是分类。可以用结构化输出让模型返回一个类别，再按类别选提示词。分类错了后面全错，所以路由适合类别边界清晰的场景。

路由的典型应用是客服系统。账单问题、技术问题、一般咨询，分给不同的”专家”回答，比一个通用提示词效果更好。

41.6 模式四：协调者-执行者

前面三个模式都要求任务结构可预测。协调者-执行者（Orchestrator-Workers）针对的是不可预测的任务。

主模型扮演协调者，分析任务后动态拆出子任务，分给多个执行者并行处理，最后汇总结果。

public class OrchestratorWorkersWorkflow {

    public WorkerResponse process(String taskDescription) {
        // 1. Orchestrator analyzes task and determines subtasks
        OrchestratorResponse orchestratorResponse = ...;

        // 2. Workers process subtasks in parallel
        List<String> workerResponses = ...;

        // 3. Results are combined into final response
        return new WorkerResponse(/*...*/);
    }
}

官方用例是生成一份 API 文档：既要技术文档，又要用户友好的说明。协调者把任务拆成两路，两个执行者各写一份，最后合并。

这个模式的难度在汇总。子任务结果格式不一，协调者需要结构化输出（.entity()）才能稳定解析。拆任务这一步本身也可能出错，需要在提示词里把拆解规则写清楚。

41.7 模式五：评估-优化

评估-优化（Evaluator-Optimizer）模拟人改稿的过程。生成一版，让评估者挑毛病，拿着反馈再生成一版，循环直到满意。

适用场景：有明确的评估标准、多轮打磨能带来可衡量的提升、任务值得多次调用模型。

public class EvaluatorOptimizerWorkflow {

    public RefinedResponse loop(String task) {
        Generation generation = generate(task, context);
        EvaluationResponse evaluation = evaluate(generation.response(), task);
        return new RefinedResponse(finalSolution, chainOfThought);
    }
}

生成和评估都是独立的 ChatClient 调用。评估结果可以是结构化对象：是否通过、问题清单、修改建议。不通过就把反馈带回下一轮。

Tip

评估环节建议用第 38 章的结构化输出，把”通过/不通过 + 理由”定义成 record。文本判断容易漏判，结构化判断才可靠。

循环必须有退出条件。常见做法是设定最大轮数，或者评估通过就停。没有退出条件的循环，成本不可控。

41.8 Spring AI 的实现优势

五种模式在 Spring AI 里实现起来，有三个共同优势。

模型可移植。换模型只改一个依赖，代码不用动：

<dependency>
    <groupId>org.springframework.ai</groupId>
    <artifactId>spring-ai-starter-model-openai</artifactId>
</dependency>

换成 Anthropic、Gemini、Ollama，都是同样的 starter 模式。

结构化输出。模式之间传递数据，用 .entity() 直接映射成 Java 对象：

EvaluationResponse response = chatClient.prompt(prompt)
        .call()
        .entity(EvaluationResponse.class);

一致 API。所有模式都建立在 ChatClient 上。统一接口、内置重试、灵活的提示管理，五种模式的代码风格完全一致，学习成本低。

41.9 智能体设计原则

官方文档给了一组设计建议，值得抄下来。

从简单入手。先选最简单的模式，跑通了再加复杂度。多数任务用链式或路由就能解决，不需要一上来就上协调者。

为可靠性设计。每步做好错误处理，响应尽量用类型安全的 entity()，关键节点加验证。智能体的错误会沿着链条放大，越早拦截越好。

权衡取舍。延迟和准确率怎么平衡？并行还是串行？固定工作流还是动态智能体？这些问题没有标准答案，按业务场景选。

文档里还有一句总结：最简单的方案往往最有效。把场景理解透，只在复杂度确实能提升性能时再加。

41.10 小结

五种模式覆盖了智能体编排的主要场景：链式管顺序、并行管吞吐、路由管分类、协调者管动态拆解、评估-优化管质量。

它们不是互斥的，可以组合。比如路由之后再接链式，评估-优化包住整个流程。Anthropic 的论文也指出，未来方向正是模式组合、持久记忆、工具与 MCP 集成。

下一章讲提示工程模式。智能体的骨架靠代码，灵魂靠提示词。

构建高效智能体

41.1 两种智能体系统

41.2 智能体的积木

41.3 模式一：链式工作流

41.4 模式二：并行工作流

41.5 模式三：路由工作流

41.6 模式四：协调者-执行者

41.7 模式五：评估-优化

41.8 Spring AI 的实现优势

41.9 智能体设计原则

41.10 小结