AREX Feed Article
OpenAI 宣布 Decisions API 正式发布：单请求问题上限翻倍至 400，新增 GPT-Live 原生集成
OpenAI 于 10 月 22 日（UTC）通过官方开发者账号 @OpenAIDevs 宣布，Decisions API 正式发布（generally available）。按照的说法，这套 API 用来给工作流加上近实时决策：应用和 agent 可以用它对文本和图像做分类、评估输入、决定下一步动作，而不必让模型生成完整的回复。OpenAI 在中称，它返回类型化答案的速度比通过 Responses API 调用 GPT-6 Luna 快至多 10 倍。
博客写明，正式版基于 GPT-6 Luna、通过专用的 Decisions 端点提供服务。相比 10 月 6 日开启的公测，开发者现在可以用上原生 GPT-Live 集成、prompt caching（提示词缓存）、原生 JSON 输入和单题指令内嵌图片，单请求问题上限也从 200 提到 400。
从公测到正式版的十六天：五项新能力写进规格
Decisions API 的公测是 10 月 6 日在 宣布的，当时它已经接受文本和图像输入，返回谓词、选项、评分三类结果。16 天后的 10 月 22 日 19 时 07 分（UTC），@OpenAIDevs 连发两条推文：第一条宣布正式发布，逐项列出公测以来的新增能力：
- 原生 GPT-Live 集成（OpenAI 面向语音应用的实时对话 API），语音应用可以在用户说话的同时作出反应；
- prompt caching，复用上下文时降低成本；
- 原生 JSON 输入，结构化应用数据可以直接传入；
- 单题问题指令中加入图片，可以把多张图片分别与共享参考图对比；
- 单请求最多 400 个问题，单次调用能做出的决策数量翻倍。
的更新清单比推文更长：托管的图片输入支持公网 HTTP/HTTPS 链接和 base64 内嵌数据；input 可以放入按序排列的对话历史，连同函数调用、工具调用及其输出一起评估；新增组织级用量报告；还可以通过 Private Link 走专用连接发送请求。博客另提到两点运营侧变化：新增美国和欧盟的推理驻留（inference residency）选项，并在亚洲若干区域扩充容量以继续压低延迟。
三种答案类型：概率、选项与评分
开发者把请求发到 POST /v1/decisions。一次请求由三部分组成：model（当前只有 gpt-6-luna）、input（所有问题共享的证据，可以是一段文本，也可以是按序排列的消息、工具调用与工具输出）和 questions。返回的 answers 数组按每道题的 name 字段回填结果，个别题目也可能返回拒绝（refusal）。列出三种题型：
| 题型 | 用途 | 主要返回 |
|---|---|---|
| predicate（谓词） | 判断某个条件是否成立，如产品照片上有无可见损伤 | probability：0～1 之间、条件为真的概率 |
| choice（选项） | 从开发者预设的选项中选一，如该把投诉转给哪个部门 | choice：所选值，附各选项概率与置信度 |
| score（评分） | 按有序等级量表评分，如损伤的严重程度 | score：等级索引的概率加权平均，可落在两级之间 |
输入端的两项扩展各有具体机制。JSON 输入通过 input_json 内容块传入，目前仅限 user 角色的消息；文档的示例是把一张客服工单和对应订单记录并排传入，让模型判断“工单描述的重复扣款是否被订单证据支持”。单题图片指令则把每道题的 instructions 写成文本加图片的数组：所有题目共享的证据放在 input，每个候选图片单独一题，与同一张参考图对比。
边界也写得很具体：这个端点不支持文件、音频和条目引用，图片只能用 base64 或公网 URL，不接受 file_id；文档同时提醒，如果需要让模型生成遵循自定义 JSON schema 的对象——比如抽取字段或写一段解释——应该改用 Responses API 的 Structured Outputs 或函数调用，而不是 Decisions。
接入 GPT-Live：在用户说话的同时触发决策
五项新增里，GPT-Live 集成直接面向语音应用。按给出的做法，开发者在现有 GPT-Live 会话的 session.triggers 里加入一段 decisions 配置，把 event_type 设为 session.input_transcript.delta——输入转写每有增量就触发一次；Live 随后发出 decision.event，应用读取结果并执行动作。文档的表述更概括：Live 可以直接调用 Decisions，也可以在输入或输出转写到达时触发决策。
博客举了两个场景：客服坐席的应用可以在对话进行中实时决定，是追问澄清、转接请求还是升级问题；虚拟形象可以根据用户的话语调整表情，该眨眼时眨眼、该微笑时微笑。示例配置是一道名为 reaction 的 choice 题，选项是 neutral、happy、sad、concerned 四种表情。
每百万输入 token 0.1 美元，缓存命中 0.01 美元
与公测持平的部分是输入价格：每百万输入 token 0.10 美元，只按输入 token 计费，没有输出 token 费用。变化在缓存：缓存命中的输入按每百万 token 0.01 美元计费，是普通输入价的十分之一；缓存写入分 30 分钟和 12 小时两档，具体费率 OpenAI 让开发者查阅定价指南。而在公测期间，开发者确认这套 API 当时没有缓存可用。
数据与网络方面，博客写明区域处理覆盖美国和欧盟，符合条件的客户可以使用 Zero Data Retention（零数据保留）。写代码之前，开发者也可以在 OpenAI 提供的 Decisions Playground 里用自己的文本或图片试跑问题。
内部团队与早期客户：从交易分类到保险单路由
列举的用法里，OpenAI 内部团队占了三个：dots 团队用它缩短响应时间、提升互动性；Personal Finance 团队用它给交易描述分类；Communications 团队用它按主题给媒体报道分类，并按报道强化或挑战关键叙事的程度打分，据此挑出值得细看的内容。列名的早期客户有 Box、Datadog、Ramp、Sierra 和 Speak。
Box 平台与集成产品管理副总裁 Biswaroop Palit 在博客中给出了具体数字：“借助 Box Extract 和 Decisions API，我们对商业文档做分类并路由到正确的下一步。在我们的评估中，Decisions API 在 30 个保险证明（certificate of insurance）案例上把路由选择提速约 5 倍，准确率与 Responses API 相同——把例行工作自动化，低置信度的案例转给审查人员。”
公测论坛的反馈：缓存缺口补上了，choice 概率仍存疑
公测开启次日，就有用户在论坛问起缓存；用户 VeitB 随后确认，“目前 Decisions API 没有可用的缓存”。正式版把 prompt caching 列入新增能力，当时的缺口至此补上。
同一批讨论里还留下了对题型可靠性的质疑。用户 platypus 用一枚正面概率被调到 70% 的硬币做测试：1,000 次试验中，predicate 题型给出的正面比例与真实偏差一致；换成 choice 题型，却有 98% 的结果押在正面。他在后续回复中还发现，调换选项顺序会改变概率分布，并在帖子里写下结论：“我现在的判断是别用 choice 题。”这些只是论坛上的小规模自测——用户 jefff 也提醒，自己的自测结论只基于几百道题，只能算早期信号，不是通用基准。
文档给这两种题型的定位是：choice 用于部门这类无序类别的选择，score 用于严重程度这类有序等级。OpenAI 的正式发布公告没有提及上述概率分布的观察；而文中引用的提速数字——OpenAI 的至多 10 倍、Box 的约 5 倍——分别出自 OpenAI 与 Box 的自述评估。