主要设计一个分层记忆管理机制：

第一层是滑动窗口记忆，保留最近5轮对话的完整内容，这部分存在reids，甚至直接放入prompt中，保证对话的连贯性。

第二层是摘要记忆（摘要压缩），当对话轮数超过5轮时，会把第5轮之前的对话进行摘要压缩。摘要会保留关键信息，比如用户提到的核心问题、重要参数、已经解决的问题等，把10轮对话压缩成2-3句话。

第三层是重要性过滤，所有历史对话都会向量化存储在向量数据库中。当用户提到"之前说的那个问题"时，可以通过向量检索找回历史对话内容。

这三层记忆相互配合，既保证了短期对话的连贯性，又支持长期对话的信息检索，还避免了上下文窗口溢出的问题。

在实现上，我会在每次调用大模型前检查token数量，如果超过阈值（比如上下文窗口的80%），就触发摘要压缩逻辑。这样可以确保系统稳定运行。

1.滑动窗口（时间维度）

  • 实现原理：保存当前 Session 最紧密、最准确的上下文。

  • 工程落地：

  • 通常以 session_id 为 Key 存储在 Redis 或本地内存中。

  • 使用 Sliding Window（滑动窗口） 策略，仅保留最近 K 轮（例如最近 5 轮）的原始对话记录 []schema.Message。

  • 作用：保证模型能准确理解指代消解（如“它”、“这个接口”）、上下文语境和即时逻辑。

2. 摘要记忆 （时间维度）

  • 实现原理：当对话轮次增加，滑动窗口之外的历史对话会被压缩成一段结构化摘要（Summary）。

  • 工程落地：

  • 当滑动窗口滑过第 K 轮之前的内容时，后台触发一次后台异步的 LLM 调用（压缩任务），提示词如：“请将以下历史对话压缩为 3 句以内的摘要，保留核心问题、已提取的参数（如 req_id、服务名）和已得出的结论”。

  • 这个摘要会作为固定节点放在 System Prompt 的 [History Summary] 区域。

3. 重要性过滤（内容维度）

4.Prompt Caching（计算层）

如果输入的系统指令与对话历史暂时没有变化的话，只有问题变化，那么大模型计算的时候，只需要重新把当前的问题转化为向量开始计算。