7.1 秒，从一句自然语言，到 Google Flights 上列出苏黎世飞伦敦的航班，全程 1 倍速录屏，包含文本生成、模型调用和加载等待。Browser Use 与 TypeSafe 合作的开源 Agent 仓库 jev-ultrafast 靠这个数字刷屏，9 月 16 日创建，三天冲到 8,346 星。
我把它 clone 到本地，跑了官方全部离线测试，审计了它「一次决策要发几次网络请求」，把两个真实页面的动作表重放成请求体算了账，还独立复核了那段 7.1 秒视频和 $0.0039 的账单。
先说清楚一件事：我没有 TypeSafe 的 API key，没能跑通端到端任务。TypeSafe 目前是 waitlist 制，仓库 issue 里有人直接问「怎么拿到 TYPESAFE_API_KEY」。所以下面所有结论来自三处可独立验证的材料：官方 31 个离线测试与源码、官方公布的录制数据、以及我用真实网页 DOM 做的重放。跑不通的部分我会标出来。
7.1 秒是真的，但计时器是后开的
官方性能文档写得很直白：计时起点是「初始首页观察之后的第一次预测」，终点是「被接受的 DONE 选择」。浏览器启动、初始导航、以及任务结束后的独立结果校验，全部在计时之外。
这不是注水，是常规口径，但读者该知道这 7.1 秒买的是什么：页面已经打开、正文已经渲染完之后，Agent 从「看第一眼」到「确认结果正确」的耗时。
视频我也复核了。ffprobe 读出来 7.566 秒、227 帧、恒定 30fps；7.566 秒 = 公布的 7.073 秒运行 + 0.5 秒结尾停留，时间轴对得上。把浏览器画面区域单独裁出来逐帧比对，227 帧里有 224 帧互不相同——它不是靠重复帧把时长凑出来的。
有一处对不上：测量文件里写 video/source_frames = 187，而视频实际是 227 帧。这更可能是渲染脚本重跑之后元数据没同步，但可以确定的是，视频右下角那个跳动的秒表是渲染时按帧序号算出来的，不是硬件计时器。所以「1 倍速」这件事，外部无法只靠看视频证明，它依赖录屏时间戳被忠实映射。
还有一点值得给作者加分：官方在性能文档里保留了匹配对照的完整数据，三对样本，中位耗时 9.450 秒降到 7.092 秒，然后自己写了一句「三对样本太少，做不了强统计声明（双尾符号检验 p = 0.25）」。同一份文档里还留着自己失败的开发尝试——有一次跑到 8.697 秒更快，但独立校验没通过，被毙了。愿意把推翻自己的数据留在仓库里，这在爆款项目里不多见。
它把「决策」从字符串生成里抠了出来
jev-ultrafast 不是一个模型，是 Browser Use 给 TypeSafe 的 Jev 模型写的一层浏览器运行时。
Jev 是 TypeSafe 9 月 15 日发布的 System One 模型。它的输出不是文本，而是类型安全的决策值加校准概率——你事先定义好问题和选项，它一次查询并行吐出所有选项的概率，不做逐 token 自回归。官方定价 $0.042 每百万输入 token，输出 token 免费，端到端 70 到 500 毫秒。名字取自杰文斯（William Stanley Jevons），那位提出「效率提升反而推高总消耗」的经济学家。
这套东西落到浏览器里，做法是这样的：每次观察页面，运行时生成一张带编号的元素表，每个可见控件占一个索引（同一个 DOM 节点即使既能点又能填，也只占一个索引）。然后把整个目标、页面正文、元素表、最近十步动作打包，一次请求里同时问四个问题：下一步做哪个操作、如果点那么点哪个、如果填那么填哪个、如果下拉那么选哪项。
只有被选中的那个操作对应的目标头会被读取，其余的即使模型答了也不执行。这样一来，过去「先问该做什么，再问点哪里」的两次往返被压成一次，同时保证了不会拿一个 TYPE_TEXT 的目标去执行点击。
整个 Agent 主循环 agent.py 是 174 行。快照逻辑 snapshot.js 107 行。
我把它的每一步都拆开算了
离线部分全部通过。官方测试 31 个断言 1.04 秒跑完，一个不挂；ruff 静态检查干净；两个前端脚本 node --check 通过；uv build 能正常打出 wheel。代码总量 1,681 行 Python（其中测试 320 行），对一个需要驱动真实浏览器的项目来说小得反常。
一次决策确实只有一次网络往返。 我替换掉 HTTP 客户端做拦截，捕获到的请求体里同时挂着四个问题头：operation、click_target、type_text_target、select_target。返回的答案里，目标头带着完整的概率分布，但代码只取与所选操作匹配的那一个。README 里「两个决策，一次网络往返」的说法成立。
真实页面的账单我也算了。我用浏览器在目标站点上原样跑了一遍官方的快照脚本，拿到真实的动作表，再喂回官方 Python 的 action_space() 和 choose() 生成请求体：
| 页面（1120×780 视口） | 可点元素 | 请求体 | 粗估 token |
|---|---|---|---|
| Google Flights 首页 | 21 个元素 / 24 个动作候选 | 9,935 字节 | 2,483 |
| GitHub issue 列表页 | 57 个元素 / 60 个动作候选 | 17,395 字节 | 4,348 |
拿这个数字去对官方录制：那次跑动用 17 次请求消耗 90,558 输入 token，均摊每次 5,327 token。我的重放是 2,483 到 4,348，量级一致——说明 90,558 这个统计可信，而且后续步骤因为要带上历史动作和更满的结果页，单次开销还会涨。
账单也算得回来。90,558 × $0.042/百万 = $0.0038，官方宣传的任务成本是 $0.0039，差 2.6%，基本就是四舍五入。输出 token 不收费。折算下来一次跨境航班搜索不到 3 分钱人民币，而且这个数字里还不含浏览器和文本助手的开销（那部分官方实测是 $0.00006272）。Doom 那个演示跑 10 次决策每秒，作者说约合 $7 每小时。
安全边界经得起打。README 声明「模型输出永远不会变成选择器、坐标、shell 命令或可执行 JavaScript」。我构造了六种畸形响应去打它：把 choice 换成 document.querySelector('#x')、换成一段 script 标签、概率之和只有 0.5、概率里塞 NaN、选了个不是最大概率的选项、概率集合和候选对不上。六种全部被拦，一行动作都不会执行。
顺带发现一个代码里没写的原因：快照最多保留 250 个动作候选，而 TypeSafe 官方博客明确说 Jev 的选项基数上限是 255。250 这个数字大概不是随手取的。
视频、代理，和两个 AI 编出来的 issue
代理这一条，中文用户几乎必踩。issue #16 报告：httpx 在模块导入时就建了连接池且不处理代理，只要环境变量里有 ALL_PROXY=socks5://，程序在 import 阶段直接崩，报 ImportError: Using SOCKS proxy, but the 'socksio' package is not installed。我在沙盒里原样复现了。Clash、v2ray、xray 的默认配置都会导出这个变量。
代码默认值里还埋了一个坑。文本助手的 base URL 在代码里的默认值是 https://api.deepseek.com/v1，而 .env.example 和 README 写的是 OpenRouter。也就是说，一个人照着 README 只填了 TEXT_MODEL_API_KEY 就运行，他填进去的 OpenRouter 密钥连同页面文本会被发到 DeepSeek 的接口上。这条是 issue #36，我核对源码 164 行属实。
生态侧的数据就不那么好看了。仓库三天收了 40 个 PR，39 个没合并，唯一合掉的是作者自己改 README 的一条。16 个 issue 全部处于 open，一个都没关闭。三位贡献者里只有一位（作者本人），3 个 commit。
更麻烦的是信噪比。这里面混着明显是 AI 生成的幻觉报告，其中一条标着 HIGH：声称 README 的 clone 地址指向了错误的仓库——我 clone 过了，地址是对的；另一条说 agent.py 被压缩成了一行行的超长代码、违反项目自己的 120 字符行宽——实际文件 174 行、格式正常、ruff 检查干净。两条出自同一个账号，前后相隔 7 分钟。
也有真材实料的报告。issue #23 里，一位用户拿中国铁路 12306 的购票页去跑，结果是：60 个动作全部是往同一个输入框里打字，跑了 77 秒，120 次决策预算耗尽，出发站和到达站最后都被填成了「北京」。原因是快照只收集原生控件（a[href]、button、input 等）和固定清单里的 ARIA 角色，而 12306 的站点联想行是用裸 li／div 自己绑点击事件做的，模型根本看不见，只能反复重试它唯一看得见的那个框。
这暴露了动态索引动作空间的真实边界：它不是「看得懂网页」，而是「只看得见被预先定义好的那一类控件」。Google Flights 能用，是因为 Google 老老实实写 ARIA 标注。
值得看，但现在别急着拿它当脚手架
把结论分三层说。
方法层面，这个 demo 真的有价值。它证明了一件事：把「决策」从 LLM 的字符串生成里抠出来，换成一次并行的概率输出，是 Agent 提速最直接的一刀——不需要换更强的模型，不需要减少步骤，只是把「生成一段话再解析」改成「直接给答案」。这和 Pi Agent 砍工具数、unlazy 给完成状态装闸门是同一个方向：约束模型能做什么，比让它更聪明更有效。
工程层面，代码值得读。1,681 行、31 个测试、零运行时依赖、主循环 174 行，还能把「模型输出不变成选择器」这条安全不变量守住。想自己写浏览器 Agent 的人，这个仓库一小时能读完，比啃框架文档快得多。
产品层面，别急着接。三点：TypeSafe 还是 waitlist，拿不到 key 的话开源代码只能跑离线测试；中文站点上表现堪忧，12306 那种非标准控件直接崩；官方自己承认这不是基准测试，只是「一个任务在一个已有浏览器配置上跑三次」，而且性能对照的 p 值只有 0.25。
一句话：7.1 秒是真的，$0.0039 也是真的，但这两个数字测量的是「决策够快」，不是「网页够懂」。
想继续往下看，可以读这三篇：Pi Agent 实测 讲的是同一件事的另一个解法——默认只给模型四个工具；unlazy 深度评测 解决的是「Agent 说做完了怎么验」；OpenRouter 免费大模型全量拆解 里则有 Jev 上架 OpenRouter 之后的路由逻辑。