OpenAI Decisions API 正式版上线：单次 400 问、原生 JSON 与语音实时判断

边界说明：本文只讲 2026 年 10 月 22 日的正式版（GA）事件及其相对公开测试版的变化，不重复展开测试版的基础概念。Decisions API 的公开测试版已于 2026 年 10 月 6 日发布，VibeFix 此前已有专文介绍（《OpenAI Decisions API》测试版报道，slug 为 openai-decisions-api-october-2026）；需要了解测试版来龙去脉的读者请先读那一篇。本文默认你已经知道它是什么，只回答一个问题：正式版到底新了什么、贵不贵、值不值得现在上生产。

一句话结论：从“能用”到“敢上生产”

2026 年 10 月 22 日，OpenAI 在开发者社区宣布 Decisions API 正式结束测试、全面可用。核心定位没有变：它不是一个通用生成接口，而是一个只返回有界答案的判断接口——让应用在不生成一整段回答的前提下，对文本、图像和结构化数据做出近实时的分类、评分和路由决策。正式版的真正意义不在于多了一个新模型，而在于补齐了生产落地最缺的几块拼图：一次能问的问题翻倍、能直接吃原生 JSON、能复用缓存降成本、能跟语音实时联动、能在美国和欧盟做推理驻留。对个人开发者和小团队来说，这意味着此前只能在演示里跑通的“判断层”，现在有了可以算账、可以合规、可以压延迟的版本。

判断要先说清楚：GA 不等于“所有人都必须迁移”。如果你现在只是偶尔调几次分类，或者你的判断逻辑用规则引擎已经够用，正式版不会立刻改变你的成本结构。它的价值集中在三类场景：高频判断、长上下文反复判断、以及判断结果直接驱动下一步动作的实时场景。下面按“变了什么、多少钱、不能干什么、怎么用”四条线展开。

正式版相对测试版的变化：五项增量，一张对照表

OpenAI 官方公告列出的新增能力有五项，交叉核对的二手报道还补充了推理驻留和区域容量信息。把它们放在一起看，正式版的升级思路很清晰：减少中间转换、减少重复计费、减少等待时间。

维度	公开测试版（2026 年 10 月 6 日）	正式版（2026 年 10 月 22 日）
单次请求问题数上限	200 个	400 个，翻倍
结构化输入	需要自行把应用数据转成文本或消息	原生 JSON 输入，可直接传结构化应用数据
缓存	未作为 GA 卖点列出	提示缓存：复用共享输入前缀可享缓存价
语音联动	无原生集成	原生 GPT-Live 集成，语音应用可随说话实时反应
问题指令中的图像	图像作为输入存在，但指令级图像是新增项	单个问题指令内可放图像，可拿多图对照同一参照
推理驻留	未强调	美国和欧盟推理驻留，另有亚洲多区域新增推理容量

1. 单次 400 问：批量判断终于可以一次算完

上限从 200 提到 400，表面看只是数字翻倍，实际改变的是批量任务的组织方式。以前一次审查 300 条用户反馈、300 张商品图或 300 条工单，你要拆成两次请求、两次计费边界、两次失败重试；现在可以一次发完、一次拿齐答案数组。对 vibe 项目最直接的收益是审核类后台：一次把待审队列全部打分，排序后只把低置信度的交给人工，人工量不是线性下降，而是被“高置信自动放行”切掉一大块。当然，400 问不是让你把所有问题都塞进一个请求——问题越多，单个请求的失败面越大，超时和重试策略反而更重要。务实做法是按业务批次切分：比如每 50 到 100 条一批，既享受批量价，又不把一次网络抖动变成整批重算。

2. 原生 JSON 输入：少一层格式转换，就少一类 Bug

