多轮对话记忆如何分级管理，并设计缓存策略？

核心回答

平台为同一个应用的连续修改保留三类对象：MySQL 保存展示用对话历史，Redis 支撑模型使用的消息窗口，Caffeine 缓存应用的 AI 服务实例。窗口按 appId 定位，配置最多20条消息；服务实例按应用与生成类型复用，减少重复创建和历史装载。

用户继续修改同一应用时，模型结合当前窗口与新要求生成或调整代码。服务实例需要重新创建时，再从数据库取最近历史回装窗口。因此，历史是可回看的记录，窗口是本轮模型上下文，实例缓存是运行对象的生命周期管理，不能把三者都叫作长期记忆。

一次请求与历史回装怎样连接

聊天入口先检查应用归属，将本轮用户消息写入数据库，再通过 AiCodeGeneratorServiceFactory 获取服务。工厂使用 appId + codeGenType 作为 Caffeine 键，缓存未命中时才创建实例。

创建时构造 MessageWindowChatMemory：以 appId 为 ID，接入 RedisChatMemoryStore，设置 maxMessages(20)。这里是20条消息，不是20轮对话，也不是 Token 上限。随后调用 loadChatHistoryToMemory()，按应用查询最近20条数据库历史；查到记录后反转为时间正序，先清空当前窗口，再把用户、AI 展示消息分别转成 UserMessage、AiMessage 加入。缓存命中时不会每轮重做这段装载。服务工厂和历史回装方法展示了这个顺序。

数据库回装恢复的是这些展示消息，不是先前完整的工具调用对象、调用 ID 和 ToolExecutionResultMessage 轨迹。对继续改代码的任务，历史可以说明用户之前提出过什么，当前项目文件仍是判断代码现状的依据；不能仅凭一段旧回答认定某个文件已经修改成功。

缓存策略与连续修改的取舍

Caffeine 配置最多1000个服务实例，并设置写入后30分钟、访问后10分钟的过期策略；它控制服务对象的复用，不负责提取用户偏好。Redis 消息存储另有 TTL 配置，数据库历史不会因为本地实例被淘汰而自动删除。

例如用户先要求生成表单，再要求“提交时显示加载状态”，近期窗口能保留这次修改的背景；较早的具体实现已经移出窗口时，应按需读取当前文件或相关历史，而不是无限扩大窗口。消息数窗口简单直接，但单条代码很长时仍可能超出模型预算，后续可评估 Token 窗口或保留关键修改摘要。

同一应用的请求会复用相应记忆和代码目录，实例缓存不等于请求互斥。若允许并发修改，需要另行设计应用级串行或版本检查；当前配置本身没有保证这些语义。

参考资料

• 国内：JavaGuide：Agent 记忆系统：参考工作记忆、跨会话事实与记忆读写生命周期，组织通用分级，并解释保存聊天记录不等于完成长期记忆提取。
• 国内：zero2Agent：记忆与上下文：采用状态、模型上下文与持久记录的区分，解释回装历史和恢复完整执行轨迹是不同目标。
• 国内：WeThinkIn：记忆与上下文工程：参考作用域、版本和派生副本的管理，说明缓存键与失效策略为何需要对应具体主体和数据。
• 国内：阿里云百炼：长期记忆：借鉴从对话提取特定事实、按记忆主体召回的方式，说明长期偏好与普通消息窗口、对象缓存的区别。
• 国外：LangChain4j：Chat Memory：依据 Memory 与 History、消息窗口与存储接口的区别，解释模型可见消息和完整展示历史，以及消息数限制的含义。
• 国外：Caffeine：Eviction：依据容量、写入过期和访问过期策略，解释服务实例缓存的生命周期与窗口、历史保留策略为何分开。