特别版 · 深度解读

Jev 为什么突然火了？快速决策模型能给 Agent 带来什么

Juju Radar · 特别版 · 2026.09.20

约 6,000 字 · 阅读约 21 分钟

从答案分布、概率校准到浏览器演示，看清 Jev 的实际价值，以及“快近 200 倍”和“零幻觉”各自的适用范围。

一个浏览器 Agent 查机票，真正需要写出来的内容可能只有城市和日期。更多时候，它只是在判断：点哪个输入框，选哪条建议，页面是否已经出现结果。

如果每一个小判断都要等模型生成一段回答，等待就会沿着操作过程累积。Jev 最近受到关注，正好切中了这类任务。

TypeSafe AI 在 9 月 15 日发布 Jev 的早期访问版本，把它称为 System One Model。这个名字借用了《思考，快与慢》里的快思考概念，强调在给定信息下迅速完成范围明确的判断。它把可选答案和对应概率直接交给程序使用。发布说明

对开发者来说，值得研究的问题很具体：现有 Agent 里，有多少次模型调用，其实只需要完成一次选择？如果这些调用足够快、足够便宜，整个流程可以怎样重新安排？

本文核对了官方文档、评测说明和开源项目。9 月 21 日，我通过 Vercel AI Gateway 调用官方 Jev，完成了一次中文工单的连通性测试；它只能说明接口可用、中文输入能够返回结果，不构成性能复现。

🔎 Jev 到底返回什么？

使用 Jev，需要准备两部分输入：一份当前状态，以及针对这份状态的问题。状态可以是客户消息、检索片段、页面元素列表，也可以是包含这些内容的 JSON 对象。问题则要说明判断标准和允许的答案。接口介绍

比如，一位用户说：“上周提交的报销一直没处理，今天还发现订单扣了两次钱。”程序可能需要知道它属于哪个业务、是否紧急、是否提到重复扣款。Jev 的三种基本输出刚好对应这些需要：

• Choice：适合询问“应交给哪个处理团队”，返回所选项与各选项概率。
• Score：适合按给定标准判断程度，返回分数与各等级概率。
• Noul：适合判断一个命题是否成立，返回 0—1 之间的概率。Vercel 的接口把这一类型写作 boolean。

这些是 TypeSafe 自己的接口名称。Vercel 的集成把第三种写作 boolean，阅读不同教程时容易遇到两套叫法。TypeSafe 输出类型 · Vercel Evaluation 文档

假设程序提供“费用报销、订单支付、其他”三个选项，Choice 会在这个集合里作答。选项随请求变化，不要求每次增加一个业务分类都重新训练模型。当前单个 Choice 最多支持 255 个选项；无法覆盖所有输入时，应留出“其他”或“以上皆非”。Choice 文档

这也决定了适用边界：你先定义什么结果是有意义的，模型再判断哪一种更符合眼前信息。任意长文本、代码和解释不属于它的输出能力，当前也不直接接收图片、音频或视频。System One 文档

⚡ 快在哪里：少生成，也少等几次

Jev 的速度优势，可以从两个层面理解。

首先是输出过程。通常的生成式模型逐步生成答案，即使最后只要一个 JSON，也还在做文本生成。按 TypeSafe 的说明，Jev 不自回归地逐 token 写答案，而是针对预先给定的候选结果返回概率分布。发布说明

其次是调用安排。传统客服流程可能先判断业务类型，确认是故障后再判断严重程度。Jev 允许把这些问题放进同一次请求，提前算出可能用到的答案，再由程序选择哪些结果有效。官方把这种方式称为 speculative fan-out。并行提问模式

这对网络调用尤其有用：省下一次请求往返，有时比把单次推理再压缩一点更直接。但它有前提。如果第二个问题需要读取第一次操作之后的新页面，或者必须等外部工具返回信息，就仍然要等下一轮。并行提问能提前计算已有信息支持的分支，无法提前知道尚未发生的结果。

同样，“增加问题对响应时间影响很小”也不能理解成免费增加计算。额外的问题和候选项仍占输入 token，仍受上下文与服务容量限制。一次请求同时得到多个答案，只能说明工作被更高效地安排了。Choice 的计费说明

