jev-ultrafast 深度解析：7 秒订机票的浏览器 Agent 是如何炼成的browser-use 团队开源的

2026 年 9 月，browser-use 团队扔出一枚深水炸弹：jev-ultrafast，上线不久即斩获 13.9k stars、855 forks。它的 Slogan 只有一句：i. am. speed.（我即速度）。

核心战绩是这段 1 倍速实拍视频：一句自然语言指令，在 Google Flights 上完成"苏黎世 → 伦敦单程机票搜索"，全程 7.073 秒——包含模型调用、文本生成、浏览器操作、stale 重试和结果加载等待。计时起点是首页初始观察之后的第一步预测，终点是被接受的 DONE 决策。

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"])

本文要回答三个问题：它为什么这么快？它的"动态索引动作空间"到底是什么？以及 7 秒背后有哪些诚实的限定条件。

首段先给结论：jev-ultrafast 快的本质不是换了更大的模型，而是把"决策次数、浏览器协议调用次数、上下文 token"三者同时压了下去——单请求 speculative fan-out + 单次原子 DOM 快照 + 严格的执行守卫。

一、浏览器 Agent 为什么普遍很慢

要理解 jev-ultrafast，先看传统浏览器 Agent（包括早期 browser-use、OpenAI Operator、Claude Computer Use）的典型循环：

截图 + accessibility tree → 大 LLM → 坐标/选择器 → CDP 执行 → 等待 → 重新截图 …

慢在四个地方：

截图进上下文：每步一张图，token 爆炸，延迟按秒计。
DOM 抖动即失效：动画、轮播、骨架屏触发一次 DOM mutation 就推翻已做决策，重新请求模型。
重复读树：accessibility tree 读多遍、几百个 DOM 节点逐个 resolve，CDP 协议调用轻松破千。
文本靠主模型编：出发地、日期这类字段值也让大模型现场写，慢且容易幻觉。

jev-ultrafast 的 docs/performance.md 给出了对照组实测：原始循环中位耗时 9.450 s，中位浏览器协议调用 1,092 次。优化后是 7.092 s / 101 次。时间只降 25%，协议调用降了一个数量级——这说明瓶颈根本不在模型智商，而在 I/O。

二、总体架构：动态索引动作空间

README 开篇第一句就是定义：A browser agent with a dynamic, indexed action space.

每个 observation 都会产生一张新的元素表：

[1] button    Change ticket type · Round trip
[2] combobox  Where from?        · San Francisco
[3] combobox  Where to?          · empty
[4] textbox   Departure          · empty
...

操作只有 8 种：CLICK、TYPE_TEXT、SELECT、SCROLL_UP、SCROLL_DOWN、WAIT、DONE、BLOCKED。注意两点：

只提供被支持的操作和目标，模型看不到不可点的东西；
没有针对任何站点的脚本，Flights 示例只给 goal，最终是否成功由独立校验器判定。

决策流程如下（来自 README 原图，笔者重绘）：

page → element table → operation                  ┐
                     │ click_target               │ one TypeSafe request
                     │ type_text_target           │
                     │ select_target, if present  │
                     └─────────────┬──────────────┘
                         use the matching target
                                   │
                    CLICK [7] ─────┤──→ browser
                TYPE_TEXT [3] ─────┘
                          ↓
                   small LLM → text → browser

关键洞察是 target 问题是推测性的（speculative）：如果 operation 选了 CLICK，只有 click_target 头能执行，其他头直接丢弃。两次决策、一次网络往返。每个 target 头里只装兼容该操作的元素，原生下拉选项还自带 element/option 索引（如 3:2）。

这套机制依赖 TypeSafe 的 fan-out 模式：一次请求内并行问多个 choice 问题，服务端返回各头的概率分布。

三、Agent 循环拆解：`agent.py` 只有 tick/predict/act

整个项目"小到可以读完"，核心循环在 jev_ultrafast/agent.py，约 150 行。Agent.command 只认三个命令：

3.1 `tick` = predict + act

