Jev 决策模型解读：Agent 里的大量判断，真的都需要大模型吗

Jev 决策模型解读：Agent 里的大量判断，真的都需要大模型吗

前言

搭过 Agent 的人对这种循环都不陌生：把当前状态喂给大模型，让它决定下一步做什么，执行，再把新状态喂回去。一个任务跑下来，模型被调用几十次，其中绝大多数调用其实不是在"写文章"，而是在做选择题——选哪个工具、点哪个按钮、要不要转人工。TypeSafe AI 推出的 Jev 把这件事挑明了：判断类调用也许根本不需要一个完整的生成模型。本文基于官方公开资料和社区实测记录，把这个模型的定位、工作方式、适用场景和边界梳理一遍。

---

一、Jev 是什么：一个只做判断的模型

Jev 是 TypeSafe AI 推出的决策模型，官方称之为 System One Models。创始人 Diogo Almeida 曾在 OpenAI 参与让语言模型更好听指令、更会与人对话的研究方向。团队开发两年后一次性发布了这个产品。

System One 这个名字本身就在传递定位。心理学里把人的思维分成两套系统：系统一快速、直觉、低成本，负责瞬间判断；系统二缓慢、审慎、高成本，负责深度推理。大模型显然是系统二的路线——每次调用都动用完整的生成能力。而 Jev 想做的是系统一：快速、便宜、输出空间有限但稳定的判断。名字里的取舍，就是这个产品的取舍。

它的使用方式可以概括成一句话：把当前局面和候选答案给它，它返回程序能直接使用的结果。本质上是一个面向决策的分类模型，而不是聊天模型。

接口有三种类型：

类型	问什么	返回什么
Choice	这句话在叫谁？下一步选哪个动作？	一个选项、各选项概率、confidence
Score	这段内容的风险处于哪个等级？	按自定义等级评分、概率分布、confidence
Noul	这条请求需要转人工吗？	"是"的概率（0 到 1），不单独返回 confidence

和通用大模型的根本差异在输出空间：Jev 只在提前定义好的标签里做选择，没有自由生成，也就没有幻觉这回事。它不会编出一个不存在的选项，也不会在选项之外自由发挥。代价同样来自这里——候选集之外的情况它处理不了，程序必须自己兜底。

---

二、一个游戏 demo 看懂它的工作方式

社区里有个网页小游戏 demo 很直观：角色在地图上拿金币、躲怪物、走到出口。每一步的工作分工是——游戏代码把局面整理成文字（血量、怪物位置、金币位置、出口位置），连同预定义的动作候选（上下左右、攻击、喝药）一起发给 Jev，Jev 返回一个动作，游戏执行，局面更新，循环往复。

Jev 是拿手柄的玩家，普通代码是游戏本身。

这个比喻抓住了它的角色定位。它不画地图、不管碰撞和渲染、不生成游戏内容，只在每个决策点选一下按键。还有一个容易被忽略的细节：它"看到"的是结构化的状态描述，不是屏幕截图——地图、伤害、碰撞全部由游戏代码处理，模型的输入是被整理过的文字和数据。这一点直接决定了它能不能用在你的系统里：只要业务状态能被清晰枚举成文字，它就接得上；状态本身难以结构化的场景，就不适合。

整局游戏一共发了 6 次真实 API 调用；第一步返回"攻击"的概率约为 95%，界面显示的 confidence 约为 93%——这两个数不是一回事，也都不是"这局能赢的概率"。

概率是"模型选这个选项的原始倾向"，confidence 是从概率分布算出来的统计量，衡量这次选择的果断程度。区分它们很重要：前者决定选什么，后者决定程序要不要加小心。演示里还有个细节值得一提：角色只剩 20 点血时模型第一手选了攻击而不是喝药，这个动作是否最优要看后续局面，不能只凭"没喝药"下结论——但它说明模型会做自己的取舍，做演示的人也不应该把结果改成自己预先想看的答案。

---

三、社区 Demo 速览：它到底能接到什么系统上

比单人 demo 更有信息量的是社区案例，尤其是 Browser Use 做的航班查询：页面先被解析成带编号的元素，Jev 负责决定"点哪个"，需要填城市名这类自由文本时才调生成模型。Browser Use 团队记录的一次查询总耗时 7.073 秒，其中 17 次 Jev 判断请求、只有 2 次文字生成调用。判断次数远多于生成次数——这就是 Agent 任务的真实调用结构，也是这类产品的切入点。

Demo	看点
DOOM	依据结构化游戏状态连续选动作；官方口径约每秒 10 次请求、约 7 美元/小时；输入是状态数据不是画面
Mario	模型选出的动作如何接到游戏循环上
Wikipedia 链接接龙	每步从页面已有链接里选下一跳，逐步走向目标词条
智能家居	一句话里同时判断设备、范围、动作，一次调用并发返回

看这类演示要守住一条线：每秒做十次决策，不等于接管了每一帧的物理和控制。渲染、碰撞、动画仍然是游戏系统的工作，Jev 只占其中"决定"这一个环节。把演示当成能力边界的说明，而不是当成"通用模型要被取代"的证据。

---

四、相对自回归大模型，优势到底在哪

先排除一个不成立的比较前提：通用大模型当然能分类，Structured Outputs 也早就能够约束输出字段和枚举值，"通用模型总要写一大段话"不能当成反方的论据。两者真正的差异在成本结构上：大模型做分类，每次都要走完整的前向计算和逐 token 解码，哪怕最终只输出一个词；Jev 把生成过程整个砍掉，只保留判断能力。

