企业官网建设流程全解析

JeecgBoot AI专题研究| 从 Jev 决策模型到 jev-ultrafast：把 Agent 的"判断"和"生成"拆开之后，浏览器自动化发生了什么

浏览器 Agent 为什么总是慢半拍

用过 AI 浏览器 Agent 的人大概都有同感：页面早就加载完了，按钮就摆在那儿，它却迟迟不动——因为每一步都要等大模型"想清楚"再返回下一条指令。

一个普通任务，比如查一趟航班，往往要经历十几次操作：切换单程、填出发地、填目的地、选日期、点搜索……每一次都走一遍完整的大模型推理，延迟就这样一层层叠了上去。

问题是："下一步点哪个按钮"这种事，真的需要一个能写长文的大模型来深思熟虑吗？

Browser Use 团队给出的答案是否定的。他们把专门做判断的Jev模型接进浏览器 Agent，开源了jev-ultrafast项目，上线 4 天就拿到了 13.6k Star。

先认识 Jev：一个只做选择题的模型

如果你还没接触过 Jev，可以先把它理解为**“专门回答选择题的模型”**。

它由 TypeSafe 推出，创始人 Diogo Almeida 是一位连续创业者，此前在 OpenAI 参与过指令遵循与对话训练方法的构建。和常见的大语言模型不同，Jev 不生成大段文本，它的输出只有两样东西：选了什么，以及对应的概率。

举个例子：A、B 两人参加比赛，让 Jev 根据给定信息判断谁会赢，它返回的就是"A 胜，概率 80%"这样的结构化结果：

注意看返回里的usage：输入 246 个 token，输出只有 28 个。正因为只做判断、不做生成，Jev 在这类任务上的成本据称可以比通用大模型低上百倍，响应速度也快得多。它更像人的"直觉判断"——了解情况之后，立刻给出倾向。

把这个特性放到浏览器里就很好理解了：页面上的输入框、按钮都已经在那里，Agent 需要不停地回答"下一步填哪个、点哪个、是否结束"——这恰恰是一连串的选择题。

jev-ultrafast 是什么

jev-ultrafast 是 Browser Use 开源的一个浏览器 Agent，分工非常明确：

• Jev 负责决策：下一步做什么操作、作用在哪个元素上；
• 文本模型负责补充内容：只有当需要往输入框里填文字时，才调用生成式模型；
• 程序负责执行：把决策落实为真实的点击和输入。

它的运行循环可以拆成这样几步：

1. 读取当前页面，整理出可操作的元素列表；
2. 把"操作类型 + 目标元素"交给 Jev 判断；
3. 如果需要输入文字，调用文本模型生成内容；
4. 程序执行操作，然后重新读取页面；
5. 循环往复，直到 Jev 判断任务完成或遇到无法继续的阻碍。

这种"判断交给小而快的决策模型，生成交给大模型"的拆分思路，其实不只适用于浏览器，对任何需要高频决策的 Agent 都有借鉴意义。

实测：7 秒完成一次航班搜索

官方 Demo 的任务是：查找 2026 年 9 月 20 日从苏黎世飞往伦敦、单程、一位成人、经济舱的航班。

Agent 需要依次修改行程类型、填写出发和到达城市、处理下拉候选项、选择日期，再发起搜索并等待结果。整个流程耗时约7 秒：

对于习惯了浏览器 Agent"一步一停顿"的人来说，这个速度确实是一个明显的跨越。

快在哪里：四个关键设计

一次请求，把两个问题一起答完

网页操作每一步其实都要回答两个问题：做什么（点击还是输入）和对谁做（哪个元素）。jev-ultrafast 把这两个问题合并进同一次 Jev 请求，拿到结果后由程序直接执行。

对于动辄十几步的任务，每一步省掉一次模型往返，累计下来就是数倍的时间差。

读控件，而不是看截图

默认模式下，它读取的是网页中的控件结构：元素名称、当前值、可见文字等，而不是逐步截图交给视觉模型理解。这样 Jev 可以直接围绕"目的地输入框""搜索按钮"这些语义信息做判断。

项目同时优化了页面读取、操作后等待等环节——最终的提速是模型选型与执行流程共同优化的结果，而不只是换了一个更快的模型。

每一步决策都可追溯

项目提供了本地检查界面，可以看到元素编号、操作概率、目标概率以及已经执行过的动作。你既可以让它全自动跑，也可以设置为每一步执行前暂停。出错时，顺着"页面状态 → 模型选择 → 执行结果"逐步排查即可。

概率输出在这里很有价值：当某一步的最高概率明显偏低时，往往意味着页面状态和预期不一致，是排查问题的好线索。

执行前再确认一次页面

模型做决定的那一瞬间，页面可能已经变了：按钮挪了位置、弹窗冒了出来、输入框被重新渲染……这些都会让刚才的判断失效。jev-ultrafast 会在执行前再次校验目标元素和页面状态，并检查点击位置是否被遮挡，避免"点了个寂寞"。

冷静看待：它不是万能的

关于 Jev 这类决策模型，目前社区里既有热捧也有降温的声音，有几点值得客观看待：

• 适合封闭判断，不适合开放生成：Jev 擅长"从已知选项中挑一个"，需要创作、推理链很长或涉及精确计算的任务，仍然要交给通用大模型；
• 对延迟极敏感的场景未必够用：比如有人尝试用它做量化交易，高频场景的延迟要求它达不到，低频场景又未必比现有方案更有优势；
• 页面结构质量影响很大：读控件的方式依赖网页的可访问性信息，遇到大量 Canvas 绘制或结构混乱的页面，效果可能打折扣，届时仍需截图 + 视觉模型兜底。

但"让 AI 更快、更便宜地做出一个小判断"这件事本身就有清晰的价值。浏览器自动化只是第一个被验证的场景，表单填写、RPA 流程、工单分流、测试用例执行等需要大量小决策的环节，都可能从这种"判断与生成分离"的架构中受益。

项目地址：https://github.com/browser-use/jev-ultrafast

总结

• 浏览器 Agent 慢，根源在于每一步小判断都在调用完整的大模型推理；
• Jev 是只输出"选项 + 概率"的决策模型，成本低、响应快，天然适合高频选择题；
• jev-ultrafast 把操作决策交给 Jev、文本填写交给生成模型，并通过合并请求、读取控件、可追溯检查界面、执行前校验等设计，把航班搜索压缩到约 7 秒；
• 它不能替代通用大模型，但"判断与生成分离"的思路，值得所有做 Agent 的团队参考。

本文为 JeecgBoot AI 专题研究系列文章。