OpenAI 正在把「让模型做判断」这类需求从通用生成接口里进一步拆出来。最新进入公测阶段的 Decisions API 面向文本、图像或二者混合的输入，直接返回带类型的判断结果，例如某个条件成立的概率、一个固定选项中的选择，以及针对有序等级的评分。官方给出的定位很明确：它不追求生成完整文本，而是把分类、路由和优先级处理这类决策型任务封装成更轻量的 API。
OpenAI 表示，Decisions API 的返回速度约为 Responses API 的 10 倍。目前该功能处于 public beta 阶段，官方称预计将在未来几周内 GA。当前唯一可用模型是 gpt-6-luna，开发者需要通过专用端点 POST /v1/decisions 调用。OpenAI 也提供了 Playground，开发者可以先在网页环境中试验问题和输入，再进入代码接入。
它不是通用问答接口，而是「带类型输出的判断层」
从接口设计看，Decisions API 的请求由三个部分组成：输入内容、问题集合，以及每个问题的唯一名称。输入可以包含文本和图像；每个问题需要给定一个 name，API 会在响应的 answers 数组中回传这个名称，方便开发者识别对应结果。
真正决定这个 API 能力边界的，是它支持的三种问题类型：
- predicate：判断某个条件是否成立，例如图片中是否存在可见损伤、文本内容是否与某个主题相关，主要返回一个 0 到 1 之间的 probability。
- choice：从开发者给定的一组选项中选出一个，例如客服工单应归属哪个部门、内容属于哪个分类。返回结果是用户提供的候选值之一，同时也会返回离散选项上的概率。
- score：针对有序等级进行评分，例如问题严重程度。返回的 score 是基于各等级概率进行加权平均后的数值，因此可能落在两个离散等级之间。
OpenAI 对 choice 和 score 的区分也给出了使用建议：如果类别之间没有顺序，例如部门、内容分类，应使用 choice；如果等级具有顺序，例如严重性、优先级，则应使用 score。后者通过概率加权平均，把原本离散的结果转化为更适合排序、阈值处理的连续值。
与 Responses API、Structured Outputs 和 Function Calling 的边界
Decisions API 的出现，也让 OpenAI 的开发者工具链出现了一次更细的职责划分。过去，许多分类、过滤、路由任务可以通过通用对话接口、结构化输出或函数调用来完成，但这些方式往往仍要建立在一个更通用的生成流程之上。
按照官方说明，如果应用需要的是 predicate、choice、score 这类固定形态的判断结果，Decisions API 是更直接的选择；如果任务要求模型生成符合开发者自定义 JSON schema 的对象，例如抽取字段、生成解释性内容，则更适合继续使用 Responses API 配合 Structured Outputs；如果目标不是直接给答案，而是让模型发起一次带参数的工具调用，则应使用 function calling。
这意味着 Decisions API 的目标并不是替代 Agent 工作流，而是把 Agent 和自动化系统中高频出现的「先判断一下」环节单独抽出来。比如判断一张产品图是否需要人工复审、一条用户消息应被路由到哪个处理队列、某个输入是否值得进入更昂贵的后续流程，这些任务通常不需要长篇输出，但对延迟、成本和输出格式稳定性更敏感。
官方示例：用图像检测商品是否存在可见损伤
在官方示例中，OpenAI 展示了一个典型的 predicate 用例：检查一张产品照片是否存在可见损伤。开发者输入一段文本指令和图片，同时提出一个名为 visible_damage 的 predicate 问题，并在 instructions 中说明要识别裂缝、撕裂、凹陷等损伤，同时忽略阴影和包装损伤。
API 返回的 answers 数组中会包含对应名称的判断结果。如果模型拒绝回答，返回类型会是 refusal；如果正常返回，则会给出该条件成立的概率。对开发者来说，这种输出可以直接接到业务规则里：概率高于某个阈值就触发人工审核、退款流程、客服介入，或进入下一步图像质检流程。
OpenAI 同步给出了 curl、Python、JavaScript、Go 等调用示例，并说明了 SDK 版本要求：Python 3.26.0、JavaScript 7.30.0、Go 3.73.0、Ruby 0.101.0、Java 4.78.0 及以上版本。对于已经接入 OpenAI SDK 的团队来说，这些版本门槛也意味着可以较快完成迁移测试。
对开发者意味着什么
从产品形态看，Decisions API 是 OpenAI 对「判别式任务」的进一步标准化。大模型应用中，越来越多的工程需求并不是让模型写一段话，而是让系统在复杂输入上快速得到可程序化处理的结果。过去这类需求通常要通过提示词约束、结构化输出或后处理来完成；现在，OpenAI 试图把它变成一种更直接的接口能力。
它的价值主要体现在三个层面：
- 更快的响应速度：官方称速度约为 Responses API 的 10 倍，适合高并发路由、过滤和排序场景。
- 更稳定的输出结构：probability、choice、score 都是可被代码直接消费的类型化结果，减少了自由文本解析成本。
- 更清晰的工具链分工：生成任务交给 Responses API 和 Structured Outputs，工具调用交给 function calling，判断任务交给 Decisions API。
不过，该 API 目前仍处于公测阶段，可用模型只有 gpt-6-luna，正式 GA 时间和后续模型支持范围尚未确定。对于准备接入的开发者而言，现阶段更适合先在非核心链路上验证效果，例如内容分类、图片初审、请求路由和优先级排序等场景，再根据正式版本的能力扩展使用范围。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/openai-kai-fang-decisions-api-gong-ce-ba-duo-mo-tai-pan
