GPT-5.6 Sol 修复 Token 消耗缺陷

很高兴你来到这里。每周一至周五，我们都会为你送上 TNS 最优质的内容，助你及时掌握新闻动态，始终保持最佳状态。

请查看收件箱中的确认邮件，你可以在其中调整偏好设置，甚至加入更多群组。

在你常用的社交媒体平台上关注 TNS。

在 LinkedIn 上关注 TNS。

等待第一封 TNS newsletter 期间，不妨看看最新的精选与热门文章。

OpenAI 本月早些时候推出了 GPT-5.6 Sol，将其定位为一款面向高难度编码任务的模型。然而没过多久，重度用户就开始抱怨：他们的 ChatGPT Work 和 Codex 使用额度消耗得远超预期，甚至在任务看起来大部分时间都只是在等待工具执行完成时，额度也在快速减少。

作为回应，OpenAI 重置了 ChatGPT Work 和 Codex 用户的使用额度，并上线了后端推理优化。据称，这些改进可以让典型的 Sol session 延长约 18%。

这次更新解决了眼前最令人困扰的问题，同时也揭示了一个根本性转变——任何构建或部署 AI Agent 的人都必须正视这一变化。

OpenAI 工程负责人 Thibault Sottiaux 在 X 上发帖承认，公司低估了 Agent 在真实场景中执行任务所产生的成本。

“GPT-5.6 Sol 更愿意长时间持续工作、发起额外的工具调用，并协调跨工具和 subagent 的复杂工作流，”Sottiaux 写道，“这让它更擅长解决棘手问题，但有些任务消耗的额度远远超出了我们的预期。”

“GPT-5.6 Sol 更愿意长时间持续工作、发起额外的工具调用，并协调跨工具和 subagent 的复杂工作流。这让它更擅长解决棘手问题，但有些任务消耗的额度远远超出了我们的预期。”

Sol 意料之外的 token 胃口

Sottiaux 将大部分意外消耗归因于 Sol 新增的程序化工具调用能力，也就是“code mode”。该模式允许模型在工具于后台运行时继续工作，并协调更复杂的工作流，结果 Sol 消耗的 token 远远超出了 OpenAI 的预估。该公司承认，其测试并没有覆盖模型发布后重度用户的实际使用方式。“我们本应更早意识到这一点，也应该更坦诚地说明情况，”Sottiaux 写道。

“发布前，我们过于关注平均用量和中位数用量，因此遗漏了一些长尾场景，而这些场景的用量可能会高出许多。”

重度用户暴露边缘场景

大多数开发者都遇到过这种情况：系统在测试中表现良好，但重度用户会暴露出典型工作负载下从未出现过的边缘场景。AI 编码 Agent 让这类问题更容易被忽视，因为它们的大量工作都在不可见的情况下进行。

“事实上，对中位数用户而言，Sol 的 token 使用效率相当不错，”Sottiaux 指出，“但一些处理高难度任务的重度用户发现，他们的额度消耗得快得多。发布前，我们过于关注平均用量和中位数用量，因此遗漏了一些长尾场景，而这些场景的用量可能会高出许多。”

Agent 在等待时也会消耗 token

在 openai/codex GitHub 仓库中记录使用经历的开发者，让外界得以了解当时究竟发生了什么。一名用户描述了一次持续 43 分钟的编码 session：期间生成了近 300 次模型响应，还发起了 96 次执行调用和 192 次等待调用。最终，五小时使用额度中剩余的 42% 几乎被全部耗尽，而大部分消耗发生在等待工具返回结果的过程中。

另一名用户发现，看起来彼此独立的任务并没有同时执行，而是一个接一个地顺序运行，这不仅延长了运行时间，还在 700 多个执行单元中进一步增加了 token 消耗。

OpenAI 最初的应对措施，主要是提高这些工作流的效率。公司改进了 Sol 等待工具调用时的行为，精简了 web 搜索流程，并在相关改动逐步上线期间暂时取消了五小时使用上限。

聊天额度遭遇 Agent 工作负载

这些修复应该会提升 Sol 的效率，但同时也凸显出一个问题：订阅额度原本是围绕聊天场景设计的，而编码 Agent 并不一样。它们可能会花上 30 或 40 分钟处理一项任务，期间不断调用工具、修改代码，最后才返回结果。这让开发者更难预测单个任务究竟会消耗多少额度。

订阅额度原本是围绕聊天场景设计的，而编码 Agent 并不一样。