Spring AI会话记忆落地实践：从ChatMemory到多轮对话助手

做社区志愿助手这个项目，Day1 把 Spring AI 的接入和基础问答跑通了，当时还挺得意。结果 Day2 一上来就碰了个很现实的问题：AI 不记事。用户上午问过爱心食堂的开放时间，下午再问“那我想去帮厨该找谁”，它就跟失忆了一样，完全接不上话茬。这个问题的学名就是会话记忆，也就是让大模型在多次独立请求之间保留上下文。Spring AI 官方把这类能力封装成了 ChatMemory 和 Advisor 两套机制，用起来不算复杂，但里面坑不少，尤其是上下文怎么存、存多久、窗口开多大，每一处都直接影响体验和成本。这篇复盘就专门聊聊我在志愿助手项目里落地会话记忆的完整过程，包括方案选型、核心代码、参数取舍和几个典型问题，给正在用 Spring AI 做 Agent 或聊天机器人的朋友做个参考。

这个项目本身是给社区志愿者用的，场景很杂：有人问活动报名流程，有人查服务对象档案，还有社工想快速生成探访记录。共同点是对话都带有强烈的连续性，如果模型每次把用户当陌生人，那这个助手基本就废了。所以 Day2 的目标非常明确：让助手“记住”同一会话内聊过什么，并且能主动引用前文信息。适合来读这篇内容的朋友，大致是两类，一类是刚把 Spring AI 跑通、正准备加记忆功能的新手，另一类是已经在生产环境用了 ChatClient、想看看别人怎么处理窗口和持久化问题的开发者。下面进入正题，先把会话记忆的设计思路拆开讲清楚。

1. 为什么社区志愿助手绕不开会话记忆

1.1 用户场景决定了“失忆”不可接受

志愿者的日常咨询和普通聊天不一样，它不是一问一答就结束的。我拿项目里一个真实场景举例：有位阿姨在公众号里问“周末的社区义诊几点开始”，助手回答了“周六上午九点，在党群服务中心一楼”。过了十分钟她又问“那我需要带什么材料吗”，模型如果没有记忆，就会把上一句完全丢掉，重新回答一遍“请问您指的是什么活动”，阿姨大概率会觉得这系统是个智障。

这类多轮交互在所有社区服务场景里都是常态。活动报名往往要经过“查时间—确认地点—提交信息”三四个来回，探访记录整理更是需要用户分多次补充细节。也就是说，会话记忆不是一个可选项，而是这个助手能否真正产生价值的基础能力。没有记忆的 AI 助手，本质就是个带自然语言界面的搜索引擎，这跟项目的目标完全背离。

1.2 Spring AI 的请求-响应模型天然无状态

Spring AI 底层调用大模型 API 时，每次请求都是独立的 HTTP 调用，服务端并不会因为你是同一个用户就自动带上历史消息。这跟我们写 HTTP 接口是一样的，服务端无状态意味着可水平扩展，但也意味着所有上下文都得由应用层自己拼接。官方 ChatClient 接口在设计上把“构建 Prompt”和“调用模型”解耦了，Prompt 里 messages 列表就是模型能看到的所有内容，而会话记忆的核心工作，就是把历史消息按某种策略塞回这个 messages 列表里。

理解这一点特别关键。很多人一开始以为 Spring AI 有个开关能一键开启记忆，实际上没有。官方提供的是组件，不是魔法。底层逻辑是：你每次请求时，把适合的对话历史取出来，拼到当前用户消息前面，一起发给模型。会话记忆的所有实现，本质上都是在做这件事，只不过做得好不好、性能高不高、会不会爆 token，差别很大。

1.3 从 Day1 到 Day2 的能力演进

Day1 我搭的是一个无状态的 ChatClient，system prompt 里写死了一堆志愿服务的规则，用户问什么就答什么，互不干扰。功能跑通了，但测试时明显感觉不对劲，你说“帮我预约明天上午十点的场地”，它说“好的已预约”，你接着问“帮我改到下午三点”，它直接懵了，因为它不记得刚才约过。这种体验要是放出去给社区老人用，基本就是劝退。

Day2 加入会话记忆后，整个助手的交互质量上了一个台阶。用户不用每次都把前因后果重复一遍，模型能根据上下文理解指代、承接话题。更关键的是，这为后续做“志愿档案总结”“服务时长自动统计”这类复杂 agent 能力打了底。没有会话记忆，后面的工具调用、多轮任务拆解都是空谈。所以这一天的内容，其实是整个项目从“会说话”到“会聊天”的分水岭。

