Jev Ultrafast · AI 工具图鉴

📌 核心价值：一句话下任务，AI 自己打开浏览器点完整个流程 —— 搜完一趟机票只用 7 秒，MIT 开源，本机就能跑。

不用截图、不用视觉模型猜坐标，它把网页读成一张带编号的清单，一次请求直接决定"点哪个"。同一个任务，旧的截图式方案要 9.45 秒、跑 1092 次浏览器协议调用，它只要 7.07 秒、101 次。

封面图

🚀 什么是 Jev Ultrafast？

它是知名开源浏览器自动化项目 browser-use 在 2026 年 9 月 17 日上线的新仓库，由 browser-use 与 TypeSafe 联合发布，MIT 协议开源，目前已经拿到 4.5k star。

它要解决的痛点很具体：现在的网页 AI 代理又慢又贵又容易崩。传统做法是"截一张全屏图 → 丢给多模态大模型 → 模型盯着图想几秒 → 输出一段带坐标的说明 → 浏览器点一下 → 再截图"，一轮下来好几秒就没了，页面上的按钮稍微挪一下位置就直接卡死。

Jev Ultrafast 把这一套彻底拆掉：默认循环里没有截图。它把当前页面读成一张结构化元素表，交给 TypeSafe 的 Jev 模型，模型只回答两个问题——做什么操作、操作第几个元素。

核心定位：让大模型"戒掉废话"——不再生成自然语言，只输出操作和目标的概率分布。

⚡ 7.073 秒，官方实录长什么样

官方放出的录像是一个真实任务，一句话目标：

Find one-way flights from Zurich to London on September 20, 2026, for one adult in economy. Stop when matching flight options are visible. Do not select or book a flight.

AI 自己完成：打开 Google Flights → 把往返切成单程 → 出发地填苏黎世 → 目的地填伦敦 → 选 9 月 20 日 → 点搜索 → 拿到航班列表 → 自主判定任务完成。全程 1× 原速录屏，7.073 秒，并且由独立校验脚本核对"单程 / 苏黎世 / 伦敦 / 9 月 20 日 / 结果可见"五项全部通过。

7.073 秒真实运行结果

注意右下角那个 178 ms —— 这是它每次"决定下一步"的中位延迟。传统视觉代理的单次决策是秒级，它降到了百毫秒级。

✨ 核心机制：把网页变成一道选择题

整个原理可以概括成一句话：别让模型说话，让它选编号。

动作空间与单次请求流程

每一轮观察，它只做一次原子快照，把可见控件读成带索引的清单：

[1]  button    切换单程/往返 · 当前往返
[2]  combobox  Where from?   · 旧金山
[3]  combobox  Where to?     · 空
[4]  textbox   Departure     · 空

然后一次 TypeSafe 请求同时问两个问题：该做哪个操作？该点哪个目标？操作只有 8 个可选：CLICK、TYPE_TEXT、SELECT、SCROLL_UP、SCROLL_DOWN、WAIT、DONE、BLOCKED。而且目标分布里只出现与所选操作兼容的元素——如果你要 CLICK，就不可能拿到一个只能输入的框。

关键的设计取舍有四个：

一次决策 = 一次网络往返。操作和目标是并行预测的，不存在"先想操作、再想目标"的串行等待，也不存在把一句自然语言解析成坐标的出错环节。
只有要填字时才叫语言模型。如果这步是 CLICK，文本模型全程睡觉。录像里"苏黎世"生成花了 581 ms，"伦敦"花了 346 ms，两次文本调用在 OpenRouter 上合计约 $0.00006272。
模型输出永远不会变成选择器、坐标、shell 命令或可执行 JavaScript。所有目标都从已观察到的节点解析出来，执行前还要重新读一遍几何位置、检查有没有被遮挡。
用语义新鲜度代替"DOM 变了几次"。旧版循环一有动画就判定决策失效、疯狂重读无障碍树，这才是它真正慢的地方。

界面上的实时状态长这样——左边每个控件都带编号，右边显示操作概率和目标概率：

inspector 实时决策界面

