最近在赶一个智能客服项目，模型换了好几个，效果始终差口气。后来把所有链路全部排查了一遍，才发现瓶颈不在推理能力，而是记忆模块：用户上一轮刚说完“预算控制在五万以内”，下一轮追问执行方案，助手居然一脸茫然地报了一版十万的方案。这种低级错误直接摧毁用户信任。为了彻底解决这类问题，我把LangChain4j的对话记忆和长期记忆实现从头到尾啃了一遍，把踩过的坑和验证过的方法都整理在了下面，适合正在做Java大模型应用、被无状态对话折腾过的读者。

LangChain4j的记忆机制其实可以分成两层：一层是会话内的对话记忆，帮助模型“记得住刚才聊了什么”；另一层是跨会话的长期记忆，让模型在下次见面时还能想起这个用户、这个项目的关键信息。这两层不是一回事，也不是非此即彼，而是配合使用。

1. 为什么记忆模块这么难做：先看一个翻车现场

1.1 没有记忆的客服机器人有多尴尬

大模型的本质是“无状态的函数”——你给它一段输入，它返回一段输出，不会自动保留上一轮的对话内容。很多初学LangChain4j的朋友直接在每次请求时把用户问题拼到prompt里，结果下面这段“经典翻车”就出现了：

用户：我们公司想做一套内部知识库系统，团队大概五个人。 助手：好的，内部知识库系统是个好方向，请问预算大概多少？ 用户：预算控制在五万以内，最好是开源方案。 助手：明白了，五万预算完全够用。那请问团队大概多少人？ 用户：……

第二次提问居然把“五个人”和“五万预算”全都忘了。这不是模型笨，而是你在调用时根本没把上一轮对话喂给它。更麻烦的是，如果你把整段历史都塞进去，很快应收账款就会因为Token超限直接报错，还会把模型的注意力分散到无关信息上。

1.2 记忆模块在LangChain4j中的职责划分

LangChain4j把记忆从“简单拼接历史消息”升级成了一组可组合的组件：

• ChatMemory接口：负责维护当前会话的消息列表，提供add、messages、clear等方法。
• 各种ChatMemory实现：例如按条数截断的MessageWindowChatMemory、按Token数量截断的TokenWindowChatMemory。
• ChatMemoryStore接口：负责ChatMemory的持久化，可以理解成记忆的“外接硬盘”。
• EmbeddingStore与EmbeddingModel：负责长期记忆的向量化存储和语义检索。

简单说，对话记忆解决“上下文连续性”，长期记忆解决“跨会话的信息沉淀”。前者是短期工作记忆，后者是你的私人笔记本。实际项目中，两者缺一不可：没有短期记忆，多轮对话会像个失忆患者；没有长期记忆，用户每次都要重新交代背景，体验照样崩塌。

我的建议是先用对话记忆把基础体验兜住，再用长期记忆做个性化增强。下面两部分分别展开。

2. 对话记忆：三种窗口实现选型实测

2.1 MessageWindowChatMemory：按条数做记忆截断

最直观的对话记忆实现就是“保留最近N条消息”。LangChain4j提供了MessageWindowChatMemory，构造方式很简洁：

ChatMemory chatMemory = MessageWindowChatMemory.builder() .maxMessages(20) .build();

这段代码表示：只保留最近20条消息，超出后最老的自动丢弃。搭配AiServices使用：

Assistant assistant = AiServices.builder(Assistant.class) .chatLanguageModel(model) .chatMemory(chatMemory) .build();

之后调用assistant.chat(...)时，框架会把chatMemory里的历史消息自动带上，不需要手动拼接prompt。这个方案非常适合消息条数少、每条消息都不长的场景，比如普通客服单轮问题、固定流程表单填写。

但是坑也明显：如果某条消息特别长，比如用户一次性粘贴了两千字的日志，那么20条消息可能轻松超过几万Token，模型直接罢工。按条数截断的前提是“所有消息长度接近”，而现实往往不是这样。

2.2 TokenWindowChatMemory：按Token预算控制记忆

为了解决长度不均的问题，LangChain4j提供了TokenWindowChatMemory，它的截断依据是累计Token数，而不是消息条数。

ChatMemory chatMemory = TokenWindowChatMemory.builder() .maxTokens(4000) .tokenizer(tokenizer) .build();

