OpenAI 的 Decisions API 瞄准拖慢 AI 工作流的小决策

OpenAI 新推出的 Decisions API，瞄准的是 AI 软件中很少出现在发布演示里的环节：两个更大步骤之间做出的那个小决定。

这条支持请求应该转给账单团队，还是技术支持？一份文档是否已经完整到足以进入下一步工作流？生成的 shell 命令看起来是否安全，可以自动执行？语音助手应该提出澄清问题、转接对话，还是继续处理？

这些决定很容易描述，但一旦做错，代价就很高。如果应用要对每条新消息、每份文档、每笔交易或每个工具结果都做一次判断，延迟会不断累积。把每个问题都交给通用模型处理，成本同样会持续增加。错误的分类还可能把任务送进错误的队列，让不该看到信息的操作员接触到信息，或触发本应等待人工审核的操作。

OpenAI 于 2026 年 10 月 22 日宣布 Decisions API 正式开放使用。它运行在 GPT-6 Luna 上，返回的是带类型的答案，而不是一段文字：概率、预定义集合中的选项，或依据有序评分标准得出的分数。OpenAI 表示，与通过 Responses API 使用 GPT-6 Luna 相比，该端点回答这类边界明确的问题，速度最高可快 10 倍。公司列出的价格是每百万输入 token 0.10 美元，且该端点不收取输出 token 费用。

这一组合对已经在构建 AI 产品的团队很有吸引力。但它并不是通用助手的替代品。真正值得追问的，不是模型是否具备推理能力，而是团队能否把一个狭窄的决策定义得足够清楚，以便衡量它、为它设定合理阈值，并让由此产生的操作始终处于受控工作流之内。

API 实际返回什么

该端点接收共享证据和一个或多个问题。证据可以是文本、包含工具调用及其输出的有序对话、图像，或结构化 JSON。每个问题都有类型、名称和指令；在适用时，还会包含允许使用的选项集合或有序评分等级。

predicate 用于估计某个条件为真的可能性，并返回 0 到 1 之间的概率。它适合回答诸如“这张工单是否描述了订单记录所支持的重复扣款？”或“这张图片是否显示出明显损坏？”之类的问题。

choice 会从预定义集合中选择一个值。路由系统可以提供 billing、technical_support、account_access 和 human_review。语音应用则可以选择 continue、clarify、transfer 或 end_call。

score 会依据有序等级评估输入，例如低、中、高严重程度。响应会包含各等级的概率，以及按概率加权计算的平均值。这个平均值可能落在两个等级之间，适合用于排序；但如果开发者把它当成精确到近乎神奇的测量值，就会带来风险。

一次请求最多可以提出 400 个问题，高于公开测试期间的 200 个问题上限。当许多相互独立的属性都需要根据同一组证据进行评估时，这一变化很有意义。但这并不表示应该把相互依赖的决策打包处理。如果第二个问题只有在第一个问题得到回答后才应提出，那么分开发送请求会让控制流更容易检查和测试。

API 的类型化输出是它最主要的产品区别。通用模型也可以被要求返回 JSON，但开发者仍需验证输出，并处理格式错误或含义不明确的值。Decisions 在 API 层面限制了答案空间，从而减少了解析工作；但这并不能保证底层判断就是正确的。

它在真实应用中的位置

最适合的场景，是答案集合有明确边界、下一步操作清晰且需要反复执行的决策。可以把这个端点看作现有程序中的快速判断层，而不是一名自主运行的员工。

文档工作流可以用它判断上传的证书是否包含必需字段、识别文档类别，并将项目路由到合适的队列。文档提取本身可能仍需要独立系统完成。Decisions 负责回答的是更窄的问题：接下来应该做什么。

支持系统可以用它对工单分类、估计紧急程度，并判断客户消息是否包含足够信息以便首次回复。低置信度的结果可以进入人工队列，而不是直接用于发送自动回复。

智能体编排系统可以利用选择题，在一组规模较小且经过审核的工具中选定下一步工具。例如，收到的请求可能被路由到搜索工具、账户查询、日程安排函数，或澄清步骤。模型负责在这些选项中作出选择；权限、参数校验、速率限制和执行仍由应用程序负责。

安全或运维工作流可以在执行前对拟议操作进行评分。OpenAI 提到，Datadog 正使用该端点评估智能体生成的 Shell 命令，再决定是否进行自主修复。这种模式可能很有用，但不应被理解为完整的安全边界。基于模型的评分可以增加一道审查信号，却无法取代命令白名单、沙箱、身份检查、文件系统限制或审批政策。

