2026 年 10 月 6 日，OpenAI 在 HN 上低调放出一个消息：Decisions API 进入公测，所有开发者可用。论坛上这条帖子拿到了三位数的点赞，但讨论热度远不如同日的 Mistral Large 4。这有点可惜——对天天在业务代码里写「让模型判断一下」的开发者来说，这个 API 可能比又一个旗舰模型更能改变你的账单。
它到底解决什么问题
回顾一下我们现在的日常：想判断用户评论是否合规，就调一次 Chat Completions，让模型输出「是」或「否」；想给客服工单分类，就写一堆 prompt 约束它只能回某个枚举值；想按评分标准给简历打分，就得手搓一个 JSON Schema 强迫结构化输出。这些任务有个共同点：我们只想要结论，不想要创作。但我们付出的是完整生成式推理的价格和延迟，还常常要跟模型「话痨」的倾向搏斗——明明只要一个词，它偏要写一段。
Decisions API 把这类任务单独拆成了一个专用端点。官方的说法很直白：它让应用在近实时场景下选择正确的模型、工具或动作，速度最高达到经 Responses API 调用 GPT-6 Luna 的 10 倍。代价是你放弃了开放生成——模型只能在预设的判断框架内作答。
跑通第一个请求
请求结构分三部分，官方文档写得非常清楚：model 指定评估用模型（目前只有 gpt-6-luna）；input 是所有问题共享的证据，可以是纯文本，也可以是带图片的用户消息；questions 是要评估的内容，每一项声明自己的类型、指令以及可选的候选项或评分等级。
用 curl 表达大概是这样：
curl https://api.openai.com/v1/decisions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-6-luna",
"input": "用户评论：这耳机音质还行，但戴两小时耳朵就疼，退货了。",
"questions": [
{
"type": "boolean",
"instructions": "该评论是否包含可指导购买决策的实质性产品体验信息"
},
{
"type": "select",
"instructions": "判断评论的主要情感倾向",
"choices": ["正面", "中性", "负面"]
},
{
"type": "score",
"instructions": "按 1 到 5 为评论的有用程度打分",
"score_levels": [1, 2, 3, 4, 5]
}
]
}'注意这里一次请求干了三件事：判定评论价值、识别情感、给出可用性评分。三个判断项共享同一段评论证据，输入 token 只算一次。这是它和「循环调用对话接口三次」最本质的账单差异。
用 Python SDK 的写法更贴近生产：
from openai import OpenAI
client = OpenAI()
resp = client.post(
"/v1/decisions",
body={
"model": "gpt-6-luna",
"input": evidence_text,
"questions": build_questions(rubric),
},
)
for q_id, result in resp["answers"].items():
print(q_id, result)公测阶段 SDK 的封装可能还在跟进中，直接用通用 HTTP 方法发请求最稳。官方也提供了 Playground，写代码前可以先在界面上把问题和量表调通。
计费：为什么它便宜得反常
这是整个发布里最值得划重点的部分。gpt-6-luna 的输入价格是每百万 token 0.10 美元，而且你只为输入付费——没有缓存读取费、没有缓存写入费、没有输出 token 费。对比一下：常规旗舰档模型的输出价格通常是输入的数倍，而判断类任务的输入输出比往往极度倾斜——你喂进去五千字的工单历史，它只回你一个「违规」。
把这笔账算具体一点：假设内容审核场景里，平均每条内容要喂 3000 token 的上下文，一天审核 100 万条。按 0.10 美元每百万输入 token 算，一天的判断成本大约是 300 美元量级。同样的任务如果走常规生成接口，输出部分哪怕只多收每条 50 token 的输出费，按旗舰档输出价格算，账单也可能翻几倍。判断类业务越重，这个差距越大。
三个工程落地模式
模式一：Agent 路由前置层。 Agent 框架里最烧钱的就是「每个动作前都问一遍大模型该干什么」。现在可以在编排层先用 Decisions API 做一次廉价预判：这个请求该走检索、走工具还是直接回答？把 10 倍速的低成本判断放在链路最前面，只有真正需要深度推理的分支才唤醒旗舰模型。
模式二：批量审核流水线。 内容安全、评论质量分、工单分流这类场景天然适合 questions 数组的合并请求。设计上有个细节值得注意：把强相关的判断放进同一次请求，让它们共享证据；把需要不同证据的判断拆开，避免 input 里塞满对某些问题无用的长文本——毕竟省钱的本质是减少重复输入。
模式三：模型评估的评分器。 做离线评估时经常需要按量表给模型输出打分。评分（score）类型把「评分标准」显式声明在请求里，比每次手写 prompt 描述量表更规范，也让评估脚本的版本管理变得干净：量表即代码，变更可 diff。
公测期的三个坑
第一，模型只有 gpt-6-luna 一档，判断任务里遇到需要长链推理的难题时，它的准确率上限摆在那里，关键业务记得留一层降级到完整模型的通路。第二，官方说明 GA 预计在几周内，公测期间请求结构和小字段仍可能调整，生产代码里别把响应结构写死。第三，发布后官方已经提示过，该接口目前不保证与传统对话接口完全一致的判断口径——迁移现有审核规则时，先跑一段双跑对比，确认新旧接口的判定分布一致再切流量。
写在最后
Decisions API 的意义不在模型能力，而在接口经济学：它承认了「判断」和「生成」是两种负载，前者值得更便宜的专用路径。当推理成本逐月下降成为行业主旋律时，这种按负载类型切分计费与延迟的做法，可能比分数榜上的名次更早改变你的架构图。下一次写「让模型判断一下」之前，先想想这个判断值不值得一次完整生成。