OpenAI Decisions API技术解读：怎么调用、多少钱，哪些任务值得迁移？

AI应用并不总需要生成一段完整回答。有时候，它只需要做一个小判断：这条投诉该交给哪个部门？图片里的商品有没有破损？当前故障属于哪个严重等级？

过去，开发者可能让通用模型先生成一段文字，再从文字里提取分类结果。10月22日，OpenAI正式开放Decisions
API，给这类任务提供了一个专门接口。

Decisions API由GPT-6
Luna驱动，可以处理文本、图片和结构化JSON输入，返回概率、预设选项或评分。单次请求最多可以包含400个问题。官方标准价格为每百万Token输入0.10美元，Decisions端点不收取输出Token费用；缓存读取和写入仍然按照GPT-6
Luna的缓存价格分别计费。

OpenAI称，在答案范围明确的判断任务上，Decisions API相较于通过Responses
API调用GPT-6
Luna，速度最高可快至10倍。但这不代表所有业务都会快10倍，也不意味着整个Agent流程都能获得同样幅度的提速。

这次更新真正值得关注的，是OpenAI把一类常见工作单独抽象成了API：当应用不需要模型写一段话，而只需要一个可以继续执行的判断结果时，是否有更直接的接口？

01｜Decisions API是什么？它与Responses API有什么区别？

Decisions
API当前只支持gpt-6-luna，通过独立入口POST /v1/decisions调用。一次请求主要包含三个部分：

• model
  ：当前填写gpt-6-luna。
• input
  ：提供需要判断的上下文，可以是文本、图片、结构化JSON，也可以是带有工具调用记录的对话历史。
• questions
  ：列出要判断的问题、问题类型，以及必要的候选答案或评分等级。

例如，客服系统收到"我的订单被扣了两次钱"，可以让模型从"付款、配送、技术问题、其他"中选择一个部门；商品质检系统可以判断图片里是否存在明显破损；运维系统则可以按照预先定义的标准给告警分级。

这与通用Responses API的区别，不只是URL不同。

需求                                         更合适的接口

从固定类别中选一个                           Decisions API的choice

判断一个条件是否成立，并返回概率估计         Decisions API的predicate

按有序等级评分                               Decisions API的score

提取姓名、日期、金额等字段，输出自定义JSON   Responses API的Structured
                                               Outputs

生成解释、报告、摘要或开放式文本             Responses API

让模型请求调用工具并生成参数                 Responses API的Function
                                               Calling

Decisions不是通用模型的替代品，而是针对"答案集合已经定义好"的任务，提供更直接的输出形式。只需要"把工单分到付款部门"，生成一段解释再提取部门名称，可能多走了一步；但如果业务需要"为什么分到付款部门、依据哪些证据、接下来如何处理"，就不应为了省掉几个输出Token而强行改用Decisions。

02｜三种判断类型：predicate、choice和score

类型                解决什么问题             主要返回

predicate         判断一个条件是否成立     probability，范围0到1

choice            从给定候选项中选择一个   choice、各选项概率和confidence

score             按有序等级评估输入       score、各等级概率和confidence

predicate：判断条件是否成立

例如："这张商品照片中，商品本体是否存在明显破损？忽略阴影和包装上的痕迹。"接口会返回一个0到1之间的概率估计，适合判断是否存在破损、是否属于退款请求、某段内容是否与指定主题相关。

但probability: 0.92不等于"这个判断有92%的真实准确率"。它是模型对当前条件成立程度的估计，是否与真实频率相符，需要用业务样本校准。

choice：从候选答案里选一个

工单分流可以设置billing（付款、发票和退款）、technical（产品使用问题）、shipping（配送和物流）以及other（交给人工）等选项。choice会返回选中的值，同时提供选项概率分布和单独的confidence字段。

候选项应尽量互斥，描述也要清楚。两个部门职责高度重叠时，即使API返回格式完全正确，分类结果仍可能不稳定。

score：按有序等级打分

