2026 年 9 月 15 日，TypeSafe AI 发布了 Jev，并给它起了一个新的类别名：「System One 模型」。两周后，9 月 29 日，OpenAI 在 DevDay 上公布了 Decisions API 的限量预览。10 月 22 日，Decisions API 正式可用（GA）。

一家拿了 4000 万美元融资的创业公司刚刚定义出一个品类，平台方 37 天后就把同类产品推到了 GA。

最近也在思考这两个东西有啥用，从技术上到底哪里一样、哪里不一样，工程上该怎么选。在业务上，模型越来越细分，越来越快，越来越便宜，越来越垂直，我们这种做垂直赛道智能体的团队，哪些能力会被吃掉，剩下的价值在哪里。

1. 解决了什么问题

先看这类东西解决什么问题。

大部分软件流程在调用模型时，想要的并不是一段文字。客服系统要的是「这张工单归哪个团队」，智能体要的是「下一步调用哪个工具」，审核流程要的是「这条内容风险等级多少」。过去两年，这类需求几乎都用同一套逻辑：写一段提示词，让 LLM 输出 JSON，再写解析和校验代码，格式出错就重试。

这条链路的问题，做过生产系统的人都晓得：

贵：一个本质上是三选一的问题，按完整推理模型的价格付费；
慢：输出是逐 token 生成的，一次调用以秒计；
不稳：结构化输出的错误率高于零，模型会编造一个不在选项里的标签，会漏字段；
置信度不能用：LLM 自报的「我有 90% 把握」通常过度自信，没法拿来做自动执行的阈值。

Jev 和 Decisions API 处理的都是这个问题。开发者把上下文和问题一起传进去，并预先列出所有可能的答案，模型返回一个类型化的决策和对应的概率。程序拿到结果直接分支，中间没有解析环节。

流程变化如下：

聊天模型的流程
上下文 → 提示词 → 自然语言解释 → 解析和校验 → 程序分支

决策模型的流程
上下文 → 问题 + 候选答案 → 类型化决策 → 程序分支

TypeSafe 在文档里把 Jev 叫作「智能 if 语句」。我们觉得这个说法准确：它替代的是代码里那些本来想写成 if、但因为输入是自然语言，手写规则太脆弱而写不出来的分支。

2. 三种原语同构

把两家的能力摆在一起来看，其抽象几乎一样。

Jev 的 API 只有三种问题类型：

Choice：从最多 255 个选项中选一个，返回所选项、每个选项的概率和置信度分数，可以加一个显式的 other 选项，表示「以上都不符合」；
Score：在开发者用文字描述的 2 到 10 级量表上打分，结果可以落在两级之间，比如 1.4；
Noul：一个是/否命题，返回 0 到 1 之间的单一概率。

Decisions API 在 GA 时支持的答案类型也是三种：概率、选择、评分。概率对应 Noul，选择对应 Choice，评分对应 Score。

两家的计费结构也一样：只收输入 token，输出免费。这是由产品形态决定的，输出就是一个标签或一个数，没有可计费的生成量。两家都支持在一次请求里问多个问题。Jev 的做法是单次并行处理，所以加第十个问题，响应时间几乎不变；Decisions API 单次请求最多支持 400 个问题。

原语这么接近，说明这个品类的边界已经基本定型：有界的决策、预先定义的答案空间、带概率的输出、按输入计费。对我们做工程规划来说，这个结论很实际。如果两家的接口语义能一一对应，业务代码就可以面向一个内部的「决策接口」来写，底层换供应商的成本会很低。这一点在后面讲嵌入方式时还会用到。

3. 差异在哪里

原语相同，差异就集中在原语之外。我们整理了五个维度。

3.1 模型的来源

TypeSafe 一直强调 Jev 是一个新的模型类别，不想被看成更小的 LLM。它的训练方法叫 RLCD（Reinforcement Learning for Calibrated Decisions，校准决策强化学习），针对实际结果优化概率，不针对人类偏好。主导者 Diogo Almeida 参与过 OpenAI 的 RLHF 和 InstructGPT 工作。RLHF 优化的是「人类觉得这个回答好不好」，RLCD 优化的是「这个概率和真实结果的频率对不对得上」。从训练目标看，两者的方向差别很大。

