第一个旋钮：低档打赢上一代高档

从 GPT-5 那一代起，每代模型追的是同一件事：用更少的 token 干更长的活。5.6 继续这条线，Harness（模型外面那层调度代码：怎么发请求、怎么接工具、怎么循环）一个字不改，性能更强、花钱更少。

指南里给出的最直接的一条：在 Agents' Last Exam 这个 Agent 评测上，把 Harness 完全固定不动，GPT-5.6 Sol 开「低推理」的成绩超过了 GPT-5.5 开「高推理」。档位是花钱的主要旋钮，低档位打赢上一代高档位，等于同一件事的价钱直接掉一档。这一项指南没有给出具体分值。

能自己核对的对照在两张跑分图里。下面三组都是同一张图上的真实数据点，左边是上一代，右边是这一代：

两张图的成本量级差得远：搜索评测整套跑完只要几美元，编程指数整套要几百上千美元，题量和任务复杂度不同，别把两张图的金额横着比。上面每组对照都在同一张图内部。

省下来的到底是什么？是瞎折腾的那一部分。Hex 这家做数据分析的公司把模型丢进他们现成的 Harness 里，低推理档给出了他们见过最好的结果：

我们把 GPT-5.6 丢进现有的 Harness 里，低推理档给了我们最好的结果。它知道数据什么时候就是不存在，不会追着坏线索跑，用更少的 token 就走到了正确答案。

Izzy Miller，Hex 的 AI 研究负责人

「知道数据不存在」这句是关键。旧模型查不到东西时会换个关键词接着刨，每刨一轮，工具返回的内容都要当成输入 token 计费一次。会止损的模型省的正是这些空转的轮次。

往下调有效，但关到底反而更贵

降档能省钱，那把档位一路关到底是不是最省？把官方两张图里每个数据点摊开看，答案是不。

下面这个盘可以拨：选一个推理档位，四个型号的账单和分数同时跟着变。账单条的满格是 GPT-5.5 极高档跑完整套搜索评测的 33.27 美元，所有条都按这个尺子量。

而拨到最左边那一格，会看到跟直觉相反的东西。关掉推理并不省钱。两张图上各有一个证据：

• 搜索评测里的 Sol：关掉推理花 $1.97 拿 69.67 分；开到最低档只花 $0.50，拿 65.32 分。也就是说，关掉推理这个动作没省下钱，反而多花了 3.9 倍，换来的是多 4.3 分。
• 编程指数里的 Luna：关掉推理花 $123.66 拿 37.30 分；开到最低档花 $74.84，拿 42.40 分。这一组又贵又差，多花 65% 的钱，分数还低了 5.1 分。

另一头也有拐点。Luna 在搜索评测上从「极高」开到「顶格」，账单从 $1.33 涨到 $1.42，分数却从 84.04 掉到 83.25。档位开到顶，未必加分。

第二个旋钮：小型号能省 25 倍

档位这个旋钮拧完，第二个是换型号。GPT-5.6 家族有三个：Sol（旗舰）、Terra（中号）、Luna（小号）。

过去中小型号只配干边角料，原因是长上下文和大量工具调用它们扛不住，一旦任务链条拉长就掉链子。这一代变了，靠的是测试时计算。

结果就是 Luna 和 Terra 常常能打到 GPT-5.4、GPT-5.5 的水平，价钱却低一大截。指南里点名的那组对照，来自 BrowseComp，一个专考「能不能搜出犄角旮旯里的冷门事实」的评测：

Hypha 这家做文档 Agent 的公司给了另一个角度的数字：

Luna 保住了 GPT-5.5 提取准确率的 98%，成本只有十八分之一。这让我们的 Agent 能用得起高质量的文档理解，而且这个价钱在多得多的场景里都算得过账了。

Serhii Shchoholiev，Hypha 的 Agent 工程负责人

小型号该塞进流程的哪一段

三类活最适合交给它们：量特别大的、用户在等着的（对延迟敏感的交互）、Agent 流程里反复要做的那几步。