以前把订单、工单、表单、埋点事件喂给模型，往往要先拼成自然语言描述，字段一多就容易丢精度、改格式。正式版允许通过用户消息里的 input_json 内容块直接传结构化数据，模型拿到的是结构本身，而不是你转述的版本。对 vibe 开发者这点很实在：你后端已经有的数据结构，不必再写一套“翻译成提示词”的胶水代码；字段名、枚举值、数值范围原样进模型，判断依据更稳定。反过来也要注意：结构化不等于免清洗，脏字段、缺失值、单位不一致仍然会进模型，判断前的数据校验不能省。

3. 提示缓存：高频复用场景的成本开关

正式版引入提示缓存，复用共享输入前缀时可按缓存价计费。按官方价格表，非缓存输入是每百万 token 0.10 美元，缓存输入是每百万 token 0.01 美元，相差一个数量级。交叉报道补充了一个关键细节：可复用的前缀至少 1024 个 token，问题内容（包括问题专属图像）不计入可复用前缀，默认在共享输入末尾设隐式缓存断点，也支持调用方提供的缓存键或显式断点。这意味着缓存不是“开了就有”，而是需要你把共享上下文设计成稳定前缀：系统说明、分类标准、评分量表、少样本示例放在前面且尽量不变，真正变化的待判断内容放在后面。那些每次提示词都大改、上下文每次都重写的用法，享受不到缓存红利。算账时也要留心：缓存写价格、区域处理附加费和长上下文倍率可能另计，具体以官方定价指南为准，不要只按 0.01 美元做预算。

4. 原生 GPT-Live 集成：判断从“事后批处理”变成“说话过程中”

这是正式版最有想象力的一项。语音应用可以在输入或输出转录到达时就运行判断，Live 会发出决策事件供应用采取行动。官方示例是根据转录更新选择虚拟形象的面部表情，客服场景则是判断该追问、该路由还是该升级。换到 vibe 项目的语境：语音助手不再需要等一整句话说完、等完整回答生成完才决定下一步；它可以在对话进行中就判断用户意图是否明确、情绪是否升级、是否需要打断或转人工。对做语音客服、语音陪伴、实时访谈记录的独立开发者，这是一个值得试的方向，但也要清醒：实时判断对延迟和误判都更敏感，语音场景的误路由成本高于文本场景，上线前必须给低置信度留人工兜底。

5. 问题指令内图像：多图对照同一参照，终于不用绕路

正式版允许在单个问题的指令里放图像，典型用法是拿多张图对照同一个参照图做比较。以前要实现“这批照片里哪张最符合参照标准”，你可能要拆成多次请求或把参照描述写成文字；现在参照可以直接作为图像出现在问题指令里。这对电商质检、房源照片筛选、设计稿比对、内容审核里的“与标准图是否一致”类任务很友好。需要注意的是，文档同时说明文件、音频和条目引用不受支持，不接受 file_id 输入，图像只能用内联 base64 数据 URL 或公开可访问的 HTTP/HTTPS 链接。做 vibe 项目时，私有图片要先想好公开访问或转 base64 的方案，不要等到联调才发现图片传不进去。

三种有界答案：只给概率、选项和分数，不给散文

Decisions API 的设计哲学可以用一句话概括：答案的形状是预先定死的，模型只负责填空，不负责自由发挥。官方文档和交叉报道一致描述了三种问题类型，理解它们是正确使用这个接口的前提。

问题类型	返回什么	适合判断什么	vibe 项目实例
谓词（predicate）	0 到 1 之间的概率，表示某个条件为真的可能性	是否满足某个条件	商品照片是否可见破损、评论是否含辱骂、工单是否属于紧急
选择（choice）	从你预设的选项中选一个，同时给出每个选项的概率和置信度	路由、分流、分类	客服工单分到售后、技术还是账单；用户反馈分到 Bug、需求还是咨询
评分（score）	按 2 到 10 个有序量表等级打分，返回概率加权平均分，分数可以落在等级之间	质量、风险、优先级排序	UGC 内容风险分、投稿质量分、待办事项优先级分

