什么是 Decisions API？OpenAI 快速决策层详解

如果你正在搜索 what is decisions api，最简短的答案是：OpenAI Decisions API 是一个限量预览中的接口，用于在软件内部完成小而明确、答案范围受限的判断。开发者不必先让通用模型写一段话，再从文字中解析结论，而是可以定义问题、提供上下文，让系统从有限答案集合中做出选择。

这使它适合内容分类、请求路由、工具调用闸门，以及 AI Agent 循环中的下一步选择。它不是通用聊天或推理模型的替代品，而是位于应用状态和确定性代码之间的一层更窄的决策能力。

OpenAI 在 DevDay 2026 上介绍了 Decisions API。公开发布报道将它描述为 GPT-6 Luna 的专用版本，支持文本或图像上下文、预定义答案，并以限量预览形式推出。报道还提到约 150 毫秒的响应时间，以及相较普通 GPT-6 Luna 调用约十倍的速度优势。这些数字是发布期的报道和宣传信息，不是服务等级保证。

本文解释这个概念，但不会把第三方发布报道当作稳定的 API 参考文档。预览阶段的接口、价格、限制和访问规则都可能变化。真正接入关键业务前，应以 OpenAI 当前文档和账户控制台为准，并使用本文的架构和评估原则作为起点。

目录

• 一句话理解 Decisions API
• 决策 API 和 Chat API 有什么区别
• 一次决策循环如何工作
• Decisions API 可以用于什么
• 接入方式可以是什么样
• OpenAI Decisions API 与 Jev 的区别
• 它在 AI Agent 中处于哪一层
• 延迟、成本与置信度
• 生产环境前需要核实什么
• 常见问题

一句话理解 Decisions API

Decisions API 是一个面向决策的模型接口：它接收应用上下文和一个边界清晰的问题，然后返回软件可以使用的结构化选择。

关键在于“有限”。“给这个客户写一封有帮助的回复”是开放式生成任务；“这个工单应该进入哪个已批准队列”则有有限的答案空间。“这个具体的工具调用是否需要人工确认”同样可以是有限问题，前提是应用明确了“需要确认”的含义。

可以把它抽象成：

decision = f(state, question, allowed_answers)

输出不是给人阅读的完整文章，而是供周围程序使用的信号。程序仍然需要验证响应、检查权限、应用业务规则、记录结果，并决定动作是否真的被允许。

公开发布信息显示，OpenAI 的预览版本面向快速完成内容分类、请求路由和 Agent 下一步判断，同时支持文本或图像上下文以及开发者定义的有限答案。具体请求和响应结构仍应视为预览内容，直到 OpenAI 更新正式参考文档。

决策 API 和 Chat API 有什么区别

大多数模型集成都是 Chat 形态：消息进入，开放式文本出来。当产品需要解释、写作、综合信息或开放式推理时，这种灵活性很有价值。但当模型处在每天运行数千次的控制循环里时，聊天形态就不一定合适。

假设支持系统收到下面的工单：

客户被重复扣款，而且付款已经失败三天。

通用模型可能写出一段同时提到计费、支付和紧急程度的好文本。应用随后还要从文本中提取路由、校验标签、处理额外措辞，并决定格式漂移时该怎么办。有限答案问题则直接从软件契约开始：

问题：这个工单应该由哪个已批准队列处理？
答案：billing、technical、account、none_of_the_above
上下文：<工单状态>

区别不只是“JSON 和文本”的区别。结构化输出可以要求生成式模型把多个字段格式化为 JSON；决策 API 则围绕语义选择本身设计：在推理前先声明答案空间，结果也被设计成决策信号。

两种路径可以简化为：

聊天模型：   prompt -> prose -> parser -> validation -> retry -> action
决策模型：   state + bounded question -> decision -> policy -> action

第二条路径更短，但并不天然安全。结构正确的答案仍可能是错的，置信度数字也可能没有校准。模型选择“安全”并不意味着它可以获得权限。真正的优势是边界更清楚：一边是模型判断，另一边是确定性授权。

实际设计规则

当应用可以在调用前写下答案空间时，适合使用决策 API。当应用需要模型生成语言、探索可能性，或制定无法缩减为少量批准结果的计划时，应使用通用模型。

一次决策循环如何工作

可靠的接入可以拆成四步。

1. 只收集一个决策所需的状态

状态是决策可以使用的证据，可以是工单、邮件、拟执行的工具调用、截图、多个服务组合出的紧凑对象，或一小组检索事实。

状态要保持聚焦。如果路由决策只需要工单标题、正文、账户等级和最近两次支付事件，发送完整对话存档会增加噪声、延迟、隐私暴露和成本。应思考人类审核者回答这一个问题需要看到什么，而不是模型理论上能读多少内容。

2. 写出一个有限问题

一个问题应该描述一个判断。“分类、排序、退款并通知客户”隐藏了多个政策，应拆成多个问题或应用步骤：

• 哪个已批准团队负责这个案例？
• 按明确等级定义，服务影响有多严重？
• 下一步动作是否需要人工批准？

