拆解Jev Ultrafast：浏览器Agent为何能7秒查完航班

一个浏览器 Agent 在 7 秒内能干多少活？开源项目 Jev Ultrafast 给出了一个具体答案：打开 Google Flights、填入苏黎世和伦敦、选中单程、查到航班——官方录像里这段操作总共用了 7.073 秒。这个时间从它第一次开始判断算起，到页面出现正确结果为止，不包括开浏览器进入网站和结束后的复合操作。项目上线不到一周就拿到了一万五千多个 star，它到底省掉了什么才能跑这么快？

把网页从「阅读题」变成「选择题」

常见的浏览器 Agent 有点像每做一道题都要把整张卷子重新读一遍。页面有多长、里面有多少按钮、图片和文字，模型都要先看一遍，决定点击之后网页变了，它又要重新看。如果每一轮还带着截图、网页正文和工具说明，时间就一轮一轮地加上去。

Jev 换了个思路：把网页改成选择题。它会把当前能操作的元素挑出来排成一张表——1 号是按钮、2 号是输入框、3 号是下拉菜单，每一项叫什么、里面有没有内容、能做哪些操作，都一起写进去。模型不用猜鼠标坐标，也不用临时写网页选择器，只需要回答两件事：做什么、选几号。比如「点击 7 号」。

只有碰到需要输入文字时，它才会再叫一个小模型来写内容。官方记录里，生成「Zurich」用了 581 毫秒，生成「London」用了 346 毫秒。这种分工把大部分决策压缩成了一次简单选择，大幅减少了模型每一步需要处理的信息量。

传统浏览器 Agent 通常依赖两种感知方式：截图（视觉模型逐像素分析页面）或 DOM 树（将完整 HTML 结构序列化后送入模型）。前者受限于多模态模型的推理速度，后者则因现代网页 DOM 节点动辄数千甚至数万个，上下文窗口消耗极大。Jev 的做法本质上是一层语义过滤：只提取当前视口内处于可交互状态的元素（如 button、input、select、[role=button] 等），忽略纯展示性节点，再把这些元素编号后序列化成紧凑的文本清单。这样送入模型的 Token 数量可以压缩到完整 DOM 的百分之几，自然也缩短了模型的推理时延。代价是：依赖可访问性树或特定 CSS 选择器才能识别的元素（如 Canvas 绘制的控件、Shadow DOM 内的节点）会被过滤掉，这也是它在复杂网页上容易卡住的根本原因。

少读、少跑，速度的两个来源

模型看得少，是第一个提速点。默认情况下截图不会送进模型，页面下方暂时看不到的正文和页脚也不会跟着一起进去，读取当前可操作空间只需要一次浏览器调用。页面上有一点动画，它也不会马上推翻整轮判断。

第二个提速点是浏览器来回跑的次数少了。官方拿优化前后的版本各跑了三组：原始版本中位时间 9.450 秒，优化后 7.092 秒，减少约 25%；TypeSafe 请求从 22 次降到 17 次；浏览器协议调用降得更多，从 1092 次变成 101 次。

需要注意的是，这三组跑的都是同一个航班查询、同一套浏览器配置。这能说明优化对这个任务有效，但还不能证明换到任何网站都能跑出同样的速度。项目另外放了两个小测试：打开指定 Wikipedia 页面用了 2.798 秒，本地酒店筛选页面用了 1.896 秒——但这两项没有拿旧版本做同条件对照。

浏览器协议调用从 1092 次降至 101 次这一数字，背后涉及 Chrome DevTools Protocol（CDP）的工作方式。CDP 是 Playwright、Puppeteer 等浏览器自动化库底层的通信协议，每次点击、截图、读取 DOM、等待网络空闲都对应若干次 CDP 消息往返。次数过多不仅增加本地通信开销，还会触发浏览器内部更多的渲染和布局计算。Jev 把「读一次可交互元素列表」压缩成单次批量调用，并跳过截图和视口外内容的抓取，从源头减少了 CDP 往返量。这也是为什么即便模型推理时间没有明显变化，整体端到端耗时依然能下降约 25%——瓶颈不只在模型，还在浏览器与 Agent 之间的网络往返。

执行前先复查，避免「拿旧答案硬点」

如果模型刚选完，网页自己变了呢？Jev 不会拿着旧答案硬点。真正执行之前，它会再检查一次：还是不是刚才那一页、目标还在不在、按钮有没有被弹窗挡住。对不上，它就把这次操作丢掉，重新看页面。

它支持点击、输入、选择、滚动、等待和结束这几类动作。跑起来之后本地会打开一个检查页面，读到了哪些元素、准备做什么、目标选了谁、前面做过哪些步骤，都能在这里看到，方便调试和观察它的决策链路。

开源不等于免费：成本与依赖

这个项目代码虽然开源（MIT 许可证），完整跑起来并不免费。负责决定「下一步点什么、选什么」的核心模型 GIV 目前只能走 TypeSafe 的官方接口。碰到输入场景，项目还会调用一个文本模型，默认配置用的是 OpenRouter，所以还要再填一个 Key。

这个文字模型可以换成本地的 OpenAI 兼容服务，但负责点击决策的 GIV 目前只能走远程接口——也就是说，你可以把文字生成放在本机，但整个 Agent 还不能完全离线运行。

TypeSafe 现在按输入量收费，每 100 万 Token 为 0.042 美元，输出免费。官方文档没有列长期免费套餐，注册时有没有赠送额度要看当时的账户页面，不能把它当成免费方案。官方给过一个很低的费用数字，但那个数字只算了两次文字生成，没有算进 TypeSafe 的账单，不能当成整次航班查询的总价格。

TypeSafe 是 Jev 背后团队自研的多模态结构化输出服务，GIV 是其核心模型，专门针对「给定操作候选列表、输出结构化动作」这类任务做了优化。与通用大语言模型不同，GIV 的输出被约束为 JSON Schema 定义的固定格式（TypeSafe 的核心卖点之一），这样可以省去模型自由生成文本再解析的步骤，减少输出 Token 并降低解析错误率。目前 TypeSafe 按输入 Token 收费、输出免费的定价结构，意味着页面元素清单越长、步骤越多，成本越高；但由于 Jev 本身已经做了元素过滤，单步输入 Token 数相对可控。真正需要留意的是：当任务步骤数增多或页面元素较多时，累计费用会线性增长，不能只用官方两步演示的费用数字来估算复杂任务的成本。

它挑网页，也挑任务

Jev 对网页类型比较挑剔。普通按钮、输入框和下拉菜单它比较容易处理；但碰到 Shadow DOM、Frame、Canvas、文件上传、新标签页、嵌套滚动或者复杂的键盘操作，就可能停在半路。

它还会使用你现有的 Chrome 配置，如果浏览器里已经登录了账号，测试网站和账号权限都要收紧。付款、删数据、发消息这类操作，别让它自己一路点到底。

结合这些特性，比较合适的用法是：查资料、填普通表单、切换几个筛选项这类短流程可以试；流程里要上传文件、跨 Frame、过验证码或者牵涉敏感账号的，就加上人工确认，别只靠它一个。

小结

Jev Ultrafast 的核心思路很清晰：先把网页压成一张操作清单，再让模型做选择——看的内容少了，浏览器调用也少了，这就是它跑得快的原因。截至 2026 年 9 月 22 日，项目已有 15975 个 star，采用 MIT 许可证。需要提醒的是，本文的速度和费用数据都来自仓库公开的演示与报告，并非独立复现；它跑得快是真的，但适用范围和真实成本，都需要按自己的场景重新评估。