做过大模型对话应用的人应该都遇到过这个尴尬场景用户问完上一句下一句发过来模型好像彻底失忆了一样。这不是模型笨是因为大模型本身没有“状态”每次调用都是独立的请求。要在自己的应用里做出连续对话、记住用户偏好、保持多轮上下文就必须在应用层把“记忆”这件事管起来。Spring AI Alibaba的Memory机制就是解决这个问题的。它做的事情听起来不复杂把对话历史按会话维度存起来在每次调用模型时自动带上这些历史消息让模型“看起来”记得之前聊过什么。但真正落地时怎么存、存多少、怎么清、怎么隔离不同用户里面有不少细节。这篇文章我把我实际折腾这套机制的过程、选型思路和踩过的坑完整写出来希望能帮你少走几步弯路。1. 为什么AI应用离不开Memory机制1.1 大模型的“失忆”本质先明确一个基本事实大模型API是无状态的。你发一段请求进去模型返回一段结果这个请求和上一个请求之间没有任何逻辑关联。如果你在做一个聊天机器人用户说“我叫小王”然后下一次问“我叫什么”模型根本不知道小王是谁。要破解这个问题最朴素的做法就是把历史对话原文拼到当前请求里一起发给模型。这也是目前绝大多数应用实际在用的方式。模型看到“之前用户说过自己叫小王”自然就能回答“你叫小王”。这种做法在工程上有一个专门的名字叫上下文组装Memory机制的核心工作就是自动完成这件事。它省去你在业务代码里手动维护List、手动拼Prompt、手动清理超长历史的麻烦把这块逻辑收敛成一个可复用的基础设施。1.2 无状态到有状态中间层说了算既然模型本身无状态那“状态”就只能放到应用层。Spring AI Alibaba提供的Memory机制本质上就是一个基于ChatMemory接口的中间层。它承担三件事存把对话消息按会话维度持久化或缓存起来取在每次请求前读取对应的历史消息组装把历史消息以合适的格式传给模型。这三件事听起来平淡但组合起来就能让一个原本无状态的模型调用链表现出“记忆力”。我在项目里最直观的感受是业务代码不用再关心消息存到哪、存在哪个key下、历史太长怎么截断。我只管传一个conversationId框架帮你把其他事做完。这非常符合Spring生态一贯的风格约定优于配置接口先行实现可替换。1.3 适合哪些场景Memory机制不是所有场景都必须用但下面这几类场景基本离不开多轮对话助手用户连续提问每个问题的回答都要参考前面几轮内容。客服机器人用户可能需要分多次描述问题系统需要把整段沟通过程串起来。角色扮演或个性化应用需要记住用户设定的名字、偏好、语气。Agent式应用在一次复杂任务执行中多个步骤之间需要共享中间结果。反过来如果你的场景只是单轮问答、每次输入完全独立那Memory机制反而会白白增加存储负担和token消耗。用不用、用多深取决于业务形态。2. Spring AI Alibaba Memory机制的核心概念2.1 ChatMemory接口与ChatMessage几乎所有Memory实现都围绕两个核心类型运转ChatMemory接口和ChatMessage消息模型。ChatMessage是这条链路上的“基本单位”。它至少包含两个关键信息消息角色和消息内容。角色就是user、assistant、system这类基础角色内容就是实际文本。可以把一条ChatMessage理解成对话记录里的一行日志。ChatMemory接口则定义了“怎么操作这些日志”的统一契约。我平时主要用到这几个方法add向指定会话追加消息。get读取指定会话的消息列表。clear清空指定会话的所有消息。这个接口设计有一个很聪明的点它不关心消息存到哪、用什么数据结构存只定义行为。所以你完全可以根据自身需求实现自己的ChatMemory也可以直接用框架内置的实现。业务代码面向接口编程底层实现随意切换。2.2 消息窗口策略如果只是存和取那Memory机制还不算难。难的是消息会无限增长。用户从早聊到晚消息历史可能几百轮。如果全塞给模型先不说费用问题很多模型对上下文长度有限制超出直接报错。所以必须有策略决定“到底带哪些历史消息给模型”。Spring AI Alibaba在这块提供了窗口策略。常见做法是固定保留最近N条消息比如只保留最近20条。这背后的逻辑很简单离当前时间越近的消息对下一步对话的影响越大远古时期的寒暄早就没有参考价值了。窗口策略实现时会遇到一个细节如果用户消息和助手消息各算一条那窗口到底按什么单位截断实际实现中一般按消息条数或token数来控制。按条数简单直观按token数更精准但需要额外计算。我在实际项目里优先用条数控制先把链路跑通等token成本压力大了再换token维度。2.3 观察者模式与智能清理在窗口策略之外Spring AI Alibaba的Memory还引入了类似观察者的思路。不是简单地按窗口一刀切而是让系统在组装上下文时“观察”当前的消息列表根据预设策略决定哪些消息应该被保留、哪些可以丢弃。这种设计的价值在于有些系统消息、工具调用结果、或某几轮特别关键的信息不该被简单的时间窗口淘汰。你可以自定义观察规则更精细地控制哪些内容必须留在记忆里。记得有一次做知识库问答用户先问一个背景概念再问一个与此强相关的细节问题中间隔了十几轮闲聊。如果只按最近20条窗口截断背景概念早就被挤出窗口了模型回答就成了无根之木。后来我用观察策略把“包含指定关键词的消息”设为重点保留对象问题才解决。这种场景下灵活的Memory策略比固定窗口实用得多。3. 实操在Spring AI Alibaba里配置和使用Memory3.1 依赖准备Memory机制是Spring AI Alibaba和Spring AI生态的一部分并不需要额外引入特殊的Memory专用依赖单独的Redis实现除外。在项目里正常引入相关依赖后就可以直接使用。我建议你从最简单的InMemoryChatMemory开始先把机制跑通再决定是否换持久化实现。dependency groupIdcom.alibaba.cloud.ai/groupId artifactIdspring-ai-alibaba-starter/artifactId /dependency如果是Spring Boot项目配合自动配置就能把核心组件注入容器不用自己手工new一大堆对象。3.2 最简实现用InMemoryChatMemory跑通流程InMemoryChatMemory是最简单的ChatMemory实现消息直接存放在JVM内存里。适合开发调试、单机部署、非关键数据场景。Component public class AppConfig { Bean public ChatMemory chatMemory() { return new InMemoryChatMemory(); } Bean public ChatClient chatClient(ChatModel chatModel, ChatMemory chatMemory) { return ChatClient.builder(chatModel) .defaultAdvisors(new MessageChatMemoryAdvisor(chatMemory)) .build(); } }这里核心动作是MessageChatMemoryAdvisor。它像一个拦截器在每次调用模型前自动从ChatMemory里按会话ID取出历史消息拼接到当前请求中模型返回后再把新消息存回ChatMemory。使用时的代码非常直观String answer chatClient.prompt() .user(我的名字是小王记住了吗) .advisors(spec - spec.param(conversationId, user-001)) .call() .content(); String answer2 chatClient.prompt() .user(我叫什么名字) .advisors(spec - spec.param(conversationId, user-001)) .call() .content();第二次提问时因为带了相同的conversationId系统能查到之前“我叫小王”的记录模型就能正确回答出“你叫小王”。如果第二次提问时换一个conversationId比如user-002那么系统查不到任何历史消息模型就会诚实地说“我不知道”。这就是会话隔离的直观体现。3.3 配置消息窗口大小默认情况下所有历史消息都会被保留并发送。但真实环境不合适所以需要配置窗口大小。窗口大小可以在构建时设置也可以根据业务调整。一个常见的做法是让MessageChatMemoryAdvisor关心消息数量上限。比如设定单个会话最多保留20条消息Bean public ChatMemory chatMemory() { return MessageWindowChatMemory.builder() .chatMemoryStore(new InMemoryChatMemory()) .maxMessages(20) .build(); }这个实现内部会自动维护窗口逻辑新消息进入时总数量超过20条就把最旧的多余消息丢弃。用起来不需要业务代码感知历史消息列表始终不会超过上限。这里有一个重要提醒窗口大小要结合模型上下文限制来定。如果业务场景里每条消息平均几百字20条消息已经接近1万token再叠加每次调用都要包含系统Prompt、用户问题很容易撞到模型上下文上限。建议根据实际模型、实际消息长度做测算不要盲目贪大。3.4 持久化到Redis多实例共享记忆单机内存存储适合调试但如果应用部署了多个实例或者需要重启后保留对话记录就必须使用持久化存储。Spring AI Alibaba生态里可以使用RedisChatMemory或基于Redis的自定义实现。核心思路是把ChatMessage列表序列化后存到指定key下。配置Redis实现的思路是这样Configuration public class MemoryConfig { Bean public ChatMemory redisChatMemory(RedisTemplateString, Object redisTemplate) { return new RedisChatMemory(redisTemplate); } }这里的关键点是RedisTemplate的序列化方式。我踩过的一个坑是如果RedisTemplate默认使用JDK序列化存进去的消息列表在反序列化时可能因为类型信息缺失而失败。建议显式配置JSON序列化并指定信任的消息类型。Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory factory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(factory); template.setKeySerializer(new StringRedisSerializer()); GenericJackson2JsonRedisSerializer serializer new GenericJackson2JsonRedisSerializer(); template.setValueSerializer(serializer); template.setHashValueSerializer(serializer); return template; }用Redis的好处很明确多个应用实例共享同一份记忆某次请求无论落到哪个实例上都能拿到完整的会话上下文。而且Redis天然支持过期时间可以给对话记忆设置TTL比如用户会话3天没活跃就自动清除防止key无限堆积。这是内存实现做不到的运维优势。3.5 自定义存储后端如果Redis不合适比如团队想用数据库或对象存储也没必要硬套框架自带实现。ChatMemory接口本身就是SPI实现自己的ChatMemory非常顺手。简单实现一个基于数据库的存储时核心就是转成业务表的读写Component public class DatabaseChatMemory implements ChatMemory { private final MessageRecordMapper messageRecordMapper; public DatabaseChatMemory(MessageRecordMapper messageRecordMapper) { this.messageRecordMapper messageRecordMapper; } Override public void add(Object conversationId, ListMessage messages) { // 循环插入数据库记录conversationId作为业务键 } Override public ListMessage get(Object conversationId) { // 按会话ID查询记录按时间排序返回 } Override public void clear(Object conversationId) { // 删除该会话的所有记录 } }自己实现的好处是存储自由、查询可控尤其当需要做记忆导出、数据分析时数据库的优势就出来了。但代价是你要自己处理好消息排序、序列化、事务等问题。如果只是想把机制跑起来优先用框架自带实现。4. 多用户会话隔离与上下文扩展4.1 conversationId的正确用法Memory机制里最关键的一个参数就是conversationId。它的作用相当于抽屉标签哪个会话用哪个抽屉互不干扰。很多新手犯的错误是不传conversationId或者所有人共用同一个id。结果就是用户A的消息被用户B看到整个对话上下文乱成一片。我在实际项目中的经验是conversationId应该来自业务层不能用模型消息内容来生成也不能在每次请求时随机生成。常见的做法是登录用户直接用用户ID或“用户ID会话场景”组合。匿名用户首次访问生成一个UUID返回给前端后续请求带上。多会话场景用“用户ID会话ID”保证一个用户可以有多个独立会话。伪代码示例String conversationId userId : sessionId; String answer chatClient.prompt() .user(question) .advisors(spec - spec.param(conversationId, conversationId)) .call() .content();这样既保证了用户之间隔离也保证了同一用户不同会话之间互不串场。4.2 隔离维度设计隔离不只是“用户ID隔离”还要考虑业务维度的隔离。举个例子一个客服系统里用户和客服在同一个界面对话但背后可能关联了多个订单。如果所有关于订单的问题都混在同一个conversationId里模型很容易把订单A的消息和订单B的消息混淆。更好的做法是“用户ID订单ID”作为会话维度每个订单单独一个上下文。这种方式在实现上成本很低只是conversationId拼接规则不同而已但效果非常明显。我在做某跨渠道服务系统时通过把隔离维度细化直接把上下文串扰问题解决了不需要改动任何存储逻辑。4.3 SystemPrompt与记忆的配合Memory机制里除了用户消息和助手消息SystemMessage也是一个需要重点关注的类型。SystemMessage通常用来设定模型的角色和行为准则。这部分消息不应该被窗口策略随意淘汰。如果窗口只有20条消息而SystemPrompt占了3条那么当消息滚动到20条时最早的用户消息被挤掉但SystemPrompt如果也被挤掉模型可能会“忘记”自己应该扮演的角色。建议把SystemPrompt通过ChatClient的defaultSystem配置而不是塞进对话历史。这样SystemPrompt每次都在不受窗口策略影响ChatClient chatClient ChatClient.builder(chatModel) .defaultSystem(你是一名耐心的客服助理总是用简洁清晰的中文回答用户问题。) .defaultAdvisors(new MessageChatMemoryAdvisor(chatMemory)) .build();实战中这样配置后窗口策略只管对话轮次系统设定永远稳固不会因为消息滚动而丢失。这是一个低成本高收益的细节调整。5. 常见问题与排查实录5.1 记忆好像没生效模型还是“失忆”这是最常遇到的现象。排查顺序建议从简到繁先确认MessageChatMemoryAdvisor有没有加没有它Memory机制根本不会参与调用链。再确认每次请求是否带了相同的conversationId。最常见的就是业务代码里每次生成新ID历史消息永远查不到。然后确认ChatMemory里确实存储了消息。可以在代码里打日志调用get方法看看返回列表是否为空。最后确认是否被窗口策略截断。如果消息总量超过了maxMessages最旧的消息会被删除模型当然看不到更早的上下文。大部分“失忆”问题查完上面四步都能找到原因。我见过一个项目把conversationId写成了随机数查了很久才发现是这问题非常考验细心程度。5.2 内存占用持续增长使用InMemoryChatMemory时消息全部存在JVM堆内存里如果会话多、消息多、长期不清内存迟早出问题。这类问题的处理办法有几种给会话设置生命周期闲置一段时间后调用clear清除。换用Redis实现把消息挪到外部存储内存压力自然转移。通过异步任务定期清理历史会话数据。没有一劳永逸的方案要根据自己的会话量级评估。我个人的经验是如果同时在线会话超过几千内存存储就已经很危险尽早切换持久化存储是明智选择。5.3 Redis反序列化异常使用Redis存储时最常见的异常是反序列化失败报错信息往往是ClassCastException或JsonMappingException。这个问题的根源基本都在序列化器配置上。GenericJackson2JsonRedisSerializer需要在序列化时写入类型信息但如果RedisTemplate的序列化配置不一致存和取用的就不是同一套规则。排查方法也很直接看Redis里的value长什么样。如果是\xAC\xED开头的乱码说明走了JDK序列化如果是正常的JSON字符串说明序列化配置正常。不过需要注意的是GenericJackson2JsonRedisSerializer生成的JSON里会带class字段这也是它反序列化时能恢复具体类型的原因不要为了省空间把这个字段去掉去掉后大概率反序列化失败。5.4 Token费用超出预期Memory机制会持续累积消息每次调用模型都会带上所有历史消息token消耗会跟着上涨。我遇到过项目上线后token费用翻了几倍的情况主要就是历史消息全量发送导致的。控制方式有两个方向一是缩小窗口大小只保留最近N条二是引入摘要机制把长历史先压缩成摘要再用摘要参与后续对话。ChatMemory的观察策略可以帮上忙但摘要机制通常需要自己实现。思路是当消息积累到一定阈值时调用模型把前面若干轮对话总结成一段摘要然后清掉原始消息只保留摘要。这种方式适合对话特别长的场景成本控制效果明显但实现复杂度更高初期不建议优先考虑。6. 一些实测下来的选型心得说实话Memory机制本身不复杂但它牵扯到的工程问题多且杂。我在项目中用过的组合方式简单总结一下场景推荐方案理由本地开发调试InMemoryChatMemory无需外部依赖重启即清空方便验证逻辑单机部署、会话量小InMemoryChatMemory 定时清理部署简单性能好多实例部署、需要持久化RedisChatMemory共享存储天然适合水平扩展高合规、需要数据存档自定义数据库实现数据可控、可导出、可审计长对话、严格控制成本小窗口 摘要机制限制token增长保持上下文相关有一点必须提醒Memory机制不是越大越好窗口越大模型能利用的上下文越多但token成本和响应延迟都会上升。建议先按20条左右起步观察模型回答质量和成本再逐步调整。另外凡是涉及到用户数据的存储都要考虑合规和隐私。在实现自定义ChatMemory时可以把消息加密后存储或者设置更短的TTL。不要图省事把所有用户对话明文永久保存等真出了问题就已经晚了。7. 最后分享一个我在实际项目中总结的小技巧给对话记忆设置“软隔离”和“硬隔离”两层设计会是后期维护的福音。所谓“硬隔离”是把不同租户、不同用户的上下文严格装进不同的conversationId里互不触碰。所谓“软隔离”是在同一条conversationId下通过消息内容里的结构化字段区分不同业务子场景。这样做既能保证数据安全又能让同一用户的多轮复杂任务共享同一条上下文链模型不会因为业务子场景切换而彻底失去前文。这个做法我在一个同时支持多个子业务的对话系统里试过效果很好。系统只维护了一套Memory基础设施却能灵活支撑多种场景后续新增业务也不需要改底层代码。Memory机制是Spring AI Alibaba里很不起眼但极其关键的一环。它不像模型调用本身那么引人注目却直接决定你的应用“看起来聪不聪明”。把上面这些设计和坑都捋清楚你的对话应用才算真正有了可靠的记忆底座。