ARTICLE · 1113943
Jev 和 Laya 为什么突然火了?AI 开始给软件做判断了
大家好，我是十月七。
最近看 AI 开发者的讨论，经常能碰到 Jev 和 Laya。
这两个模型做的事有点特别：你给它一段材料，再问几个范围明确的问题，它就返回选项、评分或概率。比如工单该交给哪个部门，是否需要人工复核，某段资料和用户的问题有没有关系。程序拿到结果，就能继续往下走。
我觉得这类模型受到关注，很大程度上是因为大家开始做更长的 Agent 流程了。聊天时，回答慢一点还可以等；一个任务要连续调用模型很多次，等待和费用就会累积。更麻烦的是，某一步选错了，后面可能跟着一起错。
所以我想看看，它们究竟省掉了哪些工作，已经有人拿来做了什么，以及那些很亮眼的性能数字应该怎么读。
这篇文章用到的资料查到 2026 年 10 月 1 日，包括官方文档、模型卡、代码仓库和研究预印本。我没有亲自运行两者做性能测试，下面的数字都会注明出处。至于为什么火，是读完这些资料后的判断；星数和讨论量只能说明有人关注，实际有多少项目在生产中使用，还不能从这些资料里得出。
01一张工单里，藏着几个判断
假设用户发来一句话：
我被重复扣费了，请帮我退回多扣的钱。
收到这句话，客服系统要先知道该交给哪个部门，还可能需要判断用户是否明确要求退款、这件事有多急。Jev 和 Laya 都支持三类问题：
使用时，你得把材料、可选答案和评分标准交代清楚。模型返回判断以后，接下来做什么由程序决定。
*图 1：概念示意。自动处理的范围和阈值需要根据真实数据验证，图中没有设定通用安全阈值。*
识别出“用户要求退款”，还只是知道了用户想做什么。订单是否存在、多扣了多少钱、有没有权限、之前退过没有，都要另外检查。不能因为模型选中了“退款”，就直接把钱退回去。
TypeSafe 的指南也建议，把宽泛任务拆成具体问题，再用代码组合答案。 决策模型负责其中的判断，完整流程还是要自己设计。
02它们为什么赶上了这轮热度
一次很便宜，调用多了也要算账
假设一个任务要串行经过二十次判断，每次多等半秒，加起来就是十秒。这个例子没有测任何模型，只是算了一笔账：流程越长，单次调用的延迟越容易被放大。
邮件分类、选工具、过滤检索结果、判断异常是否需要升级，很多时候答案就落在几个选项里。两家的产品方向都是专门处理这类任务，减少生成文字、再解析文字的开销。
通用模型当然还用得上，但如果每一步都调用它，费用和等待是否值得，就要重新算。决策模型抓住的是这部分需求。
开发者想知道，哪些请求可以放心交给程序
只拿到“财务”这个标签，程序知道该往哪里送，却不知道这次判断有多确定。拿到概率分布后，就多了一种处理办法：有些请求直接分流，有些先补材料，剩下的交给人。TypeSafe 的文档也按风险和模型表现来设计这些路径。
不过，接口里的 confidence 不能直接当作实测正确率。Jev 的 Choice 和 Score 会根据概率分布计算这个字段；Noul 返回的是条件成立的概率，没有单独的 confidence。
“校准”说的是另一件事：在足够多、分布相近的预测里，模型说有 80% 概率发生的事件，应当大约有 80% 发生。它描述的是一组预测，单次答案仍然可能错。
这就让开发者有机会测量，到底能把多少请求交给程序自动处理。但概率报得准不准，还得拿自己的数据检查。
新名字、大数字，还有创始人的经历
TypeSafe 给这条路线起了一个名字：System One。它还提出 RLCD，也就是“面向校准决策的强化学习”。创始人 Diogo Almeida 的经历也很受关注，官网介绍他曾参与 RLHF 和 InstructGPT 相关工作。
“做过聊天模型的人，现在开始做供软件使用的模型”，这个故事容易被记住。官网又把速度和价格的倍数放得很醒目，传播时也很方便引用。
但往下读官方说明，会发现这些倍数来自特定工作流，可能接近实际收益的较高端。评测的参考答案来自其他强模型给出的概率，也不都是独立人工标注的真值。
这些卖点足以让人点进去看，自己用时能省多少，还得另算。
Laya 让围观的人也能上手
Jev 主要通过托管 API 使用。Laya 提供 Apache-2.0 许可的代码与权重，以及本地运行、微调和兼容 Jev 请求格式的服务接口。
这次查资料时，Laya 的 GitHub 页面显示约 2.93 万星。 星数不能说明实际使用效果，但项目开放后，大家可以下载试用，也能做部署和集成、检查基准，或者用自己的数据微调。
我觉得这也是 Laya 容易持续被讨论的原因。试用中发现问题，提交修改，做出一个新项目，又会吸引下一批人来试。
“开源版 Jev”这个叫法很省事，但容易让人误会。Laya 是独立开发的开源替代方案，两者的决策接口相近，权重、训练数据和内部架构并不能据此视为相同。
我倾向于把这轮热度看成几件事赶到了一起：Agent 开发者有需求，模型的卖点容易讲清楚，开源项目又让人能动手参与。各自贡献了多少关注度，目前没有能量化这种因果关系的研究。
03已经有人拿它们做出了什么？
我挑了三个能查到公开资料的案例。有公开代码，也有官方演示，成熟度各不相同；它们主要说明“已经能做出什么”，还不足以证明大规模生产中的效果。
浏览器找按钮，Jev 选下一步
[browser-use/jev-ultrafast](https://github.com/browser-use/jev-ultrafast) 提供了一个公开的浏览器 Agent。页面上的按钮、输入框等控件先被整理成带编号的列表，Jev 从允许的操作中选择“点击、输入、滚动”等动作，同时选择目标元素；遇到输入文字，另一个小型生成模型提供文本。
项目公开了一次约 7.1 秒的 Google Flights 搜索演示，任务到显示匹配航班为止，没有订票。仓库也明确说，这个计时从初始页面观察之后开始，少量重复测试不能当作通用可靠性基准。
这个做法让我觉得比较实用：先把页面里能操作的东西列出来，再让模型选编号。执行器还会检查页面状态和控件，模型临时编造目标的机会就少了。
后台表单、网页查询、重复筛选，也可以参考这种做法。只是上线前还要处理登录状态、页面变化，并检查任务到底完成了没有。
同样做浏览器操作，Laya 需要针对任务训练
Laya 官方仓库收录了 [laya-browser 的适配记录](https://github.com/NandhaKishorM/laya/blob/main/docs/finetune_browser_agent.md)。它面向类似的浏览器动作选择任务，用一块 16GB 显存的 GPU 做训练，并提供权重、代码和逐次结果入口。
作者测试了 16 个真实浏览器任务，每项跑 3 次。记录中的多语言骨干微调版成功率约 62%，每一步问三个问题，延迟约 17 至 23 毫秒。基础对照的成功率为 0%，微调后也仍有多项任务反复失败，其中就包括 Google Flights。
对这个案例，我更在意微调前后的差别。能下载模型是一回事，收集自己的页面和动作数据，再把它训练到能完成具体任务，是另一笔投入。
如果做的是流程比较稳定的内部网站助手，这种投入可能值得考虑。不过这只是作者的小样本实验，不能拿 62% 和 Jev 那次航班演示直接排高低。
“关掉全屋的灯”，可以一次问完几个问题
TypeSafe 官方的[智能家居演示](https://docs.typesafe.ai/demos/smart-home)把“关掉全屋的灯”拆成请求类别、作用范围、设备类型和动作等判断，并在一次请求里并行询问。代码随后挑出相关答案；复合指令和闲聊则交给生成模型处理。
家居控制面板、会议室设备助手，或者办公室的指令入口，都可以参考这个设计。模型认出了设备和动作，控制系统还要检查权限、设备是否存在，以及执行有没有成功。
这里还要说明一下：文档仍写着完整源代码将在发布时提供。我目前只能把它列为官方演示，无法确认完整项目已经可以下载运行。
这几个项目都有一个相似的做法：先整理允许的动作和目标，再让模型从里面选。想上手的话，可以先照这个范围做一个小项目，每一步出了什么问题也比较容易查。
04托管服务和本地模型，怎么选
*图 2：基于官方资料的选型摘要。速度数字来自各自条件下的公开测量，不能视为同机比赛。*
表中 Jev 的限制与价格来自官方模型页及 API 文档；Laya 的实现与配置来自模型卡、项目页和基准说明。
选 Jev，主要是接一个托管服务；选 Laya，得自己维护模型，但也能自己改。
Jev 起步更直接。Laya 留给你的控制更多，维护工作也更多。调用量有多大，数据能不能出本地，有没有可用硬件，团队愿不愿意花时间适配，这些会比一张性能榜更影响选择。
05有些数字，得连着测试条件一起看
延迟是在本地测的，还是远程调用测的
Laya 的基准文档报告，在 Tesla T4 上，单问题延迟为英文版约 39.5 毫秒、多语言版约 32.8 毫秒。
Jev 发布文章给出的端到端范围是 70 至 500 毫秒，也说明了测量地点与服务部署地点的关系。
本地推理和远程 API 调用算进去的开销不同，输入多长、一次问几个问题、有没有冷启动、并发和网络距离，也都会影响结果。把这两组数字放在一起，能看出它们为什么引人注意，却还不能判断谁在你的产品里更快。
评估时最好看完整请求的 P50 和 P95：前者代表典型等待时间，后者帮助观察较慢的那批请求。
76.6% 的 Laya，和刚下载的基础版有区别
Laya 官方基准页列出了 typed-decisions 的 2,000 次决策结果：英文基础版准确率 36.2%，专门微调的检查点 76.6%，多数类基线 46.1%。 同样叫 Laya，换一个检查点，成绩会差很多。
这些是作者报告，本文未复现。基准页还说明，76.6% 这一行尚未附上已提交的结果文件。
所以看到“Laya 超过 Jev”，我会先找它用的是哪个检查点，有没有微调，是否比较了同一批样本，参考答案又是谁给的。
如果做项目时要花时间标注和训练，这部分投入也得算进去。最后省下的费用和人工，是否能抵得上这些工作？
把一个问题拆成两层，结果也可能变化
9 月 27 日发布的研究预印本《Do System One Decisions Add Up?》比较了 Jev 1.13.0 和固定的 Laya 英文检查点。
研究使用三组分类数据。下面只展示其中 CLINC150 的 1,000 个样本：
*图 3：根据该预印本表 4 重绘。两种方式使用相同样本；第二种综合全部大类分支的概率，并非只走最大概率大类。变化的配对 95% bootstrap 区间分别为 Jev −24.9 至 −20.9、Laya +18.0 至 +24.5 个百分点。*
这项研究尚属预印本，测试的是特定英文检查点和较多候选标签；Laya 的 token 预算也经过扩展。它不能代表所有版本和使用场景。
这个结果让我对“先分大类再分小类”更谨慎了一点。提问方式、候选集合和组合逻辑都能改变模型表现，拆分后的完整流程也要测，不能只凭感觉认为它会更好。
06选项合法，也可能选错
看到“零幻觉”这个说法，可以先看它具体保证了什么。输出限制在固定选项里，模型就没有机会随意编出第八个部门，也无需通过自由文本表达结果。
不过，它仍然可能把财务问题选成技术问题。返回值符合格式，和这次判断是否正确，得分开检查。
Jev 官方列出的已知弱点包括精确计算、日期比较、多层间接推理、夹杂无关信息的长上下文，以及对抗性内容。算术和日期顺序，官方建议交给代码处理。
Laya 的模型卡也提醒，发布的检查点存在过度自信，需要在目标领域拟合校准参数；英文检查点不应直接承担非英语任务。
还有一篇 9 月 27 日的安全决策研究预印本：它发现，整体表现和平均校准指标可以掩盖某些攻击类型上的高置信度错误。在严格限制漏检的情况下，自动放行的范围可能很小；验证阶段满足要求的阈值，在新输入上仍可能超出错误预算。
概率有没有帮上忙，得看后面的处理结果。如果想用它减少人工，就要记录自动处理了多少，其中错了多少，还有多少请求需要复核。平均准确率再好看，也不能替你回答这些问题。
07从一个小节点开始试
按目前的资料，如果想尽快接入，又允许数据进入外部服务，可以先试 Jev。输入较长、候选比较多，或者暂时不想维护本地模型，也可以从它开始。
如果希望自己部署，有反复出现的分类任务，也能收集标注数据并做微调和校准，Laya 值得试。只是版本和服务都要自己维护。
写作、开放式解释、复杂规划，或者需要多步推理的任务，还是继续用通用模型。这两个项目主要做快速、范围明确的判断。 最终选谁，最好让它们在同一批业务数据上跑一遍。
我的建议是，先挑一个小节点做。
比如“这条留言该交给哪个处理队列”，先准备一批真实样本，保留“其他”和“信息不足”等出口，再做三种比较：现有规则、通用模型、决策模型。
用一部分数据调整问题和阈值，把另一部分留作最终测试。中文、中英混杂、长输入、模糊表达和少数类别，都应覆盖。比较准确率、错误类型、端到端延迟，以及包含维护和人工复核的总成本。
如果一个简单规则已经解决大部分问题，就保留它。模型值得承担的，是规则难以稳定覆盖、又有足够材料做判断的部分。
做到这里，流程里的分工也就比较清楚了：确定性的检查用代码，范围明确的语义判断可以试决策模型，需要规划和表达的部分用通用模型。材料不足就补材料，必要时交给人复核。每一步都能单独测量，出了问题也能单独替换或改进。
我对 Jev 和 Laya 的期待，暂时就落在这些小项目上。一个留言分流节点也好，一个网页助手也好，跑一段时间，看看错了多少、等了多久、究竟省了多少人工。托管和开源提供了不同选择，热度能不能持续，要看这些账最后算不算得过来。