AI 应用里最常见的需求，往往不是让模型写一篇长文，而是快速做一个小判断：这条工单该分给谁、这张图片有没有损坏、智能体下一步该做什么。10 月 22 日，OpenAI 宣布 Decisions API 正式全面开放，把这类“小决策”做成了一个专门的接口：开发者不再需要先让模型生成一段话再解析，而是直接拿到概率、选项或评分。
事件：从 Beta 到全面开放
Decisions API 基于 OpenAI 的 GPT-6 Luna 模型，开发者通过专用的 POST /v1/decisions 接口调用。调用时，开发者先写好问题和允许的答案范围，再把文本、图片或结构化数据作为上下文传进去，模型返回的不是自由文本，而是符合预设格式的结构化结果。
它支持三种答案类型：概率型，判断某个条件成立的可能性，例如产品照片是否显示可见损坏；选项型，从开发者给定的固定集合中选出一项，并给出置信度，例如把客服工单归为账单、故障或功能建议；评分型，按 2 到 10 级的有序量表打分，返回概率加权后的平均分，适合对内容质量或风险等级做分级。
与 10 月 6 日上线的公开 Beta 相比，全面开放版本新增了几项能力：与语音服务 GPT-Live 的原生集成，让语音应用可以在对话进行中直接调用决策；提示词缓存，重复使用相同上下文时降低成本；原生 JSON 输入，可以直接传入结构化业务数据；问题指令中支持图片，可以拿多张图片对照同一参考标准做判断；单次请求的问题上限从 200 个翻倍到 400 个。
价格与速度：只收输入费用
定价是这次发布最受开发者关注的部分。官方公布的价格为：每百万输入 token 0.10 美元，缓存命中的输入为每百万 0.01 美元，输出 token 不收费。也就是说，调用成本只取决于传进去的上下文规模，而不取决于返回结果的长度，这与按生成 token 计费的通用对话接口有明显区别。
速度方面，OpenAI 称 Decisions API 比用同一模型走 Responses API 最快可达 10 倍。这是一个厂商给出的对比口径，实际延迟会随问题数量、上下文长度和负载变化，开发者在迁移前仍需用自己的真实流量做基准测试。公开报道中提到的一个案例是语言学习应用 Speak：试用后，其操作间隔从 1.4 秒缩短到 0.13 秒。
这条时间线也值得梳理：Decisions API 最早在 9 月 29 日的 DevDay 上以有限预览亮相，10 月 6 日进入公开 Beta，10 月 22 日正式全面开放。从预览到全面开放不到一个月，说明 OpenAI 希望尽快把这个接口推向生产环境，而不是长期停留在实验阶段。
背景：模型正在从“写文章”走向“做判断”
过去几年，大模型接口的主流用法是生成文本：写摘要、写代码、回答问题。但在真实应用里，大量调用其实只需要一个结构化结论。客服系统要分流，内容平台要分类，智能体要在每一步选择下一个动作——这些场景对延迟和成本更敏感，对输出格式的要求也更严格。
如果每次判断都要先生成一段话，再用规则或二次解析提取结论，不仅浪费 token，也容易因为格式漂移而出错。Decisions API 的思路是把“答案空间”前置：开发者先定义好答案，模型只在答案空间内作答，返回结果可以直接进入代码逻辑。这种做法牺牲了表达的自由度，换来的是可预测的格式、更低的延迟和更清晰的成本结构。
这也反映了 AI 应用架构的一个变化：通用大模型不再是唯一的接口形态，针对高频、低延迟、结构化任务的专用接口正在出现。开发者手里的工具箱正在分层——需要推理和长文时用通用模型，需要快速判断时用决策接口，两者按场景搭配，而不是一刀切。
影响与展望
对开发者来说，Decisions API 最直接的价值在三类场景：一是高频分类与路由，如工单分流、内容审核初筛；二是智能体的工作流控制，让智能体在每一步快速选择下一步动作；三是实时交互，如语音助手在对话中即时决定是否追问、转接或升级处理。这些场景的共同点是：判断要快、要便宜、格式要稳定。
但它也不是万能的。决策质量很大程度上取决于开发者如何设计问题和答案：如果答案集合本身有偏差，或者上下文信息不足，模型给出的概率和评分同样会误导后续流程。此外，缓存、区域处理和长上下文等因素可能影响最终账单，官方定价表之外的细节仍需以开发者文档为准。
更值得观察的是竞争格局。同类低延迟决策工具已经出现，OpenAI 此时把 Decisions API 全面开放，既是补上自己在“快速判断”这一环的产品短板，也是在争夺智能体基础设施的话语权。接下来，开发者会用真实的准确率、延迟和账单来投票：它究竟是生产环境的标配接口，还只是一个特定场景的补充工具，答案将在未来几个月的实际采用中揭晓。