多轮对话变长时，如何控制上下文长度并选择压缩策略？

核心回答

控制上下文要区分完整历史的存储和本轮模型的输入。历史保存在 Redis 或检查点里，不代表模型会自动读到；本轮不发送旧消息，也不必删除原始记录。调用前应统计指令、工具定义、历史和工具结果的 token 占用，按模型窗口预留输出空间，在超限前处理长输入。

再按信息的后续用途选择策略：

• 保留原文：近期讨论、最新更正，以及需要精确引用的内容。
• 直接裁剪：已经结束、与当前任务无关的过程。
• 抽取或摘要：把当前目标、仍生效的约束、已确认进度和待核验事项整理成简短状态。
• 外置并按需取回：长网页、报告和旧材料放在外部存储，需要时再读取相关原文。

例如报告范围从“上半年”改成“第二季度”，摘要要保留新范围和原有的来源要求。取舍是否合理，要用多轮任务检查约束、更正和关键事实有没有丢；质量达标后，再比较 token、耗时与成本。

下面用一个 32,000 token 的预算例子，把“保留、裁剪、摘要、外置”四种处理方式放在一起比较。报告范围发生更正时，也要把新约束带入下一轮。

先找到占用来源，再决定在哪里处理

轮数不能代替容量：十轮短问答可能很小，一次工具调用返回整份网页就可能很大。应在模型调用前，检查实际要发送的完整输入，而不只是用户聊天记录；工具返回后继续执行时，还要重新检查。

如果大头是工具结果，优先在源头缩小返回范围：数据库只查需要的列和行，搜索先给候选和摘要，阅读工具按章节或片段取原文。需要保留全文时，可以保存全文并返回可回查的位置。这样比“每次取回全部内容，再调用模型总结”少一次不必要的长输入，也降低摘要丢信息的风险。

如果大头是旧对话，就区分仍生效的要求、已经完成的过程和后续可能回查的材料。压缩要提前触发，因为摘要模型本身也要读得下待压缩内容；触发点还受最大输出、近期长消息和预期工具返回大小影响，没有通用的“用到窗口 75% 就一定安全”。只按消息条数保留也不保险，一条消息可能比前二十条还长。

把窗口预算换算成可用输入

假设某模型允许输入与输出合计最多 32,000 token，为输出预留 4,000，再留 2,000 作为计数误差和输入波动的余量，本轮输入预算就是 26,000。若系统指令和工具定义已经占了 3,000，那么历史、当前用户消息、检索材料和工具结果合计最多再放 23,000 token。这些数字只是预算算例，实际还要核对目标模型独立的输入、输出及其他占用限制，余量也应结合任务调整。

如果一次工具返回就有 25,000 token，即使清空旧历史，也放不进上面剩余的 23,000。此时要缩小工具返回范围，或者把原材料外置后按章节读取、分块处理；每次用于摘要的请求也要满足摘要模型自己的输入预算。处理后重新计数，再继续原任务。只反复压缩旧对话，无法解决新材料本身就过长的问题。

用同一个报告任务选择策略

设想用户先要求“分析上半年，逐条标明来源”，中途更正为“只分析第二季度”，之后又阅读了很多网页。下一轮写报告时，当前有效范围是第二季度，旧的“上半年”已经被替代。

可以按后续用途处理这些内容：

• 保留近期原文：最新更正、正在修改的段落和未完成的工具交互要准确延续。它保真度高，但保留太多仍会占满窗口。
• 直接裁剪：已经结束、与本轮无关的话题可以不发送。做法简单、没有摘要调用成本，但机械地只留最近几轮，容易把开头的来源要求一起删掉，所以仍生效的限制要另行保留。
• 抽取或摘要：把当前目标、已确认结论、下一步和待核验事项写成简短状态。数字、引文、条款等需要精确使用的内容，优先保留必要原句和出处。摘要适合延续任务，但会有遗漏和改写风险，不能把它当成无损备份。
• 外置并按需取回：完整网页、旧报告和较早的搜索材料保留在外部，当前输入只放材料标识与必要说明。后续比较某条原文时再取回相关段落。这样节省常驻上下文，但增加检索延迟，也可能没找对材料；仅存一个网址不等于已经保存了可复用的原文版本。

本例的摘要可以写成：

当前任务：只分析第二季度；每条结论标明来源。

范围变更：最初的“上半年”已被用户更正，不再采用。

已确认事实：列出核验后的要点和对应原文位置。

待核验事项：某条数据仍缺来源，不能作为定论写入报告。

下一步：补齐该来源，再修改报告的比较段落。

工作材料：当前报告版本、资料标识及可读取的原文位置。

如果摘要只剩“用户想研究近期情况，已经查过很多资料”，它虽然很短，却丢了时间范围、证据要求和下一步。反复用旧摘要生成新摘要，还可能把“准备核验”逐步写成“已经核实”。更新摘要时，把补充信息并入对应事项，去掉重复内容，按用户最新要求替换已失效的条件；资料冲突尚未核清时保留出处和待核验状态，精确引用仍重新读原文。

原消息、任务状态和长期记忆怎样分工？

原消息是可回查的记录，摘要是为下一步准备的工作状态，本轮上下文是本次实际发送给模型的内容。 三者可以同时存在，不能因为有摘要就默认原消息已经完整保留，也不能因为原消息仍在数据库里就默认它进入了本轮输入。

在 LangGraph 中，checkpointer 按线程保存执行状态，便于同一线程继续运行；Store 可以保存跨线程复用的信息。保存到数据库不会自动扩大模型窗口，后续仍要把所需内容读取并放入上下文。DeepAgents 的 StateBackend 跟随当前线程状态，适合同一线程内的临时文件和中间结果，不能仅凭“文件还在”就当作跨会话长期记忆。长期偏好是否适合沉淀，还要看后续是否确实需要跨任务使用，不能把每次临时要求都升级成永久规则。

使用摘要中间件时，通常需要配置由哪个模型摘要（model）、什么时候触发（trigger）、保留多少近期原文（keep）。这些参数解决触发和保留范围，摘要内容该保留什么仍要围绕任务设计。

裁剪还要保持消息协议合法：工具调用和相应结果应按模型接口要求成组保留或移除，避免留下孤立的工具结果；未完成调用要保留恢复执行所需状态。系统指令、身份和权限由应用的可信配置管理，不能让自由生成的摘要成为授权依据。

追问：怎么判断取舍是否合理？

换成更大窗口，还需要压缩吗？ 可以降低压缩频率。一次只分析少量长文，直接保留全文也可能更合适；多轮研究持续带上所有旧网页，则要比较实际输入成本、延迟和噪声影响。能装下，只能说明没有超过容量，不能证明所有内容对当前任务都有用。

如何确认没有压坏？ 固定一批多轮任务，让原方案和压缩方案完成相同目标。除了最终答案，还检查几个容易丢失的点：开头的限制、中途更正、隔很多轮才再次用到的数字，以及已经完成和待完成事项的区别。本例就看报告是否只覆盖第二季度、来源是否正确、待核验内容是否仍保持未确定状态。对于需要重取资料的方案，还要检查是否能读回正确版本；质量达标后，再比较输入 token、额外摘要/检索调用、总耗时和成本。

对应教程

参考资料