上下文压缩在什么条件下触发？

核心回答

上下文压缩通常在下一次模型调用将接近可用输入预算时触发，需要提前为输出、新工具结果和估算误差留空间，不能等服务端报超长才处理。

可以分成三类触发：

1. 预算触发：统计指令、工具定义、历史和新增内容的 Token，达到阈值后压缩旧历史；切换模型时按新模型的输入与窗口限制重新计算。
2. 任务事件触发：一个阶段已经结束、旧工具输出大量重复时，可以先清理或做阶段摘要。消息条数和阶段变化适合辅助判断，不能代替长度统计。
3. 溢出恢复或手动触发：实际计数超过估算、模型拒绝请求时，缩小上下文后有限重试；用户也可在明确的阶段边界主动压缩。

触发后保留当前目标、有效约束、未完成项与最近完整工具交互，把旧过程压成带出处的摘要。触发阈值与保留范围是两个参数：过早频繁压缩会增加开销，保留内容过多则可能压缩后仍然装不下。

阈值怎样设

先核对模型的最大输入、总上下文窗口与输出上限，再为本轮输出和下一次可能增长的工具结果预留余量。不能把所有模型统一设成“窗口的 70%”或“每 20 条消息”：一条工具日志可能比几十轮短对话更长，不同模型的输入限制也可能不同。

例如某任务计划在一个 100k Token 窗口中预留 10k 输出和 10k 增长余量，可先以 80k 为压缩起点，再用实际轨迹调整。这是预算示例，实际请求还要满足服务端独立的输入、输出限制。摘要调用自身也需要输入和生成空间，因此阈值应早于窗口耗尽。

冗长日志和大文件可以先保留关键片段与原件路径，再决定是否需要模型摘要；不是每次工具输出变长都要压缩整段历史。阶段摘要则适合已完成步骤，不宜把尚未返回结果的工具调用切成两半。

怎样避免反复触发

摘要成功保存后再更新覆盖位置，后续使用“摘要＋保留原文＋新增消息”构建输入。用重新组装后的大小判断是否还有空间，避免继续拿压缩前的计数触发同一次摘要。

如果固定指令、工具定义或最近一次大附件本身就超过预算，反复总结旧对话也解决不了，应缩减工具集合、拆分材料或分阶段处理。压缩失败或仍超长时设置重试上限，并保留可恢复的原始记录；摘要质量如何检查，见上下文压缩或摘要会丢失信息，如何让损失尽可能小？。

OpenCodeTypeScript

基于 OpenCode

OpenCode 2.1.2 的会话执行器在每一步模型请求之前检查自动压缩，也支持模型拒绝超长请求后的恢复，以及用户主动提交的压缩请求。三种入口共用压缩服务，但触发条件不同。

自动压缩依据模型预算

SessionRunner 先加载当前会话，再调用 compaction.compact({ reason: "auto", ... })。压缩服务用模型的 input 上限计算水位，没有独立输入上限时使用 context 窗口。

该版未显式设置 buffer 时，默认预留窗口的 15%；窗口至少为 32k 时，预留量还不低于 16k Token。例如窗口为 100k 时，默认水位为 84k。这是一版源码的策略，不能照搬为所有模型的最佳阈值。

当前大小优先以同一提供商返回的有效用量作基准，再估算此后新增的消息与工具结果；缺少有效用量时，估算系统指令、工具定义和消息。模型窗口未知时不会自动按比例触发，只能依赖手动操作或服务端溢出反馈。刚完成压缩时，执行器先重建请求；原生压缩产生的不透明窗口，也要等新用量反馈后再判断，避免拿旧计数连续压缩。

溢出恢复与手动压缩

当请求实际被判断为上下文溢出时，执行器尝试 reason: "overflow" 的压缩；成功后重新加载历史发起请求，并限制同一步的再次溢出恢复。压缩请求自身过大时，还会逐步降低目标大小，无法再缩减则返回失败，不无限重试。

自动压缩关闭时，普通水位检查和溢出恢复都会跳过压缩；用户的手动请求仍可进入压缩服务。因此，“关闭自动压缩后，超长时一定会自动兜底”并不符合这版实现。

压缩后怎样继续任务

支持原生压缩的模型走提供商原生路径；其他模型生成包含目标、要求、决定、工作状态和下一步的摘要，并按 keep 保留近期上下文。该版 keep 默认预算为 15k Token，与触发水位分别配置。

普通摘要通过消息标识关联保留片段，后续会话历史据此重建请求。这样既能减少反复携带旧过程，又保留近期任务细节；是否丢失约束仍需检查摘要及后续执行，不能仅凭压缩成功状态判断。

对应教程

参考资料