Jev 到底是什么：一个只做判断的决策模型，以及它能插进 Agent 的哪些位置

最近 TypeSafe AI 推出的 Jev 讨论度很高。Reddit 上有人拿它玩 DOOM，也有人让它跑 Mario。我申请到 API Key 之后，自己写了一个网页小游戏，想弄清楚它究竟在系统里承担什么角色。

最初的疑问很直接：同样是用 AI 操作游戏，为什么非要用 Jev，GPT 不行吗？GPT 当然可以。但做完这个 demo、又翻了一圈资料之后，我认为真正值得讨论的是另一个问题——我们搭 Agent 时，习惯让一个通用大模型反复决定下一步，可这些环节里，究竟有多少真的需要完整的生成与推理能力？

Jev 是什么

Jev 是 TypeSafe AI 在 9 月发布的决策模型，创始人是 Diogo Almeida，他此前在 OpenAI 参与过让语言模型更善于理解指令、与人对话的研究。TypeSafe 低调开发了两年，才推出这个官方称为 System One Models 的模型。

它的用法可以简单理解为：把当前状况和问题交给它，它返回程序能直接使用的结果。本质上就是一个分类模型。

接口主要分三类：

放到游戏场景里，就是每一步都问它：我现在有多少血，怪物和金币在哪，出口在哪，目标是拿到金币并活着出去，这一步该按哪个键？候选动作提前定好——上、下、左、右、攻击、喝药。Jev 返回其中一个，游戏执行，再把新局面发回去。这个模型的好处在于没有幻觉，它严格按事先约定的输出标签来选。

视频里每一步都故意多停了几秒，方便看清右侧三块内容：它看到了什么、选了哪个动作、执行后发生了什么。停留只是演示需要，不代表模型响应时间。

那一局里，Jev 先攻击挡路的怪物，再向右移动，拿到金币，最后抵达出口，一共 6 次真实 API 调用。第一步返回「攻击」的概率约 95%，界面上的置信度约 93%。这是两个不同的数，也都不是「这局赢面有多大」。

这段视频能说明的是：模型的选择确实在驱动游戏，响应速度也足以支撑这种回合制交互。它不能说明 Jev 比 GPT 更会玩。我们已经搭好了相同地图、相同规则的对比版本，但双模型实测尚未有效完成，所以这里不给胜负和性能结论。

还有一次低血量测试值得一提：角色只剩 20 点血时，Jev 第一手选了攻击，怪物反击后剩 5 点血。这一手是否最优，要看后续局面，不能因为「它没喝药」就下判断。它至少说明，模型会作出自己的取舍，演示不该把结果改成我们预先想看的答案。

这里最容易记住的一句话是：Jev 是拿手柄的玩家，普通代码是游戏本身。 它不负责画地图，也不负责生成整个游戏，我们也没有给勇者写一条自动通关路线。代码把局面整理成文字和数据，再把模型选出的动作交给游戏引擎执行。它看到的是状态描述，不是屏幕截图。

一个更直观的分工例子

Browser Use 做的航班查询例子，把「判断」和「生成」分得很清楚。页面先被整理成带编号的元素，由 Jev 决定操作什么、点哪个目标；需要填写城市名称时，再调用生成模型产出文字。

作者记录的一次查询用了 7.073 秒，其中包含 17 次 Jev 请求、2 次文字生成调用。初始打开网页和最后的独立结果校验不计入这个时间。这是一次具体任务的记录，没有购票，也不能推广成「所有浏览器任务都能七秒完成」。

这个例子有意思的地方在于：整趟操作里，选择下一步的次数明显多于写文字的次数。它展示了一种可以真正搭出来的分工。

社区里还有几个例子可以参考：DOOM、Mario（均有社区视频）、Wikipedia 链接接龙（官方演示）、智能家居（示例与演示）。

看游戏演示时还要记住一个区别：每秒做十次决策，不等于接管每一帧的物理与控制。渲染、碰撞、动画、执行仍然属于游戏系统的工作。

为什么要专门做一个 Jev

现在的自回归大模型当然也能分类，也能只返回一个动作。Structured Outputs 已经可以约束输出字段和枚举值，所以不能拿「通用模型总要写一大段话」当作比较前提。

真正的区别要放到调用频率和整体场景里看。偶尔分一条工单，多花几百毫秒没什么感觉；但一个 Agent 系统要反复判断几十次，或者一个系统每天要处理百万条内容，单次多出的时间和钱就会累积起来。

Jev 正是基于这个假设收窄了训练任务。按 TypeSafe 的说法，它采用面向决策的架构、并行采样，以及名为 RLCD 的训练方法，重点优化判断与概率校准。公开资料足以让我们理解方向，但还不足以完整还原模型内部实现。

综合来看，收益可能来自三个方向。

一是更适合反复调用的线上场景。 官方公布的响应范围约 70—500ms，输入价格每百万 tokens 0.042 美元，输出免费。这是厂商口径，实际延迟受网络、输入和负载影响。按每次总输入 1,000 tokens 粗算，一百万次请求的模型费用约 42 美元，其他服务与回退成本另算。

二是减少不必要的串行步骤。 比如收到一条反馈，可以同时判断业务类别、紧急程度和信息是否齐全，再由代码组合结果。它们如果只依赖同一份输入，就不必排队问三次。官方的智能家居例子也是这个思路：一次判断设备、范围和动作，再挑出相关结果执行。

