客户发来一句“我被重复扣款了”，应用需要先判断该转账单部门还是技术支持；用户说“刷新页面”，应用需要立刻选出刷新动作。这些任务需要的是一个判断，随后才能继续办事。

OpenAI 面向全体开发者开放了 Decisions API 公测：用 GPT-6 Luna 评估文本和图片，直接返回条件概率、预设选项或按等级计算的评分。

Decisions API 针对这类需求开辟了专用端点（POST /v1/decisions），当前支持 gpt-6-luna 模型。它并不负责生成自由文本或论述，而是专注于直接返回固定题型的答案。

这和本站介绍过的 Jev 很接近：都把条件判断、选择和评分做成软件可以直接使用的结果，带上概率，再由代码决定下一步。Jev 是 TypeSafe 的专用 System One 决策模型；这里则是 OpenAI 用 GPT-6 Luna 提供的专用接口。相似的是用途和输出形式。

为什么需要一个“只做选择题”的独立接口？

在实际应用中，这些“小判断”会在工作流的各个分支点上反复发生：把用户请求派发给不同部门、为销售线索匹配跟进动作、在小游戏画面中挑选避障车道，或是判断一条查询到底该调天气工具还是唤起复杂的推理模型。

如果借助常规的 Responses API （OpenAI 用于生成自然语言或结构化内容的主力生成接口） 配合 Structured Outputs （结构化输出，用于让模型按预设 JSON 格式输出），模型会生成文本或符合指定格式的对象，再交给程序处理。对仅需选一个已有路径的请求，应用可以改用直接返回固定题型答案的决策接口。

它的价值在于让应用先选路径，再进入对应流程：查天气的请求交给天气工具，比较方案的请求转给推理模型，需要人工看的操作进入复核队列。这样的判断可以放在每条请求、每次页面操作或每张待检查图片前面。单次判断更快、费用更低，就更适合承接这些反复发生的小决定；后端工具仍负责办事，需要生成内容时再调用生成接口。

OpenAI 称，Decisions API 做决策的速度，相比通过 Responses API 调用同一款 GPT-6 Luna，最高可快 10 倍。这个比较针对决策任务，应用还要完成网络传输和后续执行，不能直接把它当作整个应用快 10 倍。

三种核心题型：它是如何给出结论的？

调用 Decisions API 时，请求由三部分组成：指定的模型（当前支持 gpt-6-luna）、共享的输入内容（支持纯文本或图文混合），以及一个 questions 提问数组。提问支持三类题型：评估条件是否成立的 predicate、从预设选项中做单选的 choice，以及按有序等级打分的 score。接口在返回的 answers 数组中，会对应给出每个问题的名称（name）、类型（type）以及对应的计算答案。

1. Predicate（条件概率题）

用于估计某项陈述或条件是否成立的概率。接口不输出硬性的 True 或 False，而是返回模型对条件为真的概率估计值（probability，在 0 到 1 之间），并附带该问题的 name 与 type。

• 典型应用：检查上传的商品照片是否存在裂缝、撕裂或凹陷等破损；判断某段文本是否与当前上下文相关。
• 工作机制：开发者给出清晰且基于可观察标准的判定说明。应用层根据业务对误报与漏报的承受成本自行制定决策阈值：漏掉一张破损照片和误报一张完好照片的代价不同，应使用自己业务中已标注的样本来确定阈值。

2. Choice（无序选择题）

从开发者提供的一组预设候选项中，单选出最匹配的一项。

• 典型应用：工单分流（退款、技术支持、物流等类别划分）；调用路径选择（闲聊、调用工具或转接推理模型）。
• 工作机制：返回结果包含选中的选项值（choice）、所有选项各自的概率分布（probabilities），以及单独的置信度评分（confidence）。当预设的分类列表无法完全覆盖潜在输入时，文档建议配置 "other" 选项用于承接未覆盖的输入类别；而如果模型返回的置信度偏低，则属于另一维度的判断，应由应用层依据自行设定的置信度阈值决定是否转人工复核或采取回退策略，前者解决类别没覆盖，后者处理判断不够可靠。

3. Score（有序阶梯评分题）

用于将输入内容对照一组严格有序的离散等级进行打分。它不是自由生成一个孤立的分数，而是由模型给出各个离散等级的概率分布，再计算各等级数值索引的概率加权平均值。

• 典型应用：问题严重程度评估、工单优先级分级、有序质量评级。