如果只是偶尔分一条工单，这点差距无所谓。真正的分水岭是调用频率：一个 Agent 任务反复判断几十次，或一个系统每天处理百万条内容时，单次多出来的延迟和费用会累积成决定性的差距。Jev 的训练就是针对这个场景收窄的：面向决策的架构、并行采样，以及官方称为 RLCD 的训练方法，重点优化判断质量和概率校准（内部实现细节以官方说明为准，公开资料不足以完整还原）。

收益有三个。

一是高频调用的经济账。厂商口径下响应约 70 到 500ms，输入价格每百万 tokens 0.042 美元，输出免费。按每次 1000 tokens 输入粗算，一百万次请求的模型费用约 42 美元——注意这是厂商口径，实际延迟受网络和负载影响，回退和配套服务成本另算。

二是并行判断省掉串行步骤。一条用户反馈要同时判业务类别、紧急程度、信息是否齐全，如果都依赖同一份输入，就没必要排队问三次——并行评分让一次调用里并发出多个判断，延迟从三次相加变成一次。

三是程序有机会识别犹豫。同样是选 A，"明显偏向 A"和"A、B 很接近"可以走不同的后续处理：补信息、换一个模型、或者把问题交给人。传统的大模型调用里，这种犹豫信息很难拿到。

---

五、四类落地场景

把这些能力放到业务里，主要有四类用法。

游戏与仿真：每秒多次决策的回合制或轻量实时操作，物理和渲染留给游戏引擎，判断交给 Jev；无人机避障模拟、跑酷类小游戏的导航操作也属于这一类。共同特征是输入可以结构化、输出是有限的动作集合。

Agent 内部的路由与护栏：选工具、定去向这类高频判断，通用大模型可能幻觉出不存在的 API 名，Jev 只会在给定列表里选，消除了类型错误和非预期调用。置信度门禁是更实际的玩法——按厂商给的思路，置信度高的直接自动执行，中等的切到大模型细想，低的转人工介入；每个工具调用前还可以做一道 Allow、Deny、Ask 的安全审查，实时输出放行、拒绝或二次确认。

高吞吐分类与工单流转：每天百万级的工单、邮件、长文档，几百毫秒内判团队和紧急程度；模糊评价拆成多个维度并发打分，比如简历筛选或合规审计里按自定义等级评分；浏览器自动化里的"点击哪个元素"也归这类。

多指令并行解析：智能家居一句话里同时判出操作对象、范围、动作，依赖的就是前面说的并行评分能力。一句话里的多个意图不必拆成多次调用。

---

六、要冷静看的地方

先说最容易被误用的点：confidence 不是准确率。要判断"模型说 0.9 的时候是不是真有九成对"，必须拿自己的业务数据做校准——看一批样本里模型给的概率和实际结果是否相符，而不是看到一个高分就直接定一条自动执行规则。厂商的概率校准能力是通用口径，你的数据分布是另一回事。

其次，输出空间收窄是双刃剑。没有幻觉的代价是灵活性：新的选项、模糊的边界情况、需要创造性处理的问题，都不在它的能力圈里。它适合"候选清楚、规则清楚"的判断，不适合开放式任务，这一点和通用模型的分工恰恰是互补的。

再次，两个成本项容易被忽略：切换时机没设计好，省下的推理时间可能被重试和恢复吃回去；每换一个场景都要大量调优的话，API 再便宜也未必真省钱。

最后，这套东西不是只有一家在做。大模型厂商的结构化输出、工具调用、低延迟模型和蒸馏都在推进，平台能力可能直接把这类需求吸收掉，开发者也会权衡接入成本，没必要多接一家供应商；另一头，任务稳定、标签固定、数据充足的场景，传统分类器和专用小模型往往更便宜、更易部署，简单任务甚至用规则就行。Jev 的位置在两者之间：需要语义理解、候选又经常变、不值得为每个判断单独训模型的场景。

---

七、前景怎么看

方向上值得看好：它瞄准的是 Agent 开发里真实存在的浪费——大量调用只为了做判断，却动用了完整的生成过程。过去调用量小、产品在验证期，没人计较；任务复杂度和用户规模上来之后，这笔账绕不过去。

更机会主义的判断是，需求未必来自"替换现有大模型"，而是来自以前因为不划算而没做的判断。判断变便宜之后，原来不敢加的检查点、不敢做的细粒度分流，现在都变得可以做。理想分工是：复杂规划交给强模型，运行中的局部判断交给轻模型，风险和新情况升级处理——难点在切换时机、上下文传递、计划失效这些边缘条件。概率信息要发挥作用，前提是业务自己的校准数据；更进一步，如果决策模型厂商能把评测、阈值选择、回退、监控一并做好，它的价值就不只是便宜，而是帮开发者把一部分判断稳定地自动化。

至于实时语音这类场景，不一定需要外接一个判断模型。全双工音频模型本身可能就解决了打断、接话的问题，只有独立判断层带来明确收益时，才值得增加一次远程调用。

调用量大不等于利润高。模型价格一直在降、迁移门槛不高，独立厂商得靠服务质量和集成能力留住客户，这个技术方向成立，商业空间还要进一步验证。

---

结语

Jev 给 Agent 开发者提供了一个新的判断依据，可迁移的决策方法可以概括成：生成类任务找大模型；判断类任务先看调用频率——低频就直接用大模型加 Structured Outputs，别多接一个依赖；高频判断在"专用小模型"和"决策模型"之间选，标签固定数据充足训小模型，候选多变、需要语义理解就试决策模型；无论选哪条路，先拿自己的数据校准置信度，再决定哪些判断可以自动执行。

判断和生成终将各归各位，Agent 的成本结构也会因此重算一遍。