语音应用同样适合这一场景，因为决策延迟会被说话的人直接察觉。Decisions 现在原生集成 GPT-Live，可以在输入或输出转录内容到达时触发。应用可以据此决定助手应当请求澄清、转接电话，还是更新交互状态。OpenAI 表示，Speak 在测试中通过这项集成将执行下一步操作的时间从 1.4 秒缩短到 0.13 秒。这是供应商报告的结果，并不保证适用于每一种语音技术栈，但它说明了：在交互循环中，专用端点的重要性可能高于批处理流程。

实用架构：模型、阈值、动作

可靠的实现需要三个彼此分开的层次。

第一层是问题本身。问题应描述可观察的证据，并区分相邻的答案。“这好吗？”不是适合生产环境的问题。“这条消息是否包含取消付费订阅的请求，而不是询问价格的请求？”就更接近可用的问题。

第二层是解释答案的政策。概率为 0.82，并不意味着应用必须采取行动。团队需要决定 0.82 是否足以自动路由，0.55 是否应触发人工审核，以及某些类别是否无论置信度高低都必须交由人工处理。

第三层是动作。模型返回了有效选项，并不代表应因此获得广泛权限。应用应将允许的值映射到已知函数，并拒绝映射之外的任何内容。敏感操作应要求独立授权，并在适当情况下加入人工确认。

这种分离也让评估成为可能。团队可以调整阈值，而无需重写提示词；可以将模型决策与带标签的示例进行比较；还可以根据每种错误的代价，分别衡量误报和漏报。欺诈过滤器、客服路由器和内容审核队列不应仅仅因为使用同一个 API，就采用相同的阈值。

OpenAI 面向开发者的指导也提出了类似观点：应使用来自应用的带标签示例来设定阈值。这个建议很容易被忽略，因为端点返回的概率和置信度看起来颇具量化意味。但只有根据组织自己的数据完成校准后，这些数字才适合用于排序和路由。

提示词设计如今也是政策设计

即使是狭窄的决策，也高度依赖提供给模型的证据和指令。提示词应明确什么算作支持性证据、缺少证据时如何处理，以及如何区分边界案例和明确案例。

假设团队要对发票进行路由。一个薄弱的问题可能只是让模型“选择正确的部门”。面向生产环境的问题则应明确可用部门、用于识别各部门的字段、不完整文件的含义，以及信号相互冲突时的规则。它还可以明确加入 human_review 选项，避免在输入含糊时强迫模型选择某个业务队列。

示例应覆盖正常情况和失败情况。应包括简短消息、长消息、产品接受时的混合语言、相互矛盾的记录、缺失字段、格式错误的 JSON，以及试图向证据中注入指令的内容。证据属于数据，不应允许它改写决策政策。

对于图像决策，要明确模型实际能看到什么，以及它无法据此确定什么。照片可能显示出凹痕，却不能证明损坏的原因；截图可能显示错误消息，却不能证明账户已经遭到入侵。答案空间应当体现这种区别。

当多个问题共享同一份源文档或对话时，可以把可复用材料放入共享输入，再调整问题说明。API 支持针对这种模式的提示缓存。文档说明，可复用前缀至少必须包含 1,024 个词元，缓存输入则可享受折扣价格。缓存能够降低成本和延迟，但开发者也需要理解缓存边界，避免把调用方特有的信息或敏感材料放入可能在错误上下文中复用的前缀。

成本很低，但规模会改变计算方式

公开的 Decisions 定价为：未缓存输入每百万词元 0.10 美元，缓存输入每百万词元 0.01 美元。该端点不收取输出词元费用。乍看之下，许多路由任务几乎可以忽略成本。

实际账单取决于每个问题随附了多少证据。重复发送的政策文档、对话历史或工具输出，可能远大于指令本身。如果每次决策都单独发送同一份大型上下文，就违背了使用小型分类器的初衷。当前缀稳定时，缓存会有所帮助，但写入缓存和区域处理也可能增加成本。

团队应衡量每项已完成业务任务的成本，而不是每次 API 调用的成本。如果分类器拒绝某个项目并将其送入人工队列，模型调用可能很便宜，但整个流程会因此变慢。如果自动路由触发了错误的下游操作，纠正错误的成本可能远高于词元费用。

该端点可以在一次请求中提出许多彼此独立的问题。这能减少请求开销，但不应成为对每个项目提出所有可能问题的借口。额外问题会增加复杂度、加大评估难度，还可能促使团队依据未经任何人验证的分数采取行动。

合理的试点至少应记录输入词元数、缓存命中率、各延迟百分位数、答案分布、审核率、纠正率以及下游完成时间。对于交互式产品，p95 延迟比平均值更重要；对于后台队列，吞吐量和审核人员的工作量可能更关键。

隐私与区域控制

API 支持在美国和欧洲进行推理驻留，OpenAI 表示符合条件的客户可以使用零数据保留。开发者文档还列出了符合条件客户的 HIPAA 支持，并说明了 Private Link 的可用性。这些都是有用的控制措施，但部署系统的组织仍需核实适用资格、合同、端点配置以及功能限制。

