直接说结论：做 AI 应用开发第一道坎，不是 Prompt 写得不够好，是 AI 转眼就忘。上一秒刚聊完需求细节，下一秒它就开始装失忆。尤其我们 Java 后端出身的人，习惯了有状态的服务、数据库里躺着完整记录，一碰大模型接口，全乱套了——因为大模型天生无状态，你不把历史对话喂回去，它什么也不记得。

这个"失忆"问题，就是 ChatMemory 要解决的。简单说，它是一个对话历史管理组件，负责把用户和 AI 的每轮对话缓存、整理、截断、再拼装成合理的上下文，在每次请求时交给大模型，让 AI 能"记得"你们上一秒聊了什么。这篇内容，是给正在转型 AI 应用开发的 Java 程序员准备的实战笔记，全程用 Java 写代码，不绕弯子。适合三类人看：已经在调大模型接口、被多轮对话上下文搞到头大的；准备把现有 Java 服务接 AI 能力、但不知道怎么管理会话状态的；以及想搞懂对话历史存储、Token 窗口、上下文裁剪这些内功的。

我不会讲那些虚头八脑的架构图，就直接从需求拆解到代码落地，一步步带你搭一个可用的 ChatMemory 模块。

1. 内容整体设计与思路拆解

1.1 AI 失忆的根因：为什么每次对话都要重新介绍自己

先从一个最日常的场景说起。你打开一个 AI 聊天产品，跟它说"帮我写一个 Java 的 DTO 类"，它写出来了。紧接着你又说"把字段类型改成 LocalDateTime"，结果它一脸懵，反问你"哪个字段"。

这不是 AI 变笨了，而是它根本不知道你刚才说了什么。大模型的调用方式是无状态的，每一条请求都是独立的。服务器收到你的消息后，只处理你当前给它的这段文本，它看不到任何历史消息。如果开发者不把之前的对话一起发过去，模型就只当你是在跟一个刚出生的小孩说话。

这就是 ChatMemory 存在的意义。它不做任何模型推理，它的活很简单：把每一轮对话存起来，在每次调用模型之前，把相关的历史消息找出来，拼接成一个完整的对话序列，再塞给模型。

这就像你跟同事讨论方案，不可能每次都从头讲一遍需求，你得有一份会议纪要，每次开会前提一下"咱们上次聊到哪了"。ChatMemory 就是这份会议纪要。

1.2 ChatMemory 的设计目标：让无状态的大模型"看起来有记忆"

理解了根因，设计目标就清晰了。ChatMemory 不是要做成一个大而全的 AI 框架，它只需要做三件事：

第一，存储。能把每次用户输入和模型输出完整地保存下来，支持按会话维度管理。

第二，组装。能在调用模型前，按照模型的输入格式，把历史消息拼装成上下文。

第三，裁剪。当历史消息太长、超出模型上下文窗口时，能智能地丢掉不重要的部分，保住核心信息。

还有第四点，容易被忽略但实际很关键：持久化。服务重启、机器宕机了，历史对话不能丢。这对 Java 后端程序员来说反而是最熟悉的部分，无非就是接个数据库或者缓存。

所以我给它的定位是：一个轻量级的、嵌入在业务代码里的工具类模块，不依赖特定的大模型 SDK，不绑定某个云服务商，纯 Java 原生实现核心逻辑。这样你不管后面接哪家的模型，这套代码都能复用。

1.3 为什么 Java 程序员做这个有天然优势

我说句实在话，在座各位 Java 程序员搞这个真的不吃亏。对话历史管理，本质上是数据管理问题，恰好是后端开发的看家本领。

你可以把它拆解成几个很"Java 味"的子问题：用 Map 做内存缓存、用 List 存消息序列、用数据库做持久化、用事务保证一致性、用线程池处理并发。这些玩意儿，你在 CRUD 项目里写了无数遍，现在只是换了个使用场景。

真正需要补课的是大模型相关的知识，主要是两个方面：一是模型的上下文窗口限制，二是消息格式规范。这俩搞懂之后，剩下的全是你熟悉的活。

2. 核心细节解析与实操要点

2.1 消息结构：别用 String 存对话，用 Message 对象

新手最容易犯的错误，就是用 String 拼接对话历史。比如搞一个 StringBuilder，把"用户说：xxx，AI 说：xxx"拼成一大段文本塞给模型。短期跑通没问题，一旦要做裁剪、过滤、统计，就全废了。

