你的应用里每天都有成百上千个小决定：这条工单归哪个部门？这张照片里的商品坏没坏？这个 bug 有多严重？过去的做法是让大模型写一段话，再从段落里抠出答案——慢、贵，还经常要处理格式跑偏。10 月 22 日，OpenAI 把 Decisions API 推向正式可用（GA）：它不写段落，只回答你预先给好的问题，返回一个概率、一个选项或一个分数。

一、它到底是什么

Decisions API 先在 10 月 6 日以公开测试版上线，10 月 22 日正式可用，背后是 GPT-6 Luna 模型，目前也只支持这一个模型。调用端点固定为 POST /v1/decisions。一个请求只有三部分：model、input（共享证据：一段文本、图片、JSON，或一段对话历史）、questions（要问的问题）。返回的 answers 数组按你给每个问题起的 name 回填答案——你的程序直接按名字取结果，不用再解析自然语言。

OpenAI 称它比用 Responses API 调用同一模型快约 10 倍。这是厂商说法，没有独立评测佐证；但方向是对的：答案越短，推理和解析的活儿就越少。正式可用后，单次请求的问题上限从测试版的 200 道翻倍到 400 道。

二、三种问题，对应三种答案

predicate（判断题）：条件成不成立，返回 0 到 1 的概率。比如“这张照片里的商品有没有可见损坏”，答案是 probability 0.92，你自己定阈值决定要不要转人工复核。

choice（选择题）：从你给定的选项里选一个，附带每个选项的概率和一个 confidence。比如工单分流：billing、technical、shipping、other，模型返回 choice 加各选项概率。记得永远留一个 other 兜底——分类体系永远盖不住所有输入。

score（打分题）：对 2 到 10 个有序等级打分，返回的是按概率加权的等级下标均值，所以分数可以落在两个等级之间。比如严重程度三档：外观问题、有 workaround、完全阻塞，概率 0.1 / 0.7 / 0.2 对应的分数就是 1.1。

三类问题可以混在一次请求里问同一份 input；但如果后一个决定依赖前一个的答案，就得分开发两次请求——它不做链式推理，只回答你给的问题。

三、照着敲：三段 curl 就能跑通

先决条件只有一个：一个开通了 API 账单的 OpenAI 账号，以及一个能访问 gpt-6-luna 的 API Key，存进环境变量 OPENAI_API_KEY。不想先写代码的话，可以先去平台上的 Decisions Playground，用自己的文本或图片试几条。

第一段，工单分流（choice）：

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."}
      ]
    }]
  }'

第二段，严重程度打分（score）：

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "Export fails in Safari but works in Chrome.",
    "questions": [{
      "type": "score",
      "name": "severity",
      "instructions": "How severe is this issue?",
      "levels": [
        {"label": "Cosmetic", "description": "Appearance only; no lost functionality."},
        {"label": "Workaround available", "description": "A task fails, but another way works."},
        {"label": "Fully blocked", "description": "A task fails with no workaround."}
      ]
    }]
  }'

第三段，验货照片判损（predicate，图片用 inline base64 或公开 URL）：

IMAGE_BASE64="$(base64 < product.png | tr -d '\r\n')"
curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @- <<JSON
{
  "model": "gpt-6-luna",
  "input": [{
    "role": "user",
    "content": [
      {"type": "input_text", "text": "Inspect the product in this photo."},
      {"type": "input_image", "image_url": "data:image/png;base64,$IMAGE_BASE64"}
    ]
  }],
  "questions": [{
    "type": "predicate",
    "name": "visible_damage",
    "instructions": "Does the product have visible damage, such as a crack, tear, or dent? Ignore shadows and damage to the packaging."
  }]
}
JSON

验证方法：看返回里的 answers 数组——名字、类型、概率或选项是否和你问的一致；再看 usage 里的 input_tokens 和 input_tokens_details，确认计费口径。Python SDK 从 3.26.0 起支持，调用是 client.decisions.create()，发往同一个 /v1/decisions 端点。示例里的阈值和选项描述只是演示，不要直接抄进生产：阈值要用你自己已标注的历史数据，在几个候选值上测误判成本后再定。

四、价格账：只按输入 token 收费

未缓存输入每百万 token 0.10 美元，缓存输入每百万 token 0.01 美元，输出 token 不收费，缓存写入要收费，地区处理溢价和长上下文倍率可能另算。算一笔账：一条 500 token 的工单做一次分流，输入成本约 0.00005 美元，一万条约 0.5 美元——这就是“决策”该有的价格：它不写段落，所以你也不用为段落付费。

想吃到缓存红利有个前提：共享 input 的可复用前缀至少 1024 token，且 questions 部分不计入前缀。做法是把参考文档或图片固定放在 input 里、只换问题；每次都换 input 的写法是吃不到缓存的。

五、正式版新增了什么，边界在哪里

相对测试版，正式版新增：提示缓存、问题里单独配图（可拿候选图对参照图）、原生 JSON 输入（input_json，不用先拼成字符串）、公开图片 URL 输入、对话历史（含工具调用与结果）、组织用量统计（GET /v1/organization/usage/decisions）、GPT-Live 原生集成（语音对话进行中就能触发决策）、Private Link，以及美国与欧盟的区域处理；OpenAI 还提到在亚洲多个区域增加了容量。

边界同样要讲清：它不生成文本、不返回自定义结构化对象——要按自己的 schema 抽字段，用 Responses API 的 Structured Outputs；要模型决定调哪个工具、用哪些参数，用 function calling。它不支持文件 ID、音频和条目引用；给图片要用 inline base64 或公开 URL。合规方面，对符合条件的客户支持零数据留存（ZDR）与 HIPAA 场景，数据驻留在所支持的 API 区域。

给你的第一步

先别急着重构。挑应用里最高频的一个小决定：工单分流、内容分类、严重程度排序都行。按三步走：第一，在 Decisions Playground 里用真实样本先问几十条，看答案分布；第二，用已标注的历史数据定阈值——比如概率高于多少自动处理、低于多少转人工；第三，只在阈值中间的灰色地带留人工复核。等这一个决定跑稳了，再把同一套问题模板复制到下一个决定上——这才是“决策 API”该有的用法：问题越固定，它越划算。

参考来源