上下文压缩策略

压缩解决的是相反方向的问题：如何为上下文做减法, , 什么时候压缩、怎么压缩、为什么即使上下文没满也应该压缩。核心认知：上下文学习本质上是检索而非推理，压缩就是把需要思考才能得到的结论，变成可以直接检索的知识。

何时使用

• 工具调用结果动辄数万字符，几轮交互就撑满 128K 窗口
• Agent 在长任务中「明明窗口没满，却找不到关键信息」或反复纠结已解决的问题
• 模型在任务尚未完成前提前收尾、草率下结论
• 设计压缩策略（何时触发、压缩什么、保留什么）或排查压缩副作用
• 评估「把大任务委派给子 Agent」与「主 Agent 自己做完再压缩」的取舍

核心原则

• 三个动机，层次不同：① 长度与成本约束（窗口有限、token 越贵、延迟越高）；② 提升思考质量, , 总结后的知识比原始形式更利于模型使用，十几轮搜索的原始结果散落各处，模型每次决策都要在数万 token 中反复检索；③ 缓解上下文焦虑（Context Anxiety）, , 模型认为窗口即将耗尽时可能在任务完成前提前收尾，在未接近耗尽时就提前压缩可能提升决策质量。
• 上下文窗口是一台只有一半的检索引擎：检索这一半极强（相当于每次前向传播都内置了 RAG），但缺「提炼层」, , 上下文里的东西从来不会被自动数一遍、建索引或就地总结。任何「关于这些内容的结论」都要从原始记录现算一遍，代价随内容量 N 上涨。
• 压缩与状态栏是同一枚硬币的两面：状态栏把算好的结论加进上下文（由代码确定性维护），压缩把臃肿的原始记录换成算好的结论（多用一次 LLM 调用蒸馏）。
• 上下文腐化（Context Rot）≠ 溢出：溢出是「装不下了」，腐化是「装得下但找不到了」, , 后者更隐蔽，Agent 表面正常工作，决策质量悄然下降。注意力权重被分散到更多 token 上，无关内容一旦占大头，决策质量明显下滑。
• 主动显式提炼，不要期望模型自动学习：与其让模型被动在海量信息中检索，不如主动提供经过提炼的高密度结构化知识。
• 压缩最容易丢失：早期的架构决策、约束背后的理由、失败的路径。因此 Agent 需要定期把进展记录到文档，而不是把所有信息零散堆在执行历史里。
• 隔离优于压缩：压缩是信息已进入上下文后的事后有损补救；隔离让大体积中间信息根本不进入主上下文。

实践模式

1. 六种压缩策略实测对比（实验 2-10）

任务：识别并追踪 OpenAI 联合创始人的职业状态；Kimi K3（原生约 1M 窗口，实验刻意限制在 128K 预算以触发压缩）。

策略	做法	迭代	Token	压缩率	问题
无压缩	完整保留原始结果	5 次即溢出失败	~165,000	,	7 次搜索累计约 367,000 字符（平均 52,000/次），数次搜索即耗尽 128K
个体摘要	每个结果独立生成 2-3 段摘要	12	276,608	10.9%	信息碎片化，多页重复描述同一事件
组合摘要	所有结果合并后一份综合摘要	10	93,449	4.3%	输入超长必须截断，可能丢失末尾信息
上下文感知	压缩提示中带入查询意图与已积累信息	7	40,157	~3.0%	最优平衡点
带引用的上下文感知	智能压缩 + 每条事实附带来源 URL	7	,	,	内容有损、索引无损，可回溯原文
自适应窗口化	阈值触发 + 批量压缩 + 防重复	,	174,601	,	初期保留完整原始信息，灵活性最大

压缩率定义为「压缩后体积 / 原文体积」，数值越小表示压得越狠。上下文感知压缩将 token 使用量减少 75% 以上。

上下文感知的提示词写法：在压缩提示中指定 Given the search query: {query} 和 Current context: {context}，引导模型生成针对性摘要。实测把约 150K 字符压到 2K 字符时，仍保留创始人姓名与职位变动等后续任务需要的关键信息。

2. 自适应窗口化三机制（推荐默认）