给AI Agent装上记忆：对话记忆、长期记忆、向量记忆

记忆就是历史消息拼回去。模型本身没有记住这件事——你每轮把前几轮的对话塞进提示词它才接得上话塞哪几条、怎么塞全是应用层的活。Spring AI把这层活包成了Advisor模式对话窗口滑过去存哪儿、取几条、拼到哪都抽象好了你负责选组合。客服机器人群里甩来一段聊天记录用户说查下刚才那个单机器人回请问您要查询哪一单呢用户把订单号又发了一遍三轮之后用户问那它昨天为啥扣我运费机器人回请提供您要咨询的订单号。第三遍。用户没骂人就回了个算了转人工吧。机器人不笨——查订单的工具上一篇就装好了它输在记性上。ChatClient每次请求都是无状态的模型只认当下那几条消息三轮之前你说过什么它一概不知。这一篇就给它装上记忆对话记忆管刚才说什么长期记忆管重启了还能接着聊向量记忆管百轮对话里拎出相关那几条。代码照旧直接抄版本号标到 Spring AI 1.1。病根模型无状态记忆是你喂给它的说白了记忆就是历史消息拼回去。模型本身没有记住这件事——你每轮把前几轮的对话塞进提示词它才接得上话塞哪几条、怎么塞全是应用层的活。Spring AI把这层活包成了Advisor模式对话窗口滑过去存哪儿、取几条、拼到哪都抽象好了你负责选组合。三层记忆分工对话记忆是短期工作区一个会话内窗口滑动塞得下就带塞不下就忘长期记忆是保险箱数据库落盘应用重启不掉向量记忆是搜索索引百轮对话里按语义检索相关片段塞进上下文让模型想起来。三套不是替代关系是叠加关系对话窗口保当下向量库保相关数据库保不死。对话记忆一个窗口二十条消息Spring AI 1.1 里就三件套ChatMemory存历史MessageChatMemoryAdvisor负责往请求里拼CONVERSATION_ID区分会话ChatMemory chatMemory MessageWindowChatMemory.builder() .maxMessages(20) // 窗口大小20条消息≈4000 token够聊又不撑爆上下文 .build(); ChatClient chatClient ChatClient.builder(chatModel) .defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build()) .build(); // 调用时带上会话ID——别偷懒用全局默认值那是P0事故的温床 String answer chatClient.prompt() .user(q) .advisors(a - a.param(ChatMemory.CONVERSATION_ID, sessionId)) .call() .content();maxMessages(20)是窗口对话超过20条就从头滑出去——这叫遗忘不是缺点是设计上下文有限全记着迟早爆。我第一次上线时窗口开到50聊到第七轮模型开始胡乱接话token账单也跟着涨后来砍回20才稳住。上线一周用户重复自报手机号从平均每通2.4次降到0.3次——记性这件事用户是感知得到的。窗口有两道上限条数上限maxMessages和token上限。DeepSeek上下文64K窗口20条约4K还能给工具结果和系统提示词留空间。别贪大上下文塞满第一个受伤的是响应速度——模型推理时间随输入token涨。插段题外话。去年我接手过一个老客服系统会话状态搁在Redis里没设过期运维一次扩容误操作把整个Redis清了当天下午全平台的机器人集体失忆用户排着队重新自我介绍投诉工单堆了三十多张。会议室里复盘我盯着白板直懵一个对话窗口的事愣是酿成了故障。打那以后我的习惯是记忆相关的存储全带上持久化和降级开关。扯远了回到长期记忆。长期记忆重启不能丢窗口在内存里应用重启就清空。对客服场景问题不大——用户挂了电话会话也该清了但有种场景不行用户聊到一半去吃饭两小时回来接着问中间你发了版本内存里的窗口没了。JDBC存储把对话落到数据库重启不丢# pom.xml 加 spring-ai-starter-model-chat-memory-repository-jdbc spring: ai: chat: memory: repository: jdbc: initialize-schema: true # 自动建表 spring_ai_chat_memoryJdbcChatMemoryRepository jdbcRepo new JdbcChatMemoryRepository(jdbcTemplate); ChatMemory chatMemory MessageWindowChatMemory.builder() .chatMemoryRepository(jdbcRepo) .maxMessages(20) .build();JDBC存储的是整段对话取的时候按会话ID拉回来再截窗口。存的是明文敏感信息手机号、身份证别直接落库后面第三颗螺丝专门讲合规。我觉得这块跟配置中心别把密码明文推git是同一类事故——技术上都简单但真有人踩。向量记忆记不住全量就记住相关的窗口20条向量记忆解决的是该记的没在窗口里用户第3轮说过自己是VIP第15轮问会员权益窗口早滑过了模型忘了。RAG是用在知识库上的检索换到对话历史上就是向量记忆。实现跟03篇的知识库一脉相承对话双方各说一句存成Document字段里带sessionId检索时按当前问题语义找相关片段筛出本会话的塞进系统提示词。十几行就够还不用追Advisor的API变动Service public class VectorMemoryService { private final VectorStore vectorStore; // 复用03篇的pgvector public VectorMemoryService(VectorStore vectorStore) { this.vectorStore vectorStore; } /** 记一问一答存成带会话标签的Document */ public void remember(String sessionId, String q, String a) { vectorStore.add(List.of(new Document( 用户问 q \n答 a, Map.of(sessionId, sessionId, type, memory)))); } /** 取按当前问题语义检索相关历史只要本会话的 */ public String recall(String sessionId, String q) { ListDocument hits vectorStore.similaritySearch( SearchRequest.builder() .query(q) .topK(3) .similarityThreshold(0.5) .filterExpression(sessionId sessionId type memory) .build()); return hits.stream() .map(Document::getText) .collect(Collectors.joining(\n---\n)); } }取出来的是你可能说过这些话不是全量是相关的。写入时机有讲究不是每轮都写——闲聊别记记下来的都是身份信息、偏好、结论这类下次有用的。我琢磨过要不要把所有对话都向量存一份后来发现纯聊天的存进去既占向量库又占token还不如开个规则只有涉及用户信息/业务结论的才写写入前用小模型筛一下。记忆三层速查记忆存哪活多久怎么取对话记忆内存窗口一个会话整窗塞进上下文长期记忆PostgreSQLJDBC永久按会话ID整段取向量记忆pgvector永久按语义检索topK拼起来会干活还记事的最小AgentAgent这词听着玄拆开就三样模型做推理、工具做行动、记忆做上下文。循环是框架替你跑的模型说要调工具→执行→结果喂回→直到模型交卷——ReAct就是推理Reason→行动Act→观察Observe名字吓人流程朴素。带上工具和记忆完整的一个Agent长这样ChatClient agent ChatClient.builder(chatModel) .defaultAdvisors(MessageChatMemoryAdvisor.builder(chatMemory).build()) .build(); String answer agent.prompt() .system(sys) .user(q) .tools(orderTools, kbTools) // 05的手 .advisors(a - a.param(ChatMemory.CONVERSATION_ID, sessionId)) // 本篇的记性 .call() .content();tools()挂上查订单、查知识库advisors()挂上对话窗口向量记忆的片段可以拼进.system()或单独拼进.user()前缀。到了这一步你的聊天机器人就不再是金鱼记忆工具让它会干活记忆让它记得住事。生产上要拧的三颗螺丝第一颗会话隔离。CONVERSATION_ID的生成规则要严谨用户ID设备ID或者自建会话ID存库里。我见过把conversationId写死成default的上线一周用户就开始串门——张三的订单李四能查到真出事故。隔离是底线别省。第二颗记什么。窗口滑动是自动遗忘向量记忆要主动写。别什么都写用户聊天气、吐槽同事这些闲聊不用向量存写入前做个判断或者用小模型筛一次。全部录音式存储既占向量库又容易把敏感信息留在库里删都删不干净。第三颗合规删除。用户要求删除我的所有数据你得能删干净按sessionId清对话窗口chatMemory.clear(sessionId)、清JDBC存储、清向量库vectorStore.delete(sessionId sessionId )。聊出来的手机号、身份证是个人信息落库要脱敏删除要能一键清。我第一次做这块时漏了向量库用户注销后向量里还留着TA的偏好后来复盘才发现真冒冷汗。面试官会怎么问Q1Agent和普通LLM调用有什么区别三样模型负责推理工具负责行动记忆负责上下文。ReAct是推理-行动-观察的循环模型自己决定下一步——是回答还是调工具。普通的ChatClient只有推理Agent把工具和记忆叠上去。Q2对话记忆怎么实现API无状态记忆是应用层拼的。Spring AI用ChatMemory存历史MessageChatMemoryAdvisor往请求里塞窗口滑出去就遗忘。关键是会话隔离conversationId别乱来。Q3向量记忆和RAG是什么关系同一套技术换数据源。RAG检索的是知识库文档向量记忆检索的是对话历史。实现上就是03篇的pgvector换个Collection或元数据过滤条件。回头看这一篇把前面所有能力拧成了一体工具参数是结构化输出02工具执行靠Function Calling05向量记忆复用知识库的pgvector03、04——能力是叠加的不是替换的。带走三样窗口别贪大20条够用会话隔离是底线conversationId要有生成规则向量记忆写前筛别把闲聊和敏感信息都存进去。记忆不是模型的器官是你替它管的笔记本。Agent能跑了接下来该管管钱袋子——挂上记忆后每轮都背着历史跑token账单跟着轮数涨。下一篇AI网关多模型路由与Token成本管控。最后我们整理出这套 AI 大模型 突围资料包✅ 从零到一的 AI 学习路径图✅ 大模型调优实战手册附医疗/金融等大厂真实案例✅ 百度/阿里专家闭门录播课✅ 大模型当下最新行业报告✅ 真实大厂面试真题✅ 2025 最新岗位需求图谱所有资料 ⚡️ 朋友们如果有需要 《 AI大模型 入门进阶学习资源包》下方扫码获取~资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。需要这份AI大模型资料清单的话在评论区回复「清单」即可我会根据大家的问题继续补充对应的实战内容。