9 月 29 日的 DevDay 上，OpenAI 一口气发了 20 多项更新：GPT-6.1 Sol、Ultrafast 速度层级、Agents API 支持 computer use、常驻在线的 Dots、Sign in with ChatGPT、OpenAI Marketplace……
在这么多"大新闻"里，有一个只有一段话、还处于限量预览的小功能，被我列进了必读清单：
Decisions API。
原因很简单：它代表的不只是一个新接口，而是一种正在成型的模型品类——决策模型（decision model）。而且它背后的故事，比 API 本身更有意思。
一个"不写文本"的 API
传统调用大模型的姿势是：给一段 prompt，模型吐出文字，你再从文字里把需要的东西解析出来。
Decisions API 反着来。官方描述是：把 Luna 的智能聚焦到一组用户自定义的问题上，这些问题带有有限的预定义答案。开发者用文本或图片提供上下文，拿回来的就是那组答案里的某一个。
你可以粗略记成一行伪代码：
decision = f(上下文, 问题, 允许的答案集合)
它不写句子，不解释，不啰嗦。只做一件事：从你给定的选项里挑一个。
官方给的典型场景有三个：
-
• 给内容分类（classify content） -
• 路由请求（route requests） -
• 决定 Agent 的下一步动作（choose an agent's next action）
为什么"限制输出"反而是进步
很多人的第一反应是：这不就是让模型做选择题吗？有什么稀奇。
稀奇的恰恰在这里。生产环境里，绝大多数 LLM 调用其实根本不是"创作"任务，而是"判断"任务：
-
• 这张工单是不是账单问题？ -
• 这张图有没有违反内容政策？ -
• Agent 下一步该调用哪个工具？
过去大家怎么做的？用 chat 模型，在提示词里求它"只输出 JSON"，然后祈祷它别乱加解释，再写一堆校验代码去处理"合法 JSON、但不在预期标签里"的边界情况。
Structured Outputs 解决了"能不能解析"的问题，但模型仍然在生成每一个字，而你的代码仍然要处理它跑偏的可能。
Decisions API 换了个思路：把答案集合写进请求本身，而不是生成之后再过滤。输出空间被提前锁死，没有自由发挥，也就没有"解析"这一步。
速度上的收益来自同一个设计：从已知列表里返回一个答案，需要的解码量远小于写一整句话。OpenAI 给的对比数字是 150ms vs 1.6s——大约 10 倍。
它填的是一个中间地带。在"提示词 + chat 模型"和"自己训一个小分类器"之间：
-
• 用 chat 模型：灵活，但慢、贵，置信度基本靠猜 -
• 自己训分类器：快、便宜，但要有标注数据，标签一改就得重训 -
• 决策模型：标签在请求里随时可改，返回的是结构化的选择和分数
OpenAI 自己其实早就做过类似的东西——Moderation API 返回的就是各类别分数而不是文字。区别是：审核的类别由 OpenAI 定，而 Decisions API 的答案由开发者自己给。
Decisions API VS Jev
理解 Decisions API，不能不看 TypeSafe 的 Jev。
Jev 比 OpenAI 早两周发布（9 月 15 日），创始人 Diogo Almeida 是前 OpenAI 研究员。它被定义为一个 "System One"（快思考）模型，特点是：它根本不会写文本。你给它状态（字符串、JSON 或字符串数组）和一组"有类型的问题"，它并行地给出答案。
Jev 有三种问题类型：
-
• Choice：从最多 255 个选项里选一个，返回每个选项的概率和一个置信度 -
• Score：在 2–10 个有序等级上打分，返回落在哪个位置（可落在两级之间） -
• Noul：一个"是/否"的概率
它用所谓 RLCD（面向校准决策的强化学习）训练，目标不是"写出人喜欢的文本"，而是"给出校准过的概率"。售价 $0.042 / 百万输入 token，输出免费，端到端延迟 70–500ms。
对比就很清楚了：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
150ms vs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这张表里最关键的三点：
1. 受限 LLM vs 专用模型。 OpenAI 是在"缩小"一个生成模型的工作范围；Jev 是另一种模型类别。Jev 不生成文本，所以输出 token 不花钱。
2. 图片输入是 OpenAI 明确的优势。 Altman 在台上演示的是 computer use 的 agent，OpenAI 的 Romain Huet 把场景框定为"机器人根据实时看到的东西做出快速动作"。而 Jev 目前只接受文本。如果你的决策点是"一张截图"，Jev 看不见。
Reddit 的 r/AI_Agents 上出现了标题为"Jev Is Dead"的帖子。但另一派观点完全相反：OpenAI 亲自下场做决策端点，恰恰证明 Jev 开创的这个品类是真的——对一个初创公司来说，这种"验证"比两周的独家窗口更值钱。
还有第三条路：开源
不止 Jev 一家。还有一个叫 Laya 的开源方案（Apache 2.0，4.21 亿参数），可以自托管，自报约 33ms 一次决策、边际成本为零。
于是"决策模型"这个市场，很快分成了三种截然不同的商业模型：
-
• OpenAI：决策应该是你已经付费的生态里的一个原语 -
• Jev：决策应该是一个专门的、校准过的、优化过的服务 -
• Laya：决策应该是没人能向你收租的基础设施
同样的话术，三种完全不同的生意。
真正让它变重要的，是 Agent
如果只是"分类更快更便宜"，这话题不至于这么热。真正让它变成必读的，是 Agent。
一个 Agent 的循环里，通常有一个负责自由推理的"规划器"，和大量细碎的"路由步骤"。规划器需要前沿模型，但每一个小步骤都调用前沿模型，成本和延迟都撑不住。
决策模型的价值，是把"快思考"和"慢思考"拆开。这笔账很直观：
-
• 30 次 1.6 秒的决策 = 48 秒 -
• 压到 150 毫秒 = 4.5 秒
对"人等在旁边"的场景，和"一个任务里要做几十次决策"的 Agent，这是数量级的差别。
更值得关注的是安全方向。OpenAI 一直在给自主 Agent 加防护，其中一种思路是用另一个模型检查它的行为。但对每一个动作都跑一个前沿模型，算力成本高到不现实。
有人用一个演示项目验证了替代方案：用决策模型评估 Agent 的动作是否偏离了最初的任务——高置信度判定不当的就拦截，不确定的送去人工复核，符合指令的放行。据该演示引用，把这套监控应用到一次 agent 工作流，用 Jev 花了2.94美元，用前沿 LLM 要花372美元。
一百多倍的差距意味着什么？意味着"对每一个动作都做检查"从经济上不可行，变成了可行。它不会消除 Agent 的失败，但它加了一层以前负担不起的复核。
当然也有边界。轻量决策模型会继承底座的局限：多步逻辑推理、复杂算术、日期解析、对抗性输入上，准确率会下降。CMU 一项以 Jev 为研究对象的评测发现：在 0.9 置信度阈值下，被 Jev 接受的那部分答案与 GPT-6 的准确率只差一个百分点；但也发现它在"推理密集型判断"上明显吃亏（JudgeBench 上 78.6% vs 93.1%），并且当错误答案被包装得更"讲究"时，准确率掉了 9 个百分点。
所以业界的建议是混合架构：快速的决策层配置信度阈值，把复杂或不确定的边界情况交回大的推理模型。
给开发者的几条实操建议
如果你打算把决策模型用进业务，几条来自一线的经验：
-
1. 选项要互斥。"账单"和"付款"这种意思接近的标签，会把置信度劈成两半。 -
2. 一定留一个"都不是 / 无法判断"。 否则意料之外的输入会被硬塞进某个类别。 -
3. 用真实数据定阈值。 准备几百个有已知答案的历史案例，看每个置信度档位的准确率，再决定自动化的切点。 -
4. 记录人工修正。 这份日志是你回头调阈值、以及在换模型时做对比的依据。 -
5. 按"犯错的代价"决定自动化程度。 工单路由错了很容易改；支付环节判错了，代价可能不可逆。 -
6. 别把某个供应商的阈值直接搬过去。 两个模型输出都在 0 到 1 之间，含义未必一样，接受规则要在标注样本上重新测。
我的判断
决策模型不是要取代大模型，而是给它配一个"快思考"的搭档。
过去两年，大家默认"更强的模型 = 更长、更贵、更慢的推理"。Decisions API、Jev、Laya 合起来，在说一件相反的事：在很多具体环节里，把输出的空间锁死，比让模型自由发挥更有价值。
对 OpenAI 来说，这未必是它最亮眼的发布，但很可能是定义下一个阶段基础设施的一条线。
对开发者来说，现在最该做的不是急着迁移，而是想清楚一件事：
你的系统里，哪些调用本质上是"从有限答案里选一个"？
把它们标出来——无论最后用哪家的产品，这些地方都是你系统里最该被"快思考化"的部分。
END
#agent #openai #jev #gpt
如果这篇文章对你有帮助，欢迎点赞、在看、转发