每个问题都应有审核者可以检查的答案空间。当现实情况可能超出分类集合时，应加入 none_of_the_above 这样的明确出口。

3. 定义允许的答案

答案选项应该由应用拥有。路由可以使用 billing、technical、account 和 manual_review；工具闸门可以使用 allow、confirm 和 block；优先级则应使用带有业务定义的等级，而不是没有解释的“低”和“高”。

问题设计本身就是产品政策的一部分。选项变化会改变历史结果的含义，因此应将问题、评分标准和政策与模型标识一起进行版本管理。

4. 在代码执行前应用政策

返回的决策只是信号。应用仍需检查权限、资源范围、数据有效性和副作用规则。模型可以建议 refund_review，但真正的退款必须由有权限的服务或人工批准。

最安全的表达式是：

可执行路径 = 模型判断 ∩ 确定性政策

交集才是重点。决策模型处理有歧义的语义判断，代码保留授权权力。

Decisions API 可以用于什么

最适合的场景是重复出现、范围狭窄，并且周围系统已经存在下一步动作的判断。

内容分类和请求路由

把工单、潜在客户、文档、事件或审核内容路由到已批准队列。路由可以依据意图、产品区域、严重程度、客户等级，或状态中的多个事实。备用路径可以避免系统把陌生案例强行塞进误导性的类别。

选择 Agent 的下一步

Agent 可以使用更强的模型理解目标和制定计划，再使用快速决策层从允许列表中选择下一步，例如搜索、打开、填写、验证、重试、请求帮助或完成。宿主应用仍需检查动作是否可用，以及参数是否安全。

工具调用和交易闸门

在发送邮件、修改账户、删除数据、发起支付或发布内容前，可以针对拟执行动作提出一个窄问题。然后把结果与确定性允许列表、用户权限、确认要求和审计日志结合起来。模型可以帮助理解意图，但不应成为唯一授权层。

模型路由和成本控制

并非每个请求都需要前沿模型。决策层可以把简单工作路由给快速分类器，把复杂工作交给更强模型，把不确定任务交给检索，把敏感工作交给人工。路由对象应该是拥有明确输入形状、延迟区间、成本和故障回退的能力，而不是提示词里随意出现的模型名称。

分流和优先级判断

队列系统通常需要一致的优先级信号，而不是一段摘要。只有当评分标准说明每个等级的实际业务含义时，分数才有价值。“服务被阻断”和“轻微不便”比没有定义的“紧急”和“不紧急”更容易测试。

视觉判断

发布报道将图像上下文描述为预览版本的一项能力。这可能支持识别截图中的已知界面状态，或把图像报告路由到正确流程。不要因此假设所有视觉流程都已适合生产环境；应验证格式、大小限制、隐私处理和真实标注样本上的准确率。

接入方式可以是什么样

由于预览契约可能变化，不要把非官方请求体直接复制到生产环境。应将提供商封装在一个小适配器后面。下面只是概念伪代码：

{
  "context": {
    "ticket": "The customer was charged twice.",
    "account_tier": "business",
    "recent_events": ["payment_succeeded", "payment_succeeded"]
  },
  "question": {
    "name": "route",
    "prompt": "Which approved workflow owns this case?",
    "answers": ["refund_review", "technical_support", "account_security"]
  }
}

适配器应将响应当作 unknown 进行验证，拒绝允许列表之外的选项，并区分不确定性与传输失败。超时不等于自信的“否”，服务过载也不代表工具调用是安全的。

const decision = await decisionsApi.evaluate(request);

if (!allowedRoutes.includes(decision.choice)) {
  return sendToManualReview('Unknown route');
}

if (decision.score < ROUTE_THRESHOLD || !policyAllows(decision.choice)) {
  return sendToManualReview('Uncertain or disallowed route');
}

return dispatch(decision.choice, { auditId, source: 'decisions-api' });

上面的字段名仅用于说明。不要假设 score 或 confidence 一定是经过校准的概率。应记录原始结果、问题版本、政策版本、模型标识、最终动作和后续人工结果，用来评估阈值是否有效。

OpenAI Decisions API 与 Jev 的区别

OpenAI 预览版本和 Jev 都属于软件内部的快速结构化决策类别，但它们不是同一个服务，公开信息也描述了不同的契约。

维度	OpenAI Decisions API	Jev AI
当前报道中的状态	DevDay 2026 发布时为限量预览	公开 Playground 和 API 流程
报道中的引擎	GPT-6 Luna 的专用版本	Jev 决策模型
公开描述的输入	文本或图像上下文	网站公开说明中的文本、JSON 对象和文本数组
输出思路	从开发者定义的答案中选择，并在报道中提到分数	Choice、Score、Noul 类型结果，以及概率和置信度
示例任务	分类、路由和 Agent 下一步	分类、路由、评分、安全检查和人工审核闸门
契约成熟度	预览中需核实端点、限制、价格和访问权	已有公开文档和交互式 Playground

有用的问题不是“哪个品牌更好”，而是“哪个契约可以被团队评估和运营”。当账户整合、图像上下文或预览资格很重要时，OpenAI 可能更合适；当团队想立即测试公开 Playground 和类型化决策流程时，另一种公开服务可能更方便。无论选择哪一个，都应定义小答案空间、收集标注样本，并把最终授权留在应用代码中。