假设故障严重程度分为0（仅影响外观）、1（有替代办法）和2（完全受阻）。如果三个等级的概率分别是0.1、0.7和0.2，API返回的加权分数就是：

0 × 0.1 + 1 × 0.7 + 2 × 0.2 = 1.1

因此，score可以落在两个等级之间。它是概率分布对应的加权平均值，不是模型选中的某个离散等级。如果业务必须得到一个确定类别，使用choice更合适。

choice和score的confidence、概率分布与真实准确率不是一回事。字段提供了判断信息，但不会自动保证模型校准良好。

03｜实战：给在线课程反馈自动分流

用一个不同于传统客服工单的场景，看看Decisions
API怎样进入真实业务：一款在线学习应用每天会收到大量课程反馈，需要判断问题属于哪一类，并决定是否应优先交给技术团队。

例如，用户反馈：

第六课的视频声音比画面慢了两秒，退出重进后还是一样。

应用不需要模型写一篇分析报告，只需要得到一个明确类别，以及这条反馈是否明确涉及影响学习的播放故障。这正是Decisions
API适合处理的任务。

下面示例使用choice和predicate对同一份文本提出两个相互独立的问题。运行前，需要安装包含client.decisions.create方法的新版OpenAI
Python SDK，并设置环境变量OPENAI_API_KEY。

from openai import OpenAI

client = OpenAI()

feedback = (
    "第六课的视频声音比画面慢了两秒，"
    "退出重进后还是一样。"
)

decision = client.decisions.create(
    model="gpt-6-luna",
    input=feedback,
    questions=[
        {
            "type": "choice",
            "name": "feedback_category",
            "instructions": "判断这条课程反馈最主要属于哪一类。",
            "choices": [
                {
                    "value": "playback_sync",
                    "description": "音视频不同步、播放卡顿或播放失败"
                },
                {
                    "value": "course_content",
                    "description": "课程内容错误、解释不清或材料缺失"
                },
                {
                    "value": "learning_progress",
                    "description": "学习进度、完成状态或记录同步问题"
                },
                {
                    "value": "account_access",
                    "description": "登录、账号或权限问题"
                },
                {
                    "value": "other",
                    "description": "信息不足或不属于以上类别，交由人工判断"
                }
            ]
        },
        {
            "type": "predicate",
            "name": "learning_disrupted",
            "instructions": (
                "这条反馈是否明确描述了影响正常观看课程的故障？"
                "只根据用户提供的信息判断，不推测未提及的情况。"
            )
        }
    ]
)

for answer in decision.answers:
    if answer.type == "refusal":
        print(answer.name, "未能完成判断，转入备用流程")
    elif answer.type == "choice":
        print("反馈类别：", answer.choice)
        print("选项概率：", answer.probabilities)
        print("置信度字段：", answer.confidence)
    elif answer.type == "predicate":
        print("是否影响正常学习：", answer.probability)

print("输入Token：", decision.usage.input_tokens)

这段代码只负责返回判断，不会自动创建工单或联系用户。应用可以根据feedback_category把反馈送到对应队列，再根据learning_disrupted决定是否提高处理优先级。

需要注意三点。

第一，两个问题可以放在同一次请求里，是因为它们都基于同一条反馈，而且彼此不需要先后依赖。如果后一个问题必须读取前一个问题的结果，就应该拆成两次请求。

第二，probability和confidence不是准确率保证。正式上线前，应当用已经由人工分类的真实反馈做测试，查看不同类别的误判情况，并为信息不足的输入保留other或人工复核路径。

第三，返回了一个类别不等于业务动作已经成功执行。工单创建、优先级修改、通知发送等操作，仍应由应用自己的代码执行，并处理权限、失败重试和日志记录。

这个例子展示了Decisions
API在业务链路中的合理位置：模型负责把非结构化反馈转成有限、可读取的判断结果，应用负责执行后续流程，并验证最终结果。

04｜输入、图片、JSON与接口限制：接入前先看清边界