指南举的例子落在一家法律科技公司，Agent 分析之前得先把手写备忘录解析成文字。这个解析步骤不需要判断力，过去却跟着整条流程一起用旗舰模型。把它单独拆出来换成 Terra 或 Luna，省下的是实打实的钱，而后面真正需要判断的那一步照旧用 Sol。

这两张图是 OpenAI 自己跑的，图上除了自家模型还标了 Claude Fable 5、Claude Opus 4.8、Claude Mythos Preview 和 Gemini 3.1 Pro Preview。BrowseComp 那张图里，竞品只以横向参考线出现，只给了分数（Claude Mythos Preview 87.9%、Gemini 3.1 Pro Preview 85.8%、Claude Opus 4.8 84.4%），没给对应的成本，所以没法拿它们跟上面这组价钱做对照。本文的自画图只呈现 GPT-5.6 家族内部的档位与成本关系。

三个架构开关，两个就翻了近三倍

型号和档位这两个旋钮拧到头，也就这样了。剩下的省钱空间在架构里，具体说，在于 Agent 每一轮到底往上下文里塞了些什么。

指南把提效方法归成三类，并且强调 GPT-5.6 是带着这三件事一起端到端训练的，模型本来就懂怎么配合它们，无需在外面搭一层技巧去哄它：

这三件事一起开有多大差别，指南给了一个硬例子。在 ARC-AGI-3 这个评测上，GPT-5.6 Sol 用标准 Harness 拿 13.3%；只把「保留推理」和「压缩」两个开关打开，分数跳到 38.3%，同时输出的 token 还少了约 6 倍：

分数接近三倍，token 反而少了六分之五。这两个数字同时出现，说明省下来的正是那些「重新想一遍」和「重新组织一遍上下文」的空转。

开关一：别让模型每轮重头再想

先看第一个开关，治的是长任务里最贵的浪费：模型把之前做过的功白做一遍。

持久化推理：上一轮的思考带进下一轮

过去模型每一轮的思考过程，答完就丢了。下一轮它只看得见对话记录，看不见自己上一轮是怎么想的，于是从头再想一遍。5.6 支持把之前几轮的推理条目直接带进下一轮的上下文，参数是 reasoning.context：

两个容易踩的点。第一，all_turns 只在这次请求够得着之前的响应时才有效，要么用 previous_response_id 串起来，要么把完整的响应历史重放一遍；第一次请求时两种取值没有区别，因为还没有之前的推理。第二，它给的只是连续性：那些推理条目仍然加密不可读，API 不会返回推理文字，你看不见模型想了什么。

原生压缩：撞到阈值就自动打包

对话总会越滚越长。原生压缩的做法是设一条线：请求里加上 context_management，写明 compact_threshold（比如 20 万 token）。渲染出来的上下文超过这条线，服务端自动跑一遍压缩，在同一个响应流里吐出一个「压缩条目」，然后把前面的上下文裁掉，接着往下推理，不需要你另外调一次接口。

这里最容易理解错的是压缩块的性质。它不透明、人读不懂，官方文档里的原话是「opaque and not intended to be human-interpretable」。它跟「让模型写一段对话摘要」是两回事：摘要是自然语言，写多少、丢什么由模型现场发挥；压缩条目是模型在训练时就学会了怎么打包、怎么拆开的结构，把之前的状态和推理用更少的 token 原样带走。

while keep_going:
    response = client.responses.create(
        model="gpt-5.6",
        input=conversation,
        store=False,
        context_management=[{"type": "compaction", "compact_threshold": 200000}],
    )
    conversation.extend(response.output)
    conversation.append({"type": "message", "role": "user",
                         "content": get_next_user_input()})

还有一个独立的 /responses/compact 端点，给需要自己掌控时机的场景用：你送一整个上下文窗口进去，它还你一个压缩好的窗口，完全无状态。用它的时候有一条硬规矩，返回的窗口原样传给下一次调用，不要自己裁剪，因为那个窗口里除了压缩条目，还留着上一轮里需要保留的条目。

