OpenAI决策API正式可用：怎么快速做路由判断 - 追梦学习库-知识赋能，点缀梦想

OpenAI决策API（Decisions API）已在2026年10月22日正式可用。它不负责写长文，而是专门回答「有边界」的问题：该分给哪个部门？严重程度打几分？这件事是不是真的？对普通人来说，可以把它理解成「只会做选择题/判断题的AI接口」；对轻度开发者来说，它是客服路由、工单分级、智能体下一步动作的低延迟、低成本选项。

本文用大白话讲清它是什么、三种题型怎么选、和普通聊天接口差在哪，并给出可复制的 curl / Python 路由示例（改编自官方文档）。

它是什么：一句话版

Decisions API 搭载 GPT-6 Luna，通过专用端点 POST /v1/decisions 调用，目前模型也仅支持 gpt-6-luna。你把「证据」（文本、图片或原生 JSON）和「问题」交给它，它返回固定格式的答案：概率、选项之一，或按量规加权后的分数——而不是一段散文。

官方宣称：相对用 Responses API 调用同一款 GPT-6 Luna，Decisions 最高可快约 10 倍（厂商数据，实际以你的场景为准）。定价也很直白：输入 $0.10 / 百万 token，缓存命中 $0.01 / 百万，不收输出 token 费用。

为什么普通人、小团队也该关心

应用和智能体每天都在做大量「小决策」：工单该进账单还是物流？这张图有没有磕损？对话里下一步该继续、重试还是先问清楚？单次看着简单，一放大到线上流量，延迟和费用就会叠起来。

OpenAI 公告里的客户案例，能帮你建立直觉（均为对方公开表述）：

Box：保险证明等文档分类与路由，评测里路由选择约 5 倍更快，准确率与 Responses 相当。
Datadog：对智能体生成的命令做风险打分，p95 延迟显著下降，可放进热路径。
Ramp：AI 成本归因约 4 倍更快、约 30% 更便宜。
Sierra：实时客服编排选下一步动作，p95 低于 280ms。
Speak：结合 GPT-Live，下一步动作从约 1.4s 降到约 0.13s。

你未必做语音或大规模归因，但「分类 → 路由 → 置信度阈值」这条链路，小客服系统、表单分流、内容审核里处处能用。

三种决策类型：用生活类比记住

类型	干什么	主要结果
predicate（谓词）	判断「是不是」成立，如商品是否可见损坏	`probability`：0～1 的概率
choice（选择）	从你给定的选项里选一个，如账单/技术/物流/其他	`choice` + 各选项概率与 `confidence`
score（评分）	按有序量规打分，如严重程度从低到高	`score`：各档位索引的概率加权平均

记忆口诀：

要「真假概率」→ predicate
要「无序分类」→ choice（部门、标签）
要「有高低顺序的等级」→ score（严重度、优先级）

自 beta 以来，正式版还补了：原生 GPT-Live 集成、提示缓存、美欧推理驻留、原生 JSON 输入（input_json）、问题说明里可带图、单次最多 400 道题（此前 200）等。细节以开发者文档为准。

动手：把「扣了两次款」路由到账单组

官方最经典的 choice 例子：用户说 I was charged twice，让模型在 billing / technical / shipping / other 里选一个部门。下面给出 curl 与 Python（需自备 OPENAI_API_KEY）。

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": "I was charged twice for my order.",
    "questions": [{
      "type": "choice",
      "name": "department",
      "instructions": "Which department should handle this complaint?",
      "choices": [
        {"value": "billing", "description": "Payments, invoices, and refunds."},
        {"value": "technical", "description": "Problems using the product."},
        {"value": "shipping", "description": "Delivery and tracking."},
        {"value": "other", "description": "Requests outside these categories."}
      ]
    }]
  }'

示意返回（节选）：choice 为 "billing"，并带各选项概率与 confidence。你的业务可设阈值：置信度高则自动进账单队列，偏低则转人工。

Python（官方 SDK 风格）

from openai import OpenAI

client = OpenAI()
decision = client.decisions.create(
    model="gpt-6-luna",
    input="I was charged twice for my order.",
    questions=[
        {
            "type": "choice",
            "name": "department",
            "instructions": "Which department should handle this complaint?",
            "choices": [
                {"value": "billing", "description": "Payments, invoices, and refunds."},
                {"value": "technical", "description": "Problems using the product."},
                {"value": "shipping", "description": "Delivery and tracking."},
                {"value": "other", "description": "Requests outside these categories."},
            ],
        }
    ],
)

answer = decision.answers[0]
if answer.type == "refusal":
    print(f"Refused: {answer.name}")
elif answer.type == "choice":
    print(f"Department: {answer.choice} (confidence: {answer.confidence})")

