OpenAI Decisions API 还是 Responses API？2026 怎么选

工单路由还要让模型写一段解释，结果 JSON 虽然能解析，业务却不知道该把请求交给谁？

判断：如果任务只需固定选项、条件判断或标准评分，先评估 Decisions API；如果还要生成自定义结构、解释或请求工具调用，继续用 Responses API。两者可以在同一 Agent 流程中分工，不要只凭“最高可快十倍”的官方表述就全面迁移。

适合：正在为分类、分流、优先级判断选择接口的开发者与平台工程师；负责 Agent 路由、接口评测和迁移方案的技术负责人。
不适合：需要的是完整 Agent 编排、工具执行或自由生成，而不是单独的类型化判断。

最后更新于 2026 年 10 月 8 日；状态、端点、模型与计费信息核对自 OpenAI Decisions 指南、创建决策的 API 参考及官方 API 更新日志。

先按输出契约划清接口职责

判断一个调用该走哪条 API，先看下游程序究竟要接收什么，不要先看它是否返回 JSON。固定答案与任意结构化内容都可能被序列化成 JSON，但它们对模型提出的任务并不相同。

截至上述核实日期，官方文档将 Decisions API 标为公开测试版，当前只列出 GPT-6 Luna，使用专用的 POST /v1/decisions 端点。它为每个问题返回命名答案，类型包括 predicate、choice 和 score；predicate 给出条件成立的估计概率，choice 从预设选项中选一项，score 按有序等级评估输入。字段与类型可查阅官方创建决策参考。

Responses API 的职责更宽：当结果要符合团队自定义 JSON Schema、包含提取字段或自然语言解释时，可评估 Structured Outputs；需要模型请求调用业务函数时，则使用 function calling。官方对两种结构化输出路径的区分，见Structured Outputs 指南；工具请求、执行与回传的环节，见function calling 指南。

*评分是我们依据官方接口用途所做的职责适配度判断，不是性能基准或质量实测。接口能力说明见上文所引的 Decisions、结构化输出和工具调用官方文档。

一个常见误区是：“只要我要 JSON，就选某个专用决策接口。”如果业务要求模型从 billing、technical 等固定部门中选择，属于选项判断；如果还要产出用户可读的说明、抽取不固定字段或按请求内容生成新的参数对象，则属于结构化生成。决定接口的关键是输出的语义范围，不是外层格式。

再看 Agent 是否需要采取动作

Decisions API 返回判断答案，本身不等于调用业务工具、改数据库或完成 Agent 任务。我们建议把 Agent 流程拆成两个明确阶段：先判断“这是什么、优先级如何、是否满足条件”，再由 Responses API 请求所需工具，或由应用按既定规则执行下一步。

这种拆分通常更容易审计：判断阶段可以单独记录输入、问题名称与答案；动作阶段则单独验证参数、权限和副作用。反过来，如果所谓“判断”必须先查实时订单、读取账户状态或请求工具结果，别把需要执行的工作塞进分类接口的期待里；应明确数据从哪里来、工具由谁调用、错误如何回滚。

提醒：模型返回概率、置信度或评分，是接口提供的判断值，不自动构成经过业务校准的概率，也不保证路由阈值安全。尤其是退款、封禁、支付或高优先级告警，应把误报和漏报分别计入风险，并保留人工复核路径。

还有一个重要的输入边界：如果多个问题针对同一份证据、彼此独立，官方指南说明可放进同一个 questions 数组，并为每项提供唯一 name；如果第二个判断依赖第一个答案，则应分开请求。比如“判断投诉类别”和“判断是否包含威胁内容”可能共享工单文本；但若“确定部门后，再按该部门的专属标准打分”，后一步依赖前一步结果，就不应假设它们能在一个请求里完成。接口文档说明的是问题与输入的用法，不是并发执行或延迟保证。

质量要看错分代价，而不是单看置信值

分类路由的平均准确率容易掩盖高代价错误。把普通咨询误送到技术支持，和把疑似欺诈放行到自动退款，风险并不对称；团队应分别计算误报、漏报、拒答和人工复核比例，并按各类错误的业务后果设阈值。

我们会用带标签的代表性样本，不只挑“容易分”的例子：纳入少数类别、模糊边界、缺少信息、相互矛盾和高风险输入。对两种接口使用相同的输入与业务标签，按类别统计误报、漏报和拒答；再将候选阈值应用到历史样本，估算进入自动路由、人工复核与拒绝处理的比例。OpenAI 的评测最佳实践也强调，应使用结构化评测检验生产环境中的表现，而不是用单次演示代替验证。

长尾边界也在这里：OpenAI Decisions API 更适合答案集合有限的分类、分流和优先级判断；要继续用 Responses API 生成 JSON 的情形，则是字段由自定义 schema 定义、内容需要动态生成或还需解释。至于 Decisions API 能否替代 Agent 工具调用，答案是否定的：它负责类型化判断，不负责业务工具的执行。实际评测应基于现有带标签任务，使用同一批样本比较质量与后续处理负担，而不是凭 API 名称推断优劣。

总成本要把后续调用和复核一并计入

官方 Decisions 指南称，该接口采用输入 token 计费，并指出当前 GPT-6 Luna 的 Decisions 请求输入价格为 每百万 token 0.10 美元；该说明适用于 /v1/decisions，区域处理附加费用和长上下文倍率等条件也需纳入。对同一模型经其他端点发起的请求，不能直接套用 Decisions 的专属计费说明。可对照官方模型价格表，上线前应以当时页面和实际账单复核。

