事件概述

OpenAI 于 2026 年 10 月 22 日宣布 Decisions API 正式全面可用（GA）。这是一个面向“有界答案”场景的决策接口，底层模型为 GPT-6 Luna，定位是“快速、聚焦、低成本地为任何应用做决策”。

按照原文描述，应用和 Agent 在工作流中会做大量小决策：如何对输入分类、把请求路由到哪里、下一步该执行什么动作。单独看每个决策都很简单，但规模化之后，延迟和成本会累积。Decisions API 正是针对这一层需求设计的：它把 Luna 的能力收敛到答案空间有限的判断题上，官方称在文本、图像和结构化输入上，比通过 Responses API 调用 GPT-6 Luna 快至多 10 倍。

从公开 beta 到 GA，本次新增或增强的能力包括：

  • 与 GPT-Live 的原生集成，用于实时语音场景中的即时决策；
  • 针对复用上下文的 prompt caching；
  • 推理驻留（inference residency）支持 美国与欧盟；
  • 支持传入原生 JSON 输入；
  • 支持在问题指令中包含图像；
  • 单次请求最多可提出 400 个问题，为此前上限的两倍；
  • 持续优化延迟，并在亚洲多个区域增加容量。

需要说明的是，原文未披露 GPT-6 Luna 的模型规模、训练细节，也未说明 10 倍加速的具体基准测试方法和硬件条件。

关键技术点

1. 三种有界答案类型

Decisions API 的使用方式很直接：开发者定义一个问题及其允许的答案，再以文本、图像或原生 JSON 提供上下文，API 返回三种答案类型之一。

类型 用途 主要返回结果
predicate 估计某个条件为真的概率，例如产品是否有可见损坏 0 到 1 之间的概率估计
choice 从预定义选项中选择一个，例如 Agent 应继续、重试还是请求澄清 返回所选值，并附带 probabilities 与 confidence
score 按有序等级对输入打分，例如损坏严重程度 各等级索引的概率加权平均值

这一设计的关键在于把开放式生成压缩为受约束的判别任务。答案空间由调用方预先界定，模型不需要自由生成文本，因此输出结构稳定、可直接进入下游逻辑判断，也更便于做阈值控制和置信度兜底。

2. 面向实时链路的延迟与成本

原文给出的定价为：输入 每百万 token 0.10 美元，缓存输入 每百万 token 0.01 美元；30 分钟与 12 小时缓存写入的价格需参考其定价指南。这一价位明显是按“高频、短上下文、批量判断”的调用模式设计的。

客户案例从不同角度印证了延迟收益：

  • Box：在 30 个保险凭证（certificate of insurance）案例上做路由选择，Decisions API 比 Responses API 快约 5 倍，准确率相同；低置信度案例转人工复核。
  • Datadog：在 Agent 生成的 shell 命令执行前做风险评分，与可用的前沿模型相比，p95 快 40 倍，准确率相当，使决策可以放进自动修复动作的关键路径。
  • Ramp：将 AI 成本归因到具体工作，相比 GPT-6 Luna 快 4 倍、便宜 30%，且未牺牲准确率。
  • Sierra：在实时客户对话的编排中选择下一步动作，p95 低于 280 ms，比此前方案快约 3 倍、单次调用成本低 90%，客户结果无下降。
  • Speak：在 GPT-Live 中集成后，语言学习场景的“下一步动作”时间从 1.4 秒降至 0.13 秒，降幅超过 90%。

上述数字均来自原文引用的客户自述，原文未说明其评测集规模、统计口径与可复现细节，读者不宜直接外推为通用性能保证。

3. 与 GPT-Live 的原生集成

Decisions API 可以挂载到 GPT-Live 会话的 session.triggers 上，监听转写增量事件并在其中做出选择。原文示例是通过 session.input_transcript.delta 事件，让模型在 neutral、happy、sad、concerned 之间为虚拟形象选择表情，随后应用读取 decision.event 中的结果驱动动画。

示例配置示意如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
{
  "type": "decisions",
  "event_type": "session.input_transcript.delta",
  "decisions": {
    "questions": [
      {
        "type": "choice",
        "name": "reaction",
        "instructions": "Choose an appropriate reaction for the avatar based on the user's latest message.",
        "choices": [
          { "value": "neutral" },
          { "value": "happy" },
          { "value": "sad" },
          { "value": "concerned" }
        ]
      }
    ]
  }
}