建议：选项里留一个 "other" 兜底，避免「硬塞进错误部门」。

什么时候用 Decisions，什么时候用 Responses / 聊天

场景	更合适的选择
固定选项分类、是否成立、有序打分；要快、要省、答案要机器可读	Decisions API
要写说明、摘要、按自定义 JSON Schema 抽字段、或触发带参数的工具调用	Responses API（含 Structured Outputs / function calling）
开放式对话、创意写作、教学讲解	普通聊天 / Responses

一句话：答案边界清楚 → Decisions；答案要「写出来」或结构很自定义 → Responses。

给初学者的实用建议

先从一个高频决策入手：例如工单部门、内容是否违规、下一步 continue/retry/ask。在 Playground 用真实样例试，再写代码。
选项描述写清楚：每个 description 说明「什么情况下选它」，比只写英文单词更稳。
用自家标注定阈值：predicate 的概率、choice/score 的 confidence，都要按误报代价调，不要照搬示例。
共享上下文可开提示缓存：固定参考文档/长规则放在 input 前缀，问题变、前缀不变，缓存命中更便宜（前缀需足够长，见官方缓存说明）。
合规与驻留：需要美欧区域推理或 Zero Data Retention 时，查定价与数据控制页，别默认全球随便跑。
别指望它写小说：Decisions 擅长判断，不擅长长篇生成——用错接口才会「又慢又贵」。

三种题型各自适合什么场景

predicate：像「是不是」判断题

适合二值条件：商品有没有磕损、这段话是否相关、用户是否在要求退款。返回的是 0～1 概率，不是武断的「是/否」。你可以设定：概率 ≥ 0.8 自动处理，0.4～0.8 人工复核，再低则忽略或换策略。

官方文档还有「看商品图查可见损坏」的完整示例：把照片和说明一起放进 input，问题类型用 predicate。对电商退换货、质检预筛很直观。

choice：像多选一的部门分拣

适合互斥类别：账单 / 技术 / 物流 / 其他。返回选中的 value，以及各选项概率和整体 confidence。客服工单、内容标签、智能体「继续 / 重试 / 先问清楚」都属于这类。

要点：选项要互斥、含义清晰，并留兜底项，避免模型硬塞。

score：像有序量规打分

适合「有高低顺序」的等级：外观问题 → 有变通 → 完全卡住。返回的 score 是各档位索引的概率加权平均，可以落在两档之间（例如 1.1），再配合 confidence 决定是否升级工单。

若类别没有顺序（比如「营销 / 产品 / 法务」），用 choice，不要硬做成 score。

正式版相对 beta 多了什么（速览）

按官方「What's new」与产品公告，公开测试之后主要补了：

提示缓存：共用前缀可复用，缓存读更便宜。
原生 JSON 输入：input_json，结构化工单/订单不必先拼成字符串。
问题说明可带图：共享证据放 input，每道题自己的对比图放在该题 instructions 里。
单次最多 400 题（beta 为 200），适合批量打标签。
原生 GPT-Live：语音会话中途也能触发决策（例如选表情、选下一步动作）。
美欧推理驻留等数据与合规相关能力（以账号资格与文档为准）。

这些能力说明：Decisions 不只是「又一个分类接口」，而是面向热路径、可批量、可进语音链路的判断层。

和「写长文的 AI」差在哪：再举一个生活例子

假设你运营一个小电商客服机器人：

用户发来：「我被扣了两次款。」
用聊天模型，它可能先安抚、再解释政策、再问订单号——回复很长，你还要从长文里解析出该进哪个队列。
用 Decisions 的 choice，直接得到 billing + 置信度；你的程序立刻把工单丢进账单组，同时另开一条消息用聊天模型去安抚用户。

分工很清晰：判断层用 Decisions，表达层用聊天/Responses。 这也是为何案例里会出现「延迟砍到原来的几分之一」——判断不再背负「写散文」的开销。

常见踩坑（轻度开发者）

把开放式问题硬塞进 Decisions：例如「请详细说明用户情绪」。答案边界不清，应改用 Responses。
选项重叠：如同时有「退款」和「账单」，描述又含糊，模型会摇摆，confidence 也会难看。
一次请求里串依赖题：A 的答案决定 B 才该问——文档建议分两次请求，而不是假装并行。
忽视 refusal：答案类型可能是拒绝；生产代码要分支处理，不要假定永远有 choice。
缓存前缀被「微小改动」打断：多一个空格、换一段说明，都可能导致前缀对不上，缓存命中率掉光。

参考来源

OpenAI 产品公告（2026-10-22）：https://openai.com/index/decisions-api/
开发者指南 Decisions：https://developers.openai.com/api/docs/guides/decisions

（文中速度、成本倍数均为 OpenAI 或其客户公开表述，落地请以实测为准。）