截至 2026 年 8 月 14 日，OpenAI GPT-5.6 模型指南将 gpt-5.6 别名指向 Sol，把 Terra 定位为智能与成本的平衡档，把 Luna 定位为高吞吐、成本敏感档。降低 Agent 成本的起点不是统一切换模型，而是按任务步骤测试显式模型 ID，并把每次成功任务的质量、延迟和账单放在同一张评测表里。
如果已有可重复的任务集，先保持运行框架（harness）不变，测试当前 reasoning.effort 和低一档，再加入 Terra、Luna 与 Sol。只有候选配置未达到评分规则（rubric）或错误代价较高时才升级模型；没有固定任务集时，不估算节省比例，也不启用新的编排能力。
本文只处理 OpenAI API 的模型路由和计费。Claude Code、Codex 等本地长会话的上下文整理方法，另见长会话词元浪费排查指南。
按任务步骤路由 Sol、Terra 与 Luna
OpenAI 当前建议用 Sol 处理复杂专业任务，用 Terra 平衡能力与价格，用 Luna 承担成本敏感的高频工作。生产路由仍由实际任务集决定，模型定位不能替代评测。
| 步骤类型 | 第一批候选 | 升级条件 |
|---|---|---|
| 分类、抽取、格式转换、代码检索 | Terra 或 Luna，从较低推理强度开始 | 字段准确率、召回率或格式合规不达标 |
| 高频工具选择和短决策 | Luna 与 Sol 同时评测 | 错工具率或端到端成功率明显下降 |
| 长上下文分析、复杂编排、最终综合 | Sol 作为基线，同时测试 Terra | 较小模型在固定评分规则上无法通过 |
| 高错误代价的最终动作 | 通过评测的最小模型，并保留审批 | 人工复核或业务控制不能覆盖残余风险 |
不要只给整条 Agent 工作流配置一个模型。记录每个步骤的输入、允许工具、输出契约和错误代价，再为步骤单独路由。抽取和最终判断可以使用不同模型，账单也能按步骤归因。
完成定义使用四个门槛：
| 完成指标 | 必须达到 |
|---|---|
| 任务结果 | 成功率不低于当前基线 |
| 关键行为 | 字段和工具选择通过评分规则 |
| 延迟 | p95 在预算内 |
| 账单 | 每个成功任务的普通输入、缓存读写、输出词元和工具费用可核对 |
先核算三档价格与长上下文成本
下表是 2026 年 8 月 14 日核验的标准文本价格，单位为每百万词元。价格会变化，迁移前应重新打开对应模型页确认。
| 模型 | 输入 | 缓存输入 | 输出 |
|---|---|---|---|
| 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 |
GPT-5.6 缓存读取按未缓存输入价的 0.1 倍计费，写入按 1.25 倍计费；普通输入指既没有从缓存读取、也没有写入缓存的词元。输入超过 272K 词元时，整次请求的输入价格乘 2、输出价格乘 1.5；模型工具若按次收费，还要单独加入工具费用。
每个成功任务成本 =
（普通输入词元 × 输入价
+ 缓存读取词元 × 缓存输入价
+ 缓存写入词元 × 输入价 × 1.25
+ 输出词元 × 输出价
+ 工具费用）÷ 成功任务数
对异步评测、数据补全或低优先级任务，还可以比较 Batch API 与 Flex processing。Flex 用更慢响应和偶发资源不可用换取更低成本，不应直接用于有严格实时要求的生产路径。
用同一批任务测试相邻推理强度
OpenAI 的 GPT-5.6 模型指南列出六档 reasoning.effort，默认值是 medium。迁移时保留当前档位作为基线，再测试低一档；只有固定任务集证明质量提升时，才使用更高档位。
| 档位 | reasoning.effort 取值 |
|---|---|
| 较低到默认 | none、low、medium（默认） |
| 较高 | high、xhigh、max |
设置 OPENAI_API_KEY 后，先运行以下 Responses API 请求，建立 Terra + low 基线：
curl https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.6-terra",
"reasoning": {"effort": "low"},
"input": "从工单中提取优先级、产品和下一步动作，并返回 JSON。"
}'
把模型和推理强度放进同一张评测矩阵：
| 候选 | 当前推理强度 | 较低推理强度 | 更高推理强度 |
|---|---|---|---|
| 当前生产模型 | 保留基线 | 如支持则测试 | 只用于定位质量上限 |
| Terra | 测试 | 测试 | 仅在质量差距可缩小时测试 |
| Luna | 测试 | 测试 | 仅在质量差距可缩小时测试 |
| Sol | 测试 | 优先测试 | 仅用于确有收益的难例 |
| 指标组 | 必须记录 |
|---|---|
| 质量 | 端到端成功率与评分 |
| 用量 | 工具调用次数、输入与输出词元 |
| 延迟 | p50 与 p95 |
| 成本 | 单次成功任务成本 |
若提高推理强度只增加词元和延迟，却没有改善失败样例，就不要把它设为默认值。
标准模式作为基线。只有困难、高价值任务仍有明确质量缺口时，才保留当前模型 ID 和推理强度，测试 reasoning.mode: "pro"。Pro mode 会增加延迟，额外模型工作产生的词元按所选模型的标准费率计费；质量收益无法覆盖总词元、延迟和成本增量时，继续使用标准模式。
如果较低推理强度的错误集中在权限判断、金额核对或不可逆动作，即使总成功率接近，也要单独升级这些步骤或增加人工审批。
长任务复用既有推理并压缩上下文
持久化推理（persisted reasoning）会让后续 Responses API 请求使用兼容的既有推理项，但不会暴露原始推理文本。GPT-5.6 的 reasoning.context 默认是 all_turns；它只有在请求通过 previous_response_id、conversation 或完整历史拿到先前响应项时才生效，首轮请求与 current_turn 没有差异。
长任务可以把持久化推理与服务端压缩（compaction）放在同一个请求中。示例里的 resp_previous 必须替换为上一轮真实响应 ID；compact_threshold 只是演示值，生产阈值应根据上下文增长速度和回归测试确定：
{
"model": "gpt-5.6-terra",
"previous_response_id": "resp_previous",
"reasoning": {"context": "all_turns"},
"context_management": [
{"type": "compaction", "compact_threshold": 200000}
],
"input": "继续处理剩余文件，并保持此前的禁止事项。"
}
| 检查对象 | 停止或回退条件 |
|---|---|
| 目标、禁止事项和输出契约 | compaction 后约束丢失率上升 |
| 工具结果中的 ID、金额和时间 | 关键事实不能追溯或恢复 |
| 既有推理和任务状态 | 错误假设被延续，或节省不足以覆盖调试成本 |
当早期推理已经不相关时，把 reasoning.context 改为 current_turn。权限、金额和不可逆状态应保存在结构化数据中，不能只依赖不透明的推理项或压缩结果。
用 Programmatic Tool Calling 处理确定性数据
Programmatic Tool Calling 适合“取回很多结构化数据，再做过滤、聚合和排序”的步骤。OpenAI 会在全新隔离 V8 中运行模型生成的 JavaScript。环境支持顶层 await，但不提供 Node.js API，也不能安装包。它不能访问网络、通用文件系统或跨程序状态；子进程和控制台同样不可用。
请求的 tools 片段必须加入 programmatic_tool_calling，并用 allowed_callers 明确哪些工具可以由程序调用。结构稳定的返回值还应提供 output_schema：
{
"tools": [
{
"type": "function",
"name": "get_records",
"description": "按状态返回记录数量。",
"parameters": {
"type": "object",
"properties": {"status": {"type": "string"}},
"required": ["status"],
"additionalProperties": false
},
"output_schema": {
"type": "object",
"properties": {"record_count": {"type": "number"}},
"required": ["record_count"],
"additionalProperties": false
},
"allowed_callers": ["programmatic"]
},
{"type": "programmatic_tool_calling"}
]
}
假设 Agent 检索了 100 份文件，可以按四步处理：
- 工具返回结构化记录和来源 ID。
- 代码按日期、类型、状态或数值执行确定性筛选。
- 聚合层只把命中的记录、统计值和来源映射交给模型。
- 模型负责解释差异、处理歧义和生成结论。
把确定性数据处理移到程序，例如去重、精确求和、排序和分页。涉及含义判断、证据冲突或规则例外的步骤仍由模型处理，并保留来源以便复核。
隔离 V8 不会自动约束工具的外部副作用。应用仍需处理 program、程序发出的工具调用和 program_output，并用 call_id 与 caller 串起事件。工具执行层仍需校验身份与参数，并保留高影响动作审批。
仅对独立工作流启用 Multi-agent beta
截至 2026 年 8 月 14 日，Responses API Multi-agent 仍是 beta。原始 HTTP 请求要发送 OpenAI-Beta: responses_multi_agent=v1，并在请求体启用 multi_agent：
curl https://api.openai.com/v1/responses \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-H "OpenAI-Beta: responses_multi_agent=v1" \
-d '{
"model": "gpt-5.6-terra",
"input": "并行检查三个独立模块，最后合并冲突和缺失项。",
"multi_agent": {
"enabled": true,
"max_concurrent_subagents": 3
}
}'
max_concurrent_subagents 默认值和建议值都是 3，只限制整棵树中的并发子 Agent 回合。API 不限制子 Agent 总创建数或树深度，应用必须自行限制总词元、工具调用和最长运行时间。Multi-agent 也不支持 max_tool_calls，不能把它当作总预算开关。
| 启用门槛 | 必须满足的条件 |
|---|---|
| 并行性 | 子任务彼此独立，实际耗时收益超过启动与综合开销 |
| 依赖与写入 | 不会同时修改同一对象或依赖前一步输出 |
| 权限 | 工具执行层能按身份、参数和动作重新校验 |
| 综合 | 主 Agent 检查来源、冲突与缺失项，不直接拼接结果 |
一个 Multi-agent 请求只配置一个模型，所有 Agent 都能看到请求配置的全部工具，当前没有逐 Agent 工具隔离。评测时同时记录实际耗时、总词元和总工具调用；质量没有改善或合并冲突抵消并行收益时，回退到单 Agent。
显式缓存稳定前缀并核算读写
GPT-5.6 的提示词缓存要求断点前的完整渲染前缀至少有 1,024 词元。prompt_cache_options.ttl 当前只支持 30m，也是默认值；每次复用会刷新 30 分钟期限，但不会产生新的缓存写入费用。prompt_cache_key 与完全相同的前缀共同参与匹配，单个键的总流量应控制在约每分钟 15 个请求。
把断点放在稳定的 developer 角色消息末尾，并使用 explicit 模式阻止变化的用户输入触发隐式写入：
{
"model": "gpt-5.6-terra",
"prompt_cache_key": "support:knowledge-base-v1",
"prompt_cache_options": {
"mode": "explicit",
"ttl": "30m"
},
"input": [
{
"type": "message",
"role": "developer",
"content": [
{
"type": "input_text",
"text": "稳定规则、工具说明与知识库内容……",
"prompt_cache_breakpoint": {"mode": "explicit"}
}
]
},
{
"type": "message",
"role": "user",
"content": "本轮用户问题"
}
]
}
示例里的省略内容必须替换成真实稳定前缀，并确保渲染后达到 1,024 词元；按示例中的短文本直接请求不会产生缓存。
| 位置 | 放置内容 |
|---|---|
| 断点前 | 稳定规则、工具定义、结构化输出模式、共享知识 |
| 断点后 | 时间戳、请求 ID、用户输入、本轮检索结果 |
prompt_cache_key 使用稳定、可分区且不暴露个人信息的标识；高流量工作负载按确定映射拆成多个键。
Responses API 在 usage.input_tokens_details 返回 cached_tokens 和 cache_write_tokens。若写入词元持续偏高而读取很少，说明断点包含变化内容或缓存没有复用，此时应移动断点、改用仅显式缓存模式，或关闭这条缓存路径。
按固定任务集完成灰度迁移
从生产失败样例、常见任务和高成本任务中建立固定集合，并为每个样例写明成功条件、允许工具、禁止动作和可接受输出。不能只用当前生产模型的输出当标准答案。
| 阶段 | 动作 | 进入下一阶段的条件 |
|---|---|---|
| 基线 | 记录当前模型、推理强度、质量、p95 延迟和成本 | 样例与评分规则可以重复运行 |
| 候选 | 保持运行框架不变，测试相邻推理强度与三档模型 | 任务级质量不低于门槛 |
| 能力 | 分别测试推理复用与压缩、PTC、Multi-agent 和缓存 | 单项收益可归因，失败可回放 |
| 灰度 | 只发布通过门槛的步骤路由，并保留回退开关 | 线上成功率和每成功任务成本稳定 |
灰度日志分成四组记录：
| 日志组 | 字段 |
|---|---|
| 模型配置 | 模型、reasoning.effort、reasoning.mode |
| 上下文与缓存 | reasoning.context、compaction、缓存读写词元 |
| Agent 与工具 | 子 Agent 数、工具调用 |
| 版本与回退 | 价格核验日期、回退原因 |
若只记录最终模型名称，成本或质量变化发生时就无法定位原因。
扩大灰度前核对四道门槛
| 门禁 | 必须通过 |
|---|---|
| 模型与评测 | 固定任务集、成功条件、当前基线和逐步骤路由齐全 |
| 状态与上下文 | 不可丢失的权限、金额和状态保存在结构化数据中；压缩可以回放 |
| 工具与 Agent | PTC 工具调用校验参数和审批；Multi-agent 只处理独立任务并受总预算约束 |
| 缓存与账单 | 缓存读写、普通输入与输出、长上下文倍数、工具费均进入成本计算 |
流量扩大的前提是任务成功率、p95 延迟和每个成功任务成本都有通过记录；任一指标未过线，就用回滚开关恢复原模型和运行框架。