这几天用 GPT-5.6 Sol 的人，大概都有过相似的疑问：它确实更肯做事，也更愿意把一个任务往深处推，可额度看起来为什么掉得比预期快？

OpenAI 产品负责人 Tibo 在 7 月 28 日的说明 里正面回应了这个体感。他表示订阅方案的可用额度没有被下调；团队针对效率做了改进，典型 Sol 使用场景预计能多撑约 18%。同时，他也解释了问题为什么会集中发生在一部分重度用户身上：Sol 更容易长时间工作、追加工具调用、协调复杂工作流；同样的推理档位，实际计算量也可能明显高于旧模型。

这不是一句“模型变贵了”就能说明白的事情。更准确的说法是：Agent 的一轮工作已经不再等于一次问答。 当模型自己决定继续查文件、再跑测试、拉起子任务、等待网络结果、把返回内容塞回上下文并再次思考时，用量是沿着一棵任务树增长的。

先把结论说清楚

有三件事必须分开看。

1. 订阅额度不是 API token 账单。 订阅产品会把模型、套餐、公平使用、窗口限制和内部计量组合起来。不能把 API 价目表直接换算成“我的周额度还剩多少”。
2. 同一个推理档位不代表同一份工作量。 high 是行为和能力目标，不是一张固定的 token 配额。Sol 在同一档位下可能多做规划、多试几条路径，也更容易继续调用工具。
3. 工具调用不是免费的旁路。 工具返回的文件片段、测试日志、搜索结果和错误详情，常常会回流到下一轮上下文。一次看似很短的命令，可能把后续每一轮输入都变大。

所以，额度掉得快不必然意味着模型在“空转”；也不意味着每一次长回合都值得。真正要做的是把一次 Agent 任务拆开，找到其中可控制的放大器。

一次 Agent 回合，到底在消耗什么

可以把一次任务看成下面这本账，而不是一条 prompt：

总用量压力 ≈
  指令与仓库上下文
  + 本轮新读入的文件与工具结果
  + 已缓存上下文的读写
  + 模型输出与推理
  + 追加的工具轮次、重试与子任务

这不是任何产品的官方计费公式，只是排查用量时很实用的工程模型。它提醒我们：对 Agent 来说，最重要的不是“第一句问了多长”，而是接下来会发生几轮，每一轮会带回多少东西。

图中有四类输入。它们在界面上通常不会同时显眼，但对长任务的影响完全不同。

指令与环境：最容易被低估的固定成本

系统提示词、目录级 AGENTS.md、技能说明、MCP 工具描述、仓库规则和当前线程历史，都会在任务开始时形成底座。它们不一定每次都以“新输入”的样子出现，但会影响后续上下文长度、缓存命中和模型的决策空间。

大仓库里常见的误区，是把所有历史规范都放进根目录说明文件。模型当然会更了解背景，但一个只改两行前端文案的任务，也可能带着几十页架构约束出发。对人而言这叫“资料齐全”，对 Agent 而言则是每个回合都背着同一个行李箱。

更好的做法是分层：根目录只放通用约束；服务级说明放在服务目录；临时迁移、排障和一次性背景放在任务 prompt 或专门文档里。让模型在真正进入某个目录时再读取对应规则，比从第一轮起全量注入更合理。

工具调用：并行更快，不等于更省

OpenAI 在 GPT-5.6 的介绍中提到，Programmatic Tool Calling 可以让模型更灵活地并行发起工具调用，并在等待时继续推进其他工作；官方测得它在特定评测中能以更少输出 token、更短时间完成任务。GPT-5.6 发布说明

这解释了为什么它很有吸引力，也解释了为什么重度使用者的体感会分化：并行把等待时间压缩了，却可能在一次回合里同时产生更多结果。三个搜索、两段日志、一次测试失败和一次文件扫描，如果都被完整带回下一轮，节省的是墙钟时间，增加的却可能是上下文体积。

工具的正确目标不是“少用”，而是每次返回刚好够下一步决策的信息：

• 文件搜索先返回路径、命中行和短摘要，不要默认返回整文件；
• 测试失败先返回失败用例、关键堆栈和日志末尾，而不是几万行原始输出；
• 搜索先给去重后的候选和来源，选定后再展开全文；
• 让工具把结构化结果交给模型，而不是让模型从一大片混合文本里重新找字段。

缓存：便宜不等于没有成本

缓存通常能显著降低重复上下文的成本，但它不是“零成本上下文”。OpenAI 对 GPT-5.6 API 的公开说明中写明：缓存读取享受很高折扣，而缓存写入仍有单独成本。GPT-5.6 模型说明

这条 API 规则不能用来推算订阅额度，却能帮助理解一个现象：当模型不断改变前缀、插入新的工具结果、重写计划或切换子任务时，原本有机会复用的上下文未必总能命中同一段缓存。Tibo 的说明中也把“更多缓存输入 token”列为 code mode 下用量高于预期的原因之一。

工程上能做的不是“关闭缓存”，而是保持稳定前缀：固定的项目规则尽量少改；把临时日志放在短生命周期的任务段；不要为了一个小问题频繁换模型、切线程又把同一大段背景重新读一遍。

真正的放大器：重试把结果又带回来了

一轮工具调用本身不一定可怕。更昂贵的是下面这种链条：工具失败，模型读取错误；模型修改假设，再调用一次；新结果和旧错误共同进入下一轮；然后它再做一轮更长的判断。

这也是为什么“让它自己一直试到成功”对某些问题很有效，对另一些问题却很浪费。网络权限缺失、错误的环境变量、依赖不存在、上游限流等确定性故障，连续重试不会增加信息，只会把相近的错误反复写进上下文。

