InMemoryChatMemory哪去了？：大模型聊天记忆功能的彻底重构与踩坑实录

InMemoryChatMemory哪去了大模型聊天记忆功能的彻底重构与踩坑实录如果你最近在跟进学习 Spring AI并在尝试接入大模型的**“上下文会话记忆Chat Memory”**功能那么如果你用的是1.0.0-M8或更高的最新版本你一定会遭遇一系列极其绝望的报错。你可能会发现网上所有教程里教的InMemoryChatMemory找不到啦自己手写的new MessageChatMemoryAdvisor()报 private 权限错误啦甚至连配置会话 ID 的常量CHAT_MEMORY_CONVERSATION_ID_KEY也凭空消失了别慌这不是你的问题而是 Spring AI 官方在最新版本中进行了一次极其硬核的底层架构大重构。今天我们就用架构师的视角把这些“坑”一个个填平带你彻底看懂新版的正确姿势。坑位一消失的 InMemoryChatMemory 与职责分离在旧版本中我们要实现记忆功能通常会直接创建一个InMemoryChatMemory。但在新版中这个类被彻底拆解了。为什么因为在生产环境中旧版类暴露出一个致命缺陷它既管存又管发。用户聊了 1000 句它就把 1000 句全发给大模型导致Token 瞬间爆栈API 费用直接起飞。为了解决这个问题新版进行了优雅的职责分离 (Separation of Concerns)干苦力的仓库存储层InMemoryChatMemoryRepository。它只负责把数据存进内存的 HashMap 里。以后如果要上分布式可以无缝替换为RedisChatMemoryRepository。防爆栈的门卫管理层MessageWindowChatMemory。这是新架构的明星叫**“滑动窗口记忆”**。它在去仓库拿数据时只截取最近的 N 条比如只拿最近的 20 条完美控制上下文长度。新版正确配置代码CommonConfiguration.javaBeanpublicChatMemorychatMemory(){// 1. 创建底层存储仓库InMemoryChatMemoryRepositoryrepositorynewInMemoryChatMemoryRepository();// 2. 创建滑动窗口记忆管理器设置最大保留 20 条消息防爆栈returnMessageWindowChatMemory.builder().chatMemoryRepository(repository).maxMessages(20).build();}坑位二拦截器 new 不出来了Builder 模式的强推当你把配好的chatMemory准备塞进拦截器Advisor时很多同学会习惯性地写new MessageChatMemoryAdvisor(chatMemory)。结果编译器无情报错具有 private 访问权限。原因剖析官方把构造函数给锁死了。因为随着框架演进拦截器里能配置的参数越来越多比如单独设置拦截器的执行优先级order。为了代码的可维护性官方强推了Builder建造者模式。新版正确注入代码BeanpublicChatClientchatClient(ChatClient.Builderbuilder,ChatMemorychatMemory){returnbuilder.defaultSystem(你是一个可爱的智能助手...).defaultAdvisors(newSimpleLoggerAdvisor(),// 简单的拦截器目前还能 new// 关键修改放弃 new拥抱 builderMessageChatMemoryAdvisor.builder(chatMemory).build()).build();}小贴士以后在最新版 Spring AI 里看到xxxAdvisor报错 private第一反应就是去敲.builder(...)坑位三常量大搬家AbstractChatMemoryAdvisor 被彻底剿灭配置好了底层 Bean来到 Controller 层准备把前端传来的chatId会话 ID塞进请求上下文中。 以前大家都是这么写的.advisors(a - a.param(AbstractChatMemoryAdvisor.CHAT_MEMORY_CONVERSATION_ID_KEY, chatId))结果一编译又红了因为官方对底层的拦截器体系进行了一次大换血彻底废弃了抽象类基座AbstractClass转而拥抱接口Interface体系。那个又臭又长的常量不仅被搬了家还改了个清爽的名字现在它静静地躺在ChatMemory接口中。Controller 层的终极修复指南importorg.springframework.ai.chat.memory.ChatMemory;RequestMapping(value/chat)publicFluxStringchat(Stringprompt,StringchatId){returnchatClient.prompt().user(prompt)// 关键修改用 ChatMemory.CONVERSATION_ID 替换掉那个又长又臭的旧常量.advisors(a-a.param(ChatMemory.CONVERSATION_ID,chatId)).stream().content();}总结阵痛过后的架构跃升学习处于 Milestone里程碑测试阶段的前沿框架最折磨人的就是这种“昨天能跑今天报错”的破坏性更新Breaking Changes。但回看这三大重构职责分离拆分存储与滑动窗口避免 Token 爆炸。强制规范推行 Builder 模式提升扩展性。面向接口废弃庞杂的抽象类精简常量命名。每一个让人头疼的报错背后都是 Spring AI 向着企业级高可用架构迈出的坚实一步。踩平这些坑你的架构基础将变得极其扎实