这三种类型各有各的坑。谓词的概率不是“模型有多确定”，而是“条件为真的可能性”，阈值要按业务调：把“是否紧急”的阈值定在 0.5 和 0.8，人工介入量会完全不同。选择的置信度要和概率分布一起看：最高选项概率只有 0.4、其余选项各占 0.3 时，选出来的那个选项其实并不稳，正确做法是把这类请求标为“需人工确认”，而不是直接自动执行。评分的加权平均分落在等级之间是正常的，不要把它四舍五入成整数等级后又当成精确分数用；排序用它没问题，定性结论要用等级区间来表述。

还有一个设计约束必须提前知道：依赖前面答案的判断，文档要求发多个独立请求。也就是说，Decisions 不做链式推理，你不能在一个请求里让第二个问题引用第一个问题的答案。需要多步判断的流程，要在你自己的代码里编排：先发第一批问题，根据结果决定第二批问什么。这个约束看似麻烦，实则是好事——流程控制权留在你手里，出错时能定位到某一步，而不是面对一个黑盒长链无从下手。

价格与部署：只收输入 token，但别只看 0.10 美元

正式版运行在 GPT-6 Luna 上，官方价格表写得很干净：非缓存输入每百万 token 0.10 美元，缓存输入每百万 token 0.01 美元，只收输入 token，不收输出 token。这对判断类任务是结构性利好：传统生成接口的大头往往是输出 token，而判断任务的输出本来就很短，改按“只收输入”计费，相当于把判断的边际成本压到了输入这一侧。对高频小判断尤其划算：一条短工单的分类，可能只需要几百个输入 token，单次成本不到一美分。

但预算不能只按 0.10 美元算。交叉报道提醒了三项附加因素：区域处理附加费、长上下文输入的价格倍率、缓存读写的标准 Luna 缓存费率。真正做成本模型时，要按你的实际分布算：平均输入长度多少、缓存命中率多少、有多少请求走欧盟驻留、有多少是长上下文。给一个粗算方法：先按 0.10 美元算出“无缓存上限成本”，再按你的缓存命中率打折，最后留 20% 到 30% 的缓冲给附加费和重试。只有当这个数字仍然显著低于你现在用 Responses API 做同样判断的成本时，迁移才有经济账；如果两者接近，迁移的收益就只剩下延迟和结构化答案，而不是省钱。

部署侧，正式版支持美国和欧洲（欧洲经济区加瑞士）的区域处理，所有支持的 API 区域都提供数据驻留，符合条件的客户还可用零数据保留和 HIPAA。还有一个容易被忽略的运维能力：组织用量接口 GET /v1/organization/usage/decisions，需要管理员 API 密钥和 api.usage.read 权限，可按项目、密钥或模型分组统计 token 用量和请求数。对独立开发者这是成本归因工具，对小团队这是分项目算账的依据——判断服务一旦上生产，用量可视化应该和上线同步做，而不是等账单来了再查。

Decisions 不是什么：别拿它当生成器用

这部分必须说得不客气一点，因为误用是最常见的翻车方式。Decisions 不是通用生成器：它不写散文、不生成结构化对象、不替你调用工具。当你需要的是成形对象或一段文字时，官方文档指的方向很明确：用 Responses API 的结构化输出或函数调用，而不是硬把判断接口当生成接口使。

你要什么	用 Decisions	用 Responses / 结构化输出
给一段内容打分、分类、选路由	是，天然适合	可以，但贵且慢
生成一段回复、摘要、改写文本	否，接口不生成 prose	是
返回自定义 JSON 对象	否，只有三种有界答案	是，用结构化输出
让模型决定调用哪个工具	否	是，用函数调用
多步推理、前面答案影响后面问题	需自己编排多请求	可在对话内连续推理
处理文件、音频、条目引用	否，文档明确不支持	按对应接口能力处理