一个可靠的 Agent 应该有明确的停止条件：

• 同类错误连续两次，改为汇总证据并请求人工决策；
• 外部服务返回限流，按 Retry-After 或退避策略等待，不把快速重试交给模型临场决定；
• 测试范围先缩小，定位后再跑全套；
• 子任务返回结论、证据链接和必要片段，而不是把完整过程转发给主线程。

这几条并不削弱模型能力，反而把模型擅长的判断留给有信息增量的地方。

为什么 Sol 的体感会比旧模型更明显

Tibo 的说明里有两点很关键。

第一，Sol 更愿意长时间推进任务。以前模型可能在两次工具调用后就给出一个半成品结论；现在它更可能继续检查边界、补跑验证、协调多个工具或子任务。难题上的完成率可能因此提高，但一次任务的“自然结束点”往后移了。

第二，同样写着 high，Sol 做的工作可能比 GPT-5.5 的 high 更多。把推理档位理解成方向盘，而不是油箱容量，会更接近事实：它告诉模型该多努力到什么程度，却不保证每公里消耗相同。

这也解释了“中位数用户觉得还好，少数重度用户却掉得特别快”的分布。短问答、少量文件修改、工具链很短的用户，不容易碰到任务树的乘法效应；复杂仓库、多个 MCP、长线程、反复测试、浏览和子任务协作叠在一起时，额外轮次会迅速放大。

用一张表记录，而不是靠百分比猜

想知道自己的额度到底耗在什么地方，不需要先搭一套大平台。连续挑三类固定任务，各做三次，就足够看出趋势。

任务类型	建议样本	需要记录的字段	想回答的问题
小改动	修改一个函数并跑定向测试	首轮上下文、工具轮次、测试次数、完成时间	固定上下文是不是过重？
中等排错	复现一个明确错误并修复	错误类型、相同错误重复次数、返回日志大小	重试是否带来了新信息？
长任务	设计、实现、验证一个小功能	子任务数、并行工具数、线程长度、最终改动量	长任务的额外工作是否换来了可验证的质量？

每次都尽量固定模型、推理档位、仓库版本和 prompt。记录时只保存汇总数字和任务类型，不要把源代码、密钥或原始业务数据丢进另一套日志。三轮后，通常就能得到有行动价值的判断：是说明文件太大、工具输出太散、测试太宽，还是某类任务确实应该交给更强的模型。

一套不牺牲质量的使用策略

我更推荐把 Sol 当作“需要判断和耐心”的执行者，而不是所有命令的默认替代品。

先把任务做成可收敛的合同

不要只说“看看这个项目有什么问题”。给出边界、验收项和不该碰的区域：

目标：修复订单导出在空日期范围时报错的问题。
范围：只修改 export 模块及其单元测试。
验收：空范围返回空列表；已有范围行为不变；运行指定测试文件。
停止条件：若问题涉及数据库迁移或接口契约变化，先说明证据和方案，不执行扩展改动。

这类约束不会让模型变笨，反而减少了“顺手再检查十件事”的自由度。对复杂 Agent，任务边界就是控制任务树分叉数的第一道闸门。

先取证，再决定是否并行

并行适合互不依赖、结果短小且能够一起决策的步骤，例如同时查看三个独立模块的入口。它不适合把所有可能命令一次铺开：那样即便其中一个结果已经足够定位问题，其余结果仍会回来占据上下文。

一个简单的判断标准是：如果第一个结果会改变第二个工具的参数，就不要并行。 先取证，确认路径，再展开；这通常既更快，也更省。

给工具设置“短回执”

工具层最好输出机器可读的摘要：状态、关键字段、下一步建议、完整结果位置。模型需要证据时再按引用读取原文。把所有信息一次性塞回聊天窗口，最容易诱发上下文膨胀和重复分析。

把长线程当成需要维护的状态

一个线程完成一个可验收的阶段后，写下简洁交接：已完成什么、改了哪些文件、验证结果、未决问题。下一阶段从这个交接重新开始，往往优于带着数十轮历史继续聊。

这不是机械地“每十轮开新会话”。真正的切分点是：旧工具结果已经不再影响下一步决策，或者模型开始反复回顾自己早已完成的工作。此时短摘要比完整历史更有价值。

供应商该优化什么，使用者又该控制什么

Tibo 的帖子值得肯定的地方，是把问题定位到了具体机制：更长的工作、多工具协调、同档位更高的推理投入，以及 code mode 在等待和大量搜索时额外产生的响应与缓存输入。他也表示团队已经改进等待工具和搜索场景的处理，并计划恢复此前临时暂停的五小时限制窗口。

这些是平台侧要解决的：更准确的用量估计、清楚的任务级可观测性、等待期不必要的响应削减、更合理的缓存和工具调度。使用者无法修复这些底层实现。

但使用者能控制任务形状：上下文边界、工具输出大小、并发条件、重试预算、子任务交付物和线程生命周期。它们共同决定了模型的能力会被用在验证上，还是被耗在重复搬运信息上。

Sol 的变化提醒了一个朴素事实：更强的 Agent 不会自动带来更低的成本。能力提升让它有更多行动选择，工程设计的职责则是让这些选择尽量产生新信息、离验收更近。

参考资料

• Tibo：GPT-5.6 Sol 用量与效率更新
• OpenAI：GPT-5.6 发布说明
• OpenAI Help：GPT-5.6 在 ChatGPT 中的可用性与限制
• OpenAI Help：Codex Rate Card

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。