Decisions API 的发布说明称它使用 Luna 的智能，一篇 DevDay 现场报道说它是一个专用的 GPT-6 Luna 版本，GA 公告也写明基于 GPT-6 Luna。从公开信息看，它是从通用大模型派生出来的决策形态。

这个差异会影响两个方面：

语义理解：基于 Luna 的版本，在理解复杂上下文、长指令和隐含意图上大概率继承了通用模型的能力；
概率质量：Jev 在训练目标上直接对准概率质量。截至我们查到的资料，OpenAI 的公开文档里没有关于校准的技术说明。

对需要根据概率做自动执行的系统来说，概率的质量比判断准确率多出的几个点更重要。但这只是一个推断，最终要拿自己的带标签数据去测。

3.2 输入模态

Jev 目前只支持纯文本：字符串、JSON 或文本数组，不支持图像、音频和视频。

Decisions API 在预览阶段就支持文本和图片，GA 时又原生接入了 GPT-Live 实时语音。

这一项 OpenAI 明显领先。语音场景对延迟极其敏感，通话进行中需要实时判断用户意图、情绪、是否需要转人工，传统的做法是语音转文字后再走一轮 LLM，延迟叠加起来很难受。决策模型直接接在实时语音链路上，能覆盖一类 Jev 目前碰不到的业务。视觉场景也一样，比如商品图审核、单据分类、截图判断。

3.3 价格

Jev：每百万输入 token 0.042 美元，即每十亿 token 42 美元；
Decisions API：每百万输入 token 0.10 美元。

Jev 大约便宜 2.4 倍。另外，第三方的 decisions-api.dev 转售 Jev，标价每百万输入 token 600 积分，10000 积分售价 1 美元，折合每百万 token 0.06 美元，比直连 TypeSafe 贵，但仍低于 OpenAI。

两家相对通用 LLM 都便宜了几个数量级，2.4 倍的差距在大多数业务里不会是决定因素。会成为决定因素的是另一种情况：决策调用量非常大，并且业务愿意为了这部分成本去维护一个额外的供应商。

TypeSafe 自己也承认，无法证明它的定价没有补贴。一家刚融资的创业公司和一家平台公司都有动力在早期把价格压低，所以现在的价格不能当作长期价格来规划。

3.4 速度

Jev 自报延迟为 70 到 500 毫秒。主页宣称在工作流基准上比 LLM「快 193.6 倍、便宜 444.6 倍」。

Decisions API 的官方说法是比通过 Responses API 调用 Luna 快至多 10 倍。DevDay 现场报道里的演示约 150 毫秒，同一报道里普通 Luna 调用约 1.6 秒。

这些数字都来自厂商，引用之前要看清条件：

TypeSafe 的评测在自己团队的笔记本电脑上运行，地点是美国西海岸。工作流没有进训练集，但由内部团队构建。基准以 GPT-6 Astra 和 Fable 5.1 的平均值作为「正确」参考，天然偏向这两个模型。
OpenAI 的「至多 10 倍」是上限说法，150 毫秒来自演示报道，两者都不是 SLA。

两边的数字放在一起没法直接比。从结果指标上看，两者都把单次决策的延迟拉到了几百毫秒以内，进入了可以放在同步请求链路里的范围。具体快多少，只能用自己的流量去测。

3.5 生态位置

这一项最影响长期选型。

Decisions API 在 OpenAI 平台内部：同一个账号，同一套计费，同一套权限和合规流程，和 GPT-Live、Responses API 天然打通。对已经深度使用 OpenAI 的团队，接入几乎没有额外成本。

Jev 是独立供应商，它的位置是模型中立的。在级联架构里，Jev 在前面做分类和路由，后面接的前沿模型可以是任何一家。它的基准参考里用的也是 GPT-6 Astra 和 Fable 5.1 两家。对不想把决策层和生成层绑在同一个平台上的团队，这有实际意义。

反过来，独立供应商的风险也很清楚：平台方在 37 天内推出了原语同构、带多模态、价格同一量级的产品。Jev 后面的路取决于它能不能在校准质量、速度或某些垂直场景上拉开足够明显的差距。这和我们这种垂直智能体团队面对的问题几乎一模一样。

4. 将会替代了什么

4.1 LLM 里的分类调用