2. 方案选型：Spring AI 的 ChatMemory 与 Advisor

2.1 ChatMemory 接口和三种内置实现

Spring AI 官方抽象了一个 ChatMemory 接口，核心方法就两个：put 写入一段消息，get 按 conversationId 取出一段历史。接口本身非常简单，但官方在 starter 里已经内置了几种可用实现，我简单列一下：

MessageWindowChatMemory 是默认也不动脑子的选择，用起来非常省事。但它的局限也很明显：只保留最近 N 条消息，一旦超出窗口，早期信息就没了。VectorStore 看起来很美，但需要注意它召回的是“语义相似”的历史片段，不是严格按时间排序的完整对话，用在这种需要精准承接上下文的场景里，反而可能答非所问。所以我在志愿助手项目里最终选了 JdbcChatMemory 作为主方案，开发初期为了快，先用 MessageWindow 顶着，后面再切。

2.2 Advisor 机制：把记忆注入变成声明式配置

ChatMemory 本身只是存储，真正把历史消息拼进 Prompt 的工作由 Advisor 完成。Spring AI 里的 Advisor 概念可以理解为一种“请求拦截器”，在调用大模型之前，对 prompt 做加工。官方提供的 MessageChatMemoryAdvisor 就是这个用途，它负责从 ChatMemory 里按 conversationId 取历史消息，拼到当前消息前面，同时把当前这轮的用户消息和助手回复写回 ChatMemory。

用 Advisor 的好处是，你的业务代码不需要关心消息拼接的细节，只要在构建 ChatClient 时声明一个 defaultAdvisor，剩下的框架全给你干了。这非常贴合 Spring Boot 的开发习惯，配置优先，约定大于配置。我当时第一版是自己手动拼 history 再调 prompt，后来发现多会话并发的时候拼接逻辑容易写乱，改用 Advisor 之后代码干净了不止一星半点。

2.3 为什么要选 Spring AI Alibaba 的增强实现

项目热词里出现了 Spring AI Alibaba，我额外多说一嘴。社区志愿助手如果想接国内大模型，DashScope（通义千问）是个很自然的选择，而 spring-ai-alibaba 这个项目把这层封装做得比较到位。它同样实现了 ChatMemory 和 Advisor，但针对 DashScope 的返回格式、token 计费方式做了适配，尤其是它支持 DashScope 服务端的一些记忆扩展能力，跟原生 Spring AI 的 API 基本兼容。

我个人的建议是：如果你的项目确定要跑在国内云上，直接走 spring-ai-alibaba 的 starter，代码结构跟你用原生 Spring AI 几乎一样，但省去不少兼容性调试。我项目里为了稳妥，先按原生 Spring AI 接口写好业务代码，再用 alibaba 的包替换底层实现，迁移时没有遇到大问题。这块后面实操部分会体现出来。

3. 核心细节：窗口大小、会话 ID 与 Token 预算

3.1 MessageWindow 的 windowSize 到底设多大

很多教程会直接让你把 windowSize 设成 20、50，但闭眼设数字一定会踩坑。窗口大小的核心约束不是“够不够用”，而是“模型上下文窗口减去 system prompt 和当前问题后还剩多少”。一份带志愿者规则的 system prompt 大概消耗 500~800 token，用户的问题假设 100 token，模型回答预留 500 token，如果模型上下文是 8k token，那留给历史消息的空间大约是 6k token。中文会话平均每条消息（用户+助手）大概 200~300 token，算下来 20 到 30 条比较合适。

我一开始把 windowSize 调成 50，结果请求量一大，总是报 context length exceeded，一查日志才发现历史消息加系统提示已经超出上下文限制了。后来改成 20，并且必须把 system prompt 精简，体验反而更稳定。个人习惯是先做一次真实对话，数一下平均 token 消耗，再倒推窗口大小，别拍脑袋。

3.2 conversationId 怎么生成与管理

会话记忆的存取都靠 conversationId 这个钥匙。在社区志愿助手场景里，用户通过公众号或小程序进来，一个用户可能发起多个会话，所以不能简单用 userId 当 conversationId。我这边是每次对话开始时生成一个 UUID 作为 sessionId，存在前端，之后每次请求都带上。如果用户在 30 分钟内没有新消息，就新开一个会话；如果有连续交互，就沿用旧 id。