区域处理并不等于完整的隐私策略。团队仍须决定输入是否包含个人数据、是否有必要发送完整记录、应用日志会保留请求和响应多长时间，以及谁可以查看使用报告。在可行的情况下，应在调用模型之前完成脱敏和数据最小化。

结构化 JSON 本身不会让敏感信息变得安全。通过 input_json 传入的客户记录仍然是客户数据。如果图像包含面孔、地址、医疗信息或机密屏幕，同样属于敏感信息。关键问题不是 API 是否接受这种格式，而是工作流是否有充分且可辩护的理由传输这些信息。

同样的谨慎也适用于提示缓存。复用稳定的参考文档很高效；但在不相关的请求之间复用包含某位客户私密细节的前缀，则属于设计错误。缓存键和边界应当成为数据流审查的一部分，而不是性能调优时才补上的事后措施。

Decisions 无法取代什么

该端点不是通用的提取系统。如果应用需要包含许多字段的完整对象、书面解释，或遵循自定义架构的输出，那么带有结构化输出功能的 Responses API 可能更合适。如果模型需要携带参数请求工具，函数调用可能是更清晰的抽象。

它不是规则引擎。如果条件可以精确表达，确定性规则更合适。例如，不能因为模型确信账户余额低于某个阈值，就把账户判定为符合条件；应用程序可以直接比较余额。

它本身也不是安全审批机制。模型给出的“安全”选项，并不意味着可以执行不可逆操作。凡是可能花费资金、改变访问权限、向外部发送消息、修改生产数据或执行代码的操作，都应配合权限控制、允许列表、沙箱、交易限额、审批步骤和审计日志。

它也不能替代对模糊或高影响案例的人工审核。类型明确的答案确实比自由文本更容易处理，但整洁的序列化结果可能让不确定的判断显得比实际更权威。系统应保留置信度、证据引用，以及案件被升级处理的原因。

一个能够产出有用证据的小型试点

考虑使用该端点的团队，应从一个已经有可衡量结果的重复性决策开始。不要一上来就处理那种成败依赖五次模型调用和多个定义含糊的交接环节的工作流。

首先，收集一批真实输入，请合格的审核人员标注正确操作。用于测试的提示词应与这些标签分开保存。样本中要包含困难和临界案例，而不是只挑选显而易见的例子。

接着，写出有限的答案集合。如果不确定性本身就是合理结果，就加入 human_review。明确每个答案允许执行什么、不允许执行什么。如果无法清楚说明某项操作，说明这个决策可能划定得过宽。

然后测试三种运行模式：高于高阈值时自动路由，处于中间区间时转人工审核，低于较低阈值时采用安全回退。将结果与当前流程进行比较。试点如果只报告模型准确率，却不衡量审核人员的工作量或下游错误，就无法回答真正的业务问题。

记录足够的信息，以便在不过度存储敏感数据的前提下还原一次决策。应记录问题版本、模型、阈值、答案、置信度、采取的操作以及之后的修正。如果提示词发生变化，应将其视为软件发布，并重新运行评估集。

最后，在允许端点控制操作之前，让它与现有工作流并行运行。影子模式可以揭示模型在哪些地方与经验丰富的操作人员意见不一致、证据在哪些地方不完整，以及某个看似简单的决策是否暗含例外政策。

谁应该尝试，谁应该等待

对于已经有明确的分类、路由、评分或升级问题，能够定义允许的结果，并且拥有足够标注样本来评估变化的团队，Decisions API 值得测试。如果当前瓶颈是实时交互中的反复延迟，或是每个小决策都要经过更大型生成式工作流所带来的成本，它尤其值得关注。

它也可能适合这样的产品：需要针对同一段文本、同一张图像或同一条结构化记录，评估多个相互独立的问题。对于共享上下文稳定、数据要求明确的工作负载，提示词缓存和区域控制会进一步增强其适用性。

如果团队仍在寻找用例、无法解释什么样的答案才算正确，或者打算让端点任意选择工具和操作，就应该先等待。较低的 token 价格无法挽救未定义的政策。快速响应也不应被用来掩盖授权、审核或审计控制的缺失。

这次发布更广泛的意义在于架构层面。AI 应用正逐渐摆脱那种试图一次完成理解、决策和行动的大请求。更易维护的系统会把这些职责拆开：模型可以解释证据，有边界的决策端点可以在经过审核的选项中做出选择，而普通软件则负责执行权限检查并落实结果。

这种分工不会消除模型错误，但会让错误更容易被衡量、限制和纠正。对大多数团队而言，这才是测试 Decisions 的实际理由：并不是每个工作流都需要另一个 AI 端点，而是有些工作流需要一个更小、更负责任的决策层。