• 计算逻辑： 开发者定义一组按从低到高排列的等级（levels，等级索引从 0 开始递增）。官方文档以软件故障严重度为例：

  • 等级 0（Cosmetic）：仅外观问题，功能未受影响。
  • 等级 1（Workaround available）：某项任务失败，但有别的办法。
  • 等级 2（Fully blocked）：某项任务失败，且没有替代办法。

  当输入为“导出功能在 Safari 中失败但在 Chrome 中正常”时，模型评估的概率分布可能为：等级 0 为 0.1（10%），等级 1 为 0.7（70%），等级 2 为 0.2（20%）。 最终返回的分数是各等级索引根据概率加权计算得出的连续数值：

  0 × 10% + 1 × 70% + 2 × 20% = 1.1

  1.1 是对整个概率分布的汇总，并不是多出了一个“等级 1.1”。这个例子最可能落在等级 1，但仍保留了落在等级 2 的可能性。如果业务只要一个类别，应使用 choice；如果要按严重程度排序，score 更便于比较。

“最高快 10 倍”和每百万输入 0.10 美元，分别意味着什么？

Decisions API 在计费与调用规则上具备专门的定价机制：

在定价方面，使用 gpt-6-luna 模型的 Decisions API 按输入 Token 计费，价格为 每百万输入 Token 0.10 美元（$0.10 per 1M tokens）。调用该端点时不收取输出 Token 费用，也不收取缓存读取或缓存写入费用。该价格适用于 /v1/decisions 端点，且依然受区域处理溢价与长上下文倍率计费规则的约束。

高并发应用可以按输入量估算开销。例如，若假设每次请求平均消耗 1,000 个输入 Token，执行 100 万次调用的累计输入量为 10 亿 Token，对应的基础输入费用为 100 美元。这一计算仅包含纯文本的基础输入牌价，并不包含图片输入产生的 Token 量、区域溢价、长上下文乘数，以及网络往返、语音或下游工具执行等后端系统开销。

在响应速度方面，主帖演示中的销售线索分类环节曾展示其服务端响应时间低于 100 毫秒，但这仅对应于该次销售线索演示中的服务端处理时间，并不是端到端或全局 SLA 保障。在实际生产部署中，完整的交互延迟还包含客户端与服务端之间的网络传输、本地应用逻辑与后续动作执行的耗时。

六类用途都在做同一件事：先判断，再交给流程处理

在官方技术演示中，Decisions API 展现了六类应用切入点，涵盖路由分流、离散打标、图像筛查、界面决策、风险控制与聚合分析：

1. 智能路由（Routing）：在语言模型、外部工具与专职 Agent 之间做分流。例如简单天气查询直接选天气工具，复杂分析请求则导向推理模型。这样可以让不同任务进入合适的处理流程；能节省多少取决于后端工具与模型的实际成本。动画中的金额标为路径成本示意。
2. 文本分类（Text classification）：对非结构化文本快速完成类别判定与优先级评定。例如用户提出“我被重复扣款了”，接口可以归类为 Billing 部门并评估其严重级别。演示中的置信度与优先级均为展示效果的示意数据。
3. 视觉筛查与关键帧筛选（Image analysis）：结合指令对图片进行破损检查、属性分类或图像内容比较。在官方演示约 10 秒的退货检查中，输入一张橙色背包照片，界面展示了品类（Category: Backpack）以及破损判定（Damage: None detected）。按接口提供的题型，应用可以把“属于哪类商品”写成选择题，把“有没有破损”写成条件概率题，再把答案组织成页面字段。这是预设问题的组合，任意字段的自由抽取仍使用生成接口。处理视频时，也是由应用先抽帧，再交由接口快速筛选与任务相关的关键帧。
4. 辅助界面操作（Computer use）：在自动化任务中，将界面截图与可选动作列表提交给接口，辅助选出下一步操作（如从候选控件中选择“继续”）。Decisions API 仅负责做出离散选择，屏幕坐标映射与点击执行必须由外层应用完成。
5. 安全护栏（Guardrails）：在系统或 Agent 准备执行高危操作（如递归删除共享目录）前，利用 Decisions API 评估风险等级。应用依据返回的风险判断阻止执行，再转交人工审核；权限与阻断逻辑由应用负责。
6. 模式与趋势分析（Analytics）：对大规模数据集进行批量打标，进而统计整体趋势。官方演示中是对商品评论按正面（Positive）、混合（Mixed）与负面（Negative）预设标签归类并统计分布，动画中的评论条数与分布均为示意数据，并非真实数据集统计。

演示中的典型案例：线索分流与选道演示

在演示视频中，官方进一步展示了两个具体场景的实际应用方式：

• 销售线索快速分流：面对来源各异的潜在客户登记信息，系统可以迅速完成意图与规模判定，以便由差异化的销售流程承接。例如，针对 2–10 人的 Agency 团队且明确标注“准备购买（Ready to buy）”、期望在当月落地的线索，画面将下一步标为“产品演示（Product demo）”；而对于个人独立用户且处于探索阶段的线索，画面将下一步标为“套餐对比（Plan comparison）”。这体现了用预设问题快速分类，再让不同业务流程承接这些标签的思路。

• 小游戏画面选车道：在另一段小游戏演示中，系统持续将包含三条车道、障碍物与自车的画面帧送入 Decisions API，由接口在候选车道中选出避障车道。游戏调快后，画面继续展示选道避障。这演示的是小游戏中的画面判断与动作选择，实际换道由游戏程序执行。