反过来，用服务端压缩加 previous_response_id 串联时，也不要手动裁剪条目。只有走无状态的输入数组模式时，才可以把最近一个压缩条目之前的东西丢掉，让请求体小一点、长尾延迟低一点。

开关二：让模型写代码筛数据

长任务的功不白做了，但还有一处更常见的浪费：上下文被中间结果撑爆。

Agent 干的活其实分两种。一种要判断力，这份合同有没有问题、该不该继续查下去；另一种纯粹是搬运数据，筛选、合并、排序、去重、求和。麻烦在于，过去这两种活都得在模型的上下文里干。

指南举的例子是这样：Agent 去拉了 100 份文件回来，要按日期筛一遍，再找出里面相关的交易。老办法下，这 100 份的内容全都进上下文，模型一条条读过去。三个后果一起来，慢、贵，而且上下文越塞越满，模型反而越读越糊涂（这个现象叫 context rot，上下文腐烂）。

程序化工具调用（Programmatic Tool Calling）换了个做法：模型直接写一段 JavaScript 去指挥这些工具。这段代码能并行发起互不相干的调用，能写循环和条件判断，中间结果全留在 OpenAI 托管的运行环境里，最后只把筛完的那个结果交回模型手上。

那段代码跑在什么地方

跑在一个全新的、隔离的 V8 运行时里，每次执行都是干净的。这个环境的边界画得很死：

• 有的：JavaScript，支持顶层 await；能调你在这次请求里开放的那些工具；能用 text(...) 或 image(...) 输出结果。
• 没有的：Node.js、装包、网络访问、通用文件系统、子进程、console，以及两次执行之间的任何状态。
• 你的函数仍然在你自己的服务器上跑：程序执行到你的工具时会暂停，把调用吐给你，你跑完把结果连着原样的 caller 字段回传，程序才接着往下走。一次运行可以这样暂停很多回。

哪些工具允许被代码调用，由你说了算。每个工具上标一个 allowed_callers：

支持被代码调用的工具类型有：普通函数和自定义工具、MCP 工具、apply_patch、本地和托管的 shell、代码解释器。MCP 工具的审批策略照旧生效，设了需要审批，程序会停在那儿等你批。

{
  "type": "function",
  "name": "get_inventory",
  "parameters": {
    "type": "object",
    "properties": { "sku": { "type": "string" } },
    "required": ["sku"],
    "additionalProperties": false
  },
  "output_schema": {
    "type": "object",
    "properties": {
      "sku": { "type": "string" },
      "available_units": { "type": "number" }
    },
    "required": ["sku", "available_units"],
    "additionalProperties": false
  },
  "allowed_callers": ["programmatic"]
}

什么时候别用它

这个开关不是开了就一直赚。官方按任务形态给了一张对照表，判断标准是这一段的控制流可不可预测、代码能不能把结果变小：

两种模式都开的时候，还得告诉模型哪一段走哪条路。「高效使用程序化工具调用」这种话没用，它没有划出边界。官方给了一段可以直接抄的模板：

<tool_orchestration>
Use Programmatic Tool Calling for [bounded stage] using only [eligible tools].
Run independent calls concurrently when safe. Use only documented tool input
and output fields.
Process and reduce the intermediate results, then emit exactly [program result shape],
including the evidence needed for the final answer.
Stop when [condition] is met. Retry transient failures at most [R] times.
Do not repeat completed calls or perform side-effecting actions. If a required
result is still missing, return a clear structured failure.
Use direct tool calls for [semantic judgment, approval, or final validation].
</tool_orchestration>

Rogo 这家做金融研究的公司，把这套用在了拉财报、协调工具、算数字这条链上：

做金融研究，难的地方在于可靠地把文件拉全、把工具协调好、把数字算对。我们的评测里，GPT-5.6 用程序化工具调用达到了跟原来一样的评分标准，同时少用了 21% 的输入 token。这就是「一个能聊金融研究的 Agent」和「一个真能把金融研究做完的 Agent」之间的差别。

