## 01、痛点

上周一个同事拿着日志来找我，说知识问答服务上线后用户总投诉它像金鱼，只有七秒记忆。我翻了一下真实请求，第一条问“Spring AI 是什么”，返回了正常定义；第二条问“它支持哪些向量库”，服务居然开始介绍 Spring AI 支持哪些数据库连接，完全没理解“它”指代什么。我是老李。这个问题其实不是模型能力不行，而是我们把大模型接口当成了有状态服务在用。LLM API 天生接近无状态。每次请求都是一次全新对话，服务端不会替你记住上一句。模型看到的只有当前输入；如果应用不把历史上下文传过去，它当然不知道“它”是什么。多轮对话的连续感，必须由应用自己管理。这跟传统后端把会话塞进 HttpSession 不一样。以前我们总觉得模型会“理解”上下文，其实它只是每次根据传入的完整消息序列做预测。上下文没传，它就失忆。知识助手尤其典型：用户先问概念，再问能力、向量库、配置，后面全是代词和省略。没有记忆，问答就断片。现在为什么讲这个？因为 Spring AI 这类框架已经把会话记忆做成了基础组件，但很多人只看到“加个 Advisor 就有了记忆”，却不理解背后的上下文成本。我们今天就拆开来讲。

## 02、是什么

Spring AI 为多轮对话提供了 ChatMemory 接口，配套 Advisors 自动维护会话上下文。ChatMemory 负责保存和读取历史消息；Advisor 在请求前后做装配。通俗说，ChatMemory 是记忆库，Advisor 是负责回忆和归档的工人。开发人员不需要在业务代码里手动拼接历史，只需给每次会话一个 conversationId。ChatMemory 常见实现有 MessageWindowChatMemory，只保留最近 N 条消息；还有基于 JDBC 的持久化实现，可把历史落到数据库。注意，Memory 和 RAG 是两码事。Memory 回答“我们之前聊过什么”，解决多轮指代和语境；RAG 回答“外部知识里有什么”，解决事实来源和领域知识。很多人把两者混在一起，其实前者是短期交互状态，后者是长期外部检索。一个知识助手可以同时需要两者：用 Memory 记住用户追问中的“它”，用 RAG 从文档里找“Spring AI 支持哪些向量库”。如果只用 Memory，没有外部知识，模型只能凭训练数据回答；如果只用 RAG，没有 Memory，连续追问就会丢语境。Spring AI 把它们拆成不同组件，中间由 Advisors 串联。

## 03、为什么

为什么必须显式管理 Memory？因为大模型接口不保存任何会话状态。即使同一个 API Key，第一次请求和第二次请求之间没有关联。模型厂商可以选择在服务端缓存部分输入用于审计，但不会把它当成对话记忆。应用中常见三种场景：代词指代、省略追问、多轮约束。第一个例子：“Spring AI 是什么？”→“它支持哪些向量库？”没有前一条消息，模型只能瞎猜“它”是什么。第二个：“给我一个 Spring AI 配置示例。”→“这个配置里最大 Token 怎么调？”模型不知道“这个”指向哪段配置。第三个：用户说“后面回答尽量简洁”，这条约束必须一直存在后续消息里，否则模型会忘记偏好。传统做法是每次手动把全部历史拼进去。代码里维护 List<Message>，每轮追加、裁剪、去重，既繁琐又易错。Spring AI 用 ChatMemory 加 Advisor 把这类操作标准化。业务代码只需用同一个 conversationId 发起请求，框架自动读取窗口内的历史，请求结束后写回。另一个原因是上下文窗口有限。即使现在很多模型窗口很大，也不能无脑把所有历史塞进去。需要应用层策略决定保留哪些、删除哪些、是否摘要。Spring AI 的 Memory 机制提供了插拔点，可以把策略统一管理，而不是散落在每个接口里。

## 04、架构

Spring AI 的对话请求通常围绕 ChatClient 构建。你可以把 ChatClient 看成一个入口，请求经过若干 Advisor 处理后才发送给模型。MessageChatMemoryAdvisor 就是其中一个关键 Advisor。它做的事情：请求前，根据 conversationId 从 ChatMemory 取出最近消息，拼到当前消息前面；响应后，把用户消息和模型回复写入 ChatMemory。架构上分三层：应用代码、Advisor 链、模型接口。应用代码拿着 conversationId 调用 ChatClient；Advisor 链负责上下文装配；模型接口仍是无状态调用。ChatMemory 内部可以有不同的存储策略。短期窗口用内存队列，只保留最近 N 条，超出自动移除；持久化 Store 用数据库表，包含会话 ID、消息索引、消息类型、内容、创建时间等字段，适合需要跨进程、跨重启记住会话的场景。有的实现还支持按时间过期。对于知识助手这类服务，实战中通常先上短期窗口保证响应及时，再根据业务需求接持久化，避免内存无限增长。架构上还有一点值得注意：Advisor 是有序的。一般记忆 Advisor 放在检索 Advisor 前面还是后面，取决于你想让模型先看到历史还是先看到检索结果。常见做法是把记忆放最前面，保证历史语境完整；检索结果作为当前问题的事实补充追加在后面。顺序错了，模型容易把检索片段当成对话历史，产生混淆。