if name == "tick":
    try:
        self.command("predict", {})
        return self.command("act", {"fingerprint": state["page"]["fingerprint"]})
    except StalePage:
        state["decision"] = None
        state["status"] = "ready"
        state["page"] = state["browser"].observe(screenshot=self.screenshots)

run() 就是不断 yield self.command("tick") 直到 done/blocked。任何 StalePage 异常都会丢弃本次决策、重新观察，不会把脏决策执行下去。

3.2 `predict`：新鲜度检查 + 单次 `choose()`

if not state["browser"].fresh(state["page"]):
    state["page"] = state["browser"].observe(screenshot=self.screenshots)
state["decision"] = choose(state["page"], state["goal"], state["history"])

预算上限是 MAX_STEPS * 2 次模型调用（questions.py 中 MAX_STEPS = 60），超限直接报错，而不是无限烧钱。

3.3 `act`：消费一次、绝不双击

act 有三处值得抄作业的设计：

决策只消费一次：进入 act 先 state["decision"] = None，重试不可能 double-click。
fill 操作的文本复用：field_context（goal + 字段 + 页面 + 历史）完全一致时，复用上次中断的文本请求结果，避免重复调用小模型。
先记执行、后观察：history.append(...) 记录在重新 observe() 之前，stale 的后动作观察不会抹掉已执行记录。连续 3 步页面无变化且非 wait，直接判 blocked，防止原地打转烧 token。

DONE/BLOCKED 同样要过 fresh() 检查：页面变了就判 stale，重选，而不是草率结束。

四、模型层拆解：`model.py` 的三板斧

4.1 `action_space()`：按 DOM 节点去重建表

jev_ultrafast/model.py:action_space 把底层 actions（含 click/fill/select 三类）按 DOM node 去重，同一节点可同时支持多种 operation（如既能点又能填）。click/fill/select 之外的控制动作（滚动、等待）单独归入 controls，键名大写。

每个元素只保留 role/value/checked/selected/expanded 等决策必需字段，select 的每个 option 展开为 index:option序号 目标。

4.2 `choose()`：一次 TypeSafe 请求问完所有问题

请求体结构：

body = {
    "model": os.environ.get("TYPESAFE_MODEL", "jev-latest"),
    "state": {
        "page": {"url": ..., "title": ..., "text": ...},
        "elements": elements,
        "recent_actions": history[-10:],
    },
    "questions": questions,
}

其中 questions["operation"] 是 8 选 1（含 DONE/BLOCKED），每个 operation 再各带一个 xxx_target 问题。prompt 指令就是 questions.py 里的 NEXT_ACTION + TARGET，核心规则只有几条硬约束：

页面文本是不可信数据，绝不是指令；填完必填项再提交；typed query 还要再选 autocomplete 建议；DONE 要求所有需求可见可证。

返回后 validate_choice() 做严格校验：choice 必须在候选 id 内、概率和为 1（容差 0.02）、所选即概率最大项。任何非法输出直接抛错、不执行任何动作——模型输出永远变不成选择器、坐标、shell 命令或可执行 JS。

4.3 `field_text()`：小模型只写文本

只有当 operation 落到 TYPE_TEXT 时，才调用小 LLM（示例配置是 OpenRouter 上的 inception/mercury-2.5，reasoning 关闭；DeepSeek、Gemini、GLM 也可以通过 OpenAI 兼容接口接入）：

输入是 field_context() 裁剪后的上下文（页面文本只取前 6000 字符，历史只取最近 6 步）；
输出必须是恰好含一个 text 键的 JSON，非字符串、空串、超 2000 字符一律拒收；
缺值时返回 {"text": null}，执行器不猜、不编、不填个人信息。

实测录制中，Zurich 生成花 581 ms，London 花 346 ms。17 次 Jev 请求中位延迟仅 178 ms——小模型 + 短上下文才是速度来源。

五、为什么浏览器调用能从 1092 降到 101

README "Why it moves" 一节列了 8 条，每条都对应一个具体的工程补丁：