📊 实测数据：快 25% 只是开胃菜

官方做了一组对照实验：同一个任务、同一个 Chrome 配置、同一个模型（inception/mercury-2.5，关闭推理）、同样的预算上限，两套代码各跑 3 次，全部通过独立校验。

性能对照实测

指标	旧版截图式循环	Jev Ultrafast	变化
三次运行耗时	11.214 / 8.984 / 9.450 秒	6.964 / 7.913 / 7.092 秒	—
中位耗时	9.450 秒	7.092 秒	↓ 25.0%
浏览器协议调用（中位）	1092 次	101 次	↓ 91%
TypeSafe 请求数（中位）	22	17	↓ 23%
单次决策延迟（中位）	秒级	178 ms	—

协议调用从 1092 掉到 101，这才是真正值得看的一行。 原因是快照合并成了一步：一次浏览器调用就拿到全部可见控件的角色、名称、当前值、可见文本，而不是逐个元素去查样式、量包围盒、反复读无障碍树。

另外两个轻量任务：打开维基百科某条目 2.798 秒，本地酒店页面"搜索里斯本 + Design + 免费取消 + 打开 Casa Flora" 1.896 秒。

和主流方案横向比：

传统截图式 Agent vs Jev Ultrafast

第三方测评给出的单次运行成本约 $0.0039；按它的口径，TypeSafe 侧输入价格约 $0.04 / 1M tokens，比让大模型逐字生成控制指令便宜两个数量级。当然——这行数字不含浏览器开销，也只测了一个任务，官方自己也在文档里写明"三次配对太少，够不上统计意义上的强结论"。

注意：一个任务快不代表通用能力。官方明确写了这是"受控输入的小规模对照"，不是通用 Agent 基准。

🛠️ 快速上手：5 分钟跑通

安装

git clone https://github.com/browser-use/jev-ultrafast.git
cd jev-ultrafast
uv sync
cp .env.example .env
# 在 .env 里填两个 key：
#   TYPESAFE_API_KEY      —— 决策模型
#   TEXT_MODEL_API_KEY    —— 只用来生成要输入的文字（示例用 OpenRouter）
uv run jev

打开 http://127.0.0.1:8766，点 Start demo → Run automatically，就能看到 inspector 里编号元素、操作概率、目标概率和执行动作的实时滚动。Chrome 通过 browser-harness 连接（uv sync 会装上），需要时执行 uv run browser-harness --doctor 排障。

当成库来用

from jev_ultrafast import Agent

with Agent(
    "https://www.google.com/travel/flights?hl=en",
    "Find one-way flights from Zurich to London on September 20, 2026, "
    "for one adult in economy. Stop when matching flight options are visible.",
) as agent:
    for state in agent.run():
        print(state["elapsed_ms"], state["status"])

换任务不用改代码，只换目标和起点：

uv run --env-file .env python examples/run.py \
  --url https://en.wikipedia.org/wiki/Main_Page \
  --goal 'Find and open the Wikipedia article about Gödel’s incompleteness theorems.'

注意：文本助手模型不限定 OpenRouter，Gemini / GLM / DeepSeek 都能接——只要按 OpenAI 兼容格式配好模型名、端点和推理开关即可。

💡 适用场景：一次完整任务的四个阶段

下面四张图是从官方 91 帧录屏里按时间轴抽出来的真实画面。

阶段一：起点页面

演示图 1

发生了什么：Agent 拿到一句话目标后打开 Google Flights 首页，第一轮快照就已经把"往返切换、出发地、目的地、出发日期、返程日期、搜索按钮"全部编号入表。

输入要求：一个 URL + 一句自然语言目标。

适用场景：任何"需要先看清页面再动手"的表单型网站——订票、报销、选课、后台配置。

阶段二：动态填表

演示图 2

发生了什么：这一步真正吃到了"动态动作空间"的好处——用户在输入框打字时页面会弹出联想下拉，旧的做法会因为在动画中反复重读无障碍树而白白浪费决策。新版对 combobox 专门加了一个基于事件的等待，最多 200 ms 等联想项出现再让模型选；普通交互只等两帧或 50 ms。

