项目四层上下文压缩各层逻辑是什么，分别解决哪些问题？

核心回答

四层压缩需要按项目实际实现说明，L1～L4 没有统一标准。下面以一个按处理代价递进的 Coding Agent 设计为例：先清理冗余，再外置大结果，再压缩历史，最后在任务边界重建上下文。

1. L1 冗余清理：去掉重复检索、已被新版本替代的文件内容和无用日志，减少没有信息增量的输入。
2. L2 大结果外置：完整文件和长工具输出保存到外部，只保留关键片段、执行状态和可回查位置。
3. L3 历史摘要：把已完成步骤整理成目标、约束、决定、证据和未完成事项，保留近期必要原文。
4. L4 任务交接：单一窗口已不适合继续时，按子任务或阶段重建上下文，交接状态和产物，再按需读取细节。

每层处理后重新计算预算，够用就停止升级。硬约束、实际执行状态和未完成工具调用的配对关系要保住，不能为了压短而把任务含义改掉。

一次代码排障怎样经过四层

假设 Agent 已读多个文件并运行多次测试，接下来还要定位失败原因：

这里的L1、L2是减少活跃输入，不等于删除原始轨迹。摘要也有损，不能让它成为唯一证据。例如“所有测试通过”不能概括掉“只运行了其中一个测试文件”。

下图看的是升级条件：实线表示仍超限时继续处理，虚线表示每层都要回检，预算够用就停止升级。

flowchart TD
 A[预算不足时开始逐层处理] --> B[L1 清理重复与过期内容]
 B -->|仍超限| C[L2 外置大结果并保留引用]
 C -->|仍超限| D[L3 摘要已完成历史]
 D -->|仍超限| E[L4 拆分任务或阶段交接]
 B -.-> F[每层回检预算和关键资料]
 C -.-> F
 D -.-> F
 E --> F
 F --> G[预算够且资料齐全才继续
缺资料则回查或澄清
最小输入仍超限则调整任务或说明限制]

如果连最小任务说明、必要工具定义和当前证据都放不下，应缩小子任务、改用更适合的窗口或明确当前限制，不能无上限地反复摘要。

触发条件与保留契约

触发依据是目标模型允许的输入、输出预留和下一步可能返回的资料大小，不能把某个固定百分比当作所有模型的标准。摘要调用本身也需要空间，应在请求已经无法发出之前安排处理。

压缩前后重点对照：当前目标、禁止事项、资源与时间范围、已发生外部操作、未确认结果、文件版本和证据位置。工具调用和结果必须形成合法的消息序列；对仍在等待的调用，不能只保留结果或只保留一个失去关联的ID。

Checkpointer 保存执行状态快照；完整原始日志、文件和工具大结果按需另存，保留可回查位置。活跃上下文只取当前任务需要的信息。压缩失败时可回退到先前记录重新组装；这不等于撤销已经发生的外部操作。

常见追问

四层是不是比一层摘要更好？

不一定。任务短、结果小时，一层简单处理就可能足够。分层的意义是先采用损失较小、成本较低的手段，并能定位哪次处理丢了信息；是否值得增加复杂度，要看相同任务上的完成率、约束保留、延迟与成本。

怎样证明压缩有效？

保留同一任务的原始轨迹和各层输入输出，检查关键事实能否回查，再比较完成结果。要加入早期否定条件、用户修正、长日志和未完成调用等样本；Token下降只是资源收益，不能代替结果正确。

对应教程

参考资料