## 05、实战

我们用一个简化但可运行的知识助手例子来演示连续追问。假设项目基于 Spring Boot 3 和 Spring AI。先引入 spring-ai-openai-spring-boot-starter。为了演示，我们自己写一个 ChatMemory bean，用窗口大小 20。然后定义 ChatClient。代码大概如下：

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

    @Bean
    public ChatClient chatClient(ChatClient.Builder builder, ChatMemory memory) {
        return builder
            .defaultAdvisors(MessageChatMemoryAdvisor.builder(memory).build())
            .build();
    }
}
```

Controller 里，每个会话使用同一个 conversationId：

```java
@PostMapping
public String ask(@RequestBody AskRequest req) {
    String conversationId = req.getConversationId();
    return chatClient.prompt()
        .user(req.getQuestion())
        .advisors(a -> a.param("chat_memory_conversation_id", conversationId))
        .call()
        .content();
}
```

注意 conversationId 需要稳定。前端第一次进入页面生成一个 UUID，后续请求都带上来。如果用户刷新页面，可以重新生成，旧会话依然留在 Memory 里，但不再使用。知识助手请求序列演示：第一次传 conversationId=c1，问题“Spring AI 是什么？”；模型返回定义。第二次传同一个 c1，问题“它支持哪些向量库？”；MessageChatMemoryAdvisor 会取出上一条用户消息和模型回复，模型就能理解“它”指 Spring AI。如果不带 conversationId，或者每次新生成，第二条请求就变成孤立问题。我们还可以加一个简单的 RAG 检索 Advisor，让它从向量库里找文档。但本例子重点在 Memory，所以先不混入检索。你可以在控制台打开调试日志，查看实际发送给模型的消息列表。会发现第二次请求里已经包含历史消息，消息数量明显增加。这就是 Memory 在起作用。很多开发者第一次看到日志会惊讶：原来模型“变聪明”是因为输入变长了，不是它真的记住了什么。

## 06、洞见

这里有一个关键认知：Memory 本质上是 Context Budget 管理问题。不是“有没有记忆”，而是“给模型多少上下文才划算”。全量历史听起来很省心，但有三笔账要算。第一，Token 成本。每轮都把全部历史发给模型，输入 Token 线性增长。假设每轮平均 500 Token，用户聊了 40 轮，每次请求都要带近 2 万 Token 历史，费用和延迟都会上升。第二，窗口限制。再大的上下文窗口也有上限，且窗口越大，模型对中间信息的注意力可能被稀释。第三，噪声。早期无关的寒暄、失败尝试、重复内容如果一直保留，会干扰模型当前判断。合理的策略是短期窗口加摘要加持久化按需取用。短期窗口保留最近消息，保证指代和追问；摘要把较早内容压缩成要点；持久化负责跨会话查询。隐私策略也不能忽略。用户可能要求删除某段对话，或不允许长期存储。Memory 系统需要支持按 conversationId 删除或脱敏。上下文预算可以类比操作系统内存管理：不是把所有页面都加载进来，而是保留工作集，换出不活跃页。对话工作集就是当前任务所需的最短历史。超出部分应该被裁剪、摘要或归档。只有理解这一点，才能真正用好 Spring AI 的 ChatMemory，而不是简单把 maxMessages 调大。

## 07、行动

如果你想在生产里落地，我建议分两步走。第一步，实现短期窗口 Memory。用 MessageWindowChatMemory，maxMessages 先设 10 到 20。观察典型会话长度，如果连续追问超过窗口，再调整。代码前面已经给过。第二步，实现持久化 Conversation Store。Spring AI 有基于 JDBC 的实现，你可以建一张 conversation_history 表，字段包括 conversation_id, message_index, message_type, content, created_at。配置一个 JdbcChatMemory 替换内存实现。这样服务重启后旧会话还能继续。但要设置过期时间，避免数据库无限膨胀。比如定期清理 30 天未活跃的 conversation_id，或者限制每个会话最多保存 200 条消息。然后观察 Token 成本。在调用模型前打印消息列表数量和估计 Token 数。你可以写一个简单的统计过滤器，把每轮请求的 inputToken 做对比：短期窗口方案成本稳定，持久化全量方案成本随轮次线性上升。差距会在 20 轮以后非常明显。对于知识助手，最优策略通常是：窗口 20 条加关键词触发摘要加持久化按需检索历史，既保留连续追问能力，又不让成本失控。别一上来就“全量永久塞给模型”，那样做不是记忆，而是懒惰。

## 08、小结

回头看，LLM API 本身是无状态的，多轮对话的连续性来自应用侧的记忆管理。Spring AI 用 ChatMemory 加 Advisors 把这件事标准化：业务代码只关心 conversationId，框架负责装配和归档。Memory 回答“我们之前聊过什么”，RAG 回答“外部知识里有什么”，两者分工不同，但常常一起出现。实战中，连续追问的关键是保持 conversationId 稳定，并通过窗口或持久化控制历史规模。更深一层，Memory 不是无限存储，而是 Context Budget 管理问题。需要窗口、摘要、持久化和隐私策略协同。短期窗口控制成本，摘要压缩旧信息，持久化支持跨会话，隐私策略兜底合规。不要把所有历史永久塞给模型，那会透支上下文预算，推高成本，稀释信号。

## 09、链接与概念说明

- ChatMemory：Spring AI 中负责会话历史读写的接口，常见实现有 MessageWindowChatMemory 和 JDBC 版。
- MessageChatMemoryAdvisor：请求前后自动读写 ChatMemory 的 Advisor，需指定 conversationId。
- conversationId：标识一次连续会话的稳定 ID，由应用生成并保持一致。
- MessageWindowChatMemory：只保留最近 N 条消息的短期记忆实现。
- RAG：检索增强生成，从外部知识库检索相关信息后交给模型，解决事实来源问题。
- Context Budget：上下文预算，指一次请求能容纳的输入 Token 总量，需要在成本、延迟和效果之间取舍。
- 持久化 Conversation Store：将会话历史存储到数据库等介质，用于跨进程、跨重启恢复对话。
- Spring AI 官方文档：https://docs.spring.io/spring-ai/reference/ （示例链接，实际以官方为准）

注意：以上链接为示例，具体版本请以你使用的 Spring AI 版本为准。

上周一个同事拿着日志来找我，说知识问答服务上线后用户总投诉它像金鱼，只有七秒记忆。我翻了一下真实请求，第一条问“Spring AI 是什么”，返回了正常定义；第二条问“它支持哪些向量库”，服务居然开始介绍 Spring AI 支持哪些数据库连接，完全没理解“它”指代什么。我是老李。这个问题其实不是模型能力不行，而是我们把大模型接口当成了有状态服务在用。LLM API 天生接近无状态。每次请求都是一次全新对话，服务端不会替你记住上一句。模型看到的只有当前输入；如果应用不把历史上下文传过去，它当然不知道“它”是什么。多轮对话的连续感，必须由应用自己管理。这跟传统后端把会话塞进 HttpSession 不一样。以前我们总觉得模型会“理解”上下文，其实它只是每次根据传入的完整消息序列做预测。上下文没传，它就失忆。知识助手尤其典型：用户先问概念，再问能力、向量库、配置，后面全是代词和省略。没有记忆，问答就断片。现在为什么讲这个？因为 Spring AI 这类框架已经把会话记忆做成了基础组件，但很多人只看到“加个 Advisor 就有了记忆”，却不理解背后的上下文成本。我们今天就拆开来讲。

《Spring AI 2.0实战》第11招 对话怎么记住上下文

LLM 接口本身没有记忆，多轮对话必须应用自己维护上下文。本文从 Spring AI ChatMemory 讲起，结合知识助手连续追问实例，拆解短期窗口与持久化

架构师

编程语言

SpringAI多轮对话失忆源于LLM无状态特性，需通过ChatMemory与Advisors管理会话上下文。Memory解决代词指代等语境问题，RAG补充外部知识，二者分工明确。实战中稳定conversationId配合窗口策略，平衡Token成本与连续性，实现高效记忆管理。

内存管理

代码解释

数据库

2026上云采购 | AI焕新·智启新局

advisor

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring AI 2.0实战》第11招 对话怎么记住上下文-腾讯云开发者社区-腾讯云

《Spring AI 2.0实战》第11招对话怎么记住上下文

《Spring AI 2.0实战》第11招对话怎么记住上下文

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring AI 2.0实战》第11招 对话怎么记住上下文

《Spring AI 2.0实战》第11招 对话怎么记住上下文

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring AI 2.0实战》第11招对话怎么记住上下文

《Spring AI 2.0实战》第11招对话怎么记住上下文