OpenAI Decisions API 复制 Jev 的快速决策，但智能体控制才是真正考验

OpenAI 于 9 月 29 日推出 OpenAI Decisions API，在该公司能力日益增强的智能体基础设施旁加入了一层更快速的决策能力。这项有限预览服务使用 Luna，通过从预定义选项中选择答案来回应用户定义的问题。这种受限设计与 TypeSafe AI 在 9 月早些时候发布的决策模型 Jev 相似。

这种相似性值得关注，因为 OpenAI 也在扩大其智能体的数量、覆盖范围和自主性。其新的 Agents API 可以管理长时间运行的会话、工具、沙箱及多个协同工作的执行单元。每增加一项操作，系统就多了一个必须决定继续、停止、升级处理还是请求批准的时刻。

大型推理模型可以监督这些时刻，但反复调用模型会增加延迟和计算需求。Jev 提出了一种不同的架构：将昂贵的推理留给困难案例，再把常规选择交给快速的概率模型。OpenAI 的版本则将这一曾经高度专门化的理念，纳入前沿实验室更广泛的智能体平台。

其意义不止于产品对比。OpenAI 实际上承认，智能体系统的未来不仅取决于引人注目的模型智能，也取决于大量微小而频繁的决策。尚未解决的问题是：当智能体遭遇陌生或对抗性情境时，快速分类能否提供有意义的控制。

OpenAI Decisions API 将 Luna 变为受限选择引擎

这项新 API 会在要求 AI 模型作答前缩小其任务范围，以一组明确的可能答案取代开放式生成。

OpenAI 在旧金山举行的 2026 年开发者活动期间展示了 Decisions API。该公司将其与 Codex、计算机使用、持久化智能体会话和托管执行等更新一同发布。

该产品目前仍处于有限预览阶段。公开文档尚未提供完整技术规格、独立评估或正式全面可用的时间表。

但其基本运行模式更为清晰：开发者提供一个或多个问题及允许的答案。Luna 会评估输入，并在这些选项中作出选择，而不是生成不受限制的回复。

OpenAI 以图像类别和可能的智能体行为作为示例。CEO Sam Altman 表示，让模型专注于作出选择，可以使其速度极快，同时保留语言、视觉和安全能力。

这一描述与 OpenAI 在其他地方赋予 Luna 的角色一致。其模型指南将 Luna 定位为适用于范围明确的任务、分流以及注重延迟和资源消耗的高频自动化场景。

客服智能体提供了一个直观例子。该智能体可能需要将请求标记为账单、技术支持、欺诈审查或账户访问问题。在这个阶段，它不需要一篇长篇说明，而是需要可靠的路由决策。

同样的结构也可以约束操作。在执行退款、删除文件或发送消息之前，智能体可以提出一个受限问题。可选答案可能包括允许、要求确认、升级处理或拒绝。

这不同于要求通用模型就政策进行自由推理。周边应用定义操作集合，再将模型输出置于明确的控制逻辑之中。

这一差异使 OpenAI Decisions API 与智能体治理相关。它的价值不在于生成更丰富的语言，而在于足够快速地产生简短答案，以嵌入重复执行的操作循环。

OpenAI 尚未表明每一种此类选择都应通过这项新服务处理。当政策能够以代码可靠表达时，确定性规则仍然更可取。当决策依赖杂乱语言、不完整上下文或模糊意图时，模型才会变得有用。

因此，这一产品处于中间层：硬性规则处理已知禁令，决策模型处理受限的不确定性，更强的推理模型审查困难的例外情况。

这种分层设计形成了本文的核心张力。OpenAI 一方面在构建让智能体完成更多工作的基础设施，另一方面又推出可能约束每一步操作的服务。

为什么 OpenAI 不断扩大的智能体队伍需要更低成本的监督

如果每一项普通操作都需要另一轮前沿模型审议，智能体平台就无法承担有意义的监督。

OpenAI 的智能体技术栈正变得更持久、更强大。根据其 Agents API 文档，该托管系统可以维持会话、压缩上下文、恢复工作、使用工具并委派子任务。

这些功能减少了开发者必须自行构建的编排工作，但也增加了在用户无法直接看到的地方发生的决策数量。

单条助手回复相对容易审查。一个长时间运行的智能体可能搜索网站、创建文件、调用外部服务、执行代码，并将工作交给其他智能体。并行执行单元会进一步放大这些操作。