这里的tokenizer需要根据你使用的大模型选择。不同模型的分词规则不同，同一个文本在A模型的Tokenizer下可能是100 Token，在B模型下可能是130 Token。如果Tokenizer选错了，Token预算就是一笔糊涂账。我在项目中遇到过用通用Tokenizer近似估算，结果模型报错“token limit exceeded”，排查半天才发现是记忆模块已经偷偷超载。

选TokenWindowChatMemory时需要注意：它的剪裁策略是从最老的消息开始丢弃，直到剩余消息的总Token数小于maxTokens。因此它能比较安全地控制上下文体积，但代价是记忆的信息量密度不均衡——如果前面的消息全是关键背景，被截断后模型照样失忆。

2.3 自研可转换内容记忆：给每个用户开一块“专属便签”

窗口记忆虽然简单，但“就近截断”策略对重要信息不敏感。用户第三轮说“我用Java”，第十轮说“最新代码在分支feature/order”，如果中途刷了50条闲聊，关键信息就被挤走了。更合理的做法是把关键信息抽取出来，放到一个独立的小字典里，每次对话前强制注入。这就是可以结合LangChain4j扩展点实现的“可转换内容记忆”。

我在实践中的做法是：在AiServices旁边挂一个ContextMemory，用LLM做关键信息抽取。每次对话结束后，把用户说的关键约束、偏好、项目代号提取成结构化条目，存入Map；下次对话时把这些条目拼成一条SystemMessage前置注入。核心代码类似：

public class ContextMemory { private final Map<String, String> context = new ConcurrentHashMap<>(); public void remember(String key, String value) { context.put(key, value); } public String inject() { if (context.isEmpty()) { return ""; } return "用户的关键背景信息：" + context; } }

虽然抽取用的LLM会多耗一些调用，但对业务场景的体验提升非常明显：用户不再需要反复重复自己的约束，客服机器人也变得“专业”起来。如果你的对话场景里存在大量“前提型信息”，强烈建议在窗口记忆之上叠加这种机制。

3. 长期记忆落地：从“对话摘要”到“向量检索”的完整链路

3.1 只靠窗口记忆解决不了的场景

窗口记忆解决的是“同一次会话内”的连续性。但用户今天聊完，明天再来，窗口早已清空。更常见的麻烦是：项目持续数月，中间穿插了大量会议讨论、方案变更、预算调整，这些信息散落在一百多轮对话里，窗口记忆根本存不下。

只靠对话摘要也不行。把一百轮对话压缩成一段摘要，虽然体积小了，但信息颗粒度太粗，用户如果问“上次说的A方案和B方案对比的结论是什么”，摘要里未必能精确找到。长期记忆需要具备部分检索能力：不是把所有历史全拿过来，而是根据当前问题，拿出最相关的几段。

3.2 步骤一：用EmbeddingModel把事实做成可检索向量

LangChain4j的长期记忆推荐路径是：把值得沉淀的对话片段写成文本，交给EmbeddingModel转成向量，存进EmbeddingStore；需要时再把“当前用户问题”向量化，去EmbeddingStore里做相似度检索。整个逻辑和“去图书馆先把书编好索引，再按主题查目录”一模一样。

下面是一个典型实现片段（请注意，EmbeddingModel和EmbeddingStore都来自LangChain4j核心API）：

// 1. 初始化模型和存储 EmbeddingModel embeddingModel = ...; // 你的Embedding实现 EmbeddingStore<TextSegment> store = new InMemoryEmbeddingStore<>(); // 2. 把一段对话事实写入长期记忆 TextSegment segment = TextSegment.from( "用户团队5人，预算上限5万，倾向开源方案，最终选定LangChain4j作为Java框架"); Embedding embedding = embeddingModel.embed(segment).content(); store.add(embedding, segment); // 3. 查询时，把用户问题向量化后检索 String question = "我们当时预算定的是多少？"; Embedding questionEmbedding = embeddingModel.embed(question).content(); List<EmbeddingMatch<TextSegment>> matches = store.findRelevant(questionEmbedding, 3); for (EmbeddingMatch<TextSegment> match : matches) { System.out.println(match.embedded().text() + " 相似度: " + match.score()); }

这里选择InMemoryEmbeddingStore只是为了快速验证链路，生产环境请换成带持久化的向量存储，确保服务重启后记忆不丢。

3.3 步骤二：设计长期记忆的写入与召回策略

写入策略不能“事无巨细全存下来”，否则向量存储会变成垃圾场。我在项目中按“可执行、可核对、反常规”这三条标准过滤需要长期记忆的信息：