一位独立研究者对 Jev 做了 10,000 次黑箱调用，观察到状态只处理一次、不同问题彼此隔离、延迟主要随输入而非序列化后的输出长度变化。他据此推测，Jev 可能共享状态表示，并在每个问题末端直接读出概率。这个解释与公开接口和延迟现象相符，但因 Jev 不是开放权重模型，关于因果 Transformer、MoE 和具体读出头的描述仍是推断，不能写成官方已经公开的架构。黑箱分析

📊 RLCD 想解决的，是概率能不能拿来用

TypeSafe 把训练方法称为 RLCD，完整名称是 Reinforcement Learning for Calibrated Decisions，强调让预测概率和实际结果相符。训练目标说明

“校准”可以用一个简单例子理解：一批被模型判断为“有 80% 概率紧急”的工单，经过事后核查，理想情况下应有大约 80% 确实紧急。这里检验的是一批预测的统计表现，单条输出里的 0.8 仍可能对应一次错误判断。

这种能力影响系统怎样分配工作。如果模型很擅长判断明显案例，却能把模糊案例留出来，开发者就可以让一部分请求自动处理，把剩下的交给更强模型或人工。相反，一个经常答对、偶尔错得很自信的模型，会让自动化边界难以划定。

还要留意 probabilities 和 confidence 的区别。前者是候选结果的概率分布；后者在 Choice 和 Score 中，是根据分布形状计算的一个摘要值。Noul 没有同名置信度字段。confidence = 0.9 不等于已经证明这次判断有 90% 的正确率。置信度文档

因此，接入时不能照抄示例里的阈值就开始放行。更有用的测试是：随着阈值提高，自动处理比例下降了多少，剩下的错误又减少了多少？这个取舍要在自己的中文数据、业务规则和错误成本上观察。

公开资料目前足以解释 RLCD 想优化什么，但本文查到的发布说明与入门文档，没有给出可据此完整复现其训练的配方。对具体网络结构、参数量和训练细节，不能用一个“换掉输出层”的示意图补齐空白。

💰 “快近 200 倍、便宜数百倍”，该怎样读？

TypeSafe 首页给出了 193.6 倍速度、444.6 倍成本差距。这些是特定工作流评测的结果，厂商自己也注明，它们可能位于实际收益的较高一端。发布说明中的 70—500 毫秒延迟，同样需要连同其主要从美国西海岸测试的条件一起看。发布说明及限定

评测覆盖安全事件、Agent 运行记录、发票处理和客服四类流程。各模型回答拆分后的问题，再由代码合成业务动作；参考答案来自两个高能力模型的回答汇总，并非所有案例都有经过现实业务核查的人工真值。其他参评模型使用供应商默认推理设置。评测方法

这套实验能帮助判断：在这样的流程和参照标准下，Jev 能否以更低成本得到接近的结果。它没有证明 Jev 的所有能力都接近那些模型，也不能直接预测你现有系统的提速比例。

🧪 一项独立公开测试，补上了什么证据？

9 月 18 日，一项可复查的 BANKING77 实验让 Jev 对 3,080 条英文银行客服消息做 77 类意图分类。测试结果为 92.40%，原论文报告的微调 BERT 为 93.66%。Jev 没有为这项任务更新权重，但每次预测都拿到了类别定义和经 BM25 检索的 24 条标注样例，因此这不是零样本分类。

这项测试比厂商用强模型答案作参照的工作流评测多了一层价值：最终答案可以直接和人工数据集标签比较。它也有明显边界。研究者没有重新运行 BERT，没有设置纯检索基线，公开数据是否曾间接进入 Jev 的训练过程也无法确认；测试只覆盖英语分类，不能证明 Score、Noul 或中文任务同样可靠。

最终测试的估算 API 费用约 0.44 美元，四个并发进程用时 6 分 51 秒，单条平均 0.533 秒。这个时间包含检索、调度和网络通信，不能当成纯模型推理延迟，也不能据此断言 Jev 比本地分类器更快。BANKING77 实验与完整记录

价格更容易算清楚。截至本文核对时，官方标价为每百万输入 token 0.042 美元，输出不收费。模型与价格

按这个单价粗算：

• 100 万次调用、每次 1,000 token，总输入量为 10 亿 token，模型输入费用约 42 美元。
• 100 万次调用、每次 5,000 token，总输入量为 50 亿 token，模型输入费用约 210 美元。

这是算术估算，不是实测账单；每次的 token 应包含状态、问题和选项。浏览器、检索、文本生成、重试以及人工处理另算。

