大模型本身是无状态的每次调用都是独立的。所谓的“记忆”本质上是工程侧对输入上下文的动态管理策略。核心目标是在成本、延迟、记忆长度三者之间取得平衡。我通过长期摘要短期滑动窗口实现记忆。前端LocalStorage只存展示数据传给LLM的是‘增量摘要 最近5轮原文’。摘要异步生成避免阻塞关键实体单独抽取防止信息丢失。同时支持云端持久化实现跨会话记忆。这个方案在成本和效果之间取得了平衡已在项目中稳定运行。一、完整标准流程拆解分两层各司其职持久展示层LocalStorage 存全部原始完整对话作用是给用户看 这里不做任何压缩、删减原样存储用户提问 模型完整回复页面刷新、关闭重开完整聊天记录不丢失侧边历史记录、历史对话列表展示完整问答原文永久保存全量对话不会丢失早期聊天细节。LLM 推理层传给 LLM采用增量摘要 滑动窗口双轨制——①最近对话原文按 Token 数量动态截断而非硬编码轮数每次从最新消息开始往前累加 Token直到达到上限如 4000 tokens保证绝不超出模型上下文窗口同时保留最近的交互细节保证上下文连贯 【原想法是截取最近 5~8 轮完整对话---------但是如果一轮对话就有2000字8轮直接撑爆窗口了】② 早期历史摘要采用增量摘要每次只把旧摘要 本轮新增的 N 轮对话压缩成新摘要确保摘要生成的 Token 消耗恒定为 O(1)不随对话总长度线性增长③ 强制抽取关键实体时间、人名、ID、数字、核心决策随摘要一起结构化保存防止纯文本摘要丢失关键细节④ 最终拼接「历史摘要 关键实体清单 最近动态截断的原文 当前用户新问题」作为 Prompt 输入大模型。【为什么把’当前用户新问题’放在最后--------因为大多数LLM对输入末尾的注意力权重更高把当前问题放最后能让模型更聚焦于用户当下的诉求。】二、这么拆分的两大核心好处兼顾用户体验与接口成本用户侧能随时翻阅全部完整聊天记录不会丢失任何原文服务侧传给大模型的文本大幅缩短Token 消耗显著降低不会超出模型上下文窗口推理速度更快、幻觉更少。解耦不冲突本地存储的完整数据和发给模型的精简上下文是两套独立数据互不干扰本地永远有完整版兜底推理只使用轻量化压缩版。