Decisions
API当前支持文本、图片、原生JSON，以及带有工具调用记录的对话历史。单次请求可以提交1至400个问题；每个问题可以选择不同类型。它也可以将拒答作为单个问题的结果返回，而同一请求中的其他问题仍然可能正常完成。

目前只支持gpt-6-luna。choice适合无序分类，候选值需要有明确区分；选项数、输入结构等具体限制，应以最新API参考为准。

图像可以通过公开可访问的HTTP(S)地址或内嵌base64 data
URL提供。对于语音应用，Decisions并不是直接接收任意音频文件的通用音频接口；它可以与GPT-Live原生集成，依据语音会话产生的转写增量触发判断。模型返回动作选择后，实际动作仍由应用执行。

其他需要留意的边界包括：

• 文件对象、音频文件和通用item引用不属于Decisions的直接输入能力。
• questions
  里的图片属于问题级证据，不应默认能与共享输入一样命中缓存。
• 多问题请求中的答案按问题顺序返回，但任何一道题都可能被拒答。
• 400个问题是同一请求中的问题数量，不是400条无关数据的批量上传保证，也不是400个依赖步骤的自动执行。
• num_model_requests
  统计请求次数，不统计请求里的问题数。监控成本时要同时看请求量、问题量和Token用量。

05｜价格怎么计算？"输出不收费"不等于"整个请求免费"

当前官方指南写明，Decisions API使用GPT-6
Luna时，未缓存输入每百万Token收费0.10美元，输出Token不收费；缓存读取享受折扣，缓存写入仍收费。缓存读写单价与GPT-6
Luna的标准Prompt Caching价格一致。

Decisions计费项目    每百万Token价格

未缓存输入               $0.10
  缓存读取                 $0.01
  30分钟档缓存写入         $0.125
  12小时档缓存写入         $0.25
  输出Token                $0.00

区域处理附加费和长上下文输入倍率仍可能适用。上表只适用于/v1/decisions，不代表GPT-6
Luna走Responses API时也不收输出费用。

算例一：短提示词，Decisions能省多少？

假设每次判断消耗400个输入Token。累计调用100万次，就是4亿输入Token：

• Decisions：400 × 1,000,000 ÷ 1,000,000 × $0.10 = $40。
• Responses：如果每次还生成15个输出Token，输入成本为$40，输出成本为15
  × 1,000,000 ÷ 1,000,000 × $0.50 = $7.50，合计**$47.50**。

在这个假设里，Decisions每百万次判断少花7.50美元，约比Responses低16%。这里的400是"每次请求的输入Token数"，不是400个问题；单次最多400题是另一个独立限制。

算例二：长固定前缀已经命中缓存

假设每次请求包含1500个缓存命中的固定Token、100个未缓存Token，并且Responses每次生成10个输出Token。以下只比较缓存已经稳定命中的阶段，暂不计缓存写入、区域处理和其他附加成本：

每百万次请求                       Decisions   Responses

1500个缓存Token，按$0.01/M             $15        $15
  100个普通输入Token，按$0.10/M          $10        $10
  10个输出Token，按$0.50/M                $0         $5
合计$25$30

在这组条件下，Decisions仍然便宜5美元，约低16.7%。需要强调，当前Decisions也支持Prompt
Caching，不能再沿用早期公测资料中"Decisions没有缓存折扣"的说法。

如果缓存经常失效、固定前缀变化，或每次请求都需要重新写入缓存，实际成本会不同。缓存写入按实际写入Token计费；缓存读取与写入Token数量已经包含在usage.input_tokens中，不能把它们再加一次。

计算真实账单时看哪些字段？

官方响应包含usage信息。建议至少记录：

• input_tokens
  ：总输入Token数；
• input_tokens_details.cached_tokens
  ：缓存读取Token数；
• input_tokens_details.cache_write_tokens
  ：缓存写入Token数；
• 请求次数、问题数量、模型结果、延迟与业务最终结果。

组织级用量接口GET /v1/organization/usage/decisions可以按时间范围查看请求与Token使用情况，需要具有相应权限的管理员API
Key。

