摘要： TypeSafe AI 推出的 Jev 决策模型，最为什么能控制 DOOM，又能用于浏览器自动化？与 GPT、Claude、DeepSeek 等通用大模型有什么不同？本文结合开源项目与独立评测，分析 Jev 的工作原理、模型分工方式，以及它在 AI Agent、自动化测试、测试失败分类和工具调用中的应用价值。
一、一个只会做选择的 AI，为什么能玩 DOOM？
最近，AI 开发者社区出现了一个比较特别的模型：Jev。
有人用它控制《DOOM》，有人让它玩《超级马里奥》，还有开发者把它接入浏览器，让 AI 自动完成航班查询。
这些演示有一个共同点：模型不需要每一步都生成一段完整的回答，而是根据当前状态，直接决定下一步做什么。
以 DOOM 为例。
游戏程序先提取角色位置、生命值、敌人距离等信息，再交给 Jev 判断下一步应该移动、攻击还是躲避。
模型返回一个动作，游戏引擎负责执行，再把新的状态发送给模型。
整个过程不断循环。
根据 TypeSafe AI 的公开演示，Jev 可以支持约每秒 10 次决策，按演示时的调用情况估算，模型费用约为每小时 7 美元。
这里的决策频率不等于游戏帧率。画面渲染、碰撞检测、伤害计算和角色移动，仍然由游戏程序完成。
Jev 只负责选择动作。
这种模式放到 AI Agent 里，同样成立。
一个 Agent 在执行任务时，既需要复杂的语义理解和任务规划，也会遇到大量重复性的选择：
下一步调用哪个工具？
当前页面应该点击哪个元素？
执行失败后继续、重试还是回退？
当前操作是否需要人工确认？
这些任务需要一定的语义理解，但输出往往只有几个明确的选项。
如果每一步都调用通用大模型，随着执行链路变长，响应时间和模型成本就可能不断累积。
把复杂推理与高频决策拆开，是 Jev 这类模型提供的一种解决思路。
AI Agent 可以采用单一通用大模型处理整条任务链，也可以将任务规划、高频决策、工具执行和结果验证分配给不同组件。分层设计能否提高效率，需要结合真实任务验证。
二、Jev 到底是什么？和通用大模型有什么区别？
2026 年 9 月 15 日，TypeSafe AI 正式发布 Jev，将其定义为首个 System One Model（系统一模型）。
TypeSafe AI 创始人 Diogo Almeida 曾参与 OpenAI 的语言模型指令遵循与对话相关研究。
Jev 的设计方向与常见的生成式大模型有所不同。
GPT、Claude、DeepSeek 等通用模型擅长根据上下文生成文本、代码和结构化内容，也能完成复杂推理和工具调用。
Jev 不原生生成任意文本，而是根据输入状态，对预先定义好的问题进行判断，返回程序可以直接使用的结构化结果。
它的主要能力可以归纳为三类：
决策类型
核心能力
典型用途
Choice
从候选项中选择
动作选择、工具路由、故障分类
Score
按预设等级评分
风险等级、严重程度评估
Noul
判断命题成立的概率
是否重试、是否转人工
例如，一次接口自动化测试失败后，系统可以同时提出三个问题：
Choice： 失败原因更接近产品缺陷、环境异常还是脚本问题？
Score： 当前故障的严重程度属于哪个等级？
Noul： 这次失败是否值得进入自动重试流程？
Jev 支持在一次请求中处理多个独立判断，返回对应结果。
Choice 和 Score 还会提供概率分布及 confidence，帮助程序识别模型在不同候选项之间的确定程度。
这些能力并不是通用大模型做不到。
现在的 Structured Outputs 和工具调用机制，同样能够约束模型输出固定字段与枚举值。
Jev 的差异，是专门针对有限输出空间内的决策进行架构和训练优化。
TypeSafe AI 将其训练方法称为 RLCD（Reinforcement Learning for Calibrated Decisions），强调结构化决策和概率校准。
官方公布的 Jev 响应范围约为 70～500ms，输入价格为每百万 tokens 0.042 美元，输出不单独计费。
这些是厂商公开口径，实际延迟还会受到网络、输入长度和服务负载等因素影响。
对于偶尔调用一次模型的任务，差别可能并不明显。
但如果一个系统每天要进行数十万次分类，或者一个 Agent 每执行一步都需要判断下一步操作，单次调用的延迟和成本就会逐渐变成架构问题。
三、浏览器自动化案例：17 次决策完成一次航班查询
相比游戏演示，Jev 在浏览器自动化方面的探索更接近实际的软件测试工作。
Browser Use 社区开源了 jev-ultrafast 项目，将 Jev 与浏览器自动化结合，用来执行 Google Flights 航班查询任务。
整个系统采用了明确的模型分工。
Jev 负责动作选择。
判断下一步执行什么操作、操作哪个页面元素。
生成模型负责文本生成。
例如，在需要填写出发地、目的地时生成城市名称。
浏览器执行程序负责真实操作。
完成点击、输入、等待、元素检查和页面状态采集。
项目公开的一次演示数据如下：
项目
执行记录
任务
Google Flights 航班查询
总执行时间
7.073 秒
Jev 请求次数
17 次
文本生成调用
2 次
Jev 延迟中位数
178ms
数据来源：Browser Use 项目公开的 performance.md。
执行时间包括模型请求、浏览器操作、页面加载以及执行过程中的状态变化，不包括初始页面导航和最终独立校验。
项目还进行了三组配对测试。
优化后的执行版本，任务完成时间中位数从 9.450 秒降至 7.092 秒，降幅约为 25%。
不过，这次优化同时涉及 DOM 读取、浏览器协议调用和页面状态管理等工程改进，并不是单纯替换模型带来的提升。
该项目只对少量特定任务进行了测试，不能将这些成绩推广到所有浏览器自动化场景。
从工程实现来看，这套方案展示了一种分工方式：
需要理解复杂目标时使用生成模型，需要从有限动作中快速选择时使用决策模型，实际操作交给自动化程序。
这套思路可以进一步延伸到 Web、App 和接口自动化测试。
四、Jev 在 AI Agent 架构中应该放在哪一层？
如果把 Jev 接入一个 AI 自动化测试平台，比较合理的做法不是直接用它替换现有大模型，而是将不同职责拆分。
一个完整的 AI 测试 Agent，可以由以下几个部分组成。
- 通用大模型：负责测试规划
根据用户目标理解业务需求，拆解测试任务，生成执行计划。
例如，用户要求验证电商系统的下单流程。
通用大模型需要识别登录、商品选择、优惠券、订单提交、支付状态等关键环节，并生成相应的测试路径。
当执行结果偏离计划时，也可以由通用大模型重新分析和规划。
- 状态采集：负责整理当前环境
通过 Playwright、Appium 或接口客户端，获取当前页面和系统状态。
包括页面元素、App 控件树、接口返回值、执行日志和环境信息。
这些数据会作为 Jev 的决策依据。
- Jev：负责高频局部决策
根据当前状态，从有限的候选动作中选择下一步。
例如：
点击某个页面元素
选择需要调用的工具
继续等待或重新获取状态
判断是否需要重新规划
如果当前信息不足，或者候选动作无法解决问题，系统可以停止当前操作并升级处理。
- 自动化工具：负责执行
由 Playwright、Appium、API Client 或其他工具执行具体操作。
Jev 返回的是决策，并不直接保证工具执行成功。
- 验证系统：负责检查结果
通过业务断言、数据比对和规则校验，确认操作是否达到预期。
如果验证失败，系统可以重新采集状态，或由通用大模型重新规划。
同时，权限校验、安全控制、日志追踪与性能监控贯穿整个执行过程。
一种可参考的 AI 测试 Agent 分层架构。通用大模型负责规划，Jev 承担高频动作决策，自动化工具负责执行，独立测试系统负责结果验证，并通过状态反馈形成执行闭环。
这种分层设计可以让测试团队更容易定位问题。
当任务执行失败时，可以分别检查：
测试计划是否合理
状态采集是否完整
决策模型是否选错动作
自动化工具是否执行失败
结果断言是否存在问题
每个环节都能够独立测试、记录和优化。
五、Jev 在软件测试开发中，适合哪些场景？
Jev 并不擅长独立生成复杂测试方案，但在一些高频、候选结果明确的测试任务中，可以作为辅助决策组件。
- AI 自动化测试：动态动作选择
使用 Playwright 或 Appium 执行自动化测试时，页面经常会出现弹窗、加载等待、元素变化等情况。
传统脚本一般依赖预先编写的条件判断。
AI Agent 则可以根据页面状态动态选择操作。
例如：
当前出现支付确认弹窗，下一步应该点击确认、返回，还是停止测试？
通过状态采集组件获取页面信息后，Jev 可以从合法的候选动作中选择。
自动化框架执行动作，再由断言判断结果是否正确。
这类场景适合探索局部动作选择与动态状态处理。
- 测试失败分类：批量分析执行结果
在 CI/CD 流水线中，一次测试失败可能来自多种原因：
产品缺陷、脚本异常、测试数据问题、环境故障或外部依赖不稳定。
如果每天产生大量失败日志，可以尝试先使用 Jev 完成初步分类。
例如：
输入 HTTP 状态码、异常堆栈、最近的执行日志和环境信息。
模型判断失败类别、风险等级，以及是否建议进一步排查。
分类结果再进入自动分流或人工分析流程。
需要自动重试时，还必须结合接口幂等性、重试次数和环境状态进行校验，不能只根据模型判断直接重试。
这种方式适合高吞吐量测试结果的初步分流。
- Agent 工具调用：风险分类与路由
AI Agent 开始接入数据库、文件系统、业务接口后，测试范围已经不只是检查回答内容。
还需要检查 Agent 是否选择了正确的工具，以及执行动作是否符合权限和业务要求。
例如，一个 Agent 准备调用数据库接口。
系统可以先判断：
当前操作属于查询还是修改？
是否涉及敏感数据？
是否需要用户确认？
是否应该升级给更强模型分析？
Jev 可以参与工具分类、辅助风险判断和执行流程路由。
涉及资金、权限和数据删除等高风险操作，仍然需要确定性权限校验及必要的人工确认。
Jev 可探索的三个测试开发方向，包括 AI 自动化测试的动作选择、测试失败结果分类，以及 Agent 工具调用与风险评估。它们共同的特点是需要语义理解，但决策输出范围相对明确。
六、从 Demo 到生产环境，Jev 需要解决哪些问题？
模型能够快速作出选择，不代表整个系统就能稳定运行。
对于计划引入 Jev 的测试团队，需要解决四个工程问题。
- 输入状态是否完整
Jev 的判断依赖程序提供的信息。
如果页面状态只包含按钮名称，没有提供表单内容、业务状态和异常信息，模型就可能选错动作。
因此，DOM、控件树、接口结果和日志的采集质量，会直接影响决策结果。
- 候选动作是否覆盖异常场景
Jev 只能从预定义的候选动作中选择。
如果订单出现异常，但候选项只有“提交”和“返回”，模型就无法选择“停止并上报”。
候选动作除了正常业务操作，还需要包含等待、停止、升级处理和必要的回退选项。
- 置信度是否经过业务校准
Jev 的 Choice 和 Score 返回 confidence，但这个值不是实际决策正确率。
它反映的是候选答案概率分布的集中程度。
例如，模型非常确定某个动作，也不代表这个动作一定正确。
如果系统准备根据置信度自动执行、回退或转人工，就需要先用真实数据评估不同阈值下的错误率。
- 执行结果能否独立验证
Jev 选择了“提交订单”，并不代表订单测试通过。
测试系统还需要检查订单状态、支付金额、库存变化及业务规则。
对于 AI 自动化测试，动作选择和结果验证必须分别设计。
否则，一次测试失败后，很难判断是模型决策出了问题，还是执行、断言本身出了问题。
七、Jev 的实际能力怎么样？独立评测给出了什么结果？
2026 年 10 月 6 日，独立评测机构 Vals AI 发布了 Jev 与多种前沿模型的对比结果。
评测涉及两类任务：事实核验和法律推理。
评测项目
Jev 结果
400 道事实核验样本
准确率 97.5%
LegalBench 法律推理子集
类别平衡准确率 73.0%
事实核验表现
与部分前沿模型接近
法律推理表现
在所比较的 12 个系统中排名最后
在事实核验任务中，Jev 以较低成本取得了不错的成绩。
但在包含多种复杂语义关系的法律推理任务中，它的准确率明显落后于其他参与评测的模型。
评测还发现，Jev 的概率校准表现会随着任务变化，并不能保证在一种任务中可靠，换到其他业务场景后仍然稳定。
所以，团队决定是否接入 Jev，不能只看单次响应速度。
更合理的方式，是选择一批真实业务任务，对几种实现方案进行对照：
通用大模型 + Structured Outputs
Jev 决策模型
规则引擎或传统分类模型
通用大模型与 Jev 组合
重点比较以下五项指标。
决策准确率： 动作、分类和风险判断是否正确。
任务成功率： 完整测试流程能否达到预期目标。
响应时延： 单次调用与整个任务的 P50/P95 耗时。
综合成本： 模型调用、重试、回退及维护成本。
可控性与安全： 候选动作能否约束，异常能否恢复，高风险操作能否被拦截。
测试团队评估 Jev 时，应以真实测试任务为基础，对比决策准确率、端到端任务成功率、响应时延、综合成本及安全可控性，避免单纯依据模型价格或演示速度选型。
对测试团队来说，验证方法可以从一个小范围场景开始。
例如，先选择一批已经有明确原因标签的测试失败记录，统一输入数据和分类标准，再比较不同方案的准确率、延迟、成本及异常处理效果。
如果 Jev 能在满足质量要求的前提下，降低整体执行成本和响应时间，再逐步扩大使用范围。
这样的结果比单独比较模型 API 响应速度更有参考价值。
八、Jev 甚至被拿来做聊天，说明了什么？
Jev 发布后，GitHub 上还有一个名为 jev-llm 的社区实验项目。
开发者尝试通过不断调用 Jev 的选择能力，间接实现文本生成。
具体方式是先提供一组候选词，让 Jev 判断下一个词，再把选中的词加入当前内容，重复这一过程。
项目还通过候选词筛选、并行请求和重新排序等方法改善输出。
这种方式能够生成一些可读的文本，但生成速度、词汇范围和内容质量仍然存在限制。
它说明决策模型可以通过外部程序组合出新的功能，但并不意味着 Jev 已经具备与通用语言模型相同的生成能力。
对于实际项目，模型能力与工程目标是否匹配，仍然是选型的主要依据。
九、Jev 会改变未来 AI Agent 的技术架构吗？
从目前的技术方向看，Jev 提供了一种更细粒度的模型使用方式。
过去很多 Agent 系统主要围绕通用大模型构建，让模型完成任务理解、规划、动作选择、工具调用和结果分析。
这种方式灵活，适合快速开发原型。
但当系统进入生产环境，调用量、响应时间和运行成本就需要更精细的控制。
未来部分 Agent 可能采用更加明确的分工：
复杂推理交给通用大模型，高频决策交给专用决策模型，工具执行交给程序，结果正确性由独立验证机制保证。
不过，Jev 并不是所有系统都必须引入的组件。
对于复杂规划和代码生成，通用大模型仍然具有优势。
对于规则清晰、任务稳定的分类问题，规则引擎和专用小模型也可能更加经济。
引入 Jev 还会增加模型供应商依赖、网络请求和系统维护成本。
是否采用分层架构，需要根据真实业务规模与测试结果决定。
十、总结
Jev 的出现，让 AI Agent 的模型分工有了一个新的选择。
它没有试图替代通用大模型的复杂推理与文本生成能力，而是将重点放在高频、有限输出空间的结构化决策上。
从软件测试开发的角度看，比较适合探索的方向包括：
AI 自动化测试中的动态动作选择
自动化测试失败结果分类
Agent 工具调用与风险判断
高频业务流程的决策分流
这些场景都具有一定的语义理解需求，但不一定需要每一步都执行复杂的生成式推理。
当然，专用决策模型是否更适合某个测试系统，最终还要看任务成功率、执行效率、异常恢复能力及综合成本。
对于正在建设 AI 测试平台和智能体系统的团队，模型选型可以从一个更具体的问题开始：哪些环节需要复杂推理，哪些环节只需要一个快速、可靠、可验证的决策？
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
