Codex 并没有全面放弃上下文压缩，只是把 Compaction 换成了硬切窗口

最近流传的说法称所有 Codex 都已经不再压缩上下文，这一判断并不准确。Codex 仍需把相关信息塞进固定长度的输入窗口，只是处理超长上下文的方式从生成摘要变成了直接截断。Context window 是大语言模型每次工作时的核心限制，模型必须把所有相关信息放进这个固定长度的输入里才能完成推理。信号明确指出，“所有 Codex 都已经不再压缩上下文”与实际情况不是一回事，模型依然在管理上下文，只是策略发生了改变。

这一转变的本质是技术实现路径的切换。过去 Compaction 通过额外一次模型调用生成摘要来保留关键信息，现在硬切窗口则直接按 token 数截断输入。这种变化看似简化了流程，却在信息保留、计算成本和开发者实践上带来了全新挑战。理解两者差异，才能看清 Codex 当前的真实工作机制。

Compaction 通过生成摘要保留信息，却额外消耗一次模型调用

Compaction 的核心是在主推理之前，先让模型对过长的上下文生成一段浓缩摘要。这一步需要把全部原始内容喂给模型，让它提炼出核心要点，然后把摘要塞进最终的输入窗口。整个过程相当于多跑了一次完整的模型调用，因为生成摘要本身也要消耗 token 和计算资源。

信号中对 Context window 的描述清楚表明，模型每次工作都必须把相关信息放进输入。Compaction 正是为了满足这一要求而设计的中间步骤。它不直接丢弃内容，而是尝试用模型自身的理解能力把长文本压缩成短摘要。这种做法理论上能保留更多语义，但代价明显：开发者需要支付额外的 API 调用费用，而且整个响应时间也会因为多了一次前置推理而延长。

在实际系统中，这一额外调用往往发生在用户输入超过预设长度阈值时。系统先触发 Compaction 流程，生成摘要后再把摘要与最新指令组合成最终 prompt 送入主模型。整个链路增加了复杂度，也让 token 消耗变得难以预测。对于需要高频交互的场景，这种额外开销会迅速累积。

硬切窗口直接按 token 数截断，省去中间摘要步骤

硬切窗口的做法简单直接：当输入 token 数超过 Context window 上限时，系统按顺序从头部或尾部直接截断，丢弃超出部分的内容，不再调用模型生成任何摘要。这一策略完全省去了 Compaction 所需的中间模型调用，只保留最新或最重要的片段进入实际推理。

根据信号对 Context window 的定义，模型必须把相关信息放进固定长度的输入。硬切窗口严格遵守这一约束，它不试图“理解”内容，只是机械地按 token 计数器执行截断。通常实现中会优先保留最近的对话轮次，把早期历史直接砍掉。这种做法让单次推理的准备时间大幅缩短，系统响应变得更快。

与 Compaction 相比，硬切窗口的实现成本更低。开发者不再需要维护一套单独的摘要生成逻辑，也不用担心摘要步骤本身的失败率。整个上下文管理逻辑简化为一个长度检查加截断操作，工程复杂度显著下降。但这种简化也意味着模型看到的上下文不再是经过提炼的信息，而是原始内容的硬性切片。

硬切窗口可能丢失关键前文，Compaction 则可能引入摘要幻觉

两种策略在输出质量上各有风险。硬切窗口直接丢弃超出窗口的内容，可能导致模型丢失早期但关键的背景信息。例如在长文档分析或多轮复杂任务中，被切掉的前文可能包含重要约束或事实，导致后续回答出现明显偏差。

Compaction 则面临另一类问题：摘要过程本身由模型完成，可能引入幻觉。模型在压缩时可能会错误理解原意、遗漏关键细节，或者添加不存在的信息。这些错误会被带入最终的推理窗口，影响输出准确性。信号强调模型必须把相关信息放进输入，这一点在两种方法中都成立，但信息如何“相关”被不同机制定义。

实际效果取决于任务类型。对于事实性问答，硬切窗口丢失关键前文的风险更高；对于创意生成，Compaction 引入的幻觉可能更难察觉。目前还没有公开基准直接对比两者在相同 Codex 版本上的表现差异，但开发者已经观察到在长上下文场景下，硬切窗口有时会让模型突然“失忆”。

硬切窗口降低单次推理 token 成本，但可能增加多轮对话总次数

成本层面，硬切窗口的优势在于单次推理的 token 消耗明显减少。因为不再需要生成摘要的额外调用，开发者为每次请求支付的费用降低。信号对上下文窗口的描述表明，所有信息最终都要被塞进固定窗口，硬切窗口通过直接丢弃实现了最小的输入规模。

但从多轮对话的总成本看，情况可能反转。丢失关键前文后，模型输出质量下降，用户需要更多轮次澄清、纠正或重复提供信息。这些额外轮次会累积 token 消耗，最终可能超过原来使用 Compaction 的总成本。

在高并发或大规模部署场景中，硬切窗口的单次成本优势更明显。企业开发者可能更倾向于接受偶尔的信息丢失，以换取整体费用下降。但对于需要高准确率的垂直应用，Compaction 尽管单次更贵，却可能在总交互次数上更经济。目前 Codex 的定价仍按输出 token 计费，硬切窗口带来的输入精简直接反映在账单上。

开发者需从写摘要提示词转向精确控制输入顺序和长度

开发者实践也随之改变。过去使用 Compaction 时，重点是精心设计摘要提示词，让模型更好地理解压缩目标，例如指定摘要长度、重点关注领域、避免引入新内容等。提示工程围绕如何让模型生成高质量摘要展开。

转向硬切窗口后，开发者必须把精力放在精确控制输入顺序和长度上。他们需要提前规划对话历史的管理策略，例如使用滑动窗口保留最近 N 轮、重要事实抽取后手动插入、或通过外部数据库做检索增强。信号再次提醒，模型工作时必须把相关信息放进输入，这意味着开发者要承担起判断“什么信息相关”的责任。

代码层面，开发者可能需要增加 token 计数逻辑、在用户输入前做长度预检查、设计优雅的截断策略。这些工作取代了原来的摘要提示模板，成为新的提示工程重点。一些团队已经开始构建上下文管理中间件，自动根据任务类型决定保留哪些历史记录。

目前仍不清楚 Codex 在哪些长度阈值下会切换两种策略

尽管切换趋势明显，但仍有关键细节不清晰。目前还不清楚 Codex 在具体多长的上下文下会从 Compaction 切换到硬切窗口，官方文档也缺乏对这一阈值的明确说明。信号强调“更准确的说法是”这一转变并非彻底放弃压缩，暗示实际系统中可能存在混合策略或版本差异。

不同模型版本、不同部署环境下的行为可能不一致。开发者在测试中发现，有些情况下即使输入明显超长，系统仍会尝试某种形式的压缩，而另一些情况下则直接硬切。这种不确定性让生产环境中的成本预估和质量控制变得困难。

未来官方文档如果能给出明确的长度阈值、切换条件以及推荐的上下文管理最佳实践，将极大帮助开发者适应这一变化。在那之前，开发者只能通过大量实验来摸索 Codex 在自己业务场景下的真实行为边界。

参考来源