GPT-5.6 的长任务执行能力是不是退化了？我发现普通对话模式现在跑不动长任务了

最近在测试 GPT-5.6 Thinking 模型的时候发现一个非常诡异的现象：同一个 Plus 账号，原本能跑 100 多分钟的长任务，现在竟然在 26 分钟左右就强制中断了。这感觉不像是模型变笨了，更像是底层的任务调度逻辑（Routing）出了问题，把原本属于后台异步执行的任务，强行塞进了前台同步执行的模式里。

发现问题：从 102 分钟缩水到 26 分钟

我整理了一下手头的测试数据，对比非常明显。以前在普通 Chat 模式下，用 gpt-5-6-thinking 配合 extended 模式，是可以触发那种持久化的 worker 执行逻辑的。

我这里有一个具体的历史案例数据：

• 模型： gpt-5-6-thinking
• 思考强度 (thinking_effort)： extended
• 请求 ID 类型： wfr_... (这代表它走的是 worker 家族的异步路由)
• 异步源 (async_source)： saserver-...:conversation-turn-...:EU
• 实际执行耗时： 6146s (也就是 102 分钟 26 秒)

而且这并不是个例，我手里还有其他几个保存下来的 GPT-5.6 Thinking 对话，里面的 worker-family 轮次分布在不同欧洲区域，单次执行时长分别达到了 2609s、2314s 和 5094s。

但现在的状况是，当我再次使用同样的配置进行测试时，虽然模型还是那个 gpt-5-6-thinking，但请求 ID 变成了普通的 UUID，完全没有了 SAServer 的异步源标识。结果就是：任务跑不到 26 分钟左右就断了，目前的测试显示 finished_duration 大约就在 26 分钟这个量级。

路由切换的证据：同一个对话里的“身份转变”

最让我觉得这像是系统 Bug 或实验性改动的地方在于，我观察到了同一个对话内部发生的路由切换（Route-flip）。

我追踪了一个特定的对话序列，时间线如下（UTC 时间）：

• 07:41 - 08:14 期间： 所有的 turn 都是 wfr_ 加上 SAServer 标识，属于那种可以长跑的异步 worker 模式。
• 08:17:44 左右： 最后一个确认的 worker 任务结束。
• 09:15:58 左右： 同一个对话里，下一个 turn 开始了。虽然模型依然是 gpt-5-6-thinking，但它突然变成了普通的 UUID 请求 ID，没有了 SAServer 标识。

这个切换点被锁定在了 2026 年 8 月 20 日的 08:17 到 09:15 之间。这种在同一个对话里从“后台异步”变成“前台同步”的情况，很难用“旧对话损坏”或者“模型降级”来解释。

目前的情况和我的疑问

现在的情况是：

• 普通 Chat 模式： 变成了非 Temporal/Foreground 模式，上限大概只有 26 分钟左右。
• Work 模式： 在同一个账号下，Work 模式似乎还能正常接收到 worker handoff，依然保持长任务能力。

这让我非常困惑。如果这只是一个产品功能的调整，为什么 Work 模式还能保留这种能力，而普通 Chat 却被限制了？这到底是 OpenAI 在做某种灰度测试（Rollout/Experiment），还是在账号处理（Account-treatment）上出了问题，又或者是针对长任务执行逻辑的一次严重退化（Regression）？

如果你也在用 GPT-5.6 跑那种需要极长时间思考的复杂任务，建议留意一下你的请求 ID 是 wfr_ 开头的还是普通的 UUID。如果是后者，可能意味着你正在被限制在“前台模式”下运行，一旦任务超时，哪怕模型还没思考完，连接也会断掉。