OpenAI GPT-5.6 构建指南拆解：创业公司如何用模型选择与 Responses API 降低 Agent 成本

文章目录

- [先看结论：Agent 降本已经变成一个路由问题](#先看结论：Agent 降本已经变成一个路由问题)
- [第一层优化：Sol、Terra、Luna 应该如何分工](#第一层优化：Sol、Terra、Luna 应该如何分工)
- [第二层优化：`reasoning.effort` 是独立的成本旋钮](#第二层优化：reasoning.effort 是独立的成本旋钮)
- - [为什么不能只看 Token 单价](#为什么不能只看 Token 单价)
- [Responses API 的四个工程杠杆](#Responses API 的四个工程杠杆)
- - [1. 持久化推理与 Compaction：不要每一轮都从头开始](#1. 持久化推理与 Compaction：不要每一轮都从头开始)
  - - 示例：延续推理并调整模型配置
  - [2. Programmatic Tool Calling：把确定性工作移回代码](#2. Programmatic Tool Calling：把确定性工作移回代码)
  - [3. Multi-agent：只为真正可并行的任务付费](#3. Multi-agent：只为真正可并行的任务付费)
  - [4. Prompt Caching：优化稳定前缀，而不是缓存一切](#4. Prompt Caching：优化稳定前缀，而不是缓存一切)
- 一套创业团队可以执行的成本优化框架
- 两周落地路线：从离线评测到小比例上线
- - 第一周：建立基线与路由
  - 第二周：影子流量与渐进发布
- [OpenAI 这份指南透露了哪些能力边界](#OpenAI 这份指南透露了哪些能力边界)
- - [推论一：小模型能承担更多 Agent 环节，但不等于所有任务都应降级](#推论一：小模型能承担更多 Agent 环节，但不等于所有任务都应降级)
  - [推论二：Responses API 正从生成接口变成 Agent 基础设施](#推论二：Responses API 正从生成接口变成 Agent 基础设施)
  - 推论三：真正的竞争点是评测与路由能力
- 写在最后
- 参考资料

2026 年 8 月 13 日，OpenAI 发布《The builder's guide to GPT‑5.6》。这不是一份简单的新品功能清单，而是一套面向生产环境的 Agent 成本优化方法：把模型选择、推理强度、上下文管理、工具调用和并行策略放进同一套路由系统。

过去一年，许多创业团队优化 AI Agent 的方式都很直接：先接入当前最强模型，等账单变高或延迟变长，再寻找更便宜的替代品。这种做法在原型阶段足够省事，到了生产环境却很容易失控。

原因不难理解。一个完整 Agent 流程通常同时包含文档抽取、检索、排序、信息核验、复杂判断、工具调用和最终审查。它们对智能的要求并不相同。如果每一步都使用最强模型和最高推理强度，团队支付的不只是更贵的 Token，还包括更长的响应时间、更大的上下文，以及更多不必要的模型判断。

OpenAI 的官方构建指南给出的核心信号可以概括为一句话：不要再让最强模型处理工作流中的每一步。

更准确地说，GPT‑5.6 带来的变化不只是出现了 Sol、Terra、Luna 三个价格不同的模型层级。OpenAI 同时扩展了 Responses API，让开发者能够保存跨轮次推理、压缩长上下文、把确定性数据处理移入代码、按需启用多 Agent，并更精确地控制提示缓存。模型变便宜只是第一层，架构开始围绕"什么时候需要智能，什么时候只需要计算"重新分工，才是这份指南真正值得创业团队关注的地方。

本文会逐条拆解这些建议，并把它们整理成一套可执行的成本优化框架。文中涉及的官方评测与企业数据均来自 OpenAI 发布的材料，并不代表本文进行了独立复现，也不应直接外推到其他业务。

先看结论：Agent 降本已经变成一个路由问题

如果你的团队正在构建生产级 Agent，可以先记住下面五条：

先按任务难度路由模型，而不是给整个产品绑定一个模型。
模型选定后，再独立评测 reasoning.effort，不要默认使用最高档。
对长任务复用已经完成的推理，并在上下文膨胀前做压缩。
把过滤、聚合、去重等确定性工作交给代码，把模型 Token 留给判断。
用"每个成功任务的成本"做最终指标，而不是只比较每百万 Token 单价。

这五条组合起来，才构成一套完整的 Agent 成本系统。只完成其中一项，往往会把成本转移到另一个位置：模型单价降了，但重试次数增加；输出缩短了，但错误率上升；启用了多 Agent，单次延迟下降了，总 Token 却翻倍。

所以，本文所说的"降本"始终有一个前提：质量底线不能被悄悄放弃。

第一层优化：Sol、Terra、Luna 应该如何分工

GPT‑5.6 采用了新的模型分层。根据 OpenAI 的 GPT‑5.6 模型指南，gpt-5.6 是指向 gpt-5.6-sol 的别名；Sol 面向旗舰能力，Terra 在智能与成本之间取平衡，Luna 面向高吞吐、成本敏感的工作负载。

三个模型不是"好、中、差"

最容易犯的错误，是把三者理解成简单的质量排名，然后认为重要产品只能使用 Sol。更实用的理解是：它们是三种不同的单位经济模型。

Sol 适合错误代价高、判断链较长、需要跨来源综合或复杂工具协作的任务。
Terra 适合需要稳定判断能力，但调用量、延迟和预算同样重要的主流程。
Luna 适合高频、可验证、低风险或可回退的工作，例如抽取、分类、检索前处理和重复步骤。

换句话说，Sol 不应成为所有步骤的默认值，Luna 也不应因为便宜就承担所有任务。模型路由的目标，是让每个步骤使用"达到质量底线所需的最低成本配置"。

当前标准短上下文价格

下表是 2026 年 8 月 18 日实际查询 Sol、Terra 和 Luna 模型页时显示的标准文本价格，单位均为美元/百万 Token：

模型	输入	缓存输入	输出	官方定位
`gpt-5.6-sol`	$5.00	$0.50	$30.00	复杂专业工作与旗舰能力
`gpt-5.6-terra`	$2.00	$0.20	$12.00	智能与成本平衡
`gpt-5.6-luna`	$0.20	$0.02	$1.20	成本敏感的高吞吐任务

这个价差足以改变 Agent 的架构设计，但不能用一个简单乘法得出最终账单。官方模型页还注明：当单次提示输入超过 272K Token 时，整次请求的输入价格按 2 倍、输出价格按 1.5 倍计算；工具调用也可能产生额外费用。价格和计费规则可能继续变化，真正上线前应重新查看官方页面。

这意味着"大上下文能装下"不等于"把所有内容塞进去最划算"。如果系统把每一份历史文件、全部工具描述和所有中间结果重复发送，即使换成更便宜的模型，也可能被长上下文定价和重复输入抵消收益。

一张可直接使用的模型路由表

创业团队可以从下面这张初始表开始，再用自己的评测数据修正：

任务类型	推荐起点	推理强度起点	何时升级	主要验证方式
字段抽取、格式转换、标签分类	Luna	`none` 或 `low`	结构校验失败、置信度不足	Schema 校验、规则比对
向量检索前处理、关键词扩展、候选粗排	Luna	`low`	召回不足或歧义较大	Recall@K、人工抽检
常规浏览器操作、表单读取、重复工具步骤	Luna 或 Terra	`low`	页面状态异常、动作不可逆	状态断言、截图或 DOM 校验
多文档归纳、常规业务分析、内容审查	Terra	`medium`	证据冲突、任务高风险	Rubric、引用完整度
复杂规划、跨系统决策、疑难代码分析	Sol	`medium` 或 `high`	质量仍不达标时再提高 effort	任务成功率、专家复核
最终财务、法律、权限或发布审查	Sol + 人工	按评测选择	不应仅靠模型自动升级	强制审批、审计日志

这张表不是官方规定，而是根据官方模型定位推导的工程起点。真正的路由条件最好来自可观察信号，例如结构化输出是否通过验证、证据是否齐全、工具是否报错、任务是否涉及外部写入，以及当前步骤的失败代价。

官方案例说明了什么，又没有说明什么

OpenAI 在指南中给出了多组生产案例：Hypha 表示 Luna 在文档抽取任务中保留了 GPT‑5.5 约 98% 的准确率，成本约为后者的十八分之一；Browser Use 披露，在 106 个高难浏览器任务上，Luna 完成率为 78%，约花费 14 美元，而其对比的当前 SOTA 模型完成率为 80%，约花费 235 美元；PlayerZero 则称 Luna 在一项代码探索任务中降低了 64% 推理成本、缩短了 90% 响应时间，同时 F1 提升 5 个点。

这些数据有启发性，但它们首先是特定公司、特定评测集和特定工作流的结果。我们不知道每家公司完整的提示、工具、失败处理、缓存命中率和人工复核成本。因此，合理结论是"小模型值得优先进入候选集"，而不是"Luna 在任何工作负载上都能复制相同降幅"。

第二层优化：`reasoning.effort` 是独立的成本旋钮

选定模型之后，仍然有第二个经常被忽略的变量：推理强度。

GPT‑5.6 家族支持 none、low、medium、high、xhigh 和 max。OpenAI 的建议不是"一律调到最高"，而是迁移时保留当前推理档位作为基线，再测试同一档和低一档；对延迟敏感的任务，可以把 low 作为起点；只有当更高推理强度带来可测量的质量增益时，才继续上调。

这个建议非常重要，因为模型与推理强度构成了一个二维选择矩阵：

	低推理强度	中推理强度	高推理强度
Luna	高频抽取、分类、检索步骤	复杂但可验证的重复任务	仅在评测证明有收益时使用
Terra	常规分析、工具调用	主流程判断与综合	关键但仍需成本控制的任务
Sol	延迟敏感的高难任务	复杂规划和跨源判断	少量质量优先、错误代价高的任务

表格中没有"永远正确"的格子。真正的优化过程，应是沿着成本更低的方向逐格移动，直到触碰质量底线，再退回上一个通过评测的配置。

为什么不能只看 Token 单价

假设模型 A 每次调用 0.02 美元，任务成功率为 60%；模型 B 每次调用 0.05 美元，成功率为 95%。如果失败请求需要完整重试，且重试成本相同，那么模型 A 看起来便宜，实际每个成功任务的期望成本可能更高，还会带来更差的尾延迟。

更合理的指标是：

text 复制代码

每个成功任务成本 =（模型费用 + 工具费用 + 重试费用 + 人工复核费用）/ 成功任务数

这里的"成功"也不能只看模型是否返回了文本。对一个研究 Agent，成功可能意味着结论有证据、引用可访问、关键字段完整；对一个浏览器 Agent，成功意味着页面状态确实发生了预期变化；对一个客服 Agent，成功还包括没有触发错误退款、越权操作或隐私泄露。

OpenAI 在指南中披露，GPT‑5.6 Sol 使用 low 推理强度时，在 Agents' Last Exam 上超过了相同 harness 下使用 high 的 GPT‑5.5；BrowseComp 案例中，GPT‑5.6 Luna（Extra High）以 84.04% 的成绩接近 GPT‑5.5（Extra High）的 84.36%，当时报告的成本分别为 1.33 美元和 33.27 美元。它们说明低推理强度或小模型有机会达到过去更昂贵配置的水平，但这些依然是 OpenAI 披露的基准结果，不是对你业务数据的保证。

Responses API 的四个工程杠杆

模型路由解决"由谁来思考"，Responses API 的新能力解决"哪些工作需要重新思考"。这一层经常比更换模型更容易被低估。

1. 持久化推理与 Compaction：不要每一轮都从头开始

长任务中的一个隐形浪费，是模型不断重建已经形成的判断。它读过仓库结构、确认过约束、排除过失败方案，下一轮却只拿到一段残缺摘要，于是又花 Token 做一次相同探索。

根据官方 Reasoning 文档，GPT‑5.6 支持通过 reasoning.context 控制可用推理项的延续范围，并默认使用 all_turns。配合 previous_response_id、Conversation，或者由应用完整重放之前的 response items，后续调用可以继续利用兼容的推理项。这里保存的是不透明的 reasoning items，并不会向应用公开模型的原始思维文本。

这项能力适合目标、假设和优先级在多轮中保持稳定的任务，例如持续修复同一个代码库、完成一份长篇研究，或者围绕同一客户请求连续调用多个工具。如果下一轮已经切换到完全无关的目标，继续保留此前推理反而可能带来干扰，此时应考虑 current_turn。

当任务继续增长，Compaction 则负责把长上下文压缩成后续调用可继续使用的形式。它的价值不是"突破无限上下文"，而是在进入昂贵的长上下文区间前减少重复历史、工具输出和中间过程。

实施时要同时监控三件事：压缩前后的 Token 量、任务质量是否下降、压缩是否丢失了仍然有效的约束。上下文压缩是一种有损管理策略，不应被当成无条件免费的优化。

示例：延续推理并调整模型配置

下面代码仅用于展示参数关系，没有在本文写作过程中发起真实 API 请求，也不构成可直接上线的完整实现。生产代码还需要错误处理、超时、重试、结构校验、权限控制与日志脱敏。

javascript 复制代码

import OpenAI from "openai";

const client = new OpenAI();

// 第一步：用平衡型模型和较低推理强度做文档抽取。
const extraction = await client.responses.create({
  model: "gpt-5.6-terra",
  reasoning: {
    effort: "low",
    context: "all_turns",
  },
  input: "从这些合同中抽取交易方、金额、日期和待确认条款。",
});

// 第二步：沿用同一响应链，在需要更强判断时提高推理强度。
const review = await client.responses.create({
  model: "gpt-5.6-terra",
  reasoning: {
    effort: "medium",
    context: "all_turns",
  },
  previous_response_id: extraction.id,
  input: "检查抽取结果中的冲突与高风险条款，只返回有证据的问题。",
});

console.log(review.output_text);

这里特意没有演示"模型自己判断置信度后自动升级"。在生产系统里，模型口头给出的置信度不应成为唯一依据。更稳妥的升级条件来自 Schema 验证、证据数量、规则冲突、工具错误和任务风险等级。

2. Programmatic Tool Calling：把确定性工作移回代码

Agent 调用工具时，常见流程是：拿到 100 条记录，把全部结果放进模型上下文，让模型逐条过滤，再把剩余记录交给另一个工具。这种做法把本来适合代码的工作变成了昂贵的语言推理。

Programmatic Tool Calling 允许 GPT‑5.6 编写 JavaScript，在托管运行时中组织符合条件的工具调用，并在模型上下文之外处理大量中间结果。适合放进去的工作包括过滤、连接、排序、去重、聚合和结构校验。OpenAI 的构建指南举例称，Rogo 在金融研究评测中保持 rubric 质量的同时，使用这一能力减少了 21% 输入 Token。

但 Programmatic Tool Calling 并不是"工具调用越多越应该用"。以下情况更适合保留直接调用：

每次工具结果都会改变模型下一步的语义判断；
操作涉及审批、付款、删除、权限或其他高影响写入；
最终结果必须保留原始引用或原生文件；
工具输出结构不稳定，代码无法可靠解析；
中间结果本来就很小，一次直接调用已经足够。

这条边界很关键。把确定性工作移入代码，是为了减少上下文消耗，不是为了绕过审批。无论调用来自模型还是托管程序，应用都应重新检查参数、权限和副作用。

3. Multi-agent：只为真正可并行的任务付费

GPT‑5.6 的原生 Multi-agent 能让根 Agent 创建并协调多个子 Agent，并行完成独立任务，最后再综合结果。官方文档将其标记为 beta，当前支持全部 GPT‑5.6 模型。

适合并行拆分的任务通常有清晰边界，例如同时探索大型代码库的多个模块、分别研究多个来源、比较多份方案，或者独立调查若干故障原因。这些工作如果由单 Agent 顺序执行，墙上时钟时间会直接累加。

不适合多 Agent 的任务也很明确：需要严格顺序推理、频繁写入同一份可变状态，或者整体速度被一个外部慢接口主导。子 Agent 会增加额外提示、上下文和综合成本，任务本身如果很小，并行化可能比串行更贵。

因此，多 Agent 的路由条件不应是"问题看起来很难"，而应是：

是否能拆成至少两个相互独立的工作流；
子任务之间是否很少共享可变状态；
降低墙上时间是否真的有业务价值；
额外 Token 能否换来可测量的质量或速度提升。

OpenAI 原始指南也提醒，多 Agent 行为可以被明确引导。创业团队应为生成子 Agent 设定任务类型、并发上限、停止条件与预算，而不是让系统无限扩张代理树。

4. Prompt Caching：优化稳定前缀，而不是缓存一切

生产 Agent 往往会重复发送大量稳定内容：系统规则、工具说明、输出格式、企业知识前缀和项目上下文。如果这些内容长期不变，重复按未缓存输入价格计费会形成明显浪费。

根据 Prompt Caching 文档，GPT‑5.6 缓存前缀当前默认 30 分钟，复用后会刷新生命周期；开发者还可以使用显式断点和合适的 prompt_cache_key 提高命中概率。OpenAI 原始指南引用 Ploy 的案例称，他们对一个 29,000 Token 的共享提示加入缓存断点和工作区键后，未缓存输入减少了 28%。

缓存同样不是免费的午餐。GPT‑5.6 的缓存写入按未缓存输入价格的 1.25 倍计费，读取才享受折扣。因此，频繁变化、很少复用的前缀不一定值得显式写入。一个简单判断方法是：

text 复制代码

缓存净收益 ≈ 复用次数 ×（未缓存读成本 - 缓存读成本）- 缓存写入溢价

要让缓存真正生效，稳定内容应尽量放在提示前部，动态用户输入和易变数据放在后部；不同租户或工作区的缓存键需要隔离，避免跨边界混用。缓存命中率应作为生产指标记录，而不是只看配置是否已经打开。

一套创业团队可以执行的成本优化框架

讲完模型和 API 能力，真正的问题是：一个只有几名工程师的团队，怎么把这些建议安全地放进现有产品？

答案不是一次性重构，而是建立一条可重复的评测与路由闭环。

第一步：建立代表性评测集

不要只选"能演示成功"的样本。评测集至少应覆盖：

高频普通任务；
边界输入、缺失信息和相互冲突的来源；
工具超时、空结果、返回格式变化；
长上下文与多轮任务；
涉及外部写入、权限或高风险结论的请求；
当前线上最常见的失败案例。

样本数量不必一开始就很大，但必须能代表真实流量。每次发生新的重要失败，就把它加入回归集。

第二步：用高能力配置建立质量基线

先选择一个能够稳定完成任务的配置，例如 Sol + medium，记录它的任务成功率、成本、延迟、输入输出 Token 和失败类型。这个阶段的目标不是证明 Sol 最好，而是得到一个可比较的质量上限。

随后只改变一个变量：先在同一模型上降低推理强度，再尝试 Terra，最后尝试 Luna。一次同时改变模型、提示、工具和缓存，会让团队无法知道收益来自哪里。

第三步：定义可执行的质量底线

"看起来差不多"不能成为上线标准。不同任务应有不同验收规则：

抽取任务：字段准确率、Schema 通过率、漏项率；
检索任务：Recall@K、证据覆盖率、无来源断言比例；
浏览器任务：最终页面状态、误操作率、恢复率；
分析任务：Rubric 得分、引用完整度、专家通过率；
Agent 总流程：端到端成功率、平均重试次数、人工接管率。

尤其要注意结构化输出。提示模型"返回 JSON"并不能保证语法或 Schema 永远正确；应用仍需解析、验证并处理失败。外部网页、文档、邮件和工具输出也应视为不可信数据，不能因为模型更强就忽略提示注入和权限边界。

第四步：设计升级与降级路径

一种实用的三层路由是：

text 复制代码

Luna 处理默认高频任务
  ├─ 结构校验通过、证据充分 → 返回结果
  ├─ 数据冲突、工具异常、低确定性 → 升级 Terra
  └─ 高风险、复杂规划、仍不通过 → 升级 Sol 或人工审批

升级条件应尽量由应用能够验证的信号驱动。对于付款、删除、发布、权限变更等外部动作，无论使用哪个模型，都应在应用层保留明确授权和审计记录。更强模型不能替代业务审批。

降级也需要设计。如果 Sol 遇到限流、超时或成本预算耗尽，系统是返回稍慢结果、转交人工，还是退回 Terra？不能等事故发生时再临时决定。

第五步：统一记录成本与质量

建议每次 Agent 运行至少记录以下指标：

指标	作用
端到端成功率	判断优化是否真正可用
每个成功任务成本	合并模型、工具、重试与人工成本
P50 / P95 延迟	避免平均值掩盖长尾问题
输入、缓存输入、缓存写入、输出 Token	找出主要费用来源
缓存命中率	验证提示前缀设计是否有效
工具调用数与失败率	判断是否存在无效循环
模型升级率	衡量默认路由是否过于激进
人工接管率	识别自动化边界

不要只记录模型最终返回的文本。需要把使用的模型、推理强度、提示版本、工具版本、路由原因和评测结果关联起来，否则几周后很难解释为什么成本或质量发生变化。

两周落地路线：从离线评测到小比例上线

第一周：建立基线与路由

第 1 天：从真实日志抽取代表性样本，去除凭证、个人信息和机密数据。
第 2 天：定义每类任务的成功标准、质量底线和高风险边界。
第 3 天：使用当前高能力配置跑出基线，记录成本与延迟。
第 4 天：逐一比较推理强度；每轮只改一个参数。
第 5 天：加入 Terra、Luna，形成模型---推理强度矩阵。
第 6 天：为失败、冲突和高风险任务定义升级条件。
第 7 天：复查提示注入、权限、日志脱敏、结构校验和人工审批。

第一周结束时，团队应得到的不是"我们觉得 Luna 可以"，而是一张包含成功率、单次成功任务成本、P95 延迟和失败类型的对照表。

第二周：影子流量与渐进发布

第 8---9 天：让新路由处理影子流量，但不影响用户结果。
第 10 天：对比线上配置与新路由，核查质量差异和升级率。
第 11 天：先开放低风险、可回退的 1%---5% 流量。
第 12 天：检查缓存命中、重试、工具错误和长尾延迟。
第 13 天：扩到更高比例，保留自动回滚阈值。
第 14 天：复盘每个成功任务成本，决定是否继续扩大。

建议提前定义停止条件。例如成功率下降超过 2 个百分点、P95 延迟上升超过 20%、高风险误判超过零容忍线，或者人工接管率显著升高，就自动回到上一配置。具体阈值必须按业务风险调整，上述数字只是制定机制的示例，并非通用标准。

OpenAI 这份指南透露了哪些能力边界

回到文章开头的问题：为什么这份官方指南重要？

它的重要性不只在于 OpenAI 告诉市场"应该使用哪些新能力"，还在于它间接说明了 GPT‑5.6 的工程边界。

推论一：小模型能承担更多 Agent 环节，但不等于所有任务都应降级

从 OpenAI 公布的案例看，Luna 和 Terra 已经可以进入文档理解、浏览器操作、检索和部分决策任务的候选集。过去只能交给旗舰模型的工作，正在被拆分到不同成本层级。

但官方文档反复强调代表性评测和质量验证。这说明能力提升并没有消除路由的必要性，反而让路由空间更大。团队需要回答的不是"哪个模型最好"，而是"在我的数据上，哪个配置是满足质量底线的最低成本选项"。

推论二：Responses API 正从生成接口变成 Agent 基础设施

持久化推理管理多轮连续性，Compaction 管理长上下文，Programmatic Tool Calling 管理确定性计算，Multi-agent 管理并行工作，Prompt Caching 管理重复前缀的成本。把这些能力放在一起看，Responses API 承担的已经不只是文本生成，还包括 Agent 的执行、状态和资源调度。

这是本文基于官方功能组合做出的判断，并非 OpenAI 对产品路线的正式承诺。API 仍可能调整，Multi-agent 也仍处于 beta；任何生产集成都应固定可控配置、跟踪变更并准备回退路径。

推论三：真正的竞争点是评测与路由能力

当同一家模型供应商提供多个能力层级、多个推理档位和多种执行方式时，"接入最新模型"很快会变成基础工作。更难复制的能力，是团队积累的真实评测集、质量 Rubric、失败样本、路由策略和成本可观测性。

模型会继续更新，价格也会变化。如果系统写死在一个模型 ID 上，每次升级都要重新冒险；如果系统已经围绕任务类型、质量底线和升级条件设计，新的模型只是在同一套评测框架中增加一个候选配置。

写在最后

OpenAI 的 GPT‑5.6 构建指南给创业团队最实用的提醒，不是"尽快使用最新模型"，而是停止把 Agent 当作一次大模型调用。

一个成熟的 Agent 更像一条生产线：便宜模型处理高频且可验证的步骤，平衡型模型负责主要判断，旗舰模型处理少量高难与高风险任务；代码承担确定性数据处理，Responses API 维护推理连续性与上下文，缓存减少重复输入，多 Agent 只在真正可并行时出现。

这套架构不会自动带来官方案例中的成本降幅，却能让团队知道每一美元花在了哪里，也能知道降低成本时牺牲了什么。

如果只准备做一件事，可以从最简单的一步开始：从线上抽取一批代表性任务，用当前配置建立基线，然后比较同一模型低一档的 reasoning.effort。不要先争论哪个模型更强，让自己的评测结果决定下一步路由。

参考资料

本文中的价格、API 行为和产品状态核对于 2026 年 8 月 18 日。涉及模型和平台的时效性信息，请以 OpenAI 官方文档为准。

OpenAI GPT-5.6 构建指南拆解：创业公司如何用模型选择与 Responses API 降低 Agent 成本

文章目录

先看结论：Agent 降本已经变成一个路由问题

第一层优化：Sol、Terra、Luna 应该如何分工

三个模型不是"好、中、差"

当前标准短上下文价格

一张可直接使用的模型路由表

官方案例说明了什么，又没有说明什么

第二层优化：reasoning.effort 是独立的成本旋钮

为什么不能只看 Token 单价

Responses API 的四个工程杠杆

1. 持久化推理与 Compaction：不要每一轮都从头开始

示例：延续推理并调整模型配置

2. Programmatic Tool Calling：把确定性工作移回代码

3. Multi-agent：只为真正可并行的任务付费

4. Prompt Caching：优化稳定前缀，而不是缓存一切

一套创业团队可以执行的成本优化框架

第一步：建立代表性评测集

第二步：用高能力配置建立质量基线

第三步：定义可执行的质量底线

第四步：设计升级与降级路径

第五步：统一记录成本与质量

两周落地路线：从离线评测到小比例上线

第一周：建立基线与路由

第二周：影子流量与渐进发布

OpenAI 这份指南透露了哪些能力边界

推论一：小模型能承担更多 Agent 环节，但不等于所有任务都应降级

推论二：Responses API 正从生成接口变成 Agent 基础设施

推论三：真正的竞争点是评测与路由能力

写在最后

参考资料

第二层优化：`reasoning.effort` 是独立的成本旋钮