最先被替代的是目前塞在 LLM 提示词里的大量小判断。我们自己的系统里也有：意图识别、工单分级、输出合规检查、要不要触发某个工具，每一个都是一次完整的 LLM 调用。迁到决策模型之后有如下的变化：

成本降到原来的零头；
延迟从秒级降到几百毫秒；
结构化输出错误归零。

TypeSafe 的几个说法里，0% 类型错误是唯一很难质疑的。答案空间预先定义，模式匹配由构造保证，一个反例就能证伪。它带来的工程收益也最确定：JSON 解析、字段校验、格式错误重试这些胶水代码可以整块删掉。

4.2 传统的文本分类模型

这一块值得展开聊聊，因为很多团队手里有存量。

过去做文本分类，常见的路径是逻辑回归、GBDT，或者微调一个 BERT 类的模型。这套方案的成本主要在模型之外：

每个任务都要标注训练数据；
类别一改就要重新标注、重新训练、重新上线；
长尾类别样本少，效果差；
每个分类器都是一个要单独维护的资产，需要监控、需要定期重训。

决策模型的优势在于零样本和可编辑。类别定义是请求里的一段自然语言，加一个类别只是改一行配置。Jev 的 Choice 允许为每个选项写判定标准。下面是 decisions-api.dev 文档里的一个请求示例：

curl -X POST https://decisions-api.dev/v1/systemone \
  -H "Authorization: Bearer $DECISIONS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: support-ticket-1842" \
  -d '{
    "model": "typesafe/jev-1.13",
    "state": {
      "message": "I paid yesterday but still do not have access.",
      "account_status": "active"
    },
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this request?",
        "criteria": {
          "billing": "Payment, invoice, refund, or access after payment",
          "technical": "A product bug or service failure",
          "general": "A request that does not fit the other teams"
        }
      }
    }
  }'

注意 billing 的判定标准里写了「access after payment」。「付了钱但没权限」这种跨类别的边界情况，在传统分类器里要靠标注样本去教，这里一句话就写进了定义。业务方修改分类口径，不再需要经过一轮机器学习迭代。

但传统模型并不会全部消失，有三类场景它仍然更合适：

结构化数值特征：输入是交易金额、频次、设备指纹这类数据时，GBDT 在本地跑，亚毫秒级延迟，成本接近零，效果成熟。把它们序列化成文本发给一个远程模型，没有收益；
极高 QPS 且类别稳定：已经训练好、效果达标的本地分类器，迁移收益有限；
需要完全确定性和离线运行的环境。

所以：决策模型替代的是「非结构化文本 + 类别经常变 + 标注成本高」这一块传统分类，数值特征的风控模型不在这个范围里。

4.3 脆弱的规则引擎

很多系统里有一层用关键词和正则堆起来的规则，用来做路由和过滤。这些规则一开始好用，随着业务变化越堆越多，最后没人敢改。输入是自然语言、规则越写越脆的地方，正好是「智能 if 语句」的位置。

4.4 置信度的估算工作

以前要让分类器输出可用的概率，通常还要额外做一轮概率校准。RLCD 把这件事放进了模型训练里。但 TypeSafe 明确说明，校准是群体属性：在大量预测上，更高的置信度对应更高的准确率，但不保证任何单次回答正确。所以校准的验证工作还在，只是从「自己做校准」变成了「验证供应商的校准在自己的数据上成不成立」。

5. 吃不掉什么

能被替代的部分清楚了，剩下的部分需要我们再看看。

Jev 没有世界知识，只了解传进去的状态，无法主动查询任何信息，这一步决定了基于它构建的任何工作流的能力上限。

这句话说的是 Jev，但对 Decisions API 同样适用：它也只根据传入的上下文和候选答案做判断。由此可以推出决策模型吃不掉的几样东西。

5.1 状态的构建

模型判断得准不准，取决于传进去的状态里有没有关键事实。以上面那张工单为例：「昨天付了钱还是没有访问权限」。要判断它是计费问题还是技术故障，需要知道支付是否到账、权限同步任务有没有失败、这个用户过去是否有类似记录。这些信息分散在业务系统的各个角落，把它们在几十毫秒内取齐、裁剪、组织成一份精简的状态，是业务系统自己的工作。模型越便宜、越快，状态构建在整体效果中的占比就越大。

5.2 答案空间的定义

