上下文压缩策略

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

何时使用

• 工具调用结果动辄数万字符，几轮交互就撑满 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. 自适应窗口化三机制（推荐默认）

• 阈值触发：持续监控上下文使用率，prompt token 超过窗口 80% 时才激活压缩（如 102,400 / 128K）。
• 批量压缩：触发时一次性压缩所有未标记的工具结果，而不是每轮零碎压。
• 防重复保护：添加 [COMPRESSED] 标记，确保已压缩内容永不被重复处理。

3. 压缩与 KV Cache 的共存

压缩不是在单次 API 调用中修改上下文，而是在两次 API 调用之间由框架预处理消息列表：

1. System Prompt 和 Tool Definitions 永远不动——静态前缀持续缓存。
2. 压缩对象是对话历史中的 tool results——替换位置之后的缓存失效，之前的仍有效。
3. 有意识的权衡：不压缩则溢出失败；压缩损失部分缓存但长度可控、信息密度更高。压缩频次需要权衡——频繁压缩频繁破坏缓存，最好在接近阈值时批量压缩，而不是每轮都压。

4. 生产级五层分层压缩（Claude Code 参照）

不同信息有不同保质期，压缩策略应与预期生命周期匹配，按代价从低到高排列：

1. 工具结果预算控制：大体积输出存磁盘，模型只看摘要预览；替换决策一旦做出就冻结，保证缓存一致性。
2. 噪声直接删除：低价值内容（如大量搜索结果中只被用了几行的部分）直接移除，不做摘要——对噪声做摘要只是浪费 token。
3. API 层微压缩：通过上下文编辑能力指示服务端从前缀移除指定工具结果，本地消息不变；零本地实现成本，但移除点之后缓存同样失效，产生一次缓存重建——适合上下文即将溢出、反正要付这次代价时用，不要频繁触发。
4. 归档式摘要：逐轮结构化摘要，像 git log 保留每轮独立记录，而非 git squash 合并成一条，保留对话逻辑脉络。
5. 全量压缩：LLM 驱动的完整压缩，作为最后手段；分两阶段（先压会话记忆，不行再全量），并配连续失败熔断器——生产数据显示大量会话被困在反复压缩失败的循环中，熔断器避免持续烧钱。

5. 四条压缩设计原则

• 信息价值的非均匀分布：关键决策点（如人员名单）> 支撑性证据（如新闻细节）> 冗余噪声（网页导航栏、页脚广告）。
• 语义完整性：Sutskever 于 2024 年 5 月离开 OpenAI 不能压成 Sutskever 离开——时间和公司名是不可丢失的关键信息。
• 任务相关性：同样内容在「查找创始人名单」和「了解个人背景」两个任务下应产生不同压缩结果。检索类任务保广度，分析类任务保深度，创作类任务保灵感触发点；理想的 Agent 应按任务类型自适应选择压缩策略。
• 压缩即理解：有效压缩需要深层语义理解，负责压缩的模块本身要接近主模型能力，形成「模型调用模型」的递归架构；好处是显式压缩的结果可审查、可跨会话复用。

6. 必须保留的四类信息

无论哪种策略，压缩时都要显式 preserve：decisions（决策）、constraints（约束）、failures（失败路径）、citations（来源引用）。

7. 隔离优于压缩：子 Agent 上下文隔离

对比同一个任务「在代码库中找到处理支付回调的函数」：

• 主 Agent 亲自搜索：可能把十几个文件数万 token 原始代码纳入主上下文，找到目标后绝大部分沦为永久噪声，还得靠后续压缩清理。
• 委派给搜索子 Agent：主上下文只增加两条消息——一条任务描述，一条结论（「函数位于 src/payment/callbacks.py 的 handle_callback，另有两处调用点」）；中间过程的数万 token 随子 Agent 上下文一起丢弃。

代价是子 Agent 看不到主 Agent 完整上下文，任务描述必须自包含、目标明确。Claude Code 的 Task 工具、各类 Deep Research 的检索子 Agent 都是这一模式的生产实现。

常见陷阱

• 每轮都压缩：频繁破坏 KV Cache 前缀，应阈值触发 + 批量压缩。
• 对噪声做摘要：把只用了几行的搜索结果压成摘要，纯浪费 token，应直接删除。
• 压缩时丢掉时间和主体：语义不完整比不压缩更糟——模型会基于错误事实继续推理。
• 用远弱于主模型的模块做压缩：压缩即理解，能力差距大会丢关键信息。
• 把压缩当成长度问题的唯一解：即使窗口够大，压缩仍能提升思考质量、缓解上下文焦虑。
• 让模型自己数数和统计：查找是注意力强项，统计要遍历全部记录并维护计数状态；应提前把结论写进上下文。
• 把所有进展只留在执行历史里：早期架构决策、约束理由、失败路径最容易在压缩中丢失，必须定期落到文档。
• 给子 Agent 派发含糊任务：子 Agent 上下文隔离的代价就是任务描述必须自包含，否则结论质量无法保证。

配套代码

• chapter2/context-compression/ — 实验 2-10：实现并对比 6 种压缩策略（no_compression / individual / combined / context_aware / citations / windowed），输出成功率、耗时、token、压缩率、溢出次数对比表；用 python experiment.py -s context_aware 单跑，-m moonshot-v1-128k 配合 CONTEXT_WINDOW_SIZE=128K 复现溢出。

深度阅读

• book/chapter2.md「上下文压缩策略」