语音照常聊，动作单独选：青蛙表情如何跟上对话？

在语音控制场景中，Decisions API 可以与 OpenAI 的 Live API （用于双向低延迟语音对话的接口） 协同工作。依托 Live API 既有的客户端委托模式（Client Delegation），语音会话与动作决策能够在应用层形成清晰分工：GPT-Live 维持语音流的收听与播报，而具体动作的选择则交由 Decisions API 完成。

其标准的交互与执行流程如下：

1. 建立委托会话：应用启动配置了客户端委托的 Live 会话，并在会话中声明支持的动作集合。当系统接收到 session.delegation.created 事件时，保存其中的委托 ID（event.delegation.id）。
2. 组装决策输入：应用服务端收集用户与助手的对话转录文本，连同用户最新发出的请求、应用当前状态（如活动标签页与加载状态）以及当前可用动作列表（如 back、reload、noop），组合构造成 Decisions API 的输入。
3. 选择并执行动作：Decisions API 从可用选项中选出目标动作。应用在实际执行前，需要校验请求是否已被取消以及所选动作是否仍然符合当前界面状态；校验通过后由应用执行该动作并更新状态。
4. 带委托 ID 回传：动作执行完成后，应用带上之前保存的委托 ID，通过 session.commentary.append 将执行结果回传给 GPT-Live，提示其以语音告知用户；若只需更新上下文而不触发语音播报，则使用 session.thinking.append。

在遇到超出简单界面操作的复杂任务时，Decisions API 还可以作为前端分流器。例如在幻灯片控制演示中，如果用户要求“对比这两个方案并推荐一个”，Decisions API 可以将选项归入 reason，应用随即调用 Responses API 配合推理模型处理深入分析，再将结论以相同的委托 ID 回传至语音会话。

在官方技术演示中，技术人员还展示了 GPT-Live 与卡通青蛙形象的配合：GPT-Live 负责语音对话，Decisions API 则根据对话内容选择青蛙展示的表情动画。当用户说“这周过得很疯狂（crazy week）”时，GPT-Live 回复“听起来让人精疲力竭”，青蛙表情切换为疲惫状态；当用户纠正说“是开心的那种疯狂（crazy in a good way）”并提到产品上线时，GPT-Live 随即回复“太让人兴奋了”，青蛙也同步恢复笑脸表情。两者在应用层协同运作，实现了语音回复与视觉表情选择的分工配合。

接入时先确定：需要一个判断，还是一份新内容？

Decisions API 负责固定题型的判断。选接口时，先看应用需要拿到什么结果：

适合使用的场景

• 离散条件与概率估计：需要评估某个条件是否成立并获取概率估计值，由应用层依据业务设定的阈值将其转化为判定逻辑，而非依赖接口直接输出是非结论。
• 选项预先封闭的离散决策：例如工单流向选择、下一步界面动作挑选或请求路径路由。
• 依据标尺的阶梯等级打分：依照固定准则对问题严重度、优先级进行离散等级打分并获取加权数值。

不适合使用的场景与工程细节

• 需要输出长文本或解释原因：Decisions API 只输出固定格式的判定数据，不会给出自然语言解释。如需生成文本或详细论证，应当使用常规的 Responses API。
• 需要提取动态 JSON 字段：若需要从输入文本中自由提取联系人、金额、明细表格等结构化对象，应使用 Responses API 的 Structured Outputs （结构化输出）。
• 需要带有参数的工具调用：若需要模型自主生成工具参数（例如构建带条件的查询语句或拼装 API 参数），仍需使用 Function Calling （函数调用）。
• 工程实现要点：
  • 围绕可观察标准设计题目：提问应基于明确、可观察的客观标准，不同维度的判断应拆为不同问题；分类选项（choices）之间必须定义清晰、界限分明；阶梯评分（levels）的相邻档位需给出互不重叠的具体依据，让每个答案对应可解释的判断依据。
  • 独立问题合并、依赖问题拆分：在单次请求的 questions 数组中，可以同时提交多个彼此独立的提问，它们共享同一份输入数据（例如针对同一张商品图片同时检测是否有破损并分类商品类别）；但如果后续提问依赖前序问题的答案，则必须拆分为多次请求分步发起。
  • 提问命名：每个问题应指定唯一的 name，接口会在响应中如实回显该字段，便于应用层精准解析和匹配对应答案。
  • 图片输入格式：当前端点仅支持通过内嵌 Base64 Data URL 提交图片，不支持传入托管的 HTTP/HTTPS 图片地址或 file_id。

在实际架构中，Decisions API 仅负责依据开发者预设的题目与选项返回概率、选择与加权分值，而阈值裁定、流程阻断、容错回退与后续动作执行，均属于应用层自身的搭建分工。