它在 AI Agent 中处于哪一层

一个生产级 Agent 通常至少包含以下层次：

1. 编排器： 跟踪任务、上下文、重试和循环状态。
2. 生成模型： 理解意图、制定计划、生成语言或总结证据。
3. 决策层： 回答关于路由、风险、优先级或完成状态的窄问题。
4. 政策和权限层： 执行用户、Agent 和工具被允许做什么。
5. 动作和审计层： 执行获批调用，并记录发生了什么。

Decisions API 应该处在第三层，不应悄悄变成第四层。决策模型可以判断一个工具调用看起来风险较低，但不能授予政策引擎没有授予的权限。

第一次实验应选择一个可回退、低风险的决策：

历史样本
        ↓
问题 + 允许的答案
        ↓
离线评估
        ↓
Shadow 流量
        ↓
人工批准的自动化
        ↓
受监控的生产路径

涉及资金、访问权限、删除、安全和声誉时，Shadow 模式尤其重要。在允许模型改变真实世界之前，先把它的判断与人工标签或可信规则进行对比。

延迟、成本与置信度

延迟

发布报道给出的 Decisions API 延迟约为 150 毫秒，并称其速度约为普通 GPT-6 Luna 调用的十倍。这个方向对高频 Agent 循环很有吸引力，但应用仍应自行测量 p50、p95 和 p99。网络距离、上下文大小、并发、重试和排队都可能超过模型本身的计算时间。

成本

决策端点可能通过避免长篇解释、把简单请求路由到便宜模型来降低成本，但不会让完整工作流免费。单位经济模型应包含上下文、重试、可观测性、后续模型调用和人工审核。预览价格应以当前账户信息为准，不要仅凭发布报道推算。

置信度和校准

分数是证据，不是权限。0.92 的结果在某种语言、客户群体或对抗性输入上仍可能出错。至少应测量：

• 与人工审核标签的一致率；
• 每种高成本动作的误报和漏报；
• 不同阈值下的自动化覆盖率；
• 按类别、语言、输入类型和客户群体划分的校准情况；
• 人工审核量和解决时间；
• 模型、问题、政策或产品变化后的漂移。

如果第一名和第二名的概率很接近，最高标签可能并不稳定。应保留放弃自动判断或转人工的路径。对于高影响动作，可以使用双钥匙设计：决策模型推荐路径，确定性政策或人工负责授权。

生产环境前需要核实什么

公开来源将 Decisions API 描述为限量预览，因此深度接入前应核实：

1. 官方端点、认证范围和当前请求结构；
2. 账户是否启用图像输入，以及你的场景是否受支持；
3. 答案集合如何定义，以及是否支持多个问题；
4. 返回分数的含义，以及它是否经过校准；
5. 限制、延迟预期、限流行为、重试策略和错误码；
6. 数据保留、隐私控制和区域可用性；
7. 计费单位，包括失败、重复和批量调用；
8. 模型版本固定方式以及预览变更流程。

应将集成封装在窄适配器后面，对问题和政策进行版本管理，并从日志中删除敏感状态。把用户内容当作数据，而不是政策来源；工单中写着“忽略退款规则”时，不能因此改写退款规则。服务不可用时，应进入安全队列或人工审核，而不是猜测。

常见问题

Decisions API 是 ChatGPT 或通用 Responses API 的替代品吗？

不是。它更适合被理解为专用决策层。生成、计划、工具编排、解释和面向用户的文本应使用通用模型；应用需要从批准结果中选择窄判断时，才适合使用决策端点。

Decisions API 会返回文本吗？

公开描述强调从开发者定义的答案中选择，而不是生成自由段落。即使传输格式是 JSON，应用真正使用的也是决策值和相关元数据，而不是一篇给用户阅读的文章。

它可以选择 AI Agent 的下一步吗？

这是公开资料中最明确的用途之一。应限制动作集合，并在执行前校验工具、参数、权限、资源范围和确认要求。

置信度等于准确率吗？

不等于。置信度可以帮助排序或路由，但必须用真实结果进行评估。对于高成本决策，应增加阈值、放弃判断、人工审核、确定性规则和监控。

现在应该使用它吗？

如果账户有预览权限，并且工作流可以承受接口变化，可以从受控实验开始。先做离线或 Shadow 评估，不要直接启用不可逆自动化。设计适配器前，应先把类型化决策模式研究清楚。

最重要的结论是什么？

Decisions API 代表一种转变：从“让模型写点东西”转向“让模型完成一个小而类型明确的判断”。它可能让分类、路由和 Agent 控制循环更快、更容易集成。可靠性仍取决于明确的答案空间、真实数据评估、由代码掌握执行权，以及把置信度当作证据而不是授权。

参考资料

• OpenAI DevDay 2026 官方公告
• The Decoder：OpenAI expands Codex and its API at DevDay。
• Pasquale Pillitteri：OpenAI launches Decisions API to take on Jev。