因此，不能看到“无输出 token 费用”就断言整体一定更便宜：如果判断后还要再请求 Responses API 生成解释、参数或工具调用，真实工作负载是两段甚至多段链路；重复输入、复核和重试都要计入。反过来，如果原有 Responses 调用只为得到一个固定类别，却输出了大量下游不用的文本，那么值得把这类任务单独拿出来实测成本与质量。

官方 Decisions 指南还把接口描述为“比 Responses API 快约 10 倍”。这是发布方对该接口的表述，不是对任意输入长度、问题数量、网络条件或完整 Agent 端到端时延的保证。我们会分别记录 API 响应时间与任务完成时间；如果最终流程还要等待工具执行或人工确认，只比较模型接口阶段会得出偏差结论。

公开测试与数据边界决定迁移节奏

公开测试版意味着接口仍处于测试状态。对生产系统而言，团队需确认当前模型和端点是否覆盖目标任务，并审查数据处理、地域处理及自身资格要求；官方资料列出的数据区域与资格条件可能带有适用限制，不能仅凭页面出现某个区域名称就推定本项目满足要求。请在试点前核对数据控制说明中的区域支持、数据保留和资格边界。

建议的迁移评分（不是厂商评级）：输出契约固定度高、输入证据稳定、判断可回退、误判可由人工兜底时，Decisions API 试点优先级为高；如果任务依赖生成解释、任意 JSON 字段或工具执行，Responses API 保持主路径的优先级为高；如果团队无法接受测试版状态、模型范围限制或现行数据条件，则暂缓迁移的优先级为高。

按下面的清单落地，能避免把一次接口试用误当成全面迁移决策：

• [ ] 列出任务契约：逐个标注输出是 predicate、固定 choice、有序 score、自定义 JSON，还是工具调用；不符合前三种固定判断契约的任务先留在 Responses API。
• [ ] 整理标签样本：从现有任务中覆盖常见类别、边界案例与高代价错误，固定样本版本和人工标签，确保两种方案使用相同输入。
• [ ] 定义风险阈值：分别确定误报、漏报、拒答时的后果；写明自动路由、人工复核和拒绝处理的条件，不把模型置信值直接当业务承诺。
• [ ] 拆解调用链：标出哪些问题共享证据、哪些依赖先前答案；将函数执行、权限检查和外部副作用明确留给应用或工具链路。
• [ ] 核算端到端账单：按真实输入规模、问题数、重复调用、Responses 后续请求、人工复核与重试成本合计，不用官方单项价格替代全流程成本。
• [ ] 确认上线边界：发布前复核测试状态、模型与端点范围、计费说明、数据处理和团队资格；不满足要求就维持现有流程。
• [ ] 小流量双轨验证：先影子运行或小范围试点，记录质量、时延、复核和账单；只有达到预先设定的门槛，才扩大流量或调整接口职责。

常见选型问题

哪些固定答案任务适合用 Decisions API？

当输入证据明确、答案空间有限，而且结果可以表达为条件概率、固定选项或有序评分时，可以评估 Decisions API，例如工单分派、内容分类、优先级判断。先用带标签的业务样本检查误报和漏报，再依据两类错误的实际代价设定自动路由与人工复核门槛；不要把返回概率直接当成已校准的业务概率。

自定义 JSON 场景何时应保留 Responses API？

当结果需要遵循团队自定义的 JSON Schema、提取多个业务字段、附带解释文本，或根据上下文生成并非预设选项的内容时，继续用 Responses API 的 Structured Outputs。JSON 格式正确不等于业务字段符合预期，仍需按 schema 校验、处理拒答与异常，并用真实样本回归；不要仅因输出是 JSON 就把生成任务改造成固定选项判断。

类型化判断能代替 Agent 执行工具吗？

不能把类型化判断等同于工具执行。Decisions API 返回 predicate、choice 或 score 等答案；如果 Agent 还要生成调用参数、请求模型选择工具、执行函数并读取结果，应继续使用 Responses API 的 function calling，或把分类、授权检查和后续工具执行拆成明确阶段，并在业务服务端验证权限与参数。

怎样基于现有样本验证接口效果？

抽取覆盖常见类别、边界案例和高代价误判的带标签样本，让两种接口处理相同输入与版本化指令；分别记录分类错误、误报漏报、拒答、延迟、人工复核率及完整后续调用账单。按错误代价设置复核门槛，先影子运行再小流量试点；只有质量与总成本都达到预设标准，才扩大流量。

先试点接口分工，再决定是否迁移

如果现有流程用 Responses API 同时完成分类、解释和工具调用，全面迁移会带来重复请求、两套监控和回滚复杂度；如果只为一个固定标签生成大段文本，也可能多付输出与复核成本。先拿同一组代表性任务验证固定判断与生成执行的边界：判断部分可试点 Decisions API，解释和工具执行仍交给 Responses API；只有端到端质量、总账单和运行边界都过关，再扩大使用范围。

这项接口评测不要求 Mac 环境。若项目另有 iOS 或 macOS 客户端构建、签名或交付验收需求，团队可按需评估 zekmac 的 Mac 租赁作为临时构建环境；长期稳定重负载或必须连接实体硬件的项目，则应先比较自购设备与其他执行方案。