构建高效智能体
在最近的一篇研究出版物《构建高效智能体》中,Anthropic 分享了关于构建高效大型语言模型(LLM)智能体的宝贵见解。这项研究特别有趣的地方在于,它强调简单性和可组合性,而不是复杂的框架。下面让我们探讨这些原则如何通过 Spring AI 转化为实际的实现。

虽然模式描述和图表来源于 Anthropic 的原始出版物,但我们将重点介绍如何利用 Spring AI 的模型可移植性和结构化输出功能来实现这些模式。建议先阅读原始论文。
spring-ai-examples 仓库中的 agentic-patterns 目录包含以下示例所需的所有代码。
智能体系统
该研究出版物在架构上对两类智能体系统做了重要区分:
- 工作流(Workflows):通过预定义代码路径(例如规范化系统)对 LLM 和工具进行编排的系统
- 智能体(Agents):LLM 动态管理自身流程和工具使用的系统
关键见解是,虽然完全自主的智能体看起来很有吸引力,但对于定义明确的任务,工作流通常能提供更好的可预测性和一致性。这与企业对可靠性和可维护性的需求完全契合。
下面让我们看看 Spring AI 如何通过五种基本模式实现这些概念,每种模式服务于特定的用例:
链式工作流
链式工作流模式(Chain Workflow)体现了将复杂任务拆解为更简单、可管理步骤的原则。

提示链工作流(Prompt Chaining Workflow) 适用场景:
- 具有清晰顺序步骤的任务
- 希望以延迟换取更高准确性的场景
- 每一步依赖于前一步的输出
以下是 Spring AI 实现的一个实际示例:
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;
}
}
该实现展示了几个关键原则:
- 每一步都有明确的职责
- 一步的输出成为下一步的输入
- 链条易于扩展和维护
并行工作流
LLM 可以同时处理多个任务,并将它们的输出通过程序进行汇总。

并行工作流(Parallelization Workflow) 适用场景:
- 处理大量相似但相互独立的项目
- 需要多个独立视角的任务
- 当处理时间关键且任务可并行化时
List<String> parallelResponse = new ParallelizationWorkflow(chatClient)
.parallel(
"分析市场变化将如何影响该利益相关者群体。",
List.of(
"客户: ...",
"员工: ...",
"投资者: ...",
"供应商: ..."
),
4
);
路由工作流
路由模式(Routing Pattern)实现了智能任务分配,使不同类型的输入能够得到专业化处理。

路由工作流(Routing Workflow) 适用场景:
- 具有不同类别输入的复杂任务
- 不同输入需要专门处理
- 当分类可以被准确处理时
@Autowired
private ChatClient chatClient;
RoutingWorkflow workflow = new RoutingWorkflow(chatClient);
Map<String, String> routes = Map.of(
"billing", "你是账单专员,帮助解决账单问题…",
"technical", "你是技术支持工程师,帮助解决技术问题…",
"general", "你是客户服务代表,帮助处理一般咨询…"
);
String input = "我的账户上周被重复扣费了";
String response = workflow.route(input, routes);
协调器-工作者模式

适用场景:
- 复杂任务,其子任务无法提前预测
- 需要不同方法或视角的任务
- 需要自适应问题解决的情况
public class OrchestratorWorkersWorkflow {
public WorkerResponse process(String taskDescription) {
// 1. 协调器分析任务并确定子任务
OrchestratorResponse orchestratorResponse = // ...
// 2. 工作者并行处理子任务
List<String> workerResponses = // ...
// 3. 将结果汇总为最终响应
return new WorkerResponse(/*...*/);
}
}
使用示例:
ChatClient chatClient = // ... 初始化 chat client
OrchestratorWorkersWorkflow workflow = new OrchestratorWorkersWorkflow(chatClient);
WorkerResponse response = workflow.process(
"为一个 REST API 端点生成技术文档和面向用户的友好文档"
);
System.out.println("分析结果: " + response.analysis());
System.out.println("工作者输出: " + response.workerResponses());
评估器-优化器模式

适用场景:
- 存在明确的评估标准
- 迭代优化能够提供可衡量的价值
- 任务通过多轮批评和改进能够受益
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 chatClient = // ... 初始化 chat client
EvaluatorOptimizerWorkflow workflow = new EvaluatorOptimizerWorkflow(chatClient);
RefinedResponse response = workflow.loop(
"创建一个实现线程安全计数器的 Java 类"
);
System.out.println("最终方案: " + response.solution());
System.out.println("演进过程: " + response.chainOfThought());
Spring AI 的实现优势
Spring AI 对这些模式的实现提供了多个优势,与 Anthropic 的建议高度契合:
模型可移植性
<dependency>
<groupId>org.springframework.ai</groupId>
<artifactId>spring-ai-openai-spring-boot-starter</artifactId>
</dependency>
结构化输出
EvaluationResponse response = chatClient.prompt(prompt)
.call()
.entity(EvaluationResponse.class);
一致的 API
- 不同 LLM 提供商之间的统一接口
- 内置错误处理和重试机制
- 灵活的提示管理
最佳实践与建议
- 从简单开始
- 从基础工作流入手,再逐步增加复杂性
- 使用最简单的模式以满足需求
- 仅在必要时增加复杂性
- 以可靠性为设计目标
- 实现明确的错误处理
- 尽可能使用类型安全的响应
- 在每个步骤中加入验证
- 考虑权衡
- 平衡延迟与准确性
- 评估何时使用并行处理
- 在固定工作流与动态智能体之间进行选择
未来工作
这些指南将会更新,以探讨如何构建更高级的智能体,将这些基础模式与复杂功能结合起来:
模式组合
- 组合多种模式以创建更强大的工作流
- 构建利用各模式优势的混合系统
- 创建能够适应不断变化需求的灵活架构
高级智能体记忆管理
- 在对话中实现持久记忆
- 高效管理上下文窗口
- 制定长期知识保留策略
工具与模型-上下文协议(MCP)集成
- 通过标准化接口利用外部工具
- 实现 MCP 以增强模型交互
- 构建可扩展的智能体架构
结论
将 Anthropic 的研究见解与 Spring AI 的实际实现相结合,为构建高效的基于 LLM 的系统提供了一个强大的框架。
通过遵循这些模式和原则,开发者可以创建稳健、可维护且高效的 AI 应用,能够提供实际价值,同时避免不必要的复杂性。
关键在于记住,有时最简单的解决方案才是最有效的。从基础模式入手,充分理解你的使用场景,只有在明确能提升系统性能或能力时才增加复杂性。