长上下文很容易让人产生一种错觉：只要把窗口调到足够大，Agent 就终于有了「不会忘事」的记忆。

一则关于 Codex 的社交平台讨论给出了一个很直观的配置样例：把 GPT-5.6 Sol 的上下文窗口调到 100 万 Token，并把自动压缩阈值放在接近窗口末端的位置。它很适合拿来理解长上下文的潜力，也提醒我们：窗口更大，不等于任务就会更可靠、更便宜。

先说明边界：下面的配置来自这份写作素材所整理的讨论，本文没有在所有 Codex 版本、账号和组织策略下独立复现。把它当成一个需要自行验证的配置样例，不要把它当成每个客户端都默认支持的开关。

一、帖子讲了什么

素材给出的核心设置是：为当前模型显式指定 100 万 Token 上下文窗口，并在约 90 万 Token 时触发自动压缩。

model = "gpt-5.6-sol"
model_context_window = 1000000
model_auto_compact_token_limit = 900000

也可以在启动时临时指定：

codex -m gpt-5.6-sol \
  -c model_context_window=1000000 \
  -c model_auto_compact_token_limit=900000

OpenAI 当前的 GPT-5.6 Sol 模型页列出的上下文窗口为 1,050,000 Token，最大输出为 128,000 Token。这说明「约 100 万 Token 的模型窗口」本身是有公开依据的；但具体到 Codex 本地配置项是否生效，仍取决于你安装的客户端版本、所用模型权限和服务端策略。

二、为什么有人想要 100 万

对普通聊天来说，几万 Token 已经很长；对持续工作的 Coding Agent，却可能很快被消耗掉。一个较长的工程任务通常会不断带入：

• 仓库规则、目录说明和依赖关系；
• 多个文件的代码、测试和 diff；
• 命令输出、错误日志、搜索结果；
• 已经尝试过的方案，以及尚未验证的假设。

窗口变大后，Agent 可以在同一条任务线上保留更多上下文，少一些「刚定位到关键线索，就要重新解释背景」的中断。对于大仓库梳理、跨模块排错、长链路工具调用，这确实很有吸引力。

但要把「模型窗口」和「可靠记忆」分开看。材料越多，模型越需要辨别哪些信息仍然有效；过期日志、已推翻的假设和无关工具输出，也会一起占据注意力。长任务中，清晰的任务边界、短而可核验的工具回执，以及阶段性交接，依然比单纯扩大窗口更重要。

三、为什么默认值未必越大越好

超长上下文的代价不只是一行配置。

1. 延迟和用量压力会上升。 对 API 使用而言，OpenAI 的模型页明确标注：单次输入超过 272K Token 后，会进入长提示计价区间，输入价格为标准输入的 2 倍、输出价格为 1.5 倍。订阅产品的额度规则不能直接按 API 价格换算，但这仍说明超长输入不是没有成本的。
2. 噪声会累积。 一次失败命令的完整日志、重复的搜索结果、早已不再成立的判断，都会被带到后续回合。窗口更大只会让这些材料更容易留下来。
3. 排错路径会变长。 当任务没有明确停止条件时，Agent 可能继续读取、调用工具和重试。更长的窗口让它更有条件继续工作，也更需要人为设定验收边界。

因此，默认窗口的取舍并不是「越大越先进」，而是在完成率、响应速度、资源消耗和可控性之间做平衡。

四、自动压缩才是真正的安全网

自动压缩（compaction）的价值，不是把旧对话机械删掉，而是把已完成阶段的关键信息浓缩成更短的交接：改了什么、验证了什么、现在卡在哪里、下一步要证明什么。

素材中的 model_auto_compact_token_limit = 900000，表达的是同一个思路：不要等窗口完全塞满才处理历史，而是在接近上限前腾出空间。

不过，压缩也不是魔法。它可能遗漏细节，尤其是尚未写入文件、只出现过一次的临时判断。实际工作中更稳妥的做法是：

• 在一个阶段完成后主动写下简短交接；
• 把长日志、完整报告和原始数据留在文件或可检索位置；
• 让下一阶段按需读取原文，而不是把所有材料永久塞在对话里；
• 对关键结论保留测试、命令输出或代码位置作为证据。

这样即使自动压缩发生，Agent 也知道去哪里找回需要验证的细节。

五、文档写着能用，不等于每个客户端都能直接开

模型拥有约 100 万 Token 窗口，不等于每个产品入口都会把它完整暴露出来。实际可用范围通常还受这些因素影响：

• 当前 Codex 客户端是否识别相应配置；
• 账号、组织和所选模型是否有对应权限；
• 服务端是否对单次任务、工具调用或模型路由另设限制；
• 配置是否只对新会话生效，或被更高优先级的设置覆盖。

所以最可靠的验证方式不是只看配置文件，而是用一个可控的长任务实际观察：确认客户端版本；新开会话；逐步增加输入；记录工具回执、完成时间和是否发生压缩。这样既能确认设置是否生效，也能知道它对自己的任务到底有没有价值。

六、我的看法：长上下文应该服务于交付物

100 万 Token 很适合承载一段复杂、连续且有明确验收的工作：例如梳理一个陌生仓库、定位跨模块故障、完成一个需要多轮验证的功能。

但它不适合成为「所有事情都放在同一条线程里」的理由。无关主题混在一起，只会让历史越来越厚，后续每一轮都要为旧材料付出注意力和资源。

更实用的原则是：按交付物组织上下文，而不是按时间囤积上下文。 一个 PR、一次事故、一篇文档，可以保持连续；当主题切换时，留下交接摘要，再开一条更干净的任务线。这样既能利用长窗口，也不会把它变成杂物间。

参考资料

• OpenAI：GPT-5.6 Sol 模型说明
• 本文的配置样例来自 2026 年 8 月 17 日提供的社交平台讨论素材；未作为独立可复现实验结论。

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。