发布日期2026-09-03 | 话题OpenAI Codex / auto compact / 上下文管理 / 桌面端Codex auto compact自动上下文压缩是 OpenAI Codex 在会话 token 逼近上限时自动触发的历史摘要机制桌面端与 CLI 共用同一套 codex-rs 内核。2026 年 7 月以来 openai/codex 仓库已积累二十余个相关未关闭 issue症状集中在压缩卡住无法取消、压缩完成后上下文仍有约 80% 被占用、以及压缩后对话历史从界面消失。根因是一处基数错配压缩阈值按原始窗口的 90% 计算可用窗口却只有原始窗口的 95%压缩因而发生在可用窗口约 94.7% 处且该阈值只能调低不能调高。OpenAI 已于 2026 年 8 月转向 token budget 方案改用开新窗口配合持久化历史与笔记工具。桌面端用户实际遇到的是哪几类问题Codex 桌面端的自动压缩问题不是单一 bug而是四条独立的故障链在 openai/codex 仓库中均处于未关闭状态。症状Issue 编号时间关键现象压缩卡死无法取消#244322026-05-25界面停在「正在自动压缩上下文」超过 1 分 54 秒无取消按钮发消息也打不断压缩完仍接近满载#350322026-07-23提示压缩成功上下文表立刻回到约 80% 占用几次工具调用后再次触发压缩循环吃额度#313512026-07-07桌面端进入无限压缩循环消耗掉约 30% 的用量额度历史从界面消失#42311 / #419542026-09-02 / 09-01压缩后大量用户消息渲染为空原文仍在本地 JSONL 中第四类最容易被误判为「数据丢了」。issue #41954 的报告者导出了原始 rollout 文件发现历史 API 返回的条目形如{type:userMessage,text:}。而完整原文仍保存在compacted.payload.replacement_history字段里——数据没丢是渲染层没有正确回填被压缩窗口的内容。还有一类间接症状issue #397672026-08-20分析了一份长会话 rollout发现 GPT-5.6 的历史推理内容被重复计数了一次在该会话的 76 次自动压缩中76 次全部是误触发——按正确计数方式一次都不该触发。自动压缩到底在什么时候触发自动压缩的阈值是模型原始上下文窗口的 90%而不是可用窗口的 90%。这一点在 codex-rs 的模型元数据实现里写得很直白// codex-rs/protocol/src/openai_models.rspubfnauto_compact_token_limit(self)-Optioni64{letcontext_limitself.resolved_context_window().map(|context_window|(context_window*9)/10);letconfig_limitself.auto_compact_token_limit;ifletSome(context_limit)context_limit{returnSome(config_limit.map_or(context_limit,|limit|std::cmp::min(limit,context_limit)),);}config_limit}同一个文件里「可用窗口」用的是另一个字段constfndefault_effective_context_window_percent()-i64{95}注释写明这个百分比是「为系统提示词、工具开销和模型输出预留余量之后可用于输入的上下文窗口比例」。两者基数不同叠加后的结果就是 issue #400952026-08-22实测到的数字项目数值原始上下文窗口272,000可用比例95%可用上下文窗口258,400自动压缩触发阈值244,800原始窗口的 90%按可用窗口 90% 应为232,560差值12,240 token也就是说压缩实际发生在可用窗口的约 94.7% 处此时只剩约 13,600 token 余量。而压缩动作本身要携带待摘要的历史、压缩提示词和模型输出这点余量经常不够——这就是压缩卡住和压缩失败的直接来源。为什么调大 model_auto_compact_token_limit 没用model_auto_compact_token_limit只能把阈值调低调高会被静默忽略。上面那段源码的关键在std::cmp::min配置值与「原始窗口 90%」取较小者。字段注释也确认了这一行为——省略时由context_window推导出 90%提供时会被钳制到 90% 上限。网上流传的「把这个值调大就不会频繁压缩」的说法在当前实现下不成立。同理官方配置参考中并没有提供关闭自动压缩的开关阈值、作用域和压缩提示词是仅有的三类旋钮。压缩完为什么还是 80% 满以及 42GB 的磁盘去哪了压缩会把被替换掉的完整历史重新写回会话记录这既撑大了新窗口也撑爆了磁盘。issue #35032 描述的循环是压缩 → 恢复时接近满载 → 跑几次工具调用 → 再次压缩。报告者指出问题在于 replacement history 未做去重和裁剪仍然携带了不再需要的原始工具输出。磁盘侧的表现更直观。issue #418062026-08-31macOS统计了自己的~/.codex目录总体积约42GB其中archived_sessions/占28GBsessions/占 11GB其余三十多个目录合计约 500MBarchived_sessions/下有1,145 个rollout JSONL 文件平铺存放没有任何保留策略其中82 个文件超过 100MB合计约 23GB占该目录的 82%最大单文件1.2GB时间分布高度集中98.8% 的归档体积产生于 2026 年 8 月单月8 月 30 日一天新增 190 个文件根因被归结为两点压缩时把完整replacement_history重新嵌进 rollout JSONL以及归档会话从不清理、不压缩、不裁剪。反复压缩还有一层成本代价每一轮压缩都要把历史重新送进模型做摘要这部分 token 不产生任何有效产出。长 Agent 任务的费用难以预估很大一部分就来自这类不可见的重算——按额度包预付的接入形式在这类场景下用量上限在调用前即已确定例如七牛云 Token Plan 采用的就是这种计费方式。config.toml 里真正可调的旋钮Codex 桌面端与 CLI 共享~/.codex/config.toml。与压缩直接相关的配置项如下字段名与官方配置参考一致配置项类型默认值作用model_auto_compact_token_limitnumber未设置时按模型窗口推导触发自动压缩的 token 阈值只能调低model_auto_compact_token_limit_scopetotal/body_after_prefixtotal阈值针对完整活动上下文还是仅针对压缩窗口前缀之后的增量model_context_windownumber取自模型目录告诉 Codex 当前模型的上下文窗口大小compact_promptstring内置内联覆盖历史压缩提示词experimental_compact_prompt_filepath无从文件加载压缩提示词覆盖实验性tool_output_token_limitnumber—单条工具输出写入历史的 token 预算skills.max_context_tokens正整数窗口的 2%上限 10000技能占用的上下文预算把阈值调低是当前唯一能给压缩动作留出足够操作余量的办法。以 272,000 窗口为例配置成可用窗口的 85% 左右比较稳妥# ~/.codex/config.toml model_context_window 272000 model_auto_compact_token_limit 219000 # 约为可用窗口 258400 的 85% model_auto_compact_token_limit_scope body_after_prefixbody_after_prefix的意义是阈值只计算压缩窗口前缀之后新增的部分而不是整个活动上下文。对于已经压缩过一次、前缀本身就很大的长会话这个选项能显著减少「刚压缩完就又到阈值」的情况。此外还有两个生命周期钩子事件PreCompact和PostCompact可以在压缩前后执行命令或 MCP 工具支持async默认 false和additionalContextLimit默认 2500等参数。常见用法是在PreCompact里把当前任务的验收标准、待办清单写进一个外部文件压缩后再读回来避免关键状态被摘要掉。OpenAI 的答案token budget 正在取代压缩Codex 团队的方向不是修好压缩而是在长任务中不再压缩——改为直接开启新的上下文窗口靠历史与笔记工具跨窗口恢复状态。codex-rs/core/src/compact_token_budget.rs里的实现注释说明了这一点/// Token-budget compaction skips model/server summarization and installs a/// fresh context window instead. It is still modeled as compaction so compact/// hooks and ContextCompaction turn items observe the same lifecycle as/// local or remote compaction.函数体里也确实没有任何摘要请求核心只有一句sess.start_new_context_window(step_context, world_state)。压缩钩子和事件被保留是为了不破坏客户端兼容性。配套能力来自 PR #39827标题为「Add history and notes tools for token-budget sessions」已于2026 年 8 月 21 日合并。它为 token budget 会话新增了两组直连模型的工具history列出窗口与条目、读取条目、搜索对话内容notes列出、读取、搜索、追加、写入持久笔记PR 描述明确写道这是为了让 token budget 会话「能够跨上下文窗口切换恢复此前的对话上下文并保留工作状态」。内核里还内置了一条提醒模板会在窗口即将耗尽时告知模型接下来会发生什么Your context window is nearly exhausted (only {n_remaining} tokens remaining) and will be automatically reset for you soon. Once reset, message items in current context window will be cleared in the new window, but notes and history items will be persistent across windows.这套机制目前仍在功能开关后面相关配置位于features.token_budget命名空间下use_history_notes_extension是否启用历史与笔记工具默认 falsereminder_threshold_tokens触发窗口耗尽提醒的剩余 token 数必须为正reminder_message_template提醒文案模板上限 2000 字节不可为空guidance_message附加引导文案上限 2000 字节auto_compact_fallback_prompt与auto_compact_fallback_buffer_tokens回退到摘要压缩时使用两者必须成对出现缓冲 token 数必须为正否则配置校验直接报错长任务现在该怎么配在 token budget 模式全量放开之前可按以下顺序处理先确认是不是误触发。在会话里查看状态信息对比可用窗口与实际占用。如果远未接近上限却已压缩很可能命中了 issue #39767 那类推理内容重复计数的问题升级到最新版本再观察。把阈值调低到可用窗口的 80%–85%给压缩动作留出足够操作空间。记住只能调低。把 scope 切到body_after_prefix避免长会话压缩后立刻二次触发。用PreCompact钩子外置关键状态。把验收标准、待办项、已确认的结论写进项目内的文件压缩后从文件读回比指望摘要保留这些信息可靠。控制单条工具输出的体量。用tool_output_token_limit限制工具输出写入历史的规模长日志和大文件内容尽量落盘再按需读取而不是整段灌进对话。定期清理会话归档。~/.codex/archived_sessions/目前没有自动保留策略长期高强度使用后需要人工清理否则会出现 issue #41806 那样几十 GB 的占用。超长任务主动分线程。当一个任务确实需要跑几个小时与其依赖压缩续命不如在阶段边界主动开新会话用交接文档传递状态——这也正是 token budget 机制在做的事。常见问题Codex 桌面端能彻底关闭自动压缩吗不能。官方配置参考中没有提供关闭自动压缩的开关可调的只有触发阈值、阈值作用域和压缩提示词三类。把model_auto_compact_token_limit调低可以改变触发时机但无法禁用该机制。为什么我把model_auto_compact_token_limit调大了却没有生效因为源码用std::cmp::min将配置值与「原始上下文窗口的 90%」取较小者调高会被静默钳制回上限。这个字段只能用来把阈值往下调。压缩后界面里消失的对话内容还能找回来吗可以。issue #42311 和 #41954 都确认这是渲染层问题完整原文仍保存在本地会话 JSONL 文件的compacted.payload.replacement_history字段中直接读取该文件即可取回。total和body_after_prefix这两个作用域该选哪个total默认针对完整活动上下文计算阈值body_after_prefix只计算压缩窗口前缀之后新增的部分。已经压缩过一次、前缀较大的长会话选后者可以明显减少反复触发。token budget 模式现在能用吗相关代码已合入主干配套的 history 与 notes 工具随 PR #39827 于 2026 年 8 月 21 日合并但仍在features.token_budget功能开关后面use_history_notes_extension默认为 false属于逐步放量阶段。小结Codex 桌面端自动压缩的核心问题不在压缩算法本身而在触发时机阈值按原始窗口的 90% 计算可用窗口又只有原始窗口的 95%两个百分比基数不一致使压缩发生在可用空间几乎耗尽的位置。叠加 replacement history 未裁剪导致的新窗口高占用就形成了反复压缩、额度浪费和会话文件膨胀的连锁反应。据 openai/codex 仓库的公开 issue 与源码OpenAI 已在 2026 年 8 月转向 token budget 方案用开新窗口配合持久化的历史与笔记工具替代摘要式压缩。本文所述行为基于 openai/codex 仓库截至 2026 年 9 月 3 日的主干代码CLI 最新发布版本 rust-v0.153.0与官方配置参考功能开关状态和默认值随版本变动较快建议在实际配置前对照当前版本的配置文档核实字段名与默认值。延伸阅读openai/codex 仓库https://github.com/openai/codex多模型 API 用量方案https://www.qiniu.com/ai/plan