Nexus Agent会话记忆管理：无记忆、滑动窗口与摘要压缩三种策略的实战取舍

会话记忆管理是构建生产级 AI 对话系统时最容易被忽略、却又直接影响体验的关键环节：把 20 轮对话全塞给模型，Token 成本扛不住；只带最近几轮，又可能丢掉关键上下文。Nexus Agent是一个企业级 AI 智能体平台，围绕"上下文完整性 vs Token 成本"这一核心矛盾，提供了无记忆、滑动窗口、摘要压缩三种可切换的会话记忆策略，完整展示了生产环境下该如何取舍。

为什么会话记忆策略会直接影响成本

先想一个具体场景：用户和助手聊了 20 轮，第 21 轮再问一个追问。此时你有三种直觉做法：

• 全量携带历史：上下文最完整，但每次请求都要为 20 轮历史重复付费，Token 成本随轮数线性上涨；
• 只带最近几轮：便宜了，但第 1 轮里确认的"版本号是 2.4"到第 21 轮就被挤出去了，模型开始"断片"；
• 压缩历史再携带：用一份短摘要承载早期信息，成本可控且不丢关键结论——但要额外调用一次模型做摘要，还可能有压缩失真。

这三种做法正好对应 Nexus Agent 提供的三种会话记忆策略。它们的定位不是"谁替代谁"，而是按业务场景各取所需：

无记忆对话：最简单的策略，适合一次性查询

无记忆模式最直接：每轮请求只发 system prompt + 当前问题，不读取任何历史。

它的效果非常"诚实"——第一轮问"Spring Bean 的作用域有哪些"答得很好，第二轮接着问"那它默认是哪一种"，模型完全不知道"它"指什么，直接断片。对应实现是 NoMemoryChatService.java，整个对话过程无状态、不存储。

适用判断：如果你的产品是"一问一答"（查汇率、翻译短句、工单初筛），无记忆不仅省成本，还能避免历史脏数据干扰本轮回答。

滑动窗口记忆：配置简单，但要清楚它丢了什么

滑动窗口策略保留最近 N 轮完整对话，更早的消息被直接挤出窗口。Nexus Agent 的演示实现 SlidingWindowMemoryChatService.java 基于 Spring AI 的MessageWindowChatMemory，有一个新手容易踩的细节：

⚠️ 窗口裁剪的粒度是消息条数而不是轮数。一轮对话 = 1 条用户消息 + 1 条助手回复，所以配置maxRounds=3时，实际窗口大小要换算成3 × 2 = 6条消息。

窗口的实际内容可以随时查看，演示模块提供了/memory/sessions/{sessionId}快照接口，能直接看到最老的消息已经被挤出去——这一点在调试"为什么模型忘了前面说的"这类问题时非常有用。

适用判断：短期连续追问（客服工单、导购问答）用滑动窗口就够了；一旦对话可能拉长到窗口之外，早期关键信息就会静默丢失，需要升级到摘要压缩。

摘要压缩记忆：生产环境最推荐的方案

摘要压缩是 Nexus Agent 生产链路中默认启用的方案（enabled = true），核心思想一句话：最近几轮保留原文，更早的历史增量压缩成长期摘要，两者拼起来作为本轮上下文。

摘要压缩怎么工作：长期摘要 + 最近原文窗口

完整实现在 PersistentConversationMemoryService.java，流程可以拆成四步：

1. 加载记忆上下文：编排阶段调用loadMemoryContext(conversationId)，把"长期摘要 + 最近对话原文"组装成assembledHistory，供问题改写和 Prompt 组装使用；
2. 判断是否需要压缩：只统计已完成（COMPLETED）的稳定轮次，超出保留窗口（默认最近 4 轮）的部分才进入压缩队列；
3. 增量压缩：摘要记录着covered_exchange_id（已覆盖到的最后一条轮次 id），只处理新增的溢出轮次，且单次最多推进 6 轮（compressionBatchTurns），避免一次喂给模型超长历史；
4. 持久化快照：每次压缩后写入 MySQL 摘要表，应用重启后记忆不丢失。

值得注意的细节是：摘要不是"一大段自由文本"，而是一份结构化载荷，固定分为 7 个板块——长期会话摘要、会话目标、已确认事实、用户偏好与约束、已解决问题、待跟进问题、检索提示。每个板块有独立的条数和长度上限（如单条不超过 80 字符、每板块最多 6 条），从结构上防止摘要本身失控膨胀。

关键参数速查

摘要压缩的核心参数集中在 ChatRagProperties.java 的HistorySummaryProperties中，均可通过app.chat.rag前缀配置：

这套默认值意味着：无论聊了 10 轮还是 100 轮，进入模型的"记忆部分"始终被约束在2200 + 1400 字符以内，成本可预期。

兜底设计：摘要生成失败会怎样

生产环境的稳健性体现在两个"防崩"细节上：

• LLM 摘要失败时自动降级：合并摘要依赖一次模型调用，如果调用异常或返回的 JSON 解析失败，会回退到规则式压缩（fallbackMerge）——直接截取每轮的用户关注点和已有结论拼接，保证记忆链路不断；
• 异步预热线上不阻塞：一轮对话结束后，BusinessChatService.java 会异步触发摘要刷新（refreshConversationSummaryAsync），跑在独立线程池上，并用会话 id 集合防止同一会话并发重复压缩——用户感知不到摘要开销。

摘要数据落在 MySQL 的nexus_agent_chat_memory_summary表（见 create_table_mysql.sql），其中covered_exchange_id、compression_count、summary_version三个字段分别支撑增量压缩、可观测和版本追踪。如果怀疑摘要质量，还可通过管理端点/session/summary/rebuild一键重建。

怎么选：三种策略的实战取舍

一句话决策指南：

• 🟢无记忆：会话天然是"一问一答"，或历史本身就是噪声 → 省到最少；
• 🟡滑动窗口：追问集中在最近几轮，对话寿命短 → 配置最简单、零额外模型调用；
• 🟢摘要压缩：对话可能跨天、跨会话继续，早期结论（版本号、约束条件）必须长期保留 → 生产环境默认选择。

经验上还有一个组合用法：摘要压缩本身就包含一个最近原文窗口（keepRecentTurns），所以它实际上已经是"滑动窗口 + 长期摘要"的超集——大多数场景直接用它，再靠开关退化为纯窗口模式即可。

动手对比：memory 演示模块

想直观感受三种策略的差异，可以直接跑项目的演示模块（详细说明见 README.md）：

mvn -pl ai-example/ai-example-memory/ai-example-spring-ai-memory -am spring-boot:run

启动后（默认http://localhost:8091），建议按这个顺序体验：

1. /memory/no-memory/chat—— 快速看到"第二轮就断片"；
2. /memory/sliding-window/chat—— 观察最近几轮能记住、更早的丢失；
3. /memory/summary/chat—— 验证历史不会完全丢失；
4. /memory/compare—— 压轴演示：同一个多轮脚本，三种策略的回答、当前摘要内容和压缩触发次数一次性展开对比。

小结

会话记忆管理没有银弹，本质是在 Token 成本、上下文完整性和工程复杂度之间做取舍。Nexus Agent 用三种策略把这个取舍具象化了：无记忆演示了成本下限，滑动窗口演示了"够用就好"，摘要压缩则给出了生产级答案——结构化摘要、增量压缩、失败降级、持久化快照，每个环节都做了工程化兜底。理解了这三层设计，你在自己的 AI 项目里做记忆方案选型时，也就有了完整的参照系。

更多项目背景可参考项目根目录的 README.md。