别再让大模型做分诊员了
Jev 是 TypeSafe AI 发布的 System One 决策模型。它不生成文本，只输出结构化概率判断。这篇讲清它是什么、快在哪、便宜在哪，以及它换不回的那 6 个百分点。
快 193 倍，便宜 444 倍——但准确率低了 6 个点：一篇吃透 Jev
你有没有过这种体验：一条工单进来，系统先调一次大模型做意图识别，等一两秒，返回一段 JSON，前面还贴心补了句“当然可以，以下是结果：”，然后你的解析器再默默把那段客套话剥掉、校验、重试。
高峰期每条请求都这么走一遍，延迟、费用、重试逻辑和解析兜底就开始排队领号。
更扎心的是：你花大价钱买的旗舰模型，在这一层干的其实是“活体 if-else”。
Jev 处理的就是这一层。下面把它拆开讲清楚，包括它换不回的东西。
01 Jev 是什么：公司里的“分诊员”
一句话定义： Jev 是 TypeSafe AI 发布的 System One 决策模型——输入一段待判断材料（官方叫 state）和预定义问题，输出可直接被程序使用的结构化概率判断，但不生成自由文本。
这里的 System One，借用了《思考，快与慢》里的“系统 1”：快速、直觉、低消耗的判断。和它对应的“系统 2”，才是我们熟悉的慢思考、长推理、会写长篇解释的生成式大模型。
你可以把它理解成公司里的两类同事：
它不参加“谁更会聊天”这场比赛，而是把应用里那些本来只能靠 if-else、规则引擎，或者硬塞给大模型的离散判断，单独抽成一层原生能力。
不是所有 AI 调用都需要一张会说话的嘴。很多时候，你需要的只是一双能快速举牌的手。
02 三种原语：把“判断”拆成三个最常用动作
Jev 把问题类型称为 primitives，说白了就是它只擅长的三种基础动作。
noul 这个名字有点怪，它来自 Bernoulli（伯努利试验），官方就是这么拼的，不是笔误。通过 Vercel AI SDK 调用的话，它会被列成 boolean。
这里有个容易踩的坑：0.5 不是“中等风险”，而是“是和否差不多各一半”。想问“风险有多严重”该用 score，问“是不是风险”才用 noul。这两个原语返回的东西不一样，混用会让你把一个犹豫的答案当成一个确定的分数。
同一份 state 上可以一次挂一堆问题，每个问题独立评估、并行完成，响应时间几乎不动。而且问题之间不会互相污染，不像长对话上下文里，后面的判断会被前面的信息带偏。
03 为什么它又快又省：换题，而不是加速
过去我们用生成式模型“模拟分类器”——开 Structured Output、做 Function Calling，本质是“让它先写字符串，再把字符串变回程序能用的东西”。哪怕你最后只想要一个 true，自回归模型也得一个 Token 接一个 Token 地往后写。
Jev 的思路是换题：它不问“请写出答案”，而是问“这几个答案里，哪个最像当前状态？”技术形态上是一次前向计算，停在候选评分阶段，不逐 Token 生成。
输入按每百万 token 0.042 美元计费，输出不计费。这不是折扣，是架构决定的：模型不逐 Token 生成，就没有输出 Token 产生。官方没有承诺这个定价长期不变，架构上还是得给价格变化留出应对空间。
训练方式是 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习）。它优化的不是句子漂不漂亮，而是概率是否贴近真实正确率——模型说“置信度 80%”的一批样本里，理想状态约 80% 是对的。
RLHF 奖励的是“人类更喜欢哪个回答”，RLCD 奖励的是“概率和实际正确率对不对得上”。
你可能会觉得这只是“但校准不是也说了嘛，不就是个体统计性质”。问题在于，它耦合在厂商自己的概率分布上——你辛苦调好的阈值，可能在模型版本一升级时就漂了。这是引入 System One 模型要付的隐性成本：架构上必须预留价格和分布变化的应对方案。
它带来的好处是，“模型判断”终于更像一个正常的软件接口了。以前调 LLM 拿到的是需要解释的文本，现在拿到的是能直接进程序分支的值。
04 数字：这才是你该看的部分
只讲“快 193 倍、便宜 444 倍”是耍流氓。TypeSafe 官方的说法是 40–200 倍更快、40–400 倍更便宜，峰值数字（193.6 倍 / 444.6 倍）来自它自己搭的四个工作流评测，参照对象是 GPT-6 Astra 和 Fable 5.1 的平均答案。
真正该看的是同一张表里的准确率那一列。下面这组数据来自 TypeSafe 官方发布的四工作流评测，由 DataCamp 整理转述：
数据来源：TypeSafe 自建四工作流评测（安全事件响应、Agent 轨迹可观测性、发票处理、客服），参考答案取 GPT-6 Astra 与 Fable 5.1 的平均预测。厂商自报，尚无独立复现。
这张表要读出三件事：
-
它赢在中位档，不在最强档。Jev 和 GPT-5.6 Terra 的 67.8% / 67.9% 基本打平，但比 Sol（74.1%）和 Opus 5（73.1%）低了 5–6 个点。要的是峰值精度、量又不大，LLM 仍然赢。
-
但对着打平的那个模型算，成本是 1/76，速度是 25 倍。相比最贵的 Opus 5，成本差是 1/440。这种换算在高频、重复、选项封闭的场景里非常划算；换成一次性、开放式的任务，错了代价又高，就完全不划算了。
-
它真正杀死的东西不是准确率，是解析层的脆弱。在结构化输出和工具调用可靠性上，Jev 的错误率是 0%（schema 提前固定，类型错误被官方称为“数学上不可能”）。作为对照：Claude Haiku 4.5 的结构化输出错误率是 45.5%，GPT-5.6 Sol 的工具调用错误率是 17.0%。
第 3 条才是关键。回到开头那个场景：你之所以要写解析器、写正则、写“模型又给我包了一层 Markdown 围栏”的兜底、还要准备重试，是因为你用的模型可能会吐出 schema 之外的东西。Jev 把这一整层工程彻底删掉了。省掉解析层的价值，很多时候比提几个点准确率更值钱。
同一份评测里的另一面：Jev 便宜、快，但准确率不是最高的
05 在 Agent 里怎么用：十类场景
生成、规划、硬核推理交给 LLM，重复的、选项封闭的判断扔进更便宜的决策层。这么一拆，Agent 就从“从头到脚全是 LLM”变成混合系统：快模型负责反射，慢模型负责规划。
按“理论上最赚”排序：
① 实时循环（游戏 / 机器人 / 交互控制）
收益天花板最高，LLM 慢到没资格上场。Jev 待在控制循环里，LLM 规划器从外面掌舵。TypeSafe 的 Doom demo 跑到约每秒 10 次查询、约 7 美元/小时。
② 浏览器 / 电脑操作的动作选择
每一步都问“接下来干啥”最烧钱。把页面索引化，一次请求同时决定操作和目标，只有真正要生成文本时才叫醒大模型。
③ 工具风险闸门
自主 Agent 执行前加一道策略检查（这命令会删东西吗？在偷数据吗？）。类型合法不等于决策正确，应该按置信度决定执行 / 确认 / 拦截。社区项目 pi-warden 用约 250ms 判断一条 bash / write / edit 是否不可逆或偏离任务。
④ 模型路由（最建议的起步场景）
Agent 常把前沿模型的 token 浪费在不需要前沿推理的活上。把 Jev 放在模型舰队前做显式中间件，日常给快模型，硬骨头送前沿模型。位置干净、收益易算、翻车损失小。LangChain 已经把它做成了 ModelRouterMiddleware。
⑤ 目标达成与卡死检查
“目标达成了吗 / 卡住了吗”本是教科书级的 noul，今天却可能花掉一整次 LLM 调用。亚秒级决策能让这个检查每一步都跑。社区的 ProgressGate 就是干这个的。
⑥ 上下文压缩
多数编码 Agent 用 LLM 总结旧轮次，天生有损。Jev 的路线是给旧工具调用打分，该留留、该截截、过期直接扔，用户和助手的文本原样保留。删除通常比重写更保真。
⑦ 技能与工具选择
每次把全部工具说明塞进 prompt 是纯浪费。让 Jev 先挑出本次要用的几个，动作面小了，选错概率也小。TypeSafe 的 cookbook 里，从 182 个技能里挑至多 1 个只用了 2 次请求。
⑧ 输出与轨迹护栏
用 noul 判“偏离目标了吗 / 有不该出现的东西吗”，单次成本低到每步都可跑。护栏得便宜到无处不在，才真正管用。
⑨ 工单与邮件分流
典型封闭判断，要的是吞吐不要前沿推理。一次调用塞十个问题独立评估，量大的地方省真金白银。
⑩ RAG 重排
重排说到底是打分，score 就是为打分准备的。检索回 50 个候选逐个判相关，换 score 单次可忽略，还能多召回再重排、抬升召回上限。TypeSafe 的 CLERC 法律查询重排 cookbook：top-1 从 5% 提到 18%，top-10 从 38% 提到 62%。
06 边界与避坑：它不该坐的位置
Jev 有价值是真的，有边界也是真的。而工程上最怕的往往不是新技术不够强，是把它放到了不该坐的位置上。
6.1 它不擅长的事
-
不产生自由文本，也不会解释自己。 “该升级”可以，“为什么升级”得交给生成模型。这在受监管行业是硬伤——合规团队要是需要知道一笔贷款为什么被打了那个分，一个光秃秃的置信度数字满足不了他们。
-
官方明确列出的弱项： 算术、日期计算、干扰项（distractors）、对抗性输入。指望它算数或者判日期，请用确定性代码。
-
不擅长多步因果推理。 多层伪装的钓鱼邮件，支持思维链的推理模型更好。
-
候选项并非完全独立打分。 选项描述写得含糊，边缘 case 就会被硬塞进一个错误标签里。
-
单字段基数上限 255。 据第三方评测站的说法，超过这个数 TypeSafe 会改走一条两阶段路径（先独立打分，再显式选择），延迟会明显上去。一个字段有几百上千个选项，本来就该先做分层，这也正好是官方文档的建议。
-
上下文窗口 64k，state + 最长问题各限 32k。 这一项来自第三方评测整理，未在官方文档中直接核到，落地前建议自己实测。所以它不是为长文档设计的。
-
仅支持文本。 图片、音频、视频都不行，文档流程得先 OCR 转成文本。
-
中文 / CJK 校准效果没有公开数据。 官方没发布过中文场景的校准曲线，别假定它在中文业务上天然可靠。务必先用自己的数据跑小批量验证阈值，这是最容易翻车的地方。
-
架构、权重、参数量、技术论文均未公开。 截至目前也没有独立第三方基准。你在为一家公司的判断质量本身买单，而不是一个可复现的架构。
-
“不能幻觉”这句话要窄读。 模型有两种失败方式：一是产出一个不在合法输出集合里的值，二是产出一个合法但错误的值。Jev 彻底消灭了第一种，这对工程稳定性意义巨大；但对第二种，它只承诺会告诉你自己有多不确定。格式错误清零，正确率不为零，这两件事别混成一件。
6.2 安全铁律（建议直接贴进需求文档）
模型能做护栏，但不该成为悬崖边唯一那根护栏。任何单一模型都不该成为唯一防线，真正的安全边界仍在业务规则——allowlist、路径校验、沙箱、审批流。Jev 可以把可疑动作挑出来供策略层决定升级，不能成为“模型说没问题就执行”的唯一依据。
好比机场安检：闸机和行李扫描是硬规则，人工安检员负责处理那些看着不对劲的边缘情况。不能反过来只靠安检员直觉开闸。
6.3 这些时候先别上
- 要写文章 / 代码 / 话术
- 输入主要是多模态
- 任务需要两步以上的因果推理
- 候选标签经常大改（先用 LLM 探索，标签稳定了再下沉）
- 单字段上千个选项
- 中文为主却还没有测试集
- 风险极高且没有任何兜底
07 怎么落地：从分诊台开始
最好的起点不是重构整个 Agent 平台，而是挑一个现在已经在用 LLM 输出固定字段、调用量又高的环节做影子测试（shadow mode）：真实流量照跑，Jev 的判断只记录不生效，然后拿它和现有 LLM 的结果对比一段时间。
集成顺序上，从边界最干净的模型路由起步，再按需扩展到其余九类。
架构上就是分层：Jev 做快速前置筛选，复杂生成与推理交给大模型。Jev 在前面举牌，LLM 在后面掌舵。
置信度分三档处理：
- 高置信度 → 自动执行
- 中置信度 → 谨慎推进，用户确认或标记复核
- 低置信度 → 不执行，转人工或升级到更强推理模型
阈线画在哪儿取决于你这事翻车的代价：显示错页面容易恢复，批错一笔付款不。阈值一定先要在你自己的业务数据、自己的语言、自己的风险等级上验证过再用，别直接抄别人的 0.8。
有个社区实践挺能说明问题：jev-auto-approve 这个 Claude Code hook 只在 p ≥ 0.95 时才自动放行，它公布在校准数据里的结果是——8 个会改变状态的命令里，自动放行了 0 个。
落地方向推荐这几个：内容审核 / 提示注入预筛、工具风险闸门、长文档多维标签提取（在同一份访谈文本上挂 noul / choice / score 三种原语，后端规则组合评分进业务系统）。
提示注入预筛的效果值得单说：在 TypeSafe 的 RAG 章节 cookbook 里，余弦相似度把一条植入的注入指令排在了第一位、得分 0.584；Jev 给它打了 0.99，然后把它丢了。
08 最后
开头那个场景，工单等一两秒、JSON 前补一句客套话——本质是我们拿跑车去送快递。Jev 想做的，是把“举牌”这件事交还给一双专门的手。
两条原则请记住：快模型反射 + 慢模型规划，置信度路由 + 业务规则兜底。
它不是“更好的模型”，是一层新的、便宜的、专门做判断的模型。方向可信，具体倍数还没人独立验证过，5–6 个百分点的准确率差距也是真实存在的。倍数存疑，差距真实，这两个词的权重你自己掂量。
最后想抛一个问题给大家讨论：
你们现在的系统里，还有哪个环节是“用旗舰模型在做活体 if-else”的？
评论区聊聊，我很想看看大家踩过哪些坑。
说明： 文中所有性能与价格数据均来自 TypeSafe 官方发布及其公开的四工作流评测，截至 2026 年 9 月，厂商自报、尚无独立第三方复现。TypeSafe 自己也承认工作流由内部团队编写、可能存在偏差，并称这些倍数大概位于真实收益区间的上沿。API 端点为
POST api.typesafe.ai/v1/systemone，模型别名jev-latest，当前解析到jev-1.13.0。速率限制约 25 万 token/秒、1200 请求/分钟的说法流传于开发者报道，用前请以自己账户为准。
觉得有用？点个「推荐」，我会持续更新这类决策层的实操拆解。
如果这篇文章对你有帮助，欢迎转发给正在纠结「该不该换模型」的朋友。
浙公网安备 33010602011771号