Choice 的选项、Score 的描述、Noul 的命题，都要由开发者来写。这些定义本质上是业务知识：

一个保险理赔流程要分几类，每类的边界在哪；
一个医疗分诊场景的紧急程度分几级，每级对应什么处理；
一个法务审查流程里，什么样的条款算高风险。

这是领域理解，通用模型不会替你决定。并且定义写得好坏直接影响效果。我们在使用的时候，先写精简的状态，再提一个具体的问题，「这条请求应该交给哪个团队」比「理解这位客户」更容易评估；每次只改一个条件，便于确认变化来自哪里。

5.3 结果数据

RLCD 用实际结果来优化概率，说明结果数据是这类模型的训练核心。对我们来说同样如此。一个决策做出之后，最终对不对：工单是否被转走了、退款是否成立、审核是否被申诉推翻。这些结果数据只存在于业务系统中。谁有闭环的结果数据，谁就能评估模型、设定阈值、发现漂移。

5.4 动作与责任

决策模型给出判断，执行由应用代码负责。权限校验、付款变更、关闭账号这类后果较大的操作，两篇资料都建议继续用确定、可审计的规则控制。阈值怎么设、出错由谁承担、怎么向客户和监管解释，这些是业务方的责任，平台方不会接。

6. 垂直智能体的位置

回到我们自己的问题：模型越来越细分，越来越快，越来越便宜，越来越垂直，垂直智能体还有没有价值。

先说下趋势。模型细分已经在发生，Jev 和 Decisions API 就是一个具体的例子：从通用对话模型中拆出了一个「只做有界决策」的形态，价格和延迟都降了一到两个数量级。可以预期，这种拆分还会继续，比如专门做提取的、专门做排序的、专门做某种模态判断的。每拆出一个形态，原来在应用层用提示词和胶水代码实现的那部分能力，就会被下沉到模型 API 里。

所以「AI 会替代其他所有能力」这个说法，我们的看法是：它会替代的是通用的认知操作，比如分类、评分、提取、生成，以及围绕这些操作的工程胶水。它替代不了的是前一节的那四样：状态、定义、结果数据、动作与责任。

垂直智能体如果主要价值在于「我们的提示词调得好」「我们写了一套 JSON 解析和重试逻辑」「我们微调了一个分类器」，那这部分价值会被快速吃掉。Jev 发布到 Decisions API GA 的 37 天，大致可以看作这类能力被平台接手的速度参考。

如果垂直智能体的价值在于下面三件事，那么模型越便宜，它的价值越大：

接入了行业里那些难接的系统；
积累了这个行业的决策定义和结果数据；
承担了执行和责任。

Jev 的名字来自经济学家杰文斯，背后的逻辑就是杰文斯悖论：决策成本越低，决策需求越会爆炸式增长。放到我们的业务里，单次决策便宜两个数量级之后，过去因为太贵而只能抽样检查、只能在关键节点判断一次的地方，现在可以每一步都判断，每一步问十个问题。决策点的数量会成倍增加，每一个新增的决策点都需要状态、定义、阈值和执行。这些工作落在垂直应用这一层。

TypeSafe 自己的处境也在印证这一点。它和平台方原语同构，在多模态上落后，价格优势只有 2.4 倍。它能否守住，取决于校准质量这类很难被快速复制的东西。对垂直智能体来说，问题是一样的：哪些东西别人 37 天内复制不了。

7. 怎么集成到现在的系统

落到工程上，我们把集成方式整理成六点。

7.1 把它放在决策层

一种常见的架构是三层级联：

决策模型以低成本完成分类和路由；
确定性代码处理能处理的部分；
前沿模型只承接少数复杂任务。

这样做的收益如下：昂贵的 LLM 调用次数下降，「机器决策」和「需要人工」之间有了清晰、可审计的边界。决策模型不做生成：对话、代码生成和推理解释都不在它的能力范围内。所以它在架构中的位置是 LLM 前面的一层，并不替换 LLM。

7.2 按动作设置阈值

不要给整个系统设置一个统一的准确率阈值，而是按每个操作的出错代价分别设置：

廉价的只读决策，在高置信度时自动执行；
高代价的决策，要求确认；
置信度低时，转给人工，或交给完整的推理模型。

这需要先给业务里的每类动作标出出错代价。这项工作没有模型能代劳，也是我们觉得最值得投入的一项。