实际成本最好按"每千次成功判断"或"每个完成的业务任务"计算，而不是只比较单次请求均价。
如果某个分类器便宜了10%，却导致更多错误转人工，整体成本未必下降。

06｜官方称快至10倍，第三方客户案例说明了什么？

OpenAI在正式开放公告中称，Decisions
API在答案范围明确的判断任务上，相比通过Responses API调用GPT-6
Luna，速度最高可快至10倍。这是厂商公布的产品指标，不是所有输入、所有网络和所有业务链路的统一承诺。

OpenAI同时公布了部分客户使用结果：

客户         官方披露的结果                                                     应如何理解

Box          在30个保险证明文件案例中，路由选择约快5倍，准确率与Responses相同   小规模、特定文档路由评估

Datadog      在其Agent生成命令风险评分场景中，p95延迟约快40倍，准确率相近       特定安全判断路径，不等于所有模型都快40倍

Ramp         AI成本归因任务约快4倍、成本降低30%                                 特定业务流程的对比

Sierra       p95低于280毫秒，较原方案约快3倍、单次调用成本低90%                 客户原有方案与Decisions的对比

Speak        GPT-Live集成后，下一步动作等待从1.4秒降到0.13秒                    实时语音交互里的动作延迟

以上都是OpenAI发布的客户案例，不是独立、统一硬件与输入条件下的横向基准测试。

为什么这种接口可能更快？它把任务限定在概率、候选项或评分等有限答案类型上，不需要像开放式生成那样组织一段完整文本。但实际延迟仍会受到输入长度、图片处理、网络、并发、缓存和应用后续步骤影响。

如果一个Agent在一项任务里需要做20次小判断，每次等待时间的差异就可能累积；但如果任务的大部分时间花在数据库查询、浏览器加载或人工审批上，模型端减少的时间未必会等比例缩短端到端耗时。

因此，真正应该比较的是同样任务下的p50与p95延迟、业务准确率、每个成功结果的成本，以及失败后的重试和人工处理开销。

07｜概率不能直接当阈值：怎样降低误判风险？

Decisions返回的probability和confidence是模型输出的估计值，不应直接理解成真实世界里的准确率。一个分类器即使常常给出很高的置信度，也可能对某类输入系统性误判。

正式上线前，建议准备一批带有人工结论的业务样本，覆盖常见情况、边界案例、低质量输入和容易混淆的类别。评估时至少看四件事：

1. 准确率与混淆矩阵。
    不只看整体正确率，还要看哪些类别互相误判。
2. 误报与漏报的代价。
   
   

   把普通咨询分错队列，和把高风险请求错误放行，后果完全不同。
3. 概率校准。
   
   

   如果系统对很多样本都给出0.8左右的概率，这些样本中实际成立的比例是否也接近80%？
4. 拒答与兜底比例。
   
   

   模型有多少次无法给出结果？多少请求最终仍要转人工？

可以把结果设计成三档，而不是只有"自动执行／不执行"两档：

• **低风险、可撤销：**例如打标签、分配队列，可在验证后自动执行。
• **中等风险：**例如向内部团队发送提醒，可以增加规则校验或抽样复核。
• **高风险、不可逆：**例如退款、封号、对外发消息或修改关键业务数据，要求人工审批或第二道独立校验。

如果使用choice，建议保留other或needs_human等兜底选项。如果真正需要一个条件的概率，优先测试predicate，并用标注样本确定阈值。不要把0.9机械地当成"九成可靠"。

08｜迁移到Decisions API：推荐用影子测试，而不是直接替换

已经用GPT-6 Luna Responses API和严格枚举JSON
Schema实现的分类器，不一定需要马上迁移。建议按以下步骤判断。

第一步：挑选适合的任务

优先挑选高频、答案范围明确、延迟敏感的判断，例如工单路由、内容分类、商品缺陷初筛、风险标签和实时语音下一步动作。

如果任务必须输出解释、抽取多个字段、生成复杂JSON，或调用工具执行操作，先保留Responses
API通常更合理。

第二步：准备标注集