真正值得比较的单位，是完成一项合格任务的总成本。如果便宜的判断增加了后续返工，调用单价再低也未必划算。反过来，即使最终只省掉一小部分费用，只要显著减少串行等待，也可能改善用户体验。

🖱️ 七秒查机票的演示，模型实际做了什么？

Browser Use 的 jev-ultrafast 展示了一次约 7.1 秒的 Google Flights 航班搜索。计时从初次页面观察之后开始，包含后续模型调用、文本生成、浏览器操作和加载等待，没有完成订票。演示与计时说明

程序先读取并编号页面元素，Jev 选择操作与目标，执行器校验后执行；要填入的文字由另一个模型生成。默认循环读取结构化页面信息。这个例子也说明，模型判断、浏览器执行和结果验证都在贡献最终表现。

仓库的重复测试只覆盖同一任务、同一浏览器配置下的少量运行，不能推出任意网站都同样快、同样稳定。项目限制

我更看重其中的工程启发：当页面上只有一组明确可执行的动作，把这些动作交给模型选择，有机会缩短每一步等待。这项收益依赖浏览器本身能否准确读出状态，也依赖执行器能否发现页面已经变化。

🧩 “零幻觉”保证了哪一层？

TypeSafe 首页把“零幻觉”作为卖点，相关说明实际落在类型安全和输出约束上：答案来自预先定义的范围，结构符合接口要求。官方产品说明

例如，程序只允许“同意、拒绝、转人工”，模型不会突然返回一个无法解析的新动作。但它完全可能在应该拒绝时选了“同意”。结构有效、判断正确、执行结果符合预期，是三项需要分别检查的事情。TypeSafe 自己也说明，所谓 0% 只是 schema 匹配错误率，不是通过实测得到的语义错误率。发布说明中的限定

此外，限制输出格式已有其他实现路径。vLLM 的结构化输出支持指定选项、JSON Schema 和语法约束。因此，仅凭“结果可以被程序直接读取”，还不足以证明一个全新模型路线的价值。vLLM 文档

Jev 更值得比较的组合是：同等任务质量下，完成选择需要多少延迟、多少成本，返回的概率又有多可靠。评测时，应把它与配置合理的结构化输出模型、短答案模型或已有分类器放在一起。

这也回答了一个常见疑问：它是不是“又做了一遍分类器”？输出类别和概率本来就是机器学习的常见做法。Jev 的产品主张在于，把自然语言描述的判断标准、动态候选项、并行提问和校准目标放进同一套通用接口。最终能否胜出，仍要看这些能力在新任务上是否同时成立。

⚠️ 官方列出的弱点，比宣传语更有参考价值

Jev 1.13 的已知问题包括不可靠的计数和日期比较、多层转折或间接推理，以及无关长文本带来的准确率下降。官方也承认，对抗性内容和注入指令能够影响答案。这些限制意味着：金额计算、时间排序与权限校验应继续由程序完成，模型用于补足难以手写的语义判断。已知能力边界

另一个容易漏掉的细节是，不同问题的答案未必保持逻辑一致。分别询问一个命题及其否定，两个概率不保证相加为 1；同一意思改用 Noul 或 Choice，结果也可能不同。独立求值，不代表输出之间自动满足逻辑约束。需要互斥的结果宜放进一个 Choice，跨问题规则仍由代码校验。一致性限制

中文场景也不能直接套用英文演示。官方模型页明确表示，英语是主要训练语言，当前表现最好；其他语言包括中日韩文字，效果并不等同。语言支持

这对国内应用很实际。同样是客服消息，省略主语、委婉表达、行业缩写和中英混写，都值得单独留出测试集。一个中文界面能够接收请求，和它在你的中文业务里足够可靠，中间还隔着评测。

9 月 21 日的连通性测试里，我把一段中文重复扣款工单作为状态，同时询问是否已退款、主要问题类别和处理完成度。官方 Jev 返回退款概率 0.97，把问题完整归入“重复扣款”，并把处理完成度判为最高一档；整次请求使用 509 个输入 token 和 83 个输出计量 token。这个结果和题面一致，但样本是人为写出的清晰案例，只能确认中文请求和三类接口能够跑通，不能说明真实中文业务准确率。测试代码和回执保存在本地工程，没有把 API Key 写进公开材料。

