你用 Codex 重构了一个大项目。500 个文件，几十万行代码，你把整个仓库喂给 Agent，期待它拥有一份「上帝视角」般的全局理解。

然后你注意到一个细节：Codex 的上下文窗口好像变小了。不是你的错觉，是真的。

本周，OpenAI 悄然将 GPT-5.6 Sol 模型的上下文窗口从约 400K tokens 缩减到了 258K。在 AI 行业还在高喊着「百万 token 上下文」「无限窗口」的时代，这个动作显得格外扎眼。

发生了什么？#

具体来说，这个变化被记录在 GitHub Issue #32806 中。GPT-5.6 Sol 是 Codex 用户常用的一种模型变体，它的定位是「更快的推理速度、更低的延迟」，通常被用于需要快速迭代的场景，比如代码补全、实时调试、小范围重构等。

此前 Sol 版本的上下文窗口大约是 400K tokens，但现在这个数字被削减到了 258K。降幅接近 35%。

这不是一个 Bug，也不是临时的服务降级。这是一次有意的调整。

上下文窗口的「军备竞赛」：越大越强？#

要理解 OpenAI 为什么这么做，我们得先看看过去两年发生了什么。

2023 年 GPT-4 推出时，上下文窗口是 8K 和 32K。2024 年 Anthropic 的 Claude 率先把窗口推到了 200K，紧接着 Gemini 1.5 直接跳到 1M token，然后 2M。OpenAI 也在 GPT-4o、GPT-5 系列中不断扩展窗口。整个行业似乎进入了一场「谁更大」的军备竞赛。

表象上看这个逻辑是成立的：更长的上下文意味着模型可以「看到」更多信息，可以处理更大的代码库、更长的对话历史、更复杂的多文件任务。对于 Codex 来说，长上下文尤其重要，因为实际编程项目中的代码量远超单文件的范围。

但你有没有注意到一个问题：上下文窗口变大了，模型的「记忆力」真的变好了吗？

「迷失在中间」的诅咒#

斯坦福、伯克利和 Samaya AI 的研究者在 2023 年发表了一篇名为《Lost in the Middle》的论文，揭示了一个反直觉的发现：当上下文变得很长时，LLM 对中间部分信息的提取能力会显著下降。模型擅长记住开头的信息（首因效应）和结尾的信息（近因效应），但对夹在中间的内容却表现得很差。

换句话说，把 300K tokens 塞进上下文并不意味着模型真的理解并利用了所有 300K tokens。很多信息实际上是「被看见但未被处理」的，它们徒增了计算开销和延迟，却没有带来实质性的智能提升。

这就像你打开了一本一千页的技术手册，翻到了一百页中间停下来，然后问我：「这本书说了什么？」我可能记住了序言和最后一章，但对中间 500 页的内容只有一个模糊的印象。

OpenAI 的战略性缩减：为什么是 258K？#

那么问题来了：为什么偏偏是 258K？这个数字是随便选的，还是有依据的？

我认为有三个关键因素：

1. 成本优化#

每个 token 的推理都需要 GPU 计算。上下文越长，注意力计算的复杂度呈二次方增长（对于标准 Transformer 架构）。一个 400K token 的上下文窗口，其注意力矩阵是 258K 窗口的约 2.4 倍大。

对于 Sol 这种主打「性价比」的模型来说，缩减窗口直接转化为更低的 API 成本和更高的吞吐量。OpenAI 可以用同样的 GPU 集群服务更多用户。

2. 质量改善#

前面提到的「Lost in the Middle」效应在这里很关键。当上下文过长时，模型可能在海量信息中「迷失」，反而降低了回答质量。缩减窗口到一个精心选择的范围，实际上可能提升模型在窗口内信息上的表现。

258K 这个数字很可能不是凭空想象的，而是 OpenAI 内部通过「大海捞针」（Needle in a Haystack）测试、信息检索基准等实验得出的最优平衡点。

3. 分层定价策略#

这不是阴谋论，而是合理的商业策略。如果你需要超长上下文（比如处理百万行代码库），OpenAI 可以让你使用完整版的 GPT-5.6 或 GPT-5.5，支付更高的 token 价格。而对于日常的代码补全、单文件编辑、小范围重构场景，258K 已经绰绰有余，Sol 的性价比优势更加突出。

这是一种「产品分层」：把不同模型定位到不同的需求场景，而不是试图让每个模型都成为「万能选手」。

这对 Codex 用户意味着什么？#

如果你是一个日常使用 Codex 的开发者，这次调整对你的实际影响可能比你想象的要小。

让我们做一道简单的算术题：

  • 一个中大规模的代码文件通常在 5K-15K tokens
  • Codex 的系统提示（System Prompt）和工具定义大约占 5K-10K tokens
  • 对话历史（最近几轮的交互）大约占 5K-20K tokens

把这些加起来，一个典型的 Codex 会话上下文是 15K-45K tokens。即便是重度使用，同时处理 10 个文件、保留 50 轮的对话历史，上下文也很难超过 150K tokens。

258K tokens 对于绝大多数 Codex 的实际使用场景来说，仍然是一个远超需求的数字。

真正会受到影响的是少数极端场景：一次性处理几十个文件的重度重构、对整个微服务项目做跨模块分析、或者把整个代码库的文档塞进上下文做一致性检查。在这些场景下，你可能需要考虑使用完整版的 GPT-5.6 而不是 Sol。

更大的趋势：「优化」取代「堆料」#

这次调整让我想起一个更宏大的趋势。

AI 行业正在从「堆料」阶段走向「优化」阶段。2023-2025 年是参数规模的军备竞赛，2025-2026 年是上下文窗口的军备竞赛。但任何竞赛都有尽头。当窗口大到一定程度后，边际收益递减甚至消失。

真正聪明的玩家开始思考不同的问题：不是「我能把窗口做多大」，而是「在什么窗口大小下，模型的表现最好、成本最合理、用户满意度最高」。

Codex 的这次缩减，某种程度上是在说：我们不再用「最大上下文窗口」这种营销数字来吸引你了。我们在选择一个真正对你有用的数字。

这是一种成熟。也是一种自信。

少即是多#

我越来越相信，AI 的下一个阶段不是「更多」，而是「更精准」。

更精准地选择上下文长度。更精准地决定哪些信息值得保留。更精准地在速度、质量和成本之间找到那个甜蜜点。

Codex 把窗口从 400K 缩减到 258K，丢掉的是虚荣的规格表数字，留下的是实际可用的性能提升。这不是退步，这是一种诚实的工程选择。

当你下一次打开 Codex，发现它的窗口「只有」258K 时，不用遗憾。因为你实际用得到的，可能从来都没超过 100K。多出来的那些，不过是你的心理安慰剂。

真正的「上帝视角」，从来不在上下文的长度里，而在模型对每一行代码的理解深度中。

参考来源：