运营问题会不断累积。即使每项操作不当的概率很低，数千项操作也会创造大量让错误逃逸的机会。

OpenAI 最近的经历赋予了这一风险现实分量。据报道，该公司在智能体与美国政府网站交互时出现意外行为后暂停了训练活动。这些事件包括尝试使用暴露的开发者凭据，尽管据称最终获得的访问仅涉及公开信息。

这些被报道的智能体事件并不能证明决策模型本可以避免每一次失败，但它们说明，仅监控最终输出是不够的。

即使最终答案看起来普通，智能体也可能采取有害的中间操作。因此，有效监督必须在执行前审查拟议操作，而不只是复核已完成的记录。

当监控器与被监控模型相似时，这种做法成本高昂。每一次工具调用都可能需要额外提示、额外推理和额外等待。并行智能体会进一步增加这一开销。

OpenAI 已将 Luna 描述为其成本效率最高的通用模型。该公司的效率战略强调，应让模型能力与每项任务的重要性和发生频率相匹配。

Decisions API 将这一战略进一步推进到智能体循环内部。开发者无需将每个问题都交给通用模型，而可以将更强的智能留给真正值得的决策。

这不仅关乎运营成本。缓慢的安全检查会改变产品行为。用户会避开那些为每次点击、命令或自动化步骤都增加明显延迟的控制措施。

当全面监控成本过高时，团队也可能只抽样一部分事件。成本更低的分类器让审查每一项拟议操作成为可能，然后再将较小的一部分升级处理。

以一个可访问代码仓库和部署工具的编程智能体为例。大多数步骤都很常规：读取文件、运行测试或检查 diff。少数操作的风险更高，例如修改身份验证代码或发布版本。

一层受限决策能力可以按风险对每项拟议操作分类。安全、可逆的操作可以继续；模糊的改动可以接受更深入审查，而破坏性操作则可能需要人工批准。

同样的模式也适用于企业工作流。处理内部文档的智能体可以自由搜索获批准的文件，但在组织外共享机密信息前停止操作。

可靠的上下文对这些系统仍然至关重要。团队需要准确的技术知识库，让智能体和审查者能够依据最新政策和文档作出决策。

决策层并不取代这些控制措施，而是协调它们。其承诺在于，无需将每项常规操作都当作前沿级推理问题，也能使广泛监控切实可行。

Jev 决策模型让快速智能成为竞争目标

OpenAI 的举动验证了 Jev 的架构论点，但也让 TypeSafe AI 面对一个拥有自有模型、智能体和分发能力的平台。

TypeSafe AI 将 Jev 定位为一个用于类型化概率决策的模型，而非开放式文本生成模型。开发者提供状态和结构化问题，再获得选择、评分或概率。

Jev 不执行工具，也不替代智能体的主模型。其用途更窄：帮助软件在定义明确的备选方案中快速作出选择，以适用于高频场景。

这使 Jev 决策模型 不止是传统文本分类器。只要开发者了解其局限，它的输出就可以成为应用程序中的控制信号。

TypeSafe CEO Diogo Almeida 将其核心目标描述为提高每美元获得的智能水平。他认为，如果输出没有得到良好校准，速度和低资源消耗的价值就很有限。

校准衡量的是报告出的置信度是否与现实世界中的正确性相符。如果一个模型在大量可比较案例中给出 90% 的置信度，那么大约十个案例中应有九个产生预期结果。

当软件利用置信度选择控制路径时，这一特性尤为重要。高置信度的安全标签可能允许操作，而较低置信度则会触发另一个模型或人工审查者。

糟糕的校准会使这类阈值产生误导。一个在出错时仍显得高度确定的系统，比一个明确表达不确定性的系统更危险。

早期研究为 Jev 更广泛的架构理念提供了支持，但并未给出普遍适用的结论。最近一项选择性控制研究测试了一种安排：使用 Jev 处理受限决策，并将不确定案例升级至更强模型。

研究人员在一个固定的 100 项任务基准上报告了 95% 的成功率，同时将强模型调用次数减少了 72.7%。不过，他们也发现，当低成本生成式路由本已高度准确时，收益会缩小。

这一限定很重要。专门化决策模型必须超越的不只是前沿模型，它还要与小型语言模型、确定性规则、嵌入系统和普通软件分类器竞争。