🛠️ Jev 和 NanoJev：接口相似，证据需要分开

NanoJev 提供了一个可检查的开源实现：以 Qwen3-0.6B 为骨干，添加决策输出层，对状态、问题和候选项进行编码，直接得到概率。其模型卡明确说，Jev 启发了它的输入与候选集合接口。NanoJev 模型卡

它有助于理解这条路线为什么可以减少输出解码，但不能用来反推商业 Jev 的内部结构。接口行为相似，不等于网络结构、训练数据和训练方法相同。

这里也更新一下本栏目此前的笔记：NanoJev 的 9 月 20 日版本，已采用同一个检查点处理迷宫、贪吃蛇和两种 ViZDoom 任务。旧版“不同游戏分别用专门检查点”的描述，不能继续用于当前版本。项目更新记录

项目演示仍要连同外围代码理解。迷宫任务使用了共同的探索代码与已知路径记忆，模型贡献的是其中的判断。几段成功回放证明系统完成过这些任务，却不足以证明模型获得了通用规划能力；专门训练的游戏结果，也不能直接外推到客服或浏览器业务。

对想研究本地部署的人，NanoJev 的意义是开放了模型、数据和训练入口，允许进一步检查性能从哪里来。把它接进真实任务时，仍要重新评测候选项规模、输入长度和任务变化带来的影响。

🔧 放进现有 Agent，先替换哪一段？

LangChain 已提供 TypeSafeClassifier 集成，并展示了模型路由等用法；Vercel 也提供了评估接口。它们说明 Jev 已经能接进常见开发工具，但集成存在本身并不构成效果验证。LangChain 接入示例 · Vercel Evaluation 文档

Vercel AI Gateway 已提供 typesafe-ai/jev，不需要先通过 TypeSafe 官网候补名单；本地调用仍需要 Vercel 团队、Gateway Key 和账户验证。若现在开始试，可以先挑一个边界清楚、调用频繁、容易回放检查的节点：

• 用户请求分流：Jev 判断应进入哪个业务流程；程序负责类别覆盖、回退和权限检查。
• RAG 片段筛选：Jev 判断片段是否相关；程序负责检索、保留证据和生成最终回答。
• 模型路由：Jev 在给定候选中作选择；程序负责预算、失败回退和任务质量统计。
• 浏览器动作选择：Jev 选择当前允许的动作；程序负责读取页面、校验目标和确认结果。

测试可以从现有日志回放开始，保留原来的处理结果作对照。先记录错误发生在哪里，再看调用费用和延迟；尤其要检查路由错一次，是否会让后续流程走很远才发现。

我会优先观察四个指标：任务成功率、单项合格任务的总费用、用户实际等待时间，以及在不同阈值下能自动处理多少请求。测试数据还应包含信息不足、没有合适选项、输入自相矛盾的情况，不能只挑分类清楚的样本。

这一步的目标，是找到一个确实值得交给快速决策模型的环节。拿到可重复的收益之后，再扩大它在系统里的职责。

接下来值得验证什么

Jev 让我感兴趣的地方，是它让一类已经存在的需求变得更容易讨论：软件经常只缺一个语义判断，却为此调用了一整套文本生成能力。如果这个判断能够以更低延迟、更低成本完成，开发者就有机会把更多细小、频繁的判断放进流程。

接下来，我会看独立业务数据上的校准结果，中文与长输入任务的表现，以及在合理基线面前还剩下多少优势。尤其值得观察的是，高置信度错误能否被压低，模型版本变化后，原先的阈值是否仍然有效。

对团队而言，现在就能做的一件事，是回看 Agent 的调用记录：哪些地方真的需要生成文字，哪些地方只需要选项、分数或一个真假判断？先把这个问题分清楚，就更容易判断 Jev 是否适合自己的系统。

想快速核对原始材料，建议先读 Jev 1.13 已知问题，再看 评测方法 与 浏览器演示的测量边界。三者分别回答它容易错在哪里、成绩怎样计算、演示究竟完成了什么。

本文为 Juju Radar 特别版，资料更新至 2026 年 9 月 21 日。内容由 AI 辅助检索与整理；厂商测试、独立公开实验、项目演示与本文的单次连通性测试已分别标明。本文没有独立复现厂商的速度、成本或校准结论。模型、接口与开源项目更新较快，部署前请复核对应版本。