正确的做法是定义消息对象。每条消息包含三个核心字段：角色、内容、时间戳。角色用来区分是用户说的还是 AI 回复的，内容就是实际文本，时间戳用于后续做时效性处理。

我给一个标准的定义：

public class ChatMessage { private String role; // "user" 或 "assistant" 或 "system" private String content; // 消息正文 private long timestamp; // 消息产生时间 public ChatMessage(String role, String content) { this.role = role; this.content = content; this.timestamp = System.currentTimeMillis(); } // getter/setter 略 }

role 字段的三个取值需要注意：system角色用于定义 AI 的人设和全局指令，user是用户输入，assistant是模型回复。这三类消息扮演的角色不同，在后续组装上下文时处理逻辑也不一样。

为什么一定要用结构化对象？我给你打个比方，用 String 拼对话就像是把所有工具混装在一个箱子里，每次要用老虎钳都得翻半天；用 Message 对象就像是分类收纳，每一项都有固定位置，要什么直接取。开发中你需要统计一轮对话消耗了多少 Token，需要知道用户最近 10 条消息是什么，还需要在异常时排除掉某条有害消息。这些操作，结构化方案都是 O(1) 的复杂度，字符串方案能把你逼疯。

2.2 会话维度：一个用户一个会话，还是一个用户多个会话

存储层设计要回答一个关键问题：会话的粒度怎么定。拿聊天产品举例，一个用户今天聊工作、明天聊学习，他不希望两件事的上下文混在一起。所以 ChatMemory 需要引入会话 ID 的概念。

推荐的设计是双层结构：

• 用户维度：使用用户 ID 做外层隔离，不同用户之间互不可见。
• 会话维度：使用会话 ID 做内层隔离，同一个用户的不同话题分开存储。

代码层面，我会用一个MemoryStore接口来抽象存储行为：

public interface MemoryStore { void saveMessage(String userId, String sessionId, ChatMessage message); List<ChatMessage> getHistory(String userId, String sessionId); void clearSession(String userId, String sessionId); }

这么做的好处是：查询历史时先按 userId 过滤，缩窄范围；再按 sessionId 过滤，定位到具体对话。索引也只需要建联合索引 (userId, sessionId)，性能上有保障。

实操的时候，会话 ID 的生成要放在业务层，不在 ChatMemory 内部生成。因为新建会话的时机由业务逻辑决定，比如用户点击了"新对话"按钮，那这个时候才应该生成新的 sessionId。ChatMemory 只负责存取，不负责业务判断。

2.3 上下文窗口：Token 是硬货币，必须精打细算

如果说消息结构和会话维度是基本功，那么 Token 管理就是 ChatMemory 的核心竞争力。

每种模型都有自己的上下文窗口，白话讲就是一次能接收多少 Token。比如某模型的窗口是 4096 Token，你塞给它 5000 Token 的内容，直接报错。更麻烦的是，有些服务商不是你超了才报错，而是超了部分直接截断，导致模型"看漏"了关键信息。

所以 ChatMemory 里头要有一个专门的模块：上下文裁剪器。核心思路是保留最重要的信息，丢掉最不重要的。哪些信息最重要？我按优先级排个序：

• System 消息：AI 的人设和指令，优先级最高，永远不能丢。
• 最近的对话：用户刚说的问题和 AI 刚给的回复，上下文强相关，必须保留。
• 早期的对话：除了其中的关键约束信息，大部分可以压缩或删除。

这背后有一个心理学原理和工程实践都验证过的规律：大模型对上下文开头和结尾部分的内容最敏感，对中间部分容易"遗忘"。所以裁剪策略通常是"掐头留尾"——记得住开头给它的系统指令，也记得住刚聊的内容，中间略旧的部分可以放弃。

裁剪具体实现时，要计算每条消息的 Token 占用。你可能会问，Token 怎么算？通常可以按字符数估算，中文大概 1 个汉字约 0.6~1 个 Token，英文一个单词约 1.3 个 Token。也可以在调用 SDK 时通过特定方法来获取准确的数量。作为通用设计，我给一个保守估算方法：estimatedTokens = content.length() / 2，中文语境下很实用。

2.4 摘要压缩：裁剪的下位替代方案

裁剪会丢信息，有些场景丢不起。比如你让 AI 读一本长篇小说然后回答问题，历史对话包含大量细节，直接裁剪会让 AI 忘记关键情节。这种时候就需要摘要压缩。

思路是：当早期对话超过一定数量后，不再简单删除，而是调用一次模型，把这段对话的核心内容提炼成几句话，存成一条摘要消息，替代原始对话。比如原来 30 条对话挤掉了，摘要后变成 1 条消息，保留 80% 的关键信息。

这个方案我用过，效果很不错，但要控制调用成本。建议只在会话窗口即将超限时才触发摘要，不要每轮都做。实现上需要异步调用模型生成摘要，避免阻塞用户请求。由于每个人对接的模型 SDK 不同，我这里不写具体实现，只把这个策略在 MemoryManager 里预留一个回调接口。

3. 实操过程与核心环节实现

3.1 核心类设计：MemoryManager 统一入口

前面拆完了设计，现在正式开始写代码。我会分三层来做：

• 存储层：MemoryStore的实现，分内存版和数据库版。
• 裁剪层：负责 Token 估算和上下文裁剪。
• 门面层：MemoryManager，对外提供保存消息、获取上下文、创建会话等能力。

MemoryManager是整个模块的门面，业务代码只跟它打交道。先看代码骨架：

public class MemoryManager { private final MemoryStore store; private final int maxTokens; public MemoryManager(MemoryStore store, int maxTokens) { this.store = store; this.maxTokens = maxTokens; } // 保存一轮对话 public void remember(String userId, String sessionId, String userInput, String assistantReply) { store.saveMessage(userId, sessionId, new ChatMessage("user", userInput)); store.saveMessage(userId, sessionId, new ChatMessage("assistant", assistantReply)); } // 获取可用于模型调用的上下文消息列表 public List<ChatMessage> getContext(String userId, String sessionId) { List<ChatMessage> history = store.getHistory(userId, sessionId); return trimToFit(history, maxTokens); } // 新开一个会话 public String createSession(String userId) { return UUID.randomUUID().toString(); } private List<ChatMessage> trimToFit(List<ChatMessage> messages, int maxTokens) { // 裁剪策略实现见下文 return messages; } }

这个门面类的逻辑并不复杂，核心在getContext方法：从存储里取出历史消息，然后交给trimToFit做裁剪，返回适合模型上下文窗口的消息列表。

3.2 内存版存储：用 ConcurrentHashMap 快速跑通流程

先实现一个内存版存储，方便本地测试。核心数据结构是一个两级嵌套的 Map：外层 key 是 userId，内层 key 是 sessionId，value 是消息列表。

public class InMemoryMemoryStore implements MemoryStore { private final Map<String, Map<String, List<ChatMessage>>> store = new ConcurrentHashMap<>(); @Override public void saveMessage(String userId, String sessionId, ChatMessage message) { Map<String, List<ChatMessage>> userSessions = store.computeIfAbsent(userId, k -> new ConcurrentHashMap<>()); List<ChatMessage> messages = userSessions.computeIfAbsent(sessionId, k -> new CopyOnWriteArrayList<>()); messages.add(message); } @Override public List<ChatMessage> getHistory(String userId, String sessionId) { Map<String, List<ChatMessage>> userSessions = store.get(userId); if (userSessions == null) { return Collections.emptyList(); } List<ChatMessage> messages = userSessions.get(sessionId); return messages == null ? Collections.emptyList() : new ArrayList<>(messages); } @Override public void clearSession(String userId, String sessionId) { Map<String, List<ChatMessage>> userSessions = store.get(userId); if (userSessions != null) { userSessions.remove(sessionId); } } }

四个细节说一下：

第一，用ConcurrentHashMap保证多线程安全。AI 服务通常是并发接收请求的，同一个会话可能同时有多个用户消息进来，Map 一定不能是普通的 HashMap。

第二，用CopyOnWriteArrayList存消息列表。这个列表读多写少，加消息是追加操作，读取历史时遍历。这种并发场景用它正合适，不会出现 ConcurrentModificationException。

第三，getHistory返回的是new ArrayList<>(messages)，做了一个防御性复制。调用方拿到的是副本，自己怎么处理都不会影响内存中的原始数据。

第四，这个实现是纯内存的，服务重启就丢了。生产环境必须替换成数据库版，但开发调试阶段它足够用，启动快、无依赖、好排查。

3.3 数据库持久化：用 JDBC 实现不依赖框架的存储

内存版只能玩，生产环境得落地。Java 后端最熟悉的方案就是关系型数据库。我再用 JDBC 写一个数据库实现，尽量不依赖 Spring 等框架，方便你在任何场景下嵌入。

建表语句：

CREATE TABLE chat_memory ( id BIGINT AUTO_INCREMENT PRIMARY KEY, user_id VARCHAR(64) NOT NULL, session_id VARCHAR(64) NOT NULL, role VARCHAR(16) NOT NULL, content TEXT NOT NULL, timestamp BIGINT NOT NULL, KEY idx_user_session_time (user_id, session_id, timestamp) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

对应的 JDBC 实现：

public class JdbcMemoryStore implements MemoryStore { private final DataSource dataSource; public JdbcMemoryStore(DataSource dataSource) { this.dataSource = dataSource; } @Override public void saveMessage(String userId, String sessionId, ChatMessage message) { String sql = "INSERT INTO chat_memory (user_id, session_id, role, content, timestamp) VALUES (?, ?, ?, ?, ?)"; try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, userId); ps.setString(2, sessionId); ps.setString(3, message.getRole()); ps.setString(4, message.getContent()); ps.setLong(5, message.getTimestamp()); ps.executeUpdate(); } catch (SQLException e) { throw new RuntimeException("保存消息失败", e); } } @Override public List<ChatMessage> getHistory(String userId, String sessionId) { String sql = "SELECT role, content, timestamp FROM chat_memory WHERE user_id = ? AND session_id = ? ORDER BY id ASC"; List<ChatMessage> result = new ArrayList<>(); try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, userId); ps.setString(2, sessionId); try (ResultSet rs = ps.executeQuery()) { while (rs.next()) { result.add(new ChatMessage( rs.getString("role"), rs.getString("content") )); } } } catch (SQLException e) { throw new RuntimeException("读取历史失败", e); } return result; } @Override public void clearSession(String userId, String sessionId) { String sql = "DELETE FROM chat_memory WHERE user_id = ? AND session_id = ?"; try (Connection conn = dataSource.getConnection(); PreparedStatement ps = conn.prepareStatement(sql)) { ps.setString(1, userId); ps.setString(2, sessionId); ps.executeUpdate(); } catch (SQLException e) { throw new RuntimeException("清空会话失败", e); } } }