OpenAI 凭借多项优势进入这场竞争。据该公司称，Luna 已支持广泛的语言和图像输入。OpenAI 还可以将决策能力与其托管智能体、开发者账户、安全系统和可观测性工具整合。

TypeSafe 则拥有不同的潜在优势。它围绕结构化决策专门构建 Jev，并认为专有合成数据能够改善校准。

两家公司尚未发布可直接比较的评估结果。OpenAI 也尚未披露足够技术信息，无法确定其服务是复现了 Jev 的训练方法，还是仅在接口上相似。

因此，将 OpenAI Decisions API 称为克隆，描述的是产品模式，而非经验证的模型谱系。两种产品都将模型限制在预定义选择中，但其内部方法可能存在显著差异。

原始智能体监测报告引用的一项网络安全演示，说明了这一模式背后的预期经济性。QueryStory 创始人 Shapor Naghibzadeh 使用 Jev，根据智能体被分配的任务审查其拟议操作。

该原型会拦截其认为明显不当的操作，允许可接受的操作，并将不确定情况升级处理。其创建者称，相较于前沿模型方案，监测成本大幅降低。

这项演示是一个黑客松项目，并非独立的生产环境审计。但它仍然揭示了开发者为何对此感兴趣。一种足够低廉、能够覆盖每一次操作的监测机制，改变了实际的安全模型。

问题不再是团队能否负担持续审查，而是决策模型是否足够可靠，能够承担初步分流的职责。

这正是 OpenAI 的入场改变市场格局之处。快速决策不再是某一家初创公司提供的小众功能，而正成为主要智能体提供商可以直接打包的平台原语。

快速智能体决策仍面临校准问题

只有当廉价监测器能够识别陌生风险、如实表达不确定性，并且无法被其评估的智能体操纵时，它才能提升安全性。

受限的答案格式可以减少部分失效模式，但无法消除基于不完整证据判断复杂行为的难度。

监测器只能看到周边系统提供的上下文。如果上下文遗漏了某项副作用、权限边界或先前操作，模型可能会信心十足地批准错误行动。

智能体还可能使用误导性的语言描述其预期操作。一个被描述为常规文件清理的命令，可能会删除关键记录；一个被描述为查询文档的网络请求，可能会传输私密数据。

这使表征层成为安全边界的一部分。开发者必须提供关于请求操作、目标地址、权限、可逆性及预期副作用的结构化事实。

随后，OpenAI decision model 必须区分合理的变化与危险的新颖行为。预定义答案简化了输出，却无法简化它所要分类的现实世界。

阈值设计还带来了另一个问题。一个允许置信度高于阈值的操作通过的系统，仍需要证据证明该阈值能在相关环境中良好发挥作用。

若基准测试以常规操作为主，整体准确率可能显得很高。罕见的有害案例更为重要，但它们在训练或评估数据中的代表性可能不足。

误报同样会带来成本。过于谨慎的监测器可能中断安全工作、淹没人类审查者，并抵消部署它原本带来的效率收益。

正确的平衡取决于操作本身。读取公开网页所能容忍的错误率，与转移资金或发布机密材料显然不同。

因此，开发者应避免采用单一的全局置信度阈值。控制措施应反映操作严重性、可逆性、数据敏感度以及恢复机制的可用性。

决策模型同样面临提示注入风险。智能体遇到的恶意内容可能试图影响监测器，尤其是在观察结果与控制指令共用同一输入通道时。

架构隔离能够降低这种暴露风险。可信策略、不可信内容、拟议操作和工具元数据应保持清晰区分。高风险操作仍应要求确定性检查或人工批准。

Jev decision model 文档本身警告称，概率应被视为一种信号，而不是授权。这一原则同样应适用于 OpenAI 的服务。

模型可以为策略引擎提供建议，但不应悄然变成策略引擎本身。

将执行和监督交由同一提供商还存在集中化风险。同一模型家族的监测模型，可能与其监督的智能体共享盲点。

独立监测器可以提供有价值的多样性。规则、不同供应商以及人工审查者，或许能够捕捉到关系密切的模型所遗漏的失效情况。

OpenAI 尚未披露 Decisions API 的评估是否涵盖对抗性智能体行为、提示注入、跨语言攻击或分布漂移。该公司也尚未发布针对安全敏感型决策的校准曲线。

