在生产环境里用 AI 写代码，你可能遇到奇怪的退化。你交过去一个复杂的编程任务。AI 回复迅速，却给出了错误答案。这不符合它平时的水平。如果你去翻看后台返回的数据，会看到一个奇怪的现象。模型的推理部分，刚好用掉了 516 个 token。不多不少，恰好是 516。系统的行为表现符合定时截断的特征。
这位开发者叫 vguptaa45。6 月底，他在 OpenAI Codex 仓库提交了 GitHub #30364。他用本地数据，审计了 390,195 条响应。这些记录来自 865 个 session。他抓到了 3,363 个 exact-516 事件。GPT-5.5 截断在 516 的比例高达 44.0%。而非 GPT-5.5 模型该比例仅为 1.3%。在不同模型上，这个数字差异明显。gpt-5.5 是 44.0%，gpt-5.4 是 19.8%。gpt-5.2 为 0.34%。gpt-5.3-codex 则是 0.0%。从月度趋势来看，这个问题在恶化。2 月比率 0.11%，3 月 2.45%，4 月 4.25%，5 月冲到 53.30%，6 月回落到 35.84%。这些数据全部来自他的 issue 原文。maille 把它发到了 HN，nsingh2 成功复现了这一现象。他把同一道难题跑了 10 次。其中 4 次刚好卡在 516，模型全部答错。另外 6 次跑了 6000-8000 token，全部答对。该讨论在 HN 拿到 368 分与 151 条评论。
模型多了一层“思考”。这一层能单独计费、单独调度。于是，模型也多了一种评测看不出来的新坏法。516 聚簇说明推理层提前终止，导致模型答错。而在同一周，Liquid AI 针对相反的坏法。他们推出 Antidoom，解决模型自我重复的死循环。这两个问题看似相反，底子却完全一样。出问题的是模型“想”的那一层。这一层，也是大家最容易忽略的地方。长会话中，你必须监控 reasoning token 的分布。千万不要假设新模型一定会更稳。
理解这个现象，需要厘清一个事实。模型没有变笨，只是想得太少就停了。在 516、1034 和 1552 这些数字里，隐藏着线索。它们高度接近 512、1024 和 1536。这三个数字都是 2 的幂次。社区的 lord_braleigh 发现了这个问题。micalm 也做出了同样的研判。他们认为，系统把推理预算划分成了固定档位。当系统判定任务简单时，就会把预算截断到最低档。
目前，OpenAI 官方还没有对这个成因给出最终结论。issue 作者 vguptaa45 态度也克制，他声明自己不主张这一定证明了隐藏截断的存在。aiweekly 的跟进也指出，这是单一报告者的聚合数据，还需要独立复现和机制解释。但社区已经找到了临时绕过的方法。你只需在 prompt 里加 ‘THIS IS HARD’。这样能骗过系统的 budget 判定，让它恢复正常推理。这说明问题不在模型能力，只是预算判定的偏差。学术界把这种现象称为 underthinking。相关研究可参考 Wang 等人 2025 年的论文。更早的 GitHub #29353 里已有 516 短路报告。
就在同一周，Liquid AI 发布了一个相反的案例。他们推出了名为 Antidoom 的工具。这个工具专门用来解决推理模型的另一种坏法：doom loop。卡在‘Wait, let me reconsider’中。它们会不断自我推翻，直到耗尽所有 token。
根据 Liquid AI 官方博客的分析，这有三层原因。首先是模型过度训练了像‘Wait’或‘So’这类词。其次是不确定性导致了上下文的自我强化。每重复一次，循环内 token 的出现概率就更接近 1。最后是贪心采样让模型无法走出这个循环。测试数据展示了具体的改进幅度。LFM 2.5 的死循环率从 10.2% 降至 1.4%。Qwen 3.5 的比例从 22.9% 降至 1.0%。在 LocalLLaMA 社区，这也成了讨论热点。学术界同样关注到了这种 overthinking 现象。Duan 等人在 2026 年发表了相关的研究论文。他们指出，语义上的重复其实早于文本上的重复。这种现象往往伴随着 V 形的注意力分配模式。这才是真正的自我加强循环。它多发生于小模型或低温度设置下，与 516 截断完全不同。
一个想得太少，因为提前截断而答错。一个想得太多，因为卡在循环里死机。这两个问题看起来风马牛不相及。但它们共享同一个病根。它们都发生在模型多出来的‘推理层’里。更棘手的是，这些坏法在传统的评测里根本看不见。
厂商用来测试模型的 pass-rate 评测，存在结构性盲区。因为 pass-rate只关心最终答案对不对。516 步截断的错答案，与正常思考的错答案没区别。在最终的评测得分上，它们都是零分。所以，OpenAI 的内部评测跑了几个月，也没有发现这个问题。Anthropic 2025年9月报告也提过类似逻辑。模型在单步错误后恢复力强，让 pass rate 维持高位。但在长会话里，这些细微退化就会积累成明显的降智体感。学术界其实早就意识到了这个问题。OptimalThinkingBench 的出现就是解决它。传统的准确率指标，照不进推理过程的暗处。学者 Ghosal 指出，推理长不一定结果好。这次 516 事件，正是这个学术判断在现实生产中的一次显形。
如果把近期的 AI 退化事件放在一起看，能清晰地看出一条轨迹。四月事件中，Claude 降级在 runtime 层。厂商悄悄修改了 adaptive thinking 默认设置。五月的 Opus 4.8 两次分析（评测体系这条线和偷懒这条线）又戳破了另一层。问题出在评测层。传统的玩具级评测，覆盖不到长会话中的模型偷懒行为。
而这一次，问题直接出在了模型‘想’的那一层。也就是 reasoning token 的分布形态上。这些事件指明了一个残酷的事实。模型和你之间，已经叠了多层复杂的机制。每一层都在悄悄失效，而你手里的评测工具只能照到最表层。每一层的失效，都需要你拿出专门的体检手段。
如果你要把 coding agent 放进长会话生产环境，下面三件事比纠结”GPT-5.5 到底退没退步”更值得做。首先，把 reasoning token 分布纳入监控指标。不要只看平均 token 数，因为平均值会抹平聚簇特征。你必须观察分布图上是否出现了异常的尖峰。审计本地 log 并绘制直方图，是行之有效的方法。像 Codex CLI，session 数据都会存在本地。你今天就能动手跑一次检测。
其次，在长会话任务中，千万别假设新模型更稳。GPT-5.5 确实比 GPT-5.2 更先进。但新模型 516 聚簇率达 44.0%，旧模型仅 0.34%。模型版本的升级，在你的实际业务上可能是倒退。在切换模型版本前，必须跑一组你自己的代表性任务。看的不只是答对率，更要看 reasoning 分布形态。
最后，遇到退化时，排查顺序需要做调整。你应该先排查推理层，再排查 prompt 和 runtime。解决 516 问题，只需在 prompt 里加难度信号。这容易让开发者误以为是 prompt 工程起效。其实，这只是你用难度信号骗过了系统的预算判定机制。这不代表系统修好了问题。
总结三个判断。第一，模型”想”的那一层是会单独坏掉的新地方，它对最终的对错指标隐形。第二，新模型不一定更稳，推理模型的可靠性并非单调上升。第三，本地 log 监控，是你反向问责的唯一杠杆。