OpenAI 把「决策」单独做成一个 API：GPT-6 Luna 提速 10 倍，输入百万 token 只要 0.10 美元

过去一年，开发者已经习惯把大模型当成一个”什么都能聊”的助手。但真正跑在生产环境里的系统，绝大多数时候要的不是一段漂亮的自然语言，而是一个能立刻拿去做分支判断的答案：这条工单该转给谁、这句评论算不算违规、这张照片里的货有没有破损。

10 月 22 日，OpenAI 宣布 Decisions API 正式开放（GA）。它基于 GPT-6 Luna 构建，把模型的智能收敛到”有边界答案”的问题上，官方称在 Responses API 下比直接用 GPT-6 Luna 快最多 10 倍。

一分钟速览

• Decisions API 正式 GA，底层是 GPT-6 Luna，主打”有界答案”的实时决策。
• 官方口径：比走 Responses API 的 GPT-6 Luna 快最多 10 倍；输入定价每百万 token 0.10 美元。
• 只返回三种结果类型：概率（predicate）、选项（choice）、评分（score）。
• 支持原生 JSON 输入、在问题里带图片，单次请求最多可问 400 个问题，是此前上限的两倍。
• 已原生接入 GPT-Live，可在实时语音对话里做决策，并新增美欧推理驻留与提示缓存。

它到底在解决什么问题

一个 Agent 跑完一次任务，中间往往要做几十上百个小判断：先分类输入，再决定路由，然后挑选下一个动作。单看每一个判断都很简单，难的是它们全都要在几百毫秒内完成，而且一天要跑几百万次。这时候”让通用大模型自由发挥”就变成了成本灾难——你为一次二分类付了写一篇小作文的钱。

Decisions API 的思路是把问题形式化：开发者先声明一个问题，再给出允许的答案集合，然后用文本、图片或原生 JSON 提供上下文。模型不能自由发挥，只能在给定的选项空间里作答。

三种答案类型，对应三类真实业务

第一种是 predicate，输出 0 到 1 的概率值，适合”这个条件是否成立”的判断，比如商品照片上有没有可见破损。第二种是 choice，从你预设的选项里选一个，同时返回各选项的概率和置信度，适合 Agent 的下一步动作：继续、重试，还是向用户追问一句。第三种是 score，按一个有顺序的评分标准打分，输出的是各等级索引的概率加权平均值，适合”破损严重程度”这类分级判断。

这三种类型的共同点在于：结果可以直接写进 if 语句。开发者不需要再写一层解析器去猜模型的意思，也不用担心今天返回”是”、明天返回”是的，确实如此”。

OpenAI 自己怎么用

官方披露了几个内部场景：dots 团队用它压缩响应时间、提升交互流畅度；个人金融团队用它给交易描述分类；传播团队则用它判断一篇报道在多大程度上支持或挑战既定叙事，从而决定哪些内容需要人工复核。后两个场景很有意思——它们本质上都是”把非结构化信息变成可统计的标签”，这正是过去要靠人工标注团队干的活。

客户侧的用法同样偏工程：有团队用它精确归因 AI 成本，把每一次模型调用的花费分摊到具体业务线；也有语言学习产品用它让对话更即时。

语音场景才是隐藏的重点

这次 GA 最值得注意的，是 Decisions API 与 GPT-Live 的原生集成。实时语音的门槛从来不是”能不能说话”，而是”能不能在该插话的时候插话”。当用户在电话里抱怨到第三句，客服 Agent 需要立刻判断：是追问细节、转接人工，还是直接给方案。这类判断如果走一次完整的模型往返，对话节奏就断了。

官方给的演示是虚拟形象的表情控制：GPT-Live 发出 decision.event 事件，应用读到选择结果后驱动表情，用户讲完一个冷笑话，虚拟人就能配合地眨个眼。听起来是玩具，但它验证的是一条低延迟通路——从语音流到结构化决策再到前端反馈，全链路不落地。

趋势：模型正在被拆成零件

把”聊天”和”决策”拆成两个 API，是一个信号。过去两年行业在比谁的模型更全能，现在开始比谁能把能力切成合适大小的零件，让开发者按需采购。推理模型负责难题，决策模型负责高频小判断，语音模型负责交互层——这种分工一旦稳定，定价就会跟着分层，而分层定价又会反过来推动应用形态的变化。

对开发者来说，短期最实际的动作是回头看自己的提示词库里有多少”其实只需要一个标签”的调用。那些为了拿一个 yes/no 而付出整段生成成本的环节，都是可以迁移的候选。省下来的不只是钱，还有那几百毫秒的延迟——在 Agent 时代，延迟就是体验本身。

官方文档与接入方式见 OpenAI 开发者平台的 Decisions API 页面。