Alex Wang，Rogo 应用 AI 团队

开关三：主 Agent 派活并行干

确定性的活能挪出去，能拆开的活也该同时干。

一个任务如果能切成几块互不依赖的工作，单个 Agent 只能一件件排队做，多个 Agent 可以同时开工。5.6 把这套编排做进了 API：主 Agent（叫 /root）负责拆任务、派活、等结果、最后汇总成一个回答，你的应用不用自己写编排逻辑。

Qualia 拿一堆开放式研究问题喂给一队 Agent 跑，GPT-5.6 Sol 一上手就对了。它比 GPT-5.5 有明显提升，比我们测过的几乎所有模型都跑得快，很快成了我们默认用的 OpenAI 模型。

E Chi，Quadrillion 创始人

GPT-5.6 是我们见过 OpenAI 最好的编排者。我们一次性甩给它六份需求（写、做、还要把六份都讲一遍），它全程没丢线索，质量也没散架。

Jon Bell，Obvious 联合创始人兼首席产品官

好处有三条，而且是三件不同的事：并行执行省的是墙上时钟时间；上下文各管各的，每个子 Agent 只拿到一个边界清楚的任务，互不相干的工作不会在同一个上下文里打架，准确率反而更高；协调由模型做主，派生、传话、等待都是它自己调度。

怎么开、怎么管

模型自己对「该派几个、什么时候派」有判断，但这件事管得住。官方给了两句现成的，一保守一激进，直接贴进 prompt 就行：

保守：只在用户明确要求时才派

Do not spawn subagents unless the user explicitly asks for subagents,
delegation, or parallel agent work.

激进：并行能明显提升速度或质量时主动派

Proactive Multi-agent delegation is active. Use subagents when parallel
work would materially improve speed or quality.

运行过程中你会在输出里看到六种协作动作，它们由服务端托管，你的应用不需要执行、也不用给它们返回结果：

四种情况别开

这个开关有四种明确的反面场景：

• 每一步都直接依赖上一步，本来就是一条有序的推理链，拆不开。
• 任务小到一趟就能跑完，派人的开销比干活还大。
• 几个 Agent 会抢同一份可变资源，频繁写同一个共享状态，并行只会打架。
• 你需要一个固定确定的执行图，模型自己调度就意味着执行路径不完全可预测。

另外，如果整件事的时间本来就卡在某一个慢的外部操作上，多派几个 Agent 也快不了。

开了多 Agent，这几件事会跟着变

官方文档单列了几条限制，其中第一条会直接影响上一节讲的压缩：

• 压缩会被自动打开。multi_agent.enabled 一设成 true，服务端压缩就隐式启用，哪怕你的请求里压根没配 context_management。压缩对根 Agent 和每个子 Agent 分别独立生效，各自保住自己的上下文；想改阈值，仍然可以显式写一个 compact_threshold 盖过默认。
• 独立的 /responses/compact 端点用不了了。想自己掌控压缩时机的那套做法，在多 Agent 下不支持。
• reasoning.summary 不支持。
• max_tool_calls 不支持。靠这个字段兜底控制工具调用次数的，开多 Agent 前要另想办法。

ChatGPT 里那个 ultra 档位，底下就是这套机制。在 BrowseComp 那张图上它单独占一个点：GPT-5.6 Sol Ultra 顶格档拿到 92.18 分，花 12.17 美元，比 Sol 单独跑顶格档的 90.36 分高 1.8 分，账单差不多是两倍。

最后一个开关：缓存断点设错更亏

前三个开关都是净赚。最后一个不一样，它可能倒亏钱。

指南里关于缓存写了两句好消息：整个模型家族的缓存存活时间延长到至少 30 分钟，缓存断点（cache breakpoint）现在可以在上下文里确定性地设置。Ploy 那边的实测是这样：

我们给一个 29,000 token 的共享 prompt 加上了缓存断点和按工作区区分的 key，未缓存的输入砍掉了 28%。30 分钟的缓存窗口也是个大解锁：我们的 Agent 可以跨多次运行复用同一份上下文，不用每次都从头加载。