7.3 扇出提问

两家都支持单次请求多问题，输出又免费，所以可以一次把所有可能有用的问题都问掉，再由代码决定用哪些。一次支持工单请求可以同时问：

由哪个团队处理（Choice）；
客户的不满程度（Score）；
客户是否明确要求退款（Noul）。

代码随后用普通的 if 组合这些答案。

这里的设计要点是把问题拆细。一个笼统的「这张工单该怎么处理」，不如拆成三四个各自可评估的原子问题。拆细之后，每个问题都可以单独用标注数据验证，也可以单独调整阈值。

7.4 做护栏

决策模型可以对其他模型的输出做护栏检查：生成的回复有没有承诺不该承诺的东西、有没有泄露敏感字段、是否偏离了任务。以前用一次 LLM 调用去检查另一次 LLM 调用，成本翻倍，很多团队因此只做抽检。决策模型的价格让全量检查变得可行。

7.5 抽象出决策接口

两家原语同构，业务代码就应该面向内部定义的决策接口来写：问题类型、选项定义、返回的概率结构。底层适配 Jev 或 Decisions API。这样做有三个好处：

可以在同一批样本上做 A/B 对比；
一家出现价格或可用性变化时可以切换；
文本场景走一家、语音和图像场景走另一家。

7.6 先建评估集

上线前用带标签的历史样例做评估，记录四类指标：

错误路由；
漏掉的升级；
响应延迟；
人工复核成本。

同时检查概率校准在自己的数据上是否成立：置信度 0.9 的那一批样本，实际准确率是否接近九成。两篇资料都强调，概率不等于测得的准确率，也不等于授权系统自动执行高风险动作。

另外一个工程细节：每个逻辑请求都应该带唯一的 Idempotency-Key，避免重试时重复调用模型。这是 decisions-api.dev 的接口要求，自建调用链路时也应该照做。

8. 谁需要它

按业务特征看，适合决策模型的场景有三个共同点：

决策频次高；
答案集合已知且有界；
输入主要是非结构化文本，或者在 OpenAI 的方案下包括图像和语音。

满足这三点的典型业务有：

客服与工单系统：分类、分级、路由、升级判断；
内容平台：审核、风险分级、违规类型判定；
智能体产品：下一步动作选择、工具路由、对生成结果的护栏检查；
信息提取与评分：线索评分、文档类型识别、字段是否存在的判断；
实时语音场景：通话中的意图识别和转人工判断。按目前的能力，这一项只有 Decisions API 能直接覆盖。

按企业特征看，最先受益的是 LLM 账单里分类类调用占比高的团队。如果一个团队的大部分调用都是「让 GPT 输出一个标签」，迁移的回报最快。其次是手里有一堆传统文本分类器、每次业务口径调整都要重新标注重训的团队。

按角色看，用到它的主要是三类人：

平台和后端工程师：用它替换胶水代码和规则引擎；
机器学习工程师：重新评估存量分类器哪些值得保留；
业务运营和策略人员：类别定义变成了自然语言配置，他们可以更直接地参与决策口径的调整，但也需要对定义的质量负责。

不适合的场景：

低频决策，用 LLM 和用决策模型的成本差异可以忽略；
以生成为主的业务；
答案空间开放、无法预先枚举的问题；
需要模型自己去查外部知识才能判断的问题。

9. 小结

Jev 和 Decisions API 用几乎一样的三种原语、一样的「只收输入」计费，把「有界决策」从提示词里拆了出来，变成一个独立的模型品类。从 Jev 发布到 Decisions API 正式可用只用了 37 天，这也说明了这类能力被平台接手有多快。

37 天能复制出来的叫功能，37 天复制不了的才叫护城河。

提示词技巧、JSON 胶水代码和专用文本分类器会最先被模型层吃掉。状态构建、答案空间定义、结果数据和动作责任，会因为决策变便宜而变得更重要，因为模型越便宜，喂给它的状态越值钱。

单次决策成本降下来，决策点会成倍增加，每多一个决策点，就多一份需要业务方来定义和承担的东西。模型负责回答，业务负责提问；把 if 交给模型，把后果留在代码里。

对垂直智能体团队来说，谁掌握结果数据，谁就掌握阈值；决策越便宜，问错问题的代价就越贵。

以上。