这里有两个实战建议：

一是按 id 升序查询，保证消息顺序和用户对话顺序一致。大模型对消息顺序很敏感，顺序乱了，你看到的就是逻辑混乱的"失忆"。

二是timestamp字段可以留作数据治理用。比如你发现某用户一个月前的旧会话占用了大量存储，可以定期跑批清理。不过这里有一个坑需要提醒一下，就是清理逻辑要和sessionId状态联动，避免前端还在展示的会话被后台误删。建议只清理超过 30 天且无活跃的会话。

3.4 上下文裁剪算法：从零实现一个实用的 Token 管理器

现在来到最有含金量的部分：裁剪。maxTokens是硬上限，我们要写一个算法在超限时智能缩减消息列表。

我采用的是一个分层裁剪策略，按优先级分三档：

private List<ChatMessage> trimToFit(List<ChatMessage> messages, int maxTokens) { if (messages.isEmpty()) { return messages; } // 第一档：高频消息数量检查，超限直接裁剪 if (messages.size() > MAX_MESSAGES) { // 保留第一条（通常是 system）和最后 MAX_MESSAGES - 1 条 List<ChatMessage> head = messages.subList(0, 1); List<ChatMessage> tail = messages.subList(messages.size() - (MAX_MESSAGES - 1), messages.size()); messages = new ArrayList<>(head); messages.addAll(tail); } // 第二档：Token 总量估算，超限继续裁剪 int totalTokens = messages.stream() .mapToInt(m -> estimateTokens(m.getContent())) .sum(); if (totalTokens <= maxTokens) { return messages; } // 第三档：从最早的非 system 消息开始丢弃，直到满足上限 List<ChatMessage> result = new ArrayList<>(); int usedTokens = 0; for (int i = 0; i < messages.size(); i++) { ChatMessage msg = messages.get(i); int tokenCount = estimateTokens(msg.getContent()); // system 消息必须保留 if ("system".equals(msg.getRole()) || usedTokens + tokenCount <= maxTokens) { result.add(msg); usedTokens += tokenCount; } else if (i == messages.size() - 1) { // 最后一条用户消息不要丢，保底也加入（需要主动控制超出风险） result.add(msg); } } return result; } private int estimateTokens(String text) { if (text == null || text.isEmpty()) { return 0; } // 中英文混合场景下按 1 字符约 0.7 Token 估算 return (int) Math.ceil(text.length() * 0.7); }

裁剪逻辑的核心思想是"保护头和尾"：头指的是 system 指令，尾指的是最近的对话。中间的消息，如果 Token 不够了，牺牲这些地方的信息是代价最小的。

关于代码里的estimateTokens，我需要解释一下为什么取了 0.7 这个系数。不同模型的 Tokenizer 实现不同，但中英文混合内容有个大致规律：英文 1 个字符约 0.25~0.3 Token，中文 1 个字符约 0.6~1 Token。综合估算取 0.7 是一个安全且偏保守的值，宁可多估也不让模型超限。如果对接的 SDK 提供了精确的计算方法，建议替换掉这个估算方法。

最后一个注意点：上面代码中"保底也加入"的最后一条消息处理，其实存在超限风险。实际项目中我建议不要让保底触发，而是训练自己在业务层控制规模，比如每次 getContext 之后检查返回消息总量，超出 window 上限就主动告警。宁可让用户看到截断后的回答，也别让请求直接 400。

3.5 组装上下文：拼装成大模型 API 需要的消息格式

裁剪完成后，下一步就是把消息列表传给模型 API。目前主流模型 API 都支持messages数组格式，提供一个伪代码示例：

public List<ChatMessage> getContext(String userId, String sessionId) { List<ChatMessage> history = store.getHistory(userId, sessionId); List<ChatMessage> trimmed = trimToFit(history, maxTokens); return trimmed; } // 在业务代码中调用 List<ChatMessage> context = memoryManager.getContext(userId, sessionId); // 调用模型 API，将 context 作为 messages 参数传入 // 假设你使用的 SDK 支持传入 List<ChatMessage>

有些模型需要一个system初始消息来设定人设。如果存储的历史里没有 system 消息，建议组装时在最前面插入一条默认的 system 消息。这种做法可以保证模型始终知道自己的身份和任务边界，避免出现角色错乱。

> 注意：如果你用的模型 API 不接受 `List<ChatMessage>` 这样的对象格式，而要求传 `List<Map<String, String>>`，那就做一个简单的转换，把 role 和 content 拿出来放进 Map 即可。这块是适配层代码，每个项目都不一样，没有标准答案，但思路一致。

4. 实战验证：把 ChatMemory 接入一个最小可运行的 AI 服务

4.1 改造前的代码：暴露无遗的问题

假设你原来写的 AI 调用代码长这样：

public String chat(String userId, String userInput) { String prompt = "用户说：" + userInput; // 直接调用模型 API AIResponse response = modelClient.chat(prompt); return response.getReply(); }

这段代码跑单轮没问题，一旦用户追加上下文就露馅："你刚才不是说要把那个字段改成 LocalDateTime 吗？"模型说："什么字段？"——这就是典型的 AI 失忆症。

4.2 改造后的代码：记忆系统加持

改造后的逻辑：

public String chat(String userId, String sessionId, String userInput) { // 1. 从记忆里取该会话的历史上下文 List<ChatMessage> context = memoryManager.getContext(userId, sessionId); // 2. 把用户当前输入作为新的 user 消息追加到上下文末尾 List<ChatMessage> requestMessages = new ArrayList<>(context); requestMessages.add(new ChatMessage("user", userInput)); // 3. 用完整上下文调用模型 AIResponse response = modelClient.chat(requestMessages); String reply = response.getReply(); // 4. 把这一轮对话存回记忆 memoryManager.remember(userId, sessionId, userInput, reply); return reply; }

区别很明显：第 1 步先查历史，第 2 步把当前输入拼到历史后面，第 3 步带着上下文去问模型，第 4 步把新对话归档。四步走完，模型每次都能看到完整的聊天记录，再也不用"重新自我介绍"了。

实际对接模型调用时，如果 SDK 接收的是字符串拼接格式，你就在 getContext 方法里加一个 toPrompt()：

public String toPrompt(List<ChatMessage> messages) { StringBuilder sb = new StringBuilder(); for (ChatMessage msg : messages) { sb.append(msg.getRole()).append(": ").append(msg.getContent()).append("\n"); } return sb.toString(); }

但这段代码我一般只做兼容用，生产环境还是推荐用结构化消息格式。

需要补充一点：同一会话可能有并发写入。比如用户在 Web 端快速点击，连续发了两条消息，后台可能同时触发两次 chat 方法。两次同时调用getContext，拿到的是同一份历史，然后各自追加、各自调用模型、各自保存。第二次保存时，会覆盖第一次的上下文，造成消息丢失。解决思路是在 remember 方法上加同步锁，或者使用分布式锁。单机场景最简单的方式是给每个 sessionId 建一个锁对象：

private final Map<String, Object> sessionLocks = new ConcurrentHashMap<>(); public void remember(String userId, String sessionId, String userInput, String assistantReply) { Object lock = sessionLocks.computeIfAbsent(sessionId, k -> new Object()); synchronized (lock) { // 先检查历史再追加，防止覆盖 List<ChatMessage> history = store.getHistory(userId, sessionId); // 业务判断是否已有相同输入，再做追加 store.saveMessage(userId, sessionId, new ChatMessage("user", userInput)); store.saveMessage(userId, sessionId, new ChatMessage("assistant", assistantReply)); } }

这个方案在单机多线程场景够用。分布式场景需要换 Redis 分布式锁，但思路一样。这里不能直接用String.intern()做锁，因为字符串池不可控，容易内存泄漏。

4.3 实测数据：裁剪到底有没有用

我在本地做了一组实测，数据很直观。假设模型的上下文窗口是 4096 Token，一个简单的问答会话，用户发了 30 条消息，每条消息约 200 字符。

不做裁剪的请求模型，前 10 条消息就把 4096 Token 用完了，后面 20 条消息直接被截断。模型回答时，"记得"前 5 轮的内容，对第 15 轮的问题完全没有概念。做裁剪后，前 20 条消息被压缩或丢弃，保留了最近 10 轮 + system 指令。模型回答时，能准确引用最近 5 轮内的信息，回答相关度明显提高。

这就是裁剪的价值。它不追求完美记住所有内容，而是保证模型在有限的窗口内，用最优的信息回答问题。

5. 常见问题与排查技巧实录

5.1 内存存储的服务重启后记忆全丢

这是我见过最多的"Bug"——开发时用InMemoryMemoryStore一切都好，一旦部署上线，每次重启，用户对话从头再来。原因显而易见：内存存储的生命周期和 JVM 一样，JVM 停了，数据就没了。

排查步骤很简单：

1. 确认MemoryStore用的是哪个实现类，是不是生产配置文件里误用了内存版。
2. 换成JdbcMemoryStore，并确认数据库表已初始化。
3. 重启服务后调用getHistory，看是否能从库里查到历史记录。

需要强调的是，这个切换不能只在代码层面改，还要在测试环境模拟一次真实的"重启-恢复"流程，确保数据库连接池、表结构都已就绪。

5.2 Token 超限报错，但裁剪明明已经生效了

这种情况通常是你估算的 Token 和真实 Token 差距太大。前面提到的estimateTokens方法用的是估算值，如果模型 Tokenizer 对某些语言的切分方式和你的估算逻辑差异很大，就会出现"估了 4000，实际 4500"的情况。

我的处理建议：

• 将estimateTokens的系数从 0.7 调整为 0.6 或 1.0，根据实际场景校准。
• 如果你的 SDK 支持获取精确 Token 数的方法，直接替换。
• 在maxTokens上留安全余量，比如模型窗口 4096，设置maxTokens = 3800，留出 300 Token 给系统回复用。

这个"留余量"的思路非常重要。上下文窗口是总 Token 上限，其中对模型回复的 Token 数也有限制，一般会与输入 Token 共享总窗口。你在组装输入时就把窗口占满，那模型回复时就会超限报错。

5.3 模型突然"忘记"了 system 指令

明明 system 消息一直在，为什么模型行为突然偏离指令？

原因在于裁剪策略为了让更多对话消息进入窗口，可能把 system 消息挤出去了。如果你写的裁剪逻辑是简单的"超了就从头删"，那第一条被删的就是 system。

排查方式：

• 打印getContext返回的消息列表，看第一条角色是不是system。
• 检查裁剪代码，确保system消息被跳过，永不参与丢弃逻辑。
• 如果你没有显式设置 system 消息，建议在getContext组装时强制插入。

强制插入参考代码：

public List<ChatMessage> getContext(String userId, String sessionId) { List<ChatMessage> history = store.getHistory(userId, sessionId); List<ChatMessage> trimmed = trimToFit(history, maxTokens); List<ChatMessage> result = new ArrayList<>(); result.add(new ChatMessage("system", "你是一个智能助手，请用简洁专业的语言回答问题。")); result.addAll(trimmed); return result; }

这样做能保证 system 指令永远在上下文的开头位置，无论历史怎么裁剪。

5.4 多轮对话串场：A 会话的消息跑到 B 会话里

这个问题最隐蔽。表象是用户聊着聊着，AI 突然说出了另一个话题的内容。排查下来，大概率是内存版存储的 key 设计出了问题。

我之前就犯过这个错，只用了sessionId做 Map 的 key，没跟userId关联。结果用户 A 和用户 B 的会话 ID 相同（比如 database id 从 1 开始自增），就串了。

正确的姿势是：所有查询和保存都必须同时带上userId和sessionId，把这两个字段当作一个复合主键来看待。这也是我在 3.2 节把存储结构设计成两层 Map 的原因——外层按用户隔离，内层按会话隔离，两层都查不到才允许返回空。

生产环境排查时，可以写一个简单的 SQL 验证同一 session_id 是否出现在不同的 user_id 下面：

SELECT user_id, session_id, COUNT(*) FROM chat_memory GROUP BY user_id, session_id HAVING COUNT(*) > 0 AND user_id IN ('u1','u2') AND session_id IN ('s1');

如果结果里出现了不该出现的配对，说明数据写入层的业务逻辑没隔离干净。

5.5 历史消息无限膨胀，占用存储空间过大

对话历史是只增不减的数据，时间长了，数据库里会堆积海量消息。用户隔十天半个月回来看一眼之前聊的内容，其实这些冷数据完全可以归档或清理。

我推荐的策略：

• 热数据保留最近 30 天，存业务表。
• 超过 30 天且会话未再活跃的，转入历史归档表或直接删除。
• 定期任务（比如每天凌晨）执行清理，用定时任务框架调一个cleanExpiredSessions方法。

具体实现上，只需要在表里加一个last_active_time字段，每次保存消息时更新。清理时执行：

DELETE FROM chat_memory WHERE last_active_time < DATE_SUB(NOW(), INTERVAL 30 DAY);

至于保留多少天，取决于你的业务形态。如果是客服场景，建议保留 90 天；如果是个人助手工具，30 天够用。这里给一个提醒：删除不可逆，建议先备份导出，再删。

6. 从第七课延伸：ChatMemory 之外，还有哪些上下文管理大招

写到这里，"ChatMemory" 本身的功能已经全部落地了。但聊到上下文管理，我觉得有必要提几个往上走的扩展方向，毕竟咱们是 Java 程序员搞 AI 转型，眼光不能只停在一个聊天记忆组件上。

第一个方向是向量检索增强记忆。当历史对话非常多，多到连摘要都放不下时，可以把历史消息向量化后存入向量数据库。每次用户提问，先向量化用户消息，在历史库里做相似度检索，找出最相关的几轮对话作为上下文。这个方案适合长周期记忆场景，比如 AI 助手要记得用户三个月前提过的偏好。它的优势是不会丢细节，代价是需要额外的向量数据库依赖。

第二个方向是记忆分级。结合业务，把记忆分成短期工作记忆和长期知识记忆。短期记忆就是最近几轮对话，长期记忆是用户画像、业务偏好等结构化信息，可以存 Redis。调用模型时，短期记忆进 messages，长期记忆转成一段描述文本附加到 system 消息里。

第三个方向是对话状态跟踪。在对话流程里抽象出"槽位"的概念，比如订机票场景需要出发地、目的地、日期，模型一轮轮地问，每问到一个就填一个槽位。ChatMemory 可以帮助管理槽位状态，在上下文过长时，优先保留未填满的槽位相关信息。

这些方向放在后面去展开。就当前阶段，把 ChatMemory 这套对话历史的存取、裁剪、持久化基本功练扎实，已经足够让你在大部分 AI 应用项目里游刃有余了。

我个人在实际开发中的一个体会是：上下文管理没有一个放之四海而皆准的完美方案，它是在"记住多少"和"能记住多久"之间做权衡。刚开始你可以用最简单的全量存储 + 末尾裁剪策略跑通业务，等产品形态稳定了，再逐步引入摘要压缩、向量检索这些进阶手段。千万不要一上来就上一套复杂的记忆体系，那只会让问题翻倍。