输出效果：输入框里出现真实的城市名（这串文字由小模型生成，不是提前写死的），随后的目标索引自动指向新的下拉选项。

关键约束：只有 TYPE_TEXT 这种操作才会调用文本模型，其余操作它完全不参与。

阶段三：单程与日期

演示图 3

发生了什么：把"往返"切成"单程"，再选日期。这类"改变页面状态而不是提交表单"的动作，最容易被旧方案搞崩——因为点击本身会触发 DOM 变化，而旧逻辑会把任何 DOM 变化都当成"决策过期"。新版改成比较语义状态：文档、完整 URL、视口、表单值、选中目标、附近上下文。

适用场景：有开关、单选、级联筛选的页面，比如电商筛选、政务表单、企业内网。

阶段四：结果与自主判定

演示图 4

发生了什么：航班列表出来后，Agent 自己判断"目标达成"并选择 DONE。但这里有个很克制的设计——模型的 DONE 不算数，必须由独立校验脚本核对单程设置、出发城市、到达城市、日期、结果可见五项，全部对上才算成功。

输出效果：19 步操作、17 次 Jev 请求、2 次文本调用，7.073 秒后拿到结果页。

适用场景：任何"需要拿到结果并验证结果"的抓取/查询任务。

用户群体总结

✅ 需要长尾网页自动化的开发者：内网报销系统、学校选课系统这类没人会为它写专门适配器的页面，扔一句话给它
✅ 在意延迟的 Agent 产品：把高频、有限选项的"下一步做什么"从大模型里剥离出来，单次判定 178 ms
✅ 在意成本的小团队：单次运行成本约 $0.0039 量级，且全程本地运行
✅ 想读懂 Agent 内部逻辑的人：agent.py / snapshot.js / browser.py / model.py 四个文件加起来足够读完
❌ 不适合：需要处理 Shadow DOM、iframe、canvas、文件上传、嵌套滚动、弹窗新标签页和复杂键盘交互的场景——这些官方明确列在 MVP 边界之外
❌ 不适合：需要视觉理解的任务（比如"看这张图里有什么"），因为它默认根本不看截图

💰 定价方案

Jev Ultrafast 本身完全免费开源，MIT 协议，本地运行。

真正要花钱的是两个 API：

项目	计费方式	实测参考
TypeSafe（Jev 决策模型）	按 token 计费，输入约 $0.04 / 1M tokens	单次完整任务约 90,558 输入 token + 6,325 输出 token
文本助手模型（OpenRouter / Gemini / GLM / DeepSeek 等）	按你的服务商计费	两次文本调用合计约 $0.00006272
整次运行成本（第三方口径）	—	约 $0.0039

开源协议： MIT

💡 省钱提示：文本助手可以换成便宜或本地模型，因为它在整个循环里只负责"生成一小段要输入的文字"，调用次数极少。

🎯 总结

Jev Ultrafast 最值得学的不是那 7.07 秒，而是它敢于把大模型的权利收回去：不让它写小作文，不让它描述屏幕，不让它输出坐标，只让它在一张有限的清单上做选择题。结果是延迟降了一个数量级、协议调用少了 91%、成本降到可忽略，而且模型输出在架构上就不可能变成可执行代码——安全性是设计出来的，不是补上去的。

当然要清醒：它只测了一个任务、两个网站，官方自己承认"两个网站不足以证明广泛可靠性"，Shadow DOM / iframe / 上传 / 弹窗全都不支持。它现在是一个极佳的架构示范 + 可用的 MVP，不是一个开箱即用的通用自动化平台。

推荐指数： ⭐⭐⭐⭐（架构与实测数据顶着五星，但通用性边界还需时间验证）

适合人群： 做 Agent 产品的工程师、需要长尾网页自动化的开发者、想把大模型从高频判断里拆出来的团队

GitHub 仓库： browser-use/jev-ultrafast

数据截至 2026-09-18，最新信息请以官网为准。

配套媒体