1、上下文没满，为什么也需要压缩？

就算上下文没满压缩也有好处：

首先就是解决长度约束和成本约束，上下文窗口有限（比如128K token或者更大一点的1M）工具调用的结果几轮交互下来就会占满窗口，任务被迫中断。还有一点就是token越多，API成本越高，推理延迟也会急剧上升。

其次就是提高思考的质量，总结后的知识比原始的形式更利于模型的使用。

最后就是缓解模型的上下文焦虑，当模型认为上下文窗口即将燃尽时，可能在任务尚未完成前就收尾，如果在上下文窗口尚未接近耗尽时就提前压缩，可能提升模型决策质量。

2、压缩的价值：把原始记录变成可用知识

除了前面提及的长度问题之外，压缩的价值还体现在把需要思考才能得到的结论，变成可以直接检索的知识。它与上一节说的状态栏有区别：状态栏往往是由代码每一步确定性的维护，压缩则是用一次LLM调用把大段的原文蒸馏掉。

如果不进行压缩可能还会导致上下文腐化问题：长上下文会导致检索精度的下降，即使上下文窗口还有空间但是Agent就是找不到关键信息，或者反复纠结一个已经解决的问题。

3、压缩会破坏KV Cache吗？

压缩不是在单次API调用的过程中修改上下文，而是在两次API调用之间由Agent框架对消息列表进行预处理，其中有以下的处理原则：

（1）系统提示词和工具定义永远不动：这两个作为上下文最前沿的静态前缀，KV Cache持续缓存

（2）压缩的对象是对话历史中的工具结果：用压缩后的摘要替换原始的工具输入时，替换位置之后的缓存会失效，之前的缓存仍然有效。

（3）压缩与否需要权衡：不压缩，上下文膨胀到超出窗口控制，任务就是直接失败；压缩后虽然损失了部分缓存，但是上下文长度可控并且信息的密度更高。因此压缩的频率不能太高，最好在上下文接近阈值的时候批量压缩。

4、六种上下文压缩策略怎么选？

5、实际系统怎样分层处理上下文？

一个成熟的上下文管理系统应包含以下设计层次[CC]：

工具结果预算控制：大体积的工具输出存到磁盘，模型只看摘要预览；

噪声直接删除：低价值的内容，比如大量搜索结果中只被使用了几行的内容直接移除，也不进行摘要处理，要不只是在浪费token；

API层微压缩：通过API层的上下文编辑能力，指示服务端从前缀中移除指定的工具结果，本地消息保持不变；

归档式摘要：逐轮进行结构化摘要，每轮保留独立的记录，保留对话的逻辑脉络；

全量压缩：由LLM驱动的完整压缩，是最后的手段（先尝试压缩会话记忆，不行再做全量压缩）此外全量压缩还搭配了熔断器使用（连续失败达到阈值后自动停止重试机制）

全量压缩 = 对对话历史做完整摘要，静态前缀不动，用户目标尽量保真，工具结果最先牺牲。

6、压缩时，哪些信息不能丢？

压缩策略设计的几条原则：

①信息价值的非均匀分布：关键决策点的价值高于支撑性证据，更高于冗余的噪声信息；

②语义完整性：压缩前后的关键信息不可丢失；

③任务相关性：一个好的设计应该能根据任务的类型自适应的选择压缩策略（检索类任务保留广度、分析类任务保留深度、创作类任务保留灵感触发点等）；

④压缩即理解：有效的压缩需要深层的语义理解，因此负责压缩的模块本身要有较好的模型能力。

7、除了压缩还能用子Agent隔离上下文

子Agent上下文隔离就是让大体积的中间信息根本不进入主上下文。这本质是用隔离代替压缩，压缩是有损的，还需要额外的LLM调用。隔离则让噪声从一开始就与主上下文绝缘，那么主Agent的KV Cache前缀也完全不受影响。但是由于子Agent看不到主Agent的完整上下文，任务委派时就需要自包含任务描述、目标明确。