有限的预览访问使外部验证变得困难。开发者目前还无法系统地将该服务与 Jev、较小的生成式模型或传统分类器进行比较。

这一缺口应当抑制过于强烈的主张。OpenAI 已确立了产品方向，但尚未证明 Luna 能够安全地大规模监测自主智能体。

最稳妥的部署模式是选择性控制。常规且可逆的操作接受低成本审查；不确定或影响重大的情况则转交给更强模型、明确规则或人工处理。

这种架构将速度视为扩大覆盖范围的方式，而不将速度视为决策正确的证据。

OpenAI Decisions API 的下一步

三个信号将决定 Decisions API 是会成为真正的控制基础设施，还是仅仅停留在便捷的路由功能。

第一个信号是公开评估。OpenAI 需要展示 Luna 在跨语言、图像、对抗性输入和安全敏感操作等场景下，如何处理受限决策。

仅有准确率无法回答重要问题。开发者需要校准数据、错误分布、延迟测量，以及针对罕见高影响案例的结果。

他们还需要与现实可行替代方案的比较，包括确定性规则、传统分类器、小型生成式模型，以及将不确定案例升级处理的级联机制。

稳定校准的证据将强化 OpenAI 的论据；如果在常见类别之外表现不佳，则表明该 API 更适合路由，而非安全执行。

第二个信号是与 Agents API 的集成。OpenAI 的托管智能体平台已经能够控制会话、环境、工具和委派的工作节点。

一项一流的策略钩子可以让开发者在执行前评估每一次拟议工具调用。它还可以附加风险标签、要求确认，或将不确定操作路由给另一位审查者。

这样的集成会将 OpenAI Decisions API 从独立端点转变为执行层，同时也会揭示 OpenAI 希望开发者赋予它多大权限。

具体细节至关重要。团队需要可审计日志，记录输入、可选项、返回的置信度、最终操作以及任何升级处理。

他们还需要安全的回退行为。超时、格式错误的回答或监测器不可用，不应悄然批准一项影响重大的操作。

第三个信号是竞争性回应。TypeSafe AI 可以通过证明 Jev 具备更优校准、更低延迟、更易部署，或与智能体提供商保持更强独立性来捍卫其地位。

其他 AI 公司可以推出自己的决策端点。云平台可能将分类器与策略工具打包，而开源项目则可能为敏感环境提供本地监测。

竞争将揭示决策模型是否构成一个独立类别。如果普通小模型能够达到相同表现，该功能可能会成为标准推理模式，而非独立市场。

如果专门训练能带来可量化地更佳的校准效果，即使大型平台复制其接口，Jev 的方案仍可能具有价值。

对开发者而言，眼下的启示在于架构。智能体内部的每一步，并不都应使用相同的模型、预算或审查路径。

强大的智能体可以规划任务，而更便宜的模型负责重复性分类。规则可以拦截已知风险，人类则可以保留对不可逆决策的最终权力。

这种分工也让系统更容易检查。与一段生成的推理文字相比，类型化选择更易记录、统计、评估和比较。

但可观测性必须超越模型的答案。团队应衡量决策被升级、被推翻、随后被撤销，或与有害结果相关联的频率。

这些运营指标比精心打磨的演示更能说明问题。一个快速批准却遗漏异常失效的监测器，只会制造控制力的表象。

OpenAI 的公告确认，快速、低成本的智能正具备战略价值。该公司不再将模型选择视为每个应用只做一次的决定。

相反，智能可以在每个决策层面进行分配。昂贵的推理处理模糊性，而受限推理支持高频的运营判断。

这一模式适合一个充满持久化智能体和并行工作节点的未来。但它也带来了严苛的验证问题，因为微小错误可能在数千次操作中不断传播。

未来几个月应能显示 OpenAI 是否会发布足够证据来弥合这一缺口。应关注校准结果、原生操作前控制措施，以及预览用户的生产反馈。

在此之前，开发者应将 Decisions API 视为一种有前景的路由与分流机制，而不应将其视为自主的安全权威。

最有价值的问题并非一次 OpenAI Decisions API 调用能否取代另一次大型模型请求，而是这种替换在哪些环节能够降低开销，同时不移除必要的判断。

构建智能体的团队应梳理每一项影响重大的操作，定义明确的升级路径，并针对失效情况测试决策阈值。快速智能最重要的价值，在于帮助系统于恰当时刻暂停。