这里有个细节容易忽略：MessageChatMemoryAdvisor 获取 conversationId 的方式是从请求参数里取，参数名默认是 conversationId。如果你走 HTTP 接口，得确保每次请求的入参里都有这个字段，不然 Advisor 会直接抛异常。我一开始没注意，前端没传这个 id，结果接口一直 500，排查了半天才发现是这里。后来我在 Controller 层加了个兜底：如果前端没传 conversationId，就用 userId + 当天日期生成一个，保证不崩。

3.3 Token 成本与响应速度的平衡

会话记忆本质上是在用 token 换上下文。历史消息拼得越多，模型理解越准，但每次调用的成本也越高，响应时间越长。社区志愿助手这种场景，用户对响应速度比较敏感，等三五秒还能忍，超过十秒就有点劝退。我实测下来，当历史消息在 20 条以内时，通义千问的响应时间基本稳定在 2~3 秒；一旦超过 40 条，响应时间会明显上涨到 5 秒以上，而且费用肉眼可见地增加。

所以生产环境不能只依赖窗口大小，还应该叠加一个摘要策略。简单说就是：保留最近 N 条完整消息，对于更早的对话，每隔几轮让模型生成一段摘要，把摘要也放回记忆里。Spring AI 有 PromptTemplate 可以做这件事，但官方没有一键集成的组件，需要自己写一个定时压缩的 advisor。这个我放在第四部分展开讲，因为它是从 demo 走向生产的必经一步。

4. 实操落地：在志愿助手里接入会话记忆

4.1 引入依赖与基础配置

我用的环境是 Spring Boot 3.3.x + Spring AI 1.0.0 GA，数据库是 PostgreSQL。为了能跑通流程，我同时引入了 spring-ai-starter-model-dashscope 和 spring-ai-starter-memory-jdbc 两个依赖。如果你直接用 OpenAI 的话，把 dashscope 的依赖换成 openai 的 starter 就行，其他逻辑没有区别。

<dependency> <groupId>com.alibaba.cloud.ai</groupId> <artifactId>spring-ai-alibaba-starter</artifactId> <version>1.0.0-M6.1</version> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-memory-jdbc</artifactId> <version>1.0.0</version> </dependency>

配置文件的重点是开启 jdbc memory 的建表能力，以及设定默认的参数：

spring.ai.chat.memory.enabled=true spring.ai.chat.memory.conversation-id=conversationId spring.ai.chat.memory.window-size=20 spring.ai.datasource.url=jdbc:postgresql://localhost:5432/volunteer spring.ai.datasource.username=postgres spring.ai.datasource.password=yourpassword

注意 spring-ai-alibaba 的版本号要跟 Spring Boot 版本匹配，我一开始用了旧版本，跟 Spring Boot 3.3 的自动配置冲突，直接起不来。这块要养成看官方 release notes 的习惯。

4.2 配置 ChatMemory 的 Bean

官方 starter 会自动装配一个 JdbcChatMemory，如果对默认配置不满意，也可以自己定义 Bean 覆盖。我这边为了能打印日志观察历史消息内容，选择手动定义了一个 MessageWindowChatMemory 先做本地验证，后面再替换成 Jdbc 版本：

@Configuration public class ChatMemoryConfig { @Bean public ChatMemory chatMemory() { return MessageWindowChatMemory.builder() .maxMessages(20) .build(); } }

如果切到 JdbcChatMemory，则不需要手动创建 Bean，直接在配置里指定数据源即可。JdbcChatMemory 会自动创建 ai_chat_memory 表，每次 put 的时候往表里插记录，get 的时候按 conversationId 查最近 N 条。需要注意的是，这个表的索引一定要建立在 conversationId 上，数据量大了之后，不带索引的查询会非常慢。我项目上线第一天数据量小没感觉，第二天一压测就暴露了，后来手动补了索引才解决。

4.3 用 Advisor 构建带记忆的 ChatClient

这是整个落地过程的核心代码。我用 ChatClient.Builder 构建客户端时，加了一个 MessageChatMemoryAdvisor：

@Configuration public class ChatClientConfig { private final ChatMemory chatMemory; public ChatClientConfig(ChatMemory chatMemory) { this.chatMemory = chatMemory; } @Bean public ChatClient chatClient(ChatClient.Builder builder) { return builder .defaultSystem(""" 你是社区志愿助手的智能助理，负责回答志愿者关于活动报名、服务记录、探访安排等问题。 请保持回答简洁、有温度。如果用户提到之前聊过的话题，请主动结合上下文回答。 """) .defaultAdvisors(new MessageChatMemoryAdvisor(chatMemory)) .build(); } }

