GPT-5.5 Codex推理令牌聚类陷阱

一个奇怪的数字模式#

前几天翻 GitHub 的时候，看到一个 Issue 让我后背一凉。不是那种安全漏洞的凉，而是——有人发现 GPT-5.5 Codex 的推理过程里藏着一组诡异的数字：516、1034、1552。这三个数字反复出现，精确到个位，像是模型在某个看不见的计时器上卡住了。

如果你用过 AI 写代码，一定有过这种体验：明明前面推理得头头是道，突然就急转弯，给出一个明显不够深思熟虑的答案。你以为是自己的 prompt 不够好，或者问题太复杂。但现在看来，问题可能出在模型自己身上。这个 Issue 的作者做了大量测试，发现 Codex 的推理令牌（reasoning tokens）在某些复杂任务中会固定地在这些边界处”罢工”——不是继续思考到真正得出结论，而是在 516、1034、1552 这些特定长度处截断，草草收场。

我第一次读到这个发现时，脑子里冒出的画面是一台老式汽车，转速表一到某个刻度就自动熄火。不管你怎么踩油门，它就是过不去那个坎。

引擎盖下的玄机#

要理解这个 bug 有多诡异，得先聊聊推理令牌是什么。简单说，这是 OpenAI 在 GPT-5 系列引入的一种机制：模型在回答问题之前，会先生成一段内部思考过程，相当于自己的草稿纸。这些令牌帮助模型处理复杂逻辑、多步骤推理和长上下文依赖。理论上，推理令牌越多，思考越深入，答案越可靠。

但这次的发现颠覆了这个假设。问题不在于模型用了多少推理令牌，而在于它在被迫停在某个固定的令牌数上。想象一下你正在解一道复杂的数学题，刚写到关键步骤，有人把你的草稿纸抽走了。你现在能怎么办？只能仓促写一个答案交上去。

GitHub 上这个 Issue 目前已经积累了相当多的讨论。开发者们分享的案例高度一致：在处理多文件重构、复杂算法实现、或者需要深入理解代码库上下文的任务时，Codex 的表现呈现出诡异的”天花板”。不管你怎么调整 prompt、切换采样参数，模型就是无法突破某些推理深度的瓶颈。而这一切，都能追溯到那个 516/1034/1552 的令牌聚簇模式。

为什么大家突然在意这件事#

说实话，AI 模型的 bug 不新鲜。GPT 系列从第一天起就在不断暴露各种边界情况。但这次不同，因为它触及了一个核心承诺：更强的推理能力。

GPT-5.5 Codex 被宣传为”迄今为止最擅长推理的编程模型”，很多人把它当成了日常开发中不可或缺的搭档。我自己也是重度用户——从代码审查到架构设计，从调试到文档生成，我几乎把能交给它的事情都交给了它。所以当我看到这个发现时，第一反应是”原来不是我一个人的错觉”。

过去几个月，我确实留意到 Codex 在某些复杂任务上表现忽高忽低。有时候它给出一个近乎完美的方案，有时候却在显而易见的地方犯低级错误。我一直以为是自己的用法不对，或者任务超出了模型的能力边界。但现在看来，可能有一种更机械、更可预测的故障在底层运作——就像一辆车，有时候能跑 200 码，但有时候在某个速度上就是提不起速，不是因为路况，而是因为变速箱在某个档位卡住了。

这种”有规律的失灵”比完全随机的错误更让人不安。因为它意味着模型的能力边界不是平滑的渐近线，而是一堵堵隐形的墙。

修复之外的问题#

OpenAI 应该会修复这个 bug。可能在我写下这些文字的此刻，某个工程师已经在检查注意力头的权重分布，或者在调整推理令牌的采样策略了。但这件事让我想得更远一点。

我们都在依赖这些模型做越来越多的重要工作。写代码、做分析、辅助决策。我们默认它们是在”思考”，在”推理”。但如果思考的深度被一个隐藏的令牌计数器限制住了呢？如果模型的”最佳表现”只是在特定条件触发了特定 bug 后的残次品呢？

516、1034、1552。这三个数字让我想起了早期神经网络里那些著名的 bug——比如一个图像分类模型学会了识别”水印”而不是”物体”，或者一个翻译模型因为训练数据里的某个空格约定而崩溃。这些故障都被修复了，被遗忘了，被更强大的版本替代了。但每一次修复都让我们对”智能”的理解更清醒一点：它们不是魔法，它们是工程，而工程总会出 bug。

下次你发现自己精心设计的 prompt 换来了一个令人失望的回答，也许可以多给它一次机会。也许它只是刚好撞上了那堵 516 个令牌高的墙。

来源：GitHub