多轮对话如何避免上下文越变越长:摘要触发点与最近消息窗口
来源:17golang原创
时间:2026-08-27 05:48:38 328浏览 收藏
客服助手上线一周后,最先暴露的通常不是模型不会回答,而是同一个会话聊到几十轮以后,旧约束悄悄消失:用户说过“只查华东仓”,后面的摘要只留下了“查库存”,模型于是把全国结果混进来。解决办法不是把窗口一味做大,而是把历史消息分成可压缩内容、必须保留的事实和最近对话三层,并在接近预算时才触发摘要。
- 用输入 token 预算决定摘要触发点,不等请求失败才处理。
- 保留一份带来源的关键事实,摘要只覆盖更早历史。
- 最近消息按 token 预算保留,压缩后用固定回放样例检查约束和未完成动作。
先把上下文拆成三块,再决定删什么
一个稳定的请求上下文可以写成:
系统规则 + 关键事实 + 最近消息窗口 + 本轮用户问题
系统规则负责行为边界,关键事实保存用户明确给出的约束,最近消息窗口保留语气、指代和正在进行的动作。最早的闲聊、已经完成的搜索过程和重复解释,才适合进入摘要。这里别急着按消息条数截断,因为一条很短的消息可能包含“不要修改生产库”这样的高价值约束。
| 区域 | 默认处理 | 不能丢的内容 |
|---|---|---|
| 系统规则 | 每次都带上 | 安全边界、工具权限、输出格式 |
| 关键事实 | 结构化保存 | 范围、偏好、已确认参数、未完成任务 |
| 最近消息 | 保留最近 6–12 轮 | 当前指代、错误信息、用户刚改的要求 |
| 更早历史 | 摘要或移除 | 只保留仍影响当前任务的结论 |
摘要触发点不要等到请求失败才处理
触发点应该由预算倒推,而不是等接口返回“上下文过长”。假设模型上下文上限是 128000,给输出预留 4096,系统还需要 8000 的安全余量,那么历史区的目标上限大约是:
history_budget = 128000 - 4096 - 8000 - current_user_tokens
实际项目里可以在达到历史预算的 70%~80% 时启动压缩,给摘要请求和重试留出空间。摘要请求本身也要使用独立的小窗口,不要把全部原文再塞回去。
if estimated_tokens(system + facts + recent + current) > history_budget:
summary = summarize(older_messages, keep=facts_and_open_tasks)
context = system + facts + summary + recent + current
估算值不必假装精确。只要 tokenizer、模型和计费口径保持一致,触发点稳定比“刚好卡在上限前”更重要。
关键事实要带来源,摘要不能凭空改写约束
建议把摘要结果和事实分开存储。事实不是一段漂亮的自然语言,而是下一轮仍要执行的约束:
{
"scope": "华东仓",
"format": "只返回缺货商品",
"confirmed_at_turn": 8,
"source": "user_message_8",
"open_task": "等待用户确认是否导出 CSV"
}
摘要可以描述“前面已经查过华东仓库存”,但不能覆盖结构化事实中的范围字段。若摘要模型把“只看华东仓”改成“优先看华东仓”,就应该被事实一致性检查拦住,而不是继续发送给主模型。

最近消息窗口保留多少轮,取决于任务形态
固定保留 10 轮只是起点。指代密集的客服对话可能需要更多最近消息;单次任务型助手则更适合保留最近动作、工具结果和未完成清单。可以先按 token 而不是轮数截取:
recent = take_from_newest(messages, max_tokens=12000)
older = messages[0:len(messages)-len(recent)]
如果一轮包含很长的工具返回,先压缩工具原始输出,只保留查询条件、结果摘要、错误码和可追溯 ID。不要把完整日志当作聊天记忆;需要时再通过 ID 读取。
用回放样例验证压缩后有没有“记错人和事”
上线前至少准备三类回放:约束保持、指代保持和未完成动作。每类都记录压缩前的期望结果,然后在相同随机参数下运行压缩后的上下文。
- 约束保持:用户先指定“华东仓、只看缺货”,压缩后追问库存,结果中不得出现华南仓或有货商品。
- 指代保持:用户说“把第二个方案改成按周统计”,压缩后仍能知道“第二个方案”指哪一项。
- 动作保持:对话停在“等待确认后导出 CSV”,压缩后不能直接声称文件已经生成。
验收结果至少看三项:关键事实命中率、未完成任务保留率、压缩前后答案是否引入新实体。只看最终文本像不像人写的,抓不住最危险的约束漂移。

相关问题:摘要成功了,答案却更不可靠
为什么摘要越短,回答反而越容易跑偏?
因为摘要把条件和结论一起压掉了。保留“查过库存”没有保留“只查华东仓、只看缺货”,主模型当然无法恢复这些细节。短不是目标,影响当前任务的事实完整才是目标。
关键事实应该每轮都重新抽取吗?
不必每轮全量抽取。可以只对新消息做增量提取,再与已有事实合并;当用户明确说“改成”或“取消”时,要求新事实覆盖旧事实,并保留变更来源。
什么时候应该彻底开启新会话?
当任务目标、权限范围或数据主体发生变化,继续复用旧摘要的风险通常高于重新开始。新会话可以携带经过确认的少量事实,但不要直接复制整段历史。
一份可落地的上线检查清单
发布前逐项确认:是否有明确的 token 预算;是否把系统规则、关键事实、最近消息和更早历史分层;摘要是否记录来源和未完成动作;工具长输出是否可按 ID 追溯;压缩触发后是否只请求一次摘要;回放样例是否覆盖约束、指代和恢复路径。
上下文管理的核心不是让模型“记住更多”,而是让它在有限窗口里记住正确的东西。把触发点、事实存储和回放验收连成一条流水线,长对话才不会在最关键的一轮突然换了范围。
-
475 收藏
-
478 收藏
-
484 收藏
-
151 收藏
-
396 收藏
-
- 前端进阶之JavaScript设计模式
- 设计模式是开发人员在软件开发过程中面临一般问题时的解决方案,代表了最佳的实践。本课程的主打内容包括JS常见设计模式以及具体应用场景,打造一站式知识长龙服务,适合有JS基础的同学学习。
- 立即学习 543次学习
-
- GO语言核心编程课程
- 本课程采用真实案例,全面具体可落地,从理论到实践,一步一步将GO核心编程技术、编程思想、底层实现融会贯通,使学习者贴近时代脉搏,做IT互联网时代的弄潮儿。
- 立即学习 516次学习
-
- 简单聊聊mysql8与网络通信
- 如有问题加微信:Le-studyg;在课程中,我们将首先介绍MySQL8的新特性,包括性能优化、安全增强、新数据类型等,帮助学生快速熟悉MySQL8的最新功能。接着,我们将深入解析MySQL的网络通信机制,包括协议、连接管理、数据传输等,让
- 立即学习 500次学习
-
- JavaScript正则表达式基础与实战
- 在任何一门编程语言中,正则表达式,都是一项重要的知识,它提供了高效的字符串匹配与捕获机制,可以极大的简化程序设计。
- 立即学习 487次学习
-
- 从零制作响应式网站—Grid布局
- 本系列教程将展示从零制作一个假想的网络科技公司官网,分为导航,轮播,关于我们,成功案例,服务流程,团队介绍,数据部分,公司动态,底部信息等内容区块。网站整体采用CSSGrid布局,支持响应式,有流畅过渡和展现动画。
- 立即学习 485次学习