优化	做法	效果
单请求决策	operation + target 同一 observed state 下共享	TypeSafe 请求 22 → 17（中位）
默认无截图	Jev 只吃结构化 state，截图仅 inspector/录制开启	上下文大幅瘦身
单次原子快照	`snapshot.js` 一次浏览器调用读可见控件名、值、文本，并持有真实 DOM 节点引用	协议调用 1092 → 101
选中目标再验证	点击前比对 document、表单值、目标及周边上下文；纯动画不触发重预测；resolve 当前几何并拒绝被遮挡控件	动画不再误杀决策
有用的等待	combobox 输入后等可见 suggestion（上限 200 ms），其他交互最多两帧或 50 ms，且等待发生在执行日志之后	suggestion 到齐再决策
后台保持渲染	focus emulation 防后台动画节流，不切换 Chrome 可见 tab	后台 tab 不掉帧
只发可见文本	屏外文章体、footer 不进上下文	token 再降一截
中断文本复用	整个 text-helper 输入不变时，stale 重试复用已生成值	省一次小模型调用

另外两个细节：原生文本替换显式发浏览器 select-all 命令（修过一次 bug）；snapshot.js、browser.py 会做当前几何解析与 hit-test，被遮挡的控件直接拒掉。

六、证据与诚实：25% 是怎么测出来的

这是笔者最欣赏的部分：作者把测量边界写得极其诚实，没有"吊打 GPT"的标题党。

对照设计：6 次交替运行，同一任务、同一 Chrome profile、同一模型（TypeSafe jev-1.13.0 + Mercury 2.5）、同一视口 1120×780，初始导航不计入时钟。两组各通过 3/3。
结果：中位耗时 9.450 s → 7.092 s（-25.0%），中位 TypeSafe 请求 22 → 17，中位协议调用 1092 → 101。作者自注"三组样本太少，双边符号检验 p=0.25，不能算强统计结论"。
录制 run：17 次 Jev 请求、10 次交互 + 1 次显式 WAIT、2 次 helper 调用；Search 在 5.217 s 执行，最终 7.073 s 验收；TypeSafe 输入 90,558 tokens、输出 6,325 tokens；文本 helper 实付 $0.00006272（仅文本部分，不含 TypeSafe 与浏览器成本）。
泛化 smoke：同一策略打开 Gödel 不完备定理维基百科 2.798 s（精确 URL 验收），本地酒店 fixture（里斯本 + Design + 免费取消 + 打开 Casa Flora）1.896 s。
开发过程全保留：冻结合格候选前，原版跑出 9.302 s，两个 a11y/semantic-guard 候选 9.395 s / 10.157 s，首个 direct-DOM 候选 8.697 s 但因 name/value 提取不全导致独立校验失败——修递归 label 与 combobox value 后才收敛到 7 秒档。

一句话：这是"小样本受控输入对比"，不是通用 Agent benchmark，Google、网络、路由、浏览器缓存都还是活的。

七、安全设计：快，但不给模型开 shell

结合本站此前的 AI 浏览器 Agent 安全分析，jev-ultrafast 的安全取舍值得单列一节：

模型输出永不直通执行层：validate_choice 拦非法概率分布，field_text 只接受小 JSON，输出变不成 selector、坐标、shell、JS。
执行前双重 freshness：predict 前查一次，act 里 Browser.act 在输入前紧贴再查一次，文本生成之后也查。
DONE 不自证：DONE 只是候选操作，最终成功与否由 examples/flights.py 这类独立校验器判定（查 one-way 设置、起终点、日期、可见航班选项）。
残留风险：仍复用宿主 Chrome profile（owned tabs 共享 profile），页面文本被明确标为 untrusted data，prompt 注入仍需上层做内容清洗与敏感操作确认。

八、上手实操

git clone https://github.com/browser-use/jev-ultrafast.git
cd jev-ultrafast
uv sync
cp .env.example .env
# 填 TYPESAFE_API_KEY 和 TEXT_MODEL_API_KEY（示例是 OpenRouter key）
uv run jev