从真实业务中抽取几百到几千条已有人工作为标准答案的样本。样本应覆盖常见情况、边界案例、模糊表达、错误输入和类别不平衡情况。不要只用模型生成的合成样本来证明模型本身准确。

第三步：影子运行

线上继续使用原方案，同时把相同输入发送给Decisions，只记录结果，不让它真正执行动作。对比：

• 分类是否一致；
• 真实标签上的准确率、精确率和召回率；
• p50、p95延迟；
• 每千次判断的实际费用；
• 拒答率、低置信度比例和人工复核比例。

第四步：按风险逐步切换

先从打标签、分队列等可撤销动作开始，再考虑影响客户或资金的操作。为新旧接口保留统一的函数签名，让业务逻辑只依赖标准化的答案，而不直接依赖某一种API返回结构。

例如，可以让业务层统一调用decide(context, question, options)，底层分别实现Responses与Decisions版本。切换时只改实现，不需要重写整条业务链路。

第五步：持续监控

上线后继续记录输入版本、问题定义、候选选项、模型返回、延迟、Token用量和最终业务结果。问题描述或类别定义发生变化时，重新跑评估集。接口进入GA并不意味着业务分类永远不会漂移。

09｜实时语音集成：Decisions返回动作选择，应用负责执行

Decisions
API已经与GPT-Live原生集成。实时语音应用可以在转写增量到达时触发判断，例如判断用户是否需要补充说明、应把请求路由到哪个队列，或让虚拟角色选择合适的表情。

它的价值在于减少中间应用层的一次往返，让小判断更靠近实时交互。但要区分三个环节：语音会话生成转写、Decisions选择结果、应用执行动作。Decisions返回"选择刷新页面"，不等于浏览器已经刷新；执行结果仍由应用完成并反馈给会话。

实时场景还要注意事件顺序。转写增量可能被合并，决策结果也可能晚到。应用应根据源事件标识把结果对应回触发它的转写，避免旧结果覆盖新状态。

10｜地区、数据控制与第三方网关：接入前要确认什么？

官方文档说明，Decisions API支持符合条件客户使用Zero Data
Retention（ZDR）和HIPAA相关能力；数据驻留可在支持的API区域内使用，区域处理支持美国与欧洲经济区加瑞士。是否符合资格、需要什么协议以及具体限制，应以官方数据控制文档为准。

如果通过第三方网关调用，不能因为它支持普通OpenAI兼容接口，就默认它也支持原生/v1/decisions。接入前需要逐项确认：

• 是否真正提供Decisions模型和对应请求格式；
• 是否支持predicate、choice、score三种类型及图片、JSON输入；
• 是否正确返回probabilities、confidence、usage和拒答状态；
• 缓存、区域处理、请求限制和费用如何计算；
• 数据会经过哪些服务商，日志和输入内容如何保存；
• 所在地区是否属于官方支持范围，使用方式是否符合相关条款。

第三方网关的价格、可用地区和数据处理规则由各自服务商决定，不能直接套用OpenAI官方价格或数据控制承诺。生产环境尤其不应仅凭"能连通"就判断服务受到官方支持。

结论｜专用判断接口的价值，在于降低整项工作的成本

Decisions
API的意义，不只是输出Token不收费，而是将高频、答案边界清晰的小判断变成一种独立的调用方式。它可以减少开放式文本生成的需要，并通过多问题请求、缓存和实时语音集成，帮助应用缩短部分判断路径。

但"输出不收费"不等于"整个请求免费"；"最高快10倍"也不等于整条业务链路快10倍。缓存写入、输入规模、区域处理、误判和人工复核，都可能改变真实成本。

如果你的应用每天需要大量重复分类，且每次只要一个概率、选项或等级，Decisions值得测试。若任务需要长解释、复杂JSON、工具调用或多步推理，就应与Responses
API做同任务对照，而不是只因为新接口价格标签更醒目就迁移。

最终要比较的，不是一次API调用花多少钱，而是每完成一千次正确判断，整个系统花了多少钱、用了多少时间，又引入了多少错误。