然后在 Controller 里直接调用：

@RestController @RequestMapping("/api/chat") public class VolunteerChatController { private final ChatClient chatClient; public VolunteerChatController(ChatClient chatClient) { this.chatClient = chatClient; } @PostMapping public Map<String, String> chat(@RequestBody ChatRequest request) { String reply = chatClient.prompt() .user(request.message()) .adults(a -> a.param("conversationId", request.conversationId())) .call() .content(); return Map.of("reply", reply); } }

这里的一个关键点是：conversationId 必须通过 param 传给 advisor，否则 advisor 不知道从哪个会话取历史。我最初以为直接放到 user message 里就行，结果发现 advisor 读的是 param，不是 message。这个坑卡了我将近一个小时，希望能帮后面的人少走弯路。

4.4 验证记忆是否生效的测试方法

写完代码先别急着接前端，我习惯用 curl 直接验证。第一次请求传入 conversationId=test-001，问“今天社区义诊几点开始”，第二次请求传同一个 id，问“那地点在哪”，如果第二次回答里包含“义诊”或第一次对话的信息，说明记忆生效了。

curl -X POST http://localhost:8080/api/chat \ -H "Content-Type: application/json" \ -d '{"conversationId":"test-001","message":"今天社区义诊几点开始"}'

curl -X POST http://localhost:8080/api/chat \ -H "Content-Type: application/json" \ -d '{"conversationId":"test-001","message":"那地点在哪"}'

如果第二条回复直接说“请问您指的是什么活动”，那就说明历史消息没有拼进去。这时候优先检查两件事：一是 ChatMemory 表里有没有写入记录，二是 advisor 有没有正确拿到 conversationId 参数。我用这种二分法排查，基本能在五分钟内定位问题。

4.5 把内存版切换成 JDBC 持久化版

验证完内存版没问题，我再把 ChatMemory 的 Bean 注释掉，依赖自动装配的 JdbcChatMemory。切换后重启应用，第一次请求时框架会自动创建表结构，然后一切照常。这一步看似简单，但要注意一个坑：JdbcChatMemory 存储的消息是按 JSON 序列化存到数据库的，如果你的 model 返回的消息类型跟序列化工具不兼容，会出现读出来是空的情况。我用的默认 Jackson 没遇到问题，但如果换了 fastjson 之类的工具，需要额外配一下序列化器。

切换持久化之后，多实例部署就顺理成章了。所有实例共用同一个数据库，conversationId 对应的历史消息存在表里，任何一台机器处理同一个会话都能读到完整上下文。对于社区志愿助手这种低并发但要求可靠的服务，这个方案足够用，而且比 Redis 少维护一个中间件。

5. 踩坑记录：窗口溢出、并发写入与上下文丢失

5.1 token 超限问题的排查思路

把会话记忆接上之后，我做的第一轮压力测试就爆了。问题表现是：连续对话超过二十轮之后，接口开始报错，日志里出现“maximum context length exceeded”之类的提示。前面也说过，这本质是历史消息 + system prompt + 当前消息的总 token 数超过了模型上限。排查方法是先看日志里实际发送的 prompt 长度，再看模型上下文上限，算一下差多少，最后把 windowSize 调小到安全范围。

另外还有一种隐蔽情况：助手的回复本身特别长，如果把每次回复都原封不动存进记忆，很快就把窗口填满了。我后来在写入记忆之前，对助手的回答做了一个简单处理，超过 500 字就截断或要求模型压缩后再写进去。这个属于经验优化，但效果非常明显，同样的 windowSize 能支撑的对话轮数几乎翻倍。

5.2 并发场景下的消息写入顺序问题

社区志愿助手虽然并发量不大，但同一个用户如果连发两条消息，后端可能同时处理两个请求。这两个请求同时读取 ChatMemory，拿到的是相同的历史，然后又同时写入，导致后写的覆盖先写的，出现上下文丢失。这个问题在 MessageWindowChatMemory 里尤其明显，因为它是纯内存操作，没有锁。

我要处理这个问题，最直接的手段是给同一个 conversationId 的请求加分布式锁，或者至少加 JVM 内锁。实现上我没有引入 Redisson，而是简单地在服务里加了 ConcurrentHashMap 的锁对象：

private final Map<String, Object> locks = new ConcurrentHashMap<>(); private Object getLock(String conversationId) { return locks.computeIfAbsent(conversationId, k -> new Object()); }

