上下文压缩策略

问题背景

当代理会话累积到数百万 token，或代码库体量达到 500 万+ token 时，上下文窗口会成为硬约束。朴素做法是尽量压掉每次请求的 token，但压缩一旦丢掉文件路径、错误码或「改了哪些文件」这类细节，代理会反复重新探索，总成本反而上升。本技能把优化目标从「每请求 token」改为每任务 token：从任务开始到完成消耗的总 token，含重新获取信息的代价。

核心思路与做法

技能区分三种可用于生产的方案：

• 锚定迭代摘要：维护带明确分区（会话意图、文件修改、决策、下一步）的持久摘要；触发时只摘要新截断片段并增量合并，用分区当检查清单，减少静默信息漂移。
• 不透明压缩：压缩比最高（约 99%+），但不可解释，难以验证保留了什么。
• 再生式完整摘要：每次全量再生结构化摘要，可读性好，长周期反复压缩时更易丢细节。

实践上还包括：在上下文利用率 70–80% 触发压缩、滑动窗口 + 结构化摘要的平衡、以及用基于探针的评估（召回、产物、延续、决策）替代 ROUGE 等无法反映「代理还能不能继续干活」的指标。编码场景里 产物轨迹（创建了/修改了/只读过的文件、函数名与错误消息）往往是各方法最弱的一环，必要时要在脚手架里单独做文件状态或产物索引。

适用边界

• 适合：会话超长、代码库超窗、设计摘要策略、调试代理「忘记」改过的文件、搭建压缩质量评估框架。
• 注意：若文件追踪是刚需，仅靠通用摘要分区可能不够；结构化方案通常比不透明压缩少约 0.7% 压缩比，但质量分更高，在重新获取成本高的任务里更值得选。