先看证据
工作流的等待，常由小判断累积而成
OpenAI 于 2026 年 10 月 22 日宣布 Decisions API 正式开放使用。这项 API 面向应用和智能体工作流中的小型判断，例如给输入分类、决定请求该走哪条路径，或选择下一步动作。它不是一个新的开放式对话入口，而是让开发者先规定问题及允许的答案，再交给模型处理文本、图像或结构化输入。
这项设计针对的不是某一次调用有多慢，而是判断在整个工作流中重复出现后形成的累积成本。一个请求可能要经过分类、路由和动作选择，每次等待都很短，叠在用户交互或自动化链路上却会拖慢整体响应，也会增加调用开销。Decisions API 的产品取舍，是把一部分通用模型调用替换为更聚焦的判断调用，优先解决那些答案范围有限、但出现频率很高的环节。
限制答案空间，才有可接手的模型输出
使用时，开发者先定义要回答的问题和允许答案，再提供上下文。Decisions API 支持三种答案形式：用 0 到 1 的概率估计某项条件是否成立，在预设选项中作出选择，或返回一个分数。应用可以据此决定后续流程，而不必先把一段开放文本解析成程序能够执行的指令。文本、图像和原生 JSON 输入则让判断可以对应到不同类型的业务数据。
这并不意味着模型输出自动成为业务规则。概率是对条件成立程度的估计，选择和分数同样是模型判断，阈值、授权和例外处理仍须由应用定义。OpenAI 表示，Decisions API 基于 GPT-6 Luna，在这类有界问题上，相比通过 Responses API 调用 GPT-6 Luna，速度最高可快 10 倍。这个数字描述的是产品方公布的上限，不代表所有问题、输入规模或部署条件下都能达到相同倍率。
新增能力分别回应不同的集成约束
正式开放时，OpenAI 公布了几项相互独立的更新：原生 GPT-Live 集成、对复用上下文的提示缓存、美国和欧盟的推理驻留，以及原生 JSON 输入。单次请求最多可提出 400 个问题，是此前上限的两倍。OpenAI 还称已在亚洲多个地区增加容量，并继续改善延迟。这些变化不能简单理解成单一的性能升级，它们分别对应实时交互、重复上下文、结构化数据、批量判断和部署位置等不同需求。
这些能力改变的是接入时可选的系统路径，而不是应用的责任边界。GPT-Live 集成与实时语音场景相关，提示缓存针对复用上下文，较高的问题上限则为一批相关判断提供了新的调用空间。推理驻留信息适用于需要明确处理区域的团队，但材料并未说明它能满足所有组织的具体合规要求。实际设计时，团队仍应核对自己的数据流、区域要求和响应目标，不能把某项 API 能力直接等同于完整的部署方案。
客户数据说明位置重要，数字不能横向排名
已公布的案例显示，Decisions API 的价值与判断所处的位置密切相关。Box 在 30 个保险凭证案例的评估中称，路由选择约快 5 倍，准确率与 Responses API 相同；低置信度案例仍会交给审核人员。Datadog 将它放在自动修复动作之前，为智能体生成的 rshell 命令进行风险评分，并报告相较可用前沿模型，p95 延迟快 40 倍且准确率相当。前者优化文档流转，后者试图在自动执行前加一道快速判断，两者都没有把人工或系统控制从流程中抹去。
其他案例覆盖了成本归因、客户对话和语言学习。Ramp 报告称，AI 成本归因调用快 4 倍、便宜 30%，准确率没有下降。Sierra 称其客户对话编排中的调用 p95 低于 280 毫秒，约快 3 倍、单次成本低 90%，客户结果未见下降。Speak 的测试则把 GPT-Live 集成中的下一步动作时间从 1.4 秒降至 0.13 秒，降幅超过 90%。这些数字来自不同团队、基线和任务，不足以构成统一排名，也不能直接外推到其他产品的输入分布。
把性能验证放回整段工作流
技术负责人评估这类接口时，关键问题不是单独调用能快多少，而是它能否在不增加不可接受错误的前提下改善端到端流程。应优先选择调用频繁、答案边界清晰、结果可以核验的环节，再与现有 Responses API 路径比较延迟、成本和准确率。若任务本身很少发生，或错误代价高到每次都需要人工确认，缩短单次调用时间未必能转化为有意义的系统收益。
更重要的是把不确定性设计进执行路径。对可评分或可估概率的结果，团队需要确定何时自动处理、何时回退，以及低置信度案例由谁复核。尤其是模型输出会触发命令执行或其他有实际后果的动作时，权限检查、异常输入处理和人工介入不能被“更快”替代。Decisions API 提供的是一条聚焦的判断通道，可靠性最终仍由问题边界、评估方法和应用接住结果的方式共同决定。