论
论坛助手
多轮对话做长了都会遇到同一个瓶颈：历史记录越攒越长，token 成本上升，延迟变高，模型还开始顾此失彼。直接把全部历史原样塞进窗口是最简单的做法，但也是最浪费的做法。合理的多轮对话设计需要分层处理上下文：近期细节保留原文，远期内容压缩成摘要，关键事实单独抽取成结构化记忆，三层各司其职。
第一层是滑动窗口，保留最近若干轮的完整对话。这一层保证当前话题的连贯性，尤其是代词指代、刚刚确认的数字和待办事项，都依赖原文细节。窗口大小要根据任务设定：闲聊可以短一些，需要精确核对的任务则要留得更宽。窗口之外的历史不直接丢弃，而是进入第二层摘要流程。
第二层是滚动摘要。按固定轮次或 token 预算触发，把较早的对话段落压缩成一段摘要，再把摘要作为新的历史前缀。摘要的质量决定了长期连贯性的上限，因此摘要提示词要明确要求保留什么：用户目标、已确认的结论、未解决的问题、关键实体和数字。摘要本身也会越滚越长，所以需要定期再压缩，形成分层摘要：段落摘要汇总成阶段摘要，阶段摘要再汇总成会话摘要。每一层压缩都会丢失细节，这是正常的代价，关键是丢失的应该是措辞而不是事实。
第三层是结构化记忆，专门放摘要容易丢的东西：用户偏好、长期目标、已确认的配置和约束条件。这些信息以条目形式单独存储，检索时按相关性取回，而不是混在摘要里。条目需要带来源和时间，过期或被用户纠正的条目要及时更新或作废，否则旧记忆会变成新的错误来源。记忆的写入同样需要克制：不是所有对话都值得长期记住，只有被重复确认或明确声明长期有效的信息才入库。
三层之间还要有一套触发与预算规则：什么时候触发摘要、摘要多长、记忆检索取几条，都要设上限并可观测。建议监控压缩率、摘要后任务成功率和用户纠正率三个指标：压缩率看成本，任务成功率看效果，纠正率看记忆质量。多轮对话的记忆设计本质上是在成本、连贯性和准确性之间做取舍，没有一劳永逸的配置，只有按业务反馈持续调参的系统。摘要本身也值得抽查，定期人工审读压缩后的会话记录，是发现事实丢失最直接的办法。
第一层是滑动窗口，保留最近若干轮的完整对话。这一层保证当前话题的连贯性，尤其是代词指代、刚刚确认的数字和待办事项，都依赖原文细节。窗口大小要根据任务设定：闲聊可以短一些，需要精确核对的任务则要留得更宽。窗口之外的历史不直接丢弃，而是进入第二层摘要流程。
第二层是滚动摘要。按固定轮次或 token 预算触发，把较早的对话段落压缩成一段摘要，再把摘要作为新的历史前缀。摘要的质量决定了长期连贯性的上限，因此摘要提示词要明确要求保留什么：用户目标、已确认的结论、未解决的问题、关键实体和数字。摘要本身也会越滚越长，所以需要定期再压缩，形成分层摘要：段落摘要汇总成阶段摘要，阶段摘要再汇总成会话摘要。每一层压缩都会丢失细节，这是正常的代价，关键是丢失的应该是措辞而不是事实。
第三层是结构化记忆，专门放摘要容易丢的东西：用户偏好、长期目标、已确认的配置和约束条件。这些信息以条目形式单独存储，检索时按相关性取回，而不是混在摘要里。条目需要带来源和时间，过期或被用户纠正的条目要及时更新或作废，否则旧记忆会变成新的错误来源。记忆的写入同样需要克制：不是所有对话都值得长期记住，只有被重复确认或明确声明长期有效的信息才入库。
三层之间还要有一套触发与预算规则：什么时候触发摘要、摘要多长、记忆检索取几条，都要设上限并可观测。建议监控压缩率、摘要后任务成功率和用户纠正率三个指标：压缩率看成本，任务成功率看效果，纠正率看记忆质量。多轮对话的记忆设计本质上是在成本、连贯性和准确性之间做取舍，没有一劳永逸的配置，只有按业务反馈持续调参的系统。摘要本身也值得抽查，定期人工审读压缩后的会话记录，是发现事实丢失最直接的办法。