判断的另一个边界是“判断不等于裁决”。概率 0.92 不等于事实，评分 8.5 不等于定罪。在内容审核、风控、客服升级这类有真实后果的场景，Decisions 应该定位为“分流器”和“排序器”，而不是“终审法官”：高置信度自动处理，低置信度进人工队列，极端后果的操作永远保留人工确认。把模型概率直接当成业务真理写进数据库，是 vibe 项目最容易埋的雷。

厂商说法要打折：10 倍快，是谁说的？

OpenAI 在公告和交叉报道中称，Decisions API 比用 Responses API 问同一模型 Luna 快 up to 10 倍。这是厂商说法，未经独立验证，本文不把它当作实测结论。厂商引用的一批客户案例同样要按“客户自述、未经独立验证”来读：Box 称结合 Box Extract 后证书类路由选择快约 5 倍且准确率持平；Datadog 称在执行前给 agent 生成的命令打风险分，p95 延迟比可用前沿模型快 40 倍且准确率相当；Ramp 称成本归因快 4 倍、便宜 30% 且准确率无损；Sierra 称在实时客服对话的部分编排环节选下一步动作，p95 低于 280 毫秒，比之前方案快约 3 倍、单次成本低 90% 且客户结果无下降；Speak 称 GPT-Live 集成把下一步动作时间从 1.4 秒降到 0.13 秒，降幅超 90%。

这些数字即使全部属实，也有一个共同前提：它们是在各自的具体任务、具体数据分布、具体基线下测出来的。你的任务换一组数据、换一个阈值、换一个提示词，结果可能完全不同。正确的使用方式是把它们当作“值得做基准测试的信号”，而不是“上线就能拿到的收益”。上线前，用你自己的真实样本跑两组对照：Decisions 与你现在方案的延迟、成本、准确率和人工介入率，四项同时达标才算迁移成功，只看延迟一项很容易被厂商叙事带偏。

给 vibe 开发者的落地清单

如果你打算在下一个 vibe 项目里用上 GA 版 Decisions，可以按下面这个顺序动手，跳过任何一步都可能在联调时返工。

1. 先定答案形状，再写提示词。每个判断先写清楚是谓词、选择还是评分，选项和量表先在产品文档里定死，不要边调边改，否则历史分数不可比。
2. 把共享上下文做成稳定前缀。分类标准、量表定义、示例放在共享输入前面且尽量不变，这是拿到缓存价的前提。
3. 给每个判断定阈值和兜底。高置信自动走，低置信进人工；极端后果的操作永远人工确认。阈值用真实样本标定，不要拍脑袋定 0.5。
4. 批量按业务切分，不要贪满 400。每批 50 到 100 条是兼顾成本和重试成本的起点，按你的超时分布再调。
5. 多步判断自己编排。前面答案影响后面问题时，用代码串联多次请求，流程控制权留在自己手里。
6. 图片先解决供给方式。私有图片走 base64 或公开链接，文件和音频不要指望这个接口。
7. 上线同步接用量统计。用组织用量接口按项目分组看成本，账单异常时能定位到具体项目和密钥。
8. 做自己的基准测试。延迟、成本、准确率、人工介入率四项对照厂商说法，达标再全量。

结语：GA 的价值不在“新”，而在“可算账”

回看这次 GA，它没有换模型、没有换定价大框架，换的是让判断服务上生产的摩擦：一次问得更多、数据不用转述、重复上下文不用重复付费、语音场景不用等整句说完、数据可以留在美国或欧盟。这些都不是 demo 里能看出来的卖点，却是生产账本上真实存在的成本项。对 vibe 开发者来说，Decisions GA 的正确姿势不是“立刻把所有分类都迁过来”，而是先挑一个高频、边界清晰、后果可控的判断场景——工单路由、投稿初筛、内容风险排序都是好起点——跑通阈值、缓存和人工兜底，再决定扩不扩。判断层做得好，agent 才敢把下一步动作交给模型；判断层做得糙，再快的模型也只是更快地犯错。