处理完用户的请求之后，再同步 put 消息。对志愿助手这个体量的项目来说，这个方案够用，但如果未来做高并发，还是要上 Redisson 或者把写入改成队列串行化。

5.3 模型“忘记”早期信息的替代方案

滑动窗口最大的毛病就是冷启动问题：新会话说得好好的，一旦窗口滚动，早期关键信息（比如用户已经报过名、已经留过电话号码）就没了，模型会重复询问已经提供过的信息。这在社区场景里特别尴尬，老人会觉得“我不是刚说过吗，你怎么还问”。

我后来的应对方式是引入摘要记忆。具体做法是：每一轮对话结束后，如果历史消息超过了窗口的一半，我会用一个小模型调用 PromptTemplate 把之前的对话总结成三到五条要点，连同最近的消息一起放回 Memory。这个功能官方没有直接给，但自己实现并不复杂，本质就是多一次模型调用，把摘要文本 prepend 到 prompt 里。

public String summarize(List<Message> history) { PromptTemplate template = new PromptTemplate(""" 请用简洁的中文总结以下对话的关键信息，包括用户的需求、已经确认的事项、待办事项。输出不超过200字。 {history} """); return chatClient.prompt() .user(template.create(Map.of("history", history)).getContents()) .call() .content(); }

实测下来，加了摘要之后，连续对话超过 50 轮，模型依然能记住“用户已预约周一上午九点探访独居老人”这样的关键信息。虽然多了一次 token 调用，但换来的体验提升非常值得。这算是会话记忆从“能用”走向“好用”的关键一步。

5.4 多轮工具调用时的记忆联动

项目后续接了工具调用（日历查询、场地预约），这时会话记忆的意义就更大了。比如用户让助手查一下“周五下午有没有空闲活动室”，助手调用工具查到结果后，这个结果会作为 assistant 消息存进记忆。用户接着问“那就订这间吧”，模型需要结合之前工具返回的“房间号 A302”才能完成预约。

这里有个 Spring AI 的细节：工具调用的中间过程，也就是 function call 和 function result，都会以消息形式进入 ChatMemory，但它们的内容可能很长。我建议对这个类型的消息做裁剪，只保留工具名、关键参数和返回值摘要，避免工具返回的一大坨 JSON 撑爆窗口。实测中，一个复杂的场地查询接口能返回 2000 多字 JSON，不加处理的话，两三次工具调用就够了。

6. 复盘总结与后续优化思路

6.1 本次迭代的关键成果

Day2 结束时，志愿助手已经具备了一个可用的会话记忆能力。用户连续咨询活动信息时，助手能准确承接上下文；多实例部署时，会话状态通过数据库共享；窗口大小经过压测调整，在成本和体验之间找到了平衡点。我把这些改动提交到代码库后，给几位同事做了演示，大家最直观的感受就是“它像在认真听你说话了”。

6.2 尚未解决的问题与下一步计划

会话记忆目前的形态还是“短时记忆”，只保证同一对话内的连续性。真正意义上的长期记忆，比如记住这个用户是位经常参与探访活动的退休教师、偏好周六上午服务，这种跨会话的画像记忆还没有引入。Spring AI 提供了 VectorStoreChatMemory 和相关的向量化能力，理论上可以做到“用户画像记忆”，这部分我准备放到后续的 Day3 版本里做。

另外，JdbcChatMemory 的存储结构是 key-value 式的，会话数据量大了以后，查询性能和存储成本会成为问题。到时候可能需要把归档的旧会话定期导出，或者切到专业的向量数据库。这些属于运维层面的优化，需要根据项目规模再具体评估。

6.3 给同样在做 Spring AI 项目的人几点建议

如果你正在做类似的项目，我的建议是不要一上来就追求复杂的记忆策略。先把 MessageWindowChatMemory 跑通，用真实业务场景验证交互效果，再逐步叠加摘要、向量检索和工具联动。会话记忆的核心在于理解你的用户到底需要记住什么，而不是把技术栈堆得越高越好。另外，conversationId 的规范要提前定好，别等到多端接入的时候再改，那会牵连到前端、网关、埋点好几个地方。

我自己实测下来，Spring AI 的会话记忆这个方向，官方文档其实写得比较精简，很多细节需要靠实战去踩。像 advisor 的 param 传递、JDBC memory 的建表时机、并发写入的顺序问题，都是文档里不会明确写但实际必踩的坑。希望这篇复盘能帮你少走几步弯路，也欢迎有类似经验的朋友一起交流。