三是让程序有机会识别犹豫。 同样是选 A，「明显偏向 A」和「A、B 很接近」可以有不同的后续处理：补充信息、换一个模型，或者把问题交给人。

这里有个容易混淆的细节：confidence 是从答案概率分布算出的统计量，不是「这次一定有多大概率正确」。视频里攻击概率约 95%、confidence 约 93%，两者都不是通关概率。

如果要用它决定是否自动执行，得先用自己的数据检验。所谓概率校准，是看一批样本中模型给出的概率与实际结果是否吻合，不能看到一个 0.9 就替业务定下通用的自动执行规则。

主要的四类应用场景

回合制或轻量实时操作。 在需要每秒多次决策、但物理与渲染交给游戏引擎的场景里，让大模型逐字生成回答成本极高、延迟也不可接受。游戏把当前地图状态、血量、敌我距离整理成结构化文本发给 Jev，Jev 在预设动作（上/下/左/右/攻击/喝药）中瞬间挑出最合适的操作。无人机避障模拟、跑酷小游戏（如 Subway Surfers）这类高频输入传感器或状态数据、输出导航操作的场景也属于这一类。

动态工具选择（Tool Selection）。 复杂 Agent 工作流里最容易出故障、又最高频的往往不是「写一整段话」，而是「选哪个工具」或「判断下一步去哪」。传统 LLM 可能幻觉出不存在的 API 名称，而 Jev 只在给定的有效 API 列表里选择，消除了类型错误和非预期调用。

置信度门禁（Confidence-Gated Fallback）。 利用经过校准的置信度评分做分流：高于 90% 直接自动执行代码，60%~90% 切换通用大模型进一步思考，低于 60% 转人工介入。

安全护栏（Agent Guardrails）。 对每一次工具调用做安全审查，实时输出 Allow（允许）、Deny（拒绝）或 Ask（二次确认）。

客服与工单自动分流。 对每天要处理百万级工单、邮件或长文档的业务系统来说，每一步都调用通用生成大模型，成本和推理时间都不可承受。根据用户反馈文本，在几百毫秒内判断「负责团队」（如账单/技术/销售）与「紧急程度」。

复合维度评估（Composite Scoring）。 把模糊评价拆成多个独立维度，例如 HR 简历筛选或合规审计中，一次性并发对候选人各项指标按自定义等级（如 1—5 分）做概率打分。

浏览器自动化与网页接龙。 生成模型负责提取文字，Jev 专门根据页面已有元素编号，连续快速决定「点击哪个元素」或「选择哪个链接」。

我的判断

如果直接问我怎么看，我偏乐观。它抓住了 Agent 开发里一个常见问题：很多调用只是为了做一个判断，却动用了完整的文本生成过程。过去调用量小、产品还在验证阶段，大家不太计较；等一个任务需要几十次模型调用、同时服务大量用户时，延迟和成本就很难忽略了。

因此，在需要快速理解语义、再作出有限选择的任务上，这个方向值得长期做。至于 Jev 能否成为这个方向的主要选择，现在下结论还早。

我认为 Jev 最容易切入的机会，是替换 Agent 里那些高频、边界清楚的调用，比如选工具、筛选检索结果、判断下一步操作、决定是否升级到更强模型——这些任务需要语义理解，但输出空间很小，只要效果接近，开发者自然会选更快更便宜的方案。

更重要的是，成本与延迟降下来之后，以前因为不划算而没做的判断，现在可能变得值得做。

复杂部分仍靠强模型规划，运行中的局部判断尽量交给轻模型，遇到新情况或高风险再升级处理。难点在切换时机、上下文传递、计划失效这些边缘条件，处理不好，省下的推理时间可能被重试和恢复抵消。

概率信息在这里很重要，但前提是业务校准。我们需要知道在什么错误率下，哪些任务可以稳定交给快模型，而不只是看平均准确率。

Jev 有机会做的不只是便宜推理，还包括评测、阈值选择、回退与监控。如果这些能力足够好，它的价值就不只是低成本，而是帮开发者把一部分判断稳定地自动化。

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

竞争压力来自两边。一边是大模型厂商，结构化输出、工具调用、低延迟模型和蒸馏都在推进，大厂只要在核心任务上做到够好够便宜，靠平台和服务能力留住客户，Jev 的空间就会被挤压；开发者也会考虑接入成本，没必要多接一家供应商。另一边是传统分类器和专用小模型，如果任务稳定、标签固定、数据充足，专用模型往往更便宜、更易部署，简单任务甚至用规则就行。

所以 Jev 比较有吸引力的位置，是在这两者之间：任务需要通用语义理解，规则和候选变化频繁，开发者又不愿为每个小判断单独训练模型。这个市场不小，尤其是在企业流程、研发工具和交互应用里。但长期看，能否持续做到「好用、稳妥、迁移成本低」，比单次推理便宜更关键。如果每换一个场景都要大量调优和修错，API 再便宜也未必真省钱。

最后，调用量大并不等于利润高。只要模型价格持续下降、迁移门槛低，Jev 还得靠服务质量和集成能力留住客户。技术方向成立，独立公司的商业空间仍需进一步验证。

补充一点：社区里已经有人用 Jev 实现了对话，见 jevchat。

不知道大家什么感受——这好像又回到了 Language model 最初的样子。