上下文压缩

它是什么

上下文压缩是在尽量保留当前任务关键信息的前提下，减少模型需要处理的上下文 Token。常见方式包括用摘要替换完整历史、删除过时或低价值片段，以及把原文转换为更紧凑的 Token 表示。[S1][S2] 它处理的是输入信息量，不等同于缓存重复 Token 的计算结果。

为什么需要它

长对话和代理任务会累积消息、日志与工具结果，最终接近窗口上限，并增加成本、时延和干扰。直接截掉最早内容可能丢失目标与决定；完整保留又会挤压新证据和输出空间。压缩试图在连续工作能力与信息保真之间建立可测量的折中。

它如何工作

摘要式压缩提取目标、决定、约束、进度和未完成事项，再用摘要替换部分历史；选择性编辑会清除已经失效的工具结果等内容；LLMLingua 一类方法则按预算评估信息重要性并删除部分 Token。[S1][S2] 无论使用哪种方式，应用都应保存原始记录、标记压缩发生的时间，并在关键节点检查状态是否完整。

必须澄清的误会

上下文压缩 ≠ 长上下文。 长上下文是模型一次能装多少的容量；压缩是容量不够时的应对手段。容量变大也取消不了压缩，因为成本与注意力都会退化。

上下文压缩 ≠ 对话上下文。 对话上下文是待压缩的原料，压缩是对它做的处理动作。

真实例子

研究助手分析二十份报告后，不必把每次搜索结果永久留在对话中。它可以把已确认结论、出处 URL、争议点和待查问题写入结构化摘要，删除重复搜索片段，并把原始材料保存在外部文件。下一轮从摘要继续，需要核对时再按出处取回原文，而不是把摘要当作最终证据。

什么时候适合与不适合

压缩适合长周期、信息重复且中间产物可外部保存的任务。不适合必须逐字引用、精确维护大量变量或依赖早期细节的场景。压缩本质上可能有损：摘要会遗漏，Token 级删除会改变表达；Anthropic SDK 的客户端压缩还可能在工具响应待处理时触发，需要按具体实现处理续接边界。[S1][S2] 压缩率高不代表任务质量高。

亲自试一下

选一段包含十项事实、三项决定、两项未完成任务和出处的长对话，先制作不超过原长度三分之一的摘要。让另一位读者只看摘要完成五个固定问题，再与原文结果比较。记录遗漏、错误归因、Token 节省和恢复原文所需步骤；任何关键约束丢失都应判定为压缩失败。

接下来学什么

先理解上下文窗口的容量约束，再用上下文工程决定什么值得保留；对于可按需取回的材料，继续学习检索上下文和长期记忆。

来源与修订

Token 级预算压缩与实验结果参考 LLMLingua 论文 [S1]；摘要替换、选择性清除及版本依赖参考 Anthropic 上下文编辑文档 [S2]。具体触发阈值、服务端行为和 SDK 参数变化较快，正文只保留方法与风险边界。