Spring AI项目中ChatClient与Advisor API的架构演进与优化

Spring AI项目中的ChatClient和Advisor API在演进过程中经历了一系列重要的架构调整和优化，这些变化旨在提高API的健壮性、一致性和灵活性。本文将深入分析这些技术改进的背景、设计思路和实现方案。

Advisor API的简化与统一

最初的Advisor API设计中包含了"before"、"after"和"around"三种不同类型的advisor，这种设计虽然提供了灵活性，但也带来了复杂性。随着项目发展，团队决定简化为单一的"around"类型advisor。然而，API命名和观察上下文中仍保留了一些历史遗留的"around"概念，这可能会造成开发者的困惑。

优化后的设计完全移除了这些历史遗留概念，使API更加清晰和一致。这种简化不仅降低了学习曲线，还减少了潜在的错误使用场景。

AdvisedRequest API的重构

AdvisedRequest API最初的设计存在几个关键问题：

1. 信息冗余与不一致：相同的信息以多种形式存储，如Prompt信息既存在于结构化格式中，又以解构形式存在。这导致消费者需要处理复杂的逻辑来判断哪些信息已被使用。

2. 消息处理复杂性：系统消息和用户消息可能出现在专用字段(userText、systemText)或通用messages集合中，消费者需要实现复杂的推断逻辑来识别实际消息。

3. 工具管理问题：工具名称可能出现在专用字段(toolNames)或通用chatOptions中，当两者都包含工具名称时，处理冲突变得复杂。

4. 可变状态风险：AdvisedRequest包含可变的ChatModel实例和List<Advisor>，这些可变状态可能导致下游消费者获取错误信息。

重构后的设计解决了这些问题：

• 移除了冗余的advisorParams字段，统一使用adviseContext
• 消除了可变状态带来的风险
• 提供了更一致的消息和工具管理方式

AdvisedResponse API的改进

原设计中，AdvisedResponse同时携带ChatResponse和上下文信息，但上下文信息对调用者不可见。这在RAG等场景中尤为不便，因为调用者无法获取向量库检索的上下文文档等重要信息。

改进后的设计将上下文信息以更清晰的方式暴露给调用者，既保持了Chat Model API的简洁性，又提供了必要的上下文访问能力。

观察机制的增强

观察上下文(Observation Context)原先依赖于DefaultChatClientRequestSpec的具体实现，这限制了其通用性。同时，由于AdvisedRequest的信息不完整问题，观察上下文可能包含错误或不完整的数据。

优化后的观察机制：

• 解除了与具体实现的耦合
• 确保观察上下文包含完整准确的信息
• 提供了更可靠的监控和诊断能力

提示模板的灵活处理

原提示模板系统基于StringTemplate实现，存在两个主要限制：

1. 当用户提示包含大括号但不使用模板时会导致失败
2. 无法支持不同的模板策略

改进后的设计引入了可插拔的模板渲染策略，允许开发者：

• 自定义模板引擎
• 处理包含特殊字符的非模板文本
• 根据需求选择最适合的模板处理方式

总结

Spring AI通过对ChatClient和Advisor API的全面重构，解决了早期版本中的一致性问题、信息冗余问题和灵活性限制。这些改进使得API更加健壮、易于使用，同时为复杂场景提供了更好的支持。新的设计特别关注了RAG等高级用例的需求，确保开发者能够充分利用框架能力构建强大的AI应用。

这些架构演进体现了Spring团队对API设计原则的坚持：简洁性、一致性和扩展性，为Spring AI项目的长期发展奠定了坚实的基础。