Lorenzo Gentile，Ploy 的 AI 工程师

但官方文档里的一张对照表说明了指南没提的一件事：GPT-5.6 把缓存的匹配方式改了。

默认情况下，系统把一个隐式断点放在最新的那条用户或工具消息上，而且不会像老模型那样自动往前找最长能对上的前缀。三档计价说清楚就是三句话：

把这两件事放一块，倒亏钱的路径就出来了。假设你的 prompt 是「一段几万字的稳定指令 + 一个时间戳 + 用户这次的问题」，你什么都不设：

断点标在哪一个内容块上，那个块连同它前面渲染的所有内容就是可复用的前缀。所以规则只有一条：找出每次请求都不变的那部分，把断点画在它的最后。

{
  "model": "gpt-5.6",
  "prompt_cache_key": "support:knowledge-base-v1",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "type": "message",
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Follow the shared support policies and reference material...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    }
  ]
}

断点可以设多个，用在 prompt 里不同部分变动频率不一样的时候（共享指令很稳、参考资料偶尔更新），这样每次请求都能复用最长的那段没变的前缀。但有两个上限要知道：每次请求最多写 4 个新缓存（超过 4 个断点，只有最后 4 个会被写；隐式模式下最新那条消息的断点先占掉一个名额），读缓存时最多回看最近 50 个断点，多个断点都能对上时，服务端从最长的那段匹配前缀读。

三种模式怎么选：隐式（默认）适合对话式地往后追加内容、前面历史不变的场景；隐式加显式断点适合共享前缀和增长的历史都值得复用；只用显式适合前缀稳定、后面每次都不一样且几乎不会被复用的场景。

还有个跟延迟有关的：给相关请求配同一个 prompt_cache_key，能提高它们落到同一台推理机器上的概率，那台机器上正好有之前写好的前缀，延迟也跟着降。

六处改动的参数速查

整篇能带走的东西，就是下面这张表。

只写在官方文档里的限制

• 缓存前缀不到 1,024 token 就完全不进缓存。这个数算的是断点为止渲染出来的整个前缀，不只是你标记的那一块。
• 每个 prompt_cache_key 的流量控制在每分钟 15 个请求左右。超了命中率会掉，大流量要用稳定的、确定性的 key 去分片。
• 复用一次会刷新 30 分钟寿命，而且刷新不再收写入费。30 分钟从写入那一刻算起，每次被复用重新计时。
• 派子 Agent 会多烧 token。拆不开的任务、要频繁写同一份共享状态的任务，开了只是把钱花在协调上。
• 程序化工具调用的沙箱没有网络、没有文件系统、装不了包、跑完不留状态。代码只能通过你这次请求里开放的工具跟外界打交道。
• 每次请求最多写 4 个新缓存，读缓存最多回看最近 50 个断点。断点设多了，只有最后 4 个会被写进去。
• 开多 Agent 会隐式打开服务端压缩，而且 /responses/compact 端点、reasoning.summary、max_tool_calls 都不再支持。这一条最容易踩：你以为压缩没开，其实它自己开了。

缓存不命中时按这四条查

指南收尾的那句话，就是这张表的总结：过去每一步都得上前沿模型的活，现在靠换小型号、调推理档位、加上架构上的选择，能用零头的价钱做到同等甚至更好的结果。

省钱的第一反应容易是把"多想"直接关掉。OpenAI 自己的跑分图说反了：关闭推理从没让账单变低。

调档位的方向是从最低档往上试，账单和分数一起看，到拐点就停。

档位和型号之外，GPT-5.6 把三件事直接训练进了模型：让推理跨轮次留下来、把搬运数据的活交给代码去跑、把能拆开的任务派给几个 Agent 并行干。三件事都是配置层面的改动，不用换模型也不用重写调度代码。

六个开关分两层：两个是旋钮（推理档位、模型型号），四个是配置开关。全部都是改配置，不用换模型也不用重写调度代码。