这体现了产品思路的一个转变：语音 Agent 不必为每个小判断发起一次完整的生成式调用，而是把“是否追问、是否转接、是否升级、表情如何变化”拆成低延迟的结构化决策挂载在事件流上。

4. 内部与外部落地范围

OpenAI 内部团队的使用场景包括：dots 团队用于降低响应时间、提升交互性；个人财务团队用于对交易描述分类；传播团队用于按主题和评分对报道分类，判断其强化还是挑战关键叙事，从而识别需要重点审阅的内容。对外部客户而言，原文列举的场景覆盖文档分类与路由、Agent 命令执行前的风险判断、AI 成本归因、实时对话编排和语言学习交互。

对数据科学与 AI Agent 落地的意义

第一，决策层正在从“提示词技巧”变成“接口契约”。 过去做分类、路由、打分，常见做法是让大模型输出 JSON 再解析，配合重试和正则兜底。Decisions API 用 predicate/choice/score 三种类型把这些模式标准化，输出结构由接口保证，工程侧的解析与校验负担显著下降。

第二，Agent 架构更适合“分层推理”。 一个 Agent 的调用链里，真正需要强推理的步骤通常只占少数，多数是低价值的判别动作。把这类动作下沉到专用端点，可以让主模型专注规划，判别模型专注高频决策，从而同时优化 p95 延迟与单任务成本。Sierra 的 280 ms、Datadog 的 40 倍 p95 都属于这类分层收益。

第三，置信度可以进入业务工作流。 choice 类型同时返回 probabilities 与 confidence，这让“高置信自动执行、低置信转人工”成为可实现的默认范式。Box 的做法就是典型：常规文档自动路由，低置信度案例交给审核员。对数据科学团队而言，这意味着可以把决策置信度当作一个可监控、可调阈值的运营指标。

第四，成本归因与可观测性变得可做。 Ramp 用它将 AI 成本归因到实际工作，说明这类高频小调用本身也需要计量体系。当单次调用足够便宜，企业才有动力为每个细粒度决策单独埋点、单独优化。

第五，多模态输入降低了预处理成本。 支持在问题指令中携带图像，意味着“这张图里是否有可见损坏”这类判断不必先走独立的视觉管线再做规则拼接，对质检、票据、证件类场景有直接价值。

我的技术点评

这次发布最有信息量的地方，不是又一个新端点，而是 OpenAI 明确地把“有界答案”作为一个独立的产品类别切出来。这与业界近一年 Agent 工程化的趋势一致：大家逐渐意识到，让一个大模型包办从规划到判别的所有环节，既不经济也不稳定。Decisions API 实质上是在承认——很多所谓智能，其实是高质量的判别。

从工程视角看，几个设计值得肯定。一是答案类型收敛到三种，覆盖概率、分类、序数评分，恰好对应数据科学里最常见的三类建模任务，迁移成本低。二是把 confidence 暴露出来，等于把“不确定性管理”写进了接口契约，而不是留给调用方自己猜。三是与 GPT-Live 的事件触发式集成，说明 OpenAI 在为“决策发生在流上”这一形态做基础设施准备，语音和实时交互场景会最先受益。

但也需要保持审慎。原文中的性能数字全部来自客户自述与官方口径，缺少统一的评测协议、样本量和失败模式说明；10 倍、40 倍这类倍率高度依赖对比基线（Responses API 的调用方式、上下文长度、问题数量），换一个工作负载未必复现。另外，400 个问题/请求的批量能力虽然提升了吞吐，但也带来新的工程问题：一批问题中若部分失败，返回语义如何界定，原文未说明；prompt caching 的命中条件与失效策略，原文仅指向定价指南，未在正文展开。

还有一点值得数据科学团队注意：score 返回的是“各等级索引的概率加权平均值”，这是一个连续的期望值，便于排序和设阈值，但它不等于校准后的概率，也不保证等级间距等距。用于风控或合规判断时，仍需自行做校准验证。

总体判断：这是一个务实的、面向成本与延迟的产品，而不是能力边界的突破。它的真正价值取决于团队能否把工作流拆解成足够细的决策点——拆得越细，收益越明显；如果仍习惯一次调用解决整条链路，那它只是一个更便宜的模型别名。

原文链接