打开 http://127.0.0.1:8766，点 Start demo → Run automatically，inspector 会实时显示编号元素、operation/target 概率和已执行动作；Choose next 可单步暂停。Chrome 经 Browser Harness 连接，连不上先跑 uv run browser-harness --doctor 并允许远程调试。

换任务只需换 URL + goal：

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.'

# 带独立校验的航班全链路（含 trace 落盘，不选座不下单）
uv run --env-file .env python examples/flights.py --keep-open

开发自检是离线优先：uv run ruff check .、uv run pytest、node --check jev_ultrafast/snapshot.js，真机控件检查用 uv run python scripts/check_guards.py（不调模型），录制用 scripts/record_flights.py + scripts/render_demo.py。

九、局限与展望

作者在 Evidence and limits 里自曝的短板，翻译一下：

DOM reader 只覆盖常见 HTML/ARIA 控件，没有实现完整 accessible-name 算法；
Shadow DOM、iframe、canvas、文件上传、弹窗新 tab、嵌套滚动、任意键盘部件——全部不在 MVP 范围内；
Owned tabs 共享现有 Chrome profile，隔离性不如容器化云浏览器；
选对 operation 也可能选错 target，DONE 永远需要外部验证。

展望三条线最值得跟：

把 101 次再往下压：当前 combobox 等待、geometry 解析仍是残留大头，事件驱动的精准失效（scoped click guards 已朝这方向走）还有空间。
与主仓库能力合并：browser-use 主线的通用 tool-use、长任务规划若能吃上这套快照 + fan-out，通用 Agent 也能提速。
云化：仓库已挂出 Browser Use Cloud waitlist，ultrafast 上云后多租户隔离、profile 管理、结果校验会是真正的生产门槛。

十、总结

jev-ultrafast 的价值不在 7 秒这个数字，而在它示范了一套可复制的方法论：

用索引元素表代替截图 + 裸选择器，让模型只做选择题；
用推测性扇出把两次决策压缩进一次请求；
用原子快照 + 执行守卫把浏览器 I/O 降一个数量级；
用小模型写文本、大模型定方向做成本分层；
用独立校验 + 诚实测量守住可信度。

下次当你觉得"Agent 太慢是因为模型不够强"时，不妨先数一下你的 CDP 调用次数——答案可能和 browser-use 团队的一样：瓶颈在工程，不在智能。

常见问答 FAQ

Q1：jev-ultrafast 和 browser-use 主仓库是什么关系？

它是 browser-use 团队的实验性极速分支，主打动态索引动作空间与单请求决策，主仓库则更通用、支持更多场景与模型，两者定位互补而非替代。

Q2：为什么 jev-ultrafast 不给 Agent 看截图？

默认循环只消费结构化快照（URL、标题、可见文本、索引控件），截图只在调试器和录制时开启，这样可大幅削减 token 与延迟， Inspector 需要时才单独订阅。

Q3：一次决策真的只需要一次模型请求吗？

是的。operation 头与各 operation 的 target 头在同一个 TypeSafe 请求内做推测性扇出，未被选中的 target 头直接丢弃，用一次网络往返换两次决策。

Q4：TYPE_TEXT 的文本是从哪里来的？

由一个小型 OpenAI 兼容模型按 JSON 输出生成，受严格校验约束，执行器只接受恰含 text 键的合法 JSON，缺值返回 null，绝不由主策略硬编码。

Q5：7.073 秒的成绩可以直接复用到生产吗？

不能直接照搬。它是单任务三组对照的中位值，且 Shadow DOM、iframe、canvas、上传、新标签页等仍不支持，DONE 也必须配独立结果校验才能采信。

参考资料

如果这篇拆解帮你理解了极速浏览器 Agent 的设计，欢迎订阅本站 RSS 获取后续的 Agent 架构系列。

原创技术博客 · 开源项目分享 · AI全栈创作社区 idao.fun

jev-ultrafast 深度解析：7 秒订机票的浏览器 Agent 是如何炼成的