Spring AI项目中VectorStoreChatMemoryAdvisor的内存持久化问题解析

问题背景

在Spring AI项目的最新版本中，开发者发现了一个关于聊天记忆持久化的关键问题：当使用AWS Bedrock Converse进行流式聊天时，VectorStoreChatMemoryAdvisor无法正确地将助手(ASSISTANT)的响应消息持久化到数据库中。这个问题在M8版本中并不存在，但在升级到RC1版本后出现。

技术细节分析

该问题的核心在于VectorStoreChatMemoryAdvisor的after方法没有被正确调用。在RC1版本中，Spring AI团队移除了StreamAroundAdvisor，改为依赖after方法来实现类似功能。这种架构变更导致了以下行为变化：

1. 在M8版本中，StreamAroundAdvisor通过observeAfter方法聚合消息响应并调用chatMemoryStore.write来写入向量存储
2. 在RC1版本中，after方法的调用依赖于AdvisorUtils.onFinishReason()的测试结果，要求response的metadata中包含finishReason文本

根本原因

深入分析后发现，问题出在Bedrock Converse API的事件处理链上：

1. 虽然MessageStopEvent被创建，但它没有被ConverseApiUtils正确拦截
2. 由于缺少这个拦截步骤，result.getMetadata().getFinishReason()始终为空
3. 这导致AdvisorUtils.onFinishReason()测试失败，最终after方法无法被调用

解决方案验证

Spring AI团队已经通过PR #3193修复了这个问题。验证表明：

1. 最新的1.0.0-SNAPSHOT版本已经解决了这个回归问题
2. MessageAggregator现在能够正确地从BedrockProxyChatModel的AggregationHandler调用adviseStream

遗留问题与建议

虽然主要问题已经解决，但仍有一个潜在问题需要注意：

MessageStopEvent的处理仍然不够完善，这可能导致响应元数据中缺少finishReason信息。建议开发者在未来版本中关注这个问题，因为它可能影响下游功能的正常运行。

总结

这个案例展示了框架升级过程中可能遇到的兼容性问题，特别是在处理流式API和事件驱动架构时。Spring AI团队快速响应并修复了这个内存持久化问题，体现了开源项目的敏捷性。开发者在使用类似功能时，应当注意版本变更带来的行为差异，并及时测试核心功能的完整性。