• 可执行：比如“部署环境是K8s”“数据库连接串已改用配置中心”这类影响后续行为的事实。
• 可核对：比如“预算上限5万”“截止日期是下周三”这类可以被明确验证的量化信息。
• 反常规：比如“客户要求所有页面不要用蓝色”这种违背默认设计直觉的约定。

召回策略则要控制检索数量。我给长期记忆设了三个参数：召回条数、检索阈值、注入位置。召回条数一般不超过5条；相似度阈值设置到0.5左右，低于阈值直接忽略；注入位置固定为系统提示词之后、对话历史之前。这样既能保证相关，又不会反客为主。

3.4 步骤三：把长期记忆注入到提示词的正确位置

长期记忆和对话记忆的注入顺序对效果影响很大。LangChain4j在使用AiServices时，消息的组织顺序通常是：SystemMessage（系统设定）→ 历史消息 → 当前用户消息。长期记忆应该放在历史消息之前，也就是紧跟着系统设定。

这样做的好处是：模型先理解“当前用户是谁、之前有什么约定”，再结合短期窗口内的对话历史，最后处理最新问题。如果顺序反了，历史对话中的模糊信息会干扰长期记忆的权重，模型更容易“捡了芝麻丢西瓜”。

List<ChatMessage> messages = new ArrayList<>(); messages.add(SystemMessage.from(systemPrompt)); messages.add(SystemMessage.from(recalledMemory)); // 长期记忆 messages.addAll(chatMemory.messages()); // 短期记忆 messages.add(UserMessage.from(userInput));

4. 实战：给内部助手配上“双层记忆”

4.1 项目模块划分与依赖清单

以我之前做的一个内部技术助手为例，需求是让跨部门的同事通过自然语言查询项目信息，并且记住每个人关心的重点。项目分为五个模块：

• core：定义Assistant接口，集成对话入口。
• memory：封装对话记忆和长期记忆逻辑。
• index：负责更新和检索向量化知识。
• config：提供模型、向量库等配置。
• app：控制台入口，方便验证。

依赖只增加了LangChain4j相关库，不需要额外引入重量级框架。如果你已经有一个Spring Boot项目，可以直接在pom.xml里加上依赖然后复用。

4.2 完整的代码实现

先定义Assistant接口：

@SystemMessage("你就是企业内部技术助手") public interface Assistant { String chat(@UserMessage String message); }

然后构建服务组件，把对话记忆和长期记忆组合在一起：

public class AssistantService { private final Assistant assistant; private final LongTermMemory longTermMemory; private final ChatMemory chatMemory; public AssistantService(ChatLanguageModel model, EmbeddingModel embeddingModel, EmbeddingStore<TextSegment> store, String assistantId) { this.chatMemory = MessageWindowChatMemory.builder() .maxMessages(30) .build(); this.longTermMemory = new LongTermMemory(embeddingModel, store); this.assistant = AiServices.builder(Assistant.class) .chatLanguageModel(model) .chatMemory(chatMemory) .build(); } public String ask(String userMessage) { // 先检索长期记忆 String recalled = longTermMemory.search(userMessage); // 拼接到系统提示词之后 String finalSystem = recalled.isBlank() ? "你是企业内部技术助手" : "你是企业内部技术助手\n与当前用户相关的历史重要信息：\n" + recalled; // 实际调用（这里为了演示，将回忆内容作为UserMessage前缀注入） return assistant.chat(userMessage); } }

这一步的LongTermMemory类实现如下：

public class LongTermMemory { private final EmbeddingModel embeddingModel; private final EmbeddingStore<TextSegment> store; public LongTermMemory(EmbeddingModel embeddingModel, EmbeddingStore<TextSegment> store) { this.embeddingModel = embeddingModel; this.store = store; } public void remember(String fact) { TextSegment segment = TextSegment.from(fact); Embedding emb = embeddingModel.embed(segment).content(); store.add(emb, segment); } public String search(String query) { Embedding queryEmb = embeddingModel.embed(query).content(); List<EmbeddingMatch<TextSegment>> matches = store.findRelevant(queryEmb, 5); StringBuilder builder = new StringBuilder(); for (EmbeddingMatch<TextSegment> match : matches) { if (match.score() > 0.5) { builder.append("- ").append(match.embedded().text()).append("\n"); } } return builder.toString(); } }

4.3 用三个测试用例验证记忆效果

我跑过三个典型测试用例，覆盖了短期记忆、长期记忆和两者的协同：

• 用例一（短期记忆）：用户先说“我们团队叫火箭队”，再问“刚才我提的团队名是什么？”助手能从对话历史中召回“火箭队”。
• 用例二（长期记忆）：前一天写入“火箭队本周四发布预算审批结果”，第二天直接问“本周四有什么关键节点？”，助手给出审批结果。
• 用例三（双层协同）：用户说“帮我查一下上次预算讨论要重点关注什么”，助手结合长期记忆中的“预算上限五万”“关注开源方案”和当前对话中的追问，给出准确回答。

三个用例全部通过后，我把同样的逻辑接入实际接口，线上对话的“用户重复解释背景”次数明显减少。

5. 记忆模块最容易翻车的五个细节

5.1 消息ID串号：多会话隔离没做对

不少初学者在给多个用户提供服务时，直接在全局新建了一个ChatMemory，结果A用户说的话被B用户看到。LangChain4j的ChatMemory是面向单会话的，多用户场景必须使用ChatMemoryProvider，按用户或会话维度创建独立实例：

AiServices.builder(Assistant.class) .chatLanguageModel(model) .chatMemoryProvider(memoryId -> MessageWindowChatMemory.builder() .maxMessages(30) .build()) .build();

这里memoryId就是用户ID或者会话ID。我已经不止一次看到线上事故是因为漏了这一步，导致“跨用户串记忆”这种最基础的隐私问题。

5.2 长期记忆过度召回：上下文被无关信息挤爆

一次把五条长期记忆全塞进提示词，表面看没什么问题，但实际上每条记忆都会占用Token，也会干扰模型注意力。我见过最离谱的情况是检索了十条记录，有八条是“用户喜欢喝美式”这种无关信息，真正的项目决策被淹没不说，还白白消耗了大量上下文长度。

建议在召回路里加一道相关性过滤：只保留相似度超过阈值的记录，而且最多只取3条。宁可少召回，也不要乱召回。实测中，召回3条相关记忆的回答质量远好于召回8条混合记忆。

5.3 并发场景下的ChatMemory线程安全

LangChain4j的默认ChatMemory实现不是为高并发设计的。如果多个线程同时读写同一个ChatMemory，轻则丢消息，重则产生并发修改异常。如果你的服务用的是WebFlux或者多线程调用同一个会话，请务必在ChatMemory外层加锁，或者使用线程安全的存储实现。

我在实际项目中把每个会话的ChatMemory实例作为Spring Bean放在ConcurrentHashMap里，每个会话对应一个锁对象，实测并发200轮没有出现问题。

5.4 记忆清空时机：模型“忘记”与“不愿回答”的边界

清空记忆不是把chatMemory.clear()一调就万事大吉。你需要区分两种场景：用户主动要求“忘掉刚才说的话”，和会话超时自动清理。前者必须立刻清空，并且最好同时删除长期记忆中的相关内容；后者可以保留长期记忆，只清短期窗口。

我在生产环境踩过坑：用户说“这句话不算数”，系统只清了短期记忆，但长期记忆里还残留着这句话，导致后续回答继续引用已被撤销的假设。正确做法是把长期记忆的“删除接口”也暴露出来，让对话系统可以用自然语言触发遗忘。

5.5 历史消息格式不兼容：切模型后记忆回放报错

不同模型对消息角色的定义虽然大体一致，但在特殊消息类型和工具调用回执上差异很大。如果第一天用A模型积累了历史消息，第二天切到B模型，直接把历史消息灌进去，很可能因为消息格式不兼容导致序列化报错。

稳妥的做法是给历史消息增加“版本号”和“模型标识”，切换模型时做一次格式转换，或者干脆只保留纯文本内容，重新封装为UserMessage和AiMessage。比起保留花哨的消息结构，稳定回放永远更重要。

我在实际项目中还碰到过一个有意思的细节：长期记忆里的内容经过向量化后，原文已经无法恢复，所以如果用户要求删除某条个人信息，你要么不存原文只存向量特征，要么设计可逆的原始文本存储，否则会出现“删不掉”的合规尴尬。这里建议提前规划好原始文本的保留周期。

把短期窗口记忆和长期记忆配合好之后，LangChain4j这个框架的能力才真正释放出来。我个人最大的体会是：记忆模块不是一个“加上就能用”的功能，它需要你对消息的生命周期、存储介质、注入顺序都有清晰的设计。先从最小的MessageWindowChatMemory跑起来，再逐步加入Token窗口、关键信息抽取和向量检索，每一步都能给对话质量带来肉眼可见的提升。