让computer use 速度飞起来：JEV-Ultrafast 的 DOM 决策链路实测

Queen Laura

JEV 实测：同一个 computer-use 任务，从 271 秒到 27 秒

发帖缘起：JEV 发布那天刷屏了，最抓人的说法是「7 秒查完一趟机票、每步不到 3 分钱」。我看完第一条反应不是转发，是想确认这东西能不能用到我这台 Linux 机器上。我平时让 agent 操作桌面用的是 computer-use 插件，速度一直是它的短板，我在前帖里形容过是「老年手速」。当晚就去申请了 JEV 的 Waitlist，第二天通过，然后花了两个晚上把链路拆开重接了一遍。这篇是完整记录。

前帖：《把 DSH 装进口袋：IM + Pocket + Computer Use 三个插件实测记录》→ lcz.me/topic/1678/9

适合谁看：已经在用 computer-use、嫌它慢的；高负荷computer-use 应用需要省token的人

先把我实测用到的东西放这儿：

我这台机器上的 computer-use 插件（Linux X11，只用 python3 + libX11 + libXtst + ImageMagick，没有重依赖）→ github.com/asdasdsdsdasdasdasd/dsh-computer-use
JEV / Jev Ultrafast（browser-use 出品，TypeSafe 的 System One 模型驱动）→ github.com/browser-use/jev-ultrafast
TypeSafe 文档（下面要用的 Choice 和 confidence 都定义在这）→ docs.typesafe.ai

结论：同一个任务、同一台机器，操作时间从 271.4 秒降到 27.41 秒，差 9.9 倍，指针全程在屏幕上真的动。

录屏

Youtube Video

▲ 全程 1 倍速，没有剪辑。鼠标是真的在屏幕上移动、滚动、点击。

一、先说数字

任务是这样一句话：

打开 NBA 官网首页，逐屏往下翻，找到库里的新闻，点开，从头翻到尾。

	改之前	改之后
总耗时	271.4s	27.41s
交互轮次	13 次工具调用	8 步
平均每步	19.4s	3.08s
怎么读屏	全屏截图送进多模态模型	读结构化 DOM，46ms
怎么决策	模型看图后输出一段话	TypeSafe 一次 Choice，约 1s

271.4 秒那次我事后数了一遍：13 次调用，每次 19.4 秒。这 19.4 秒里浏览器真正干的事，滚一屏或者点一个链接，是毫秒级的。

时间花在这些地方：截取 2560×1440 全屏、编码成图片、把图片塞进 agent 的上下文、模型读完图决定下一步、再发出动作。中间两步是纯开销，而且每加一步就多花一次。

也就是说，慢的不是鼠标，是每一步都要一个多模态模型重新看一遍屏幕。

二、JEV 有句话很关键

翻 JEV 代码的时候看到 README 里这段：

It never sends a screenshot to a big model. Instead it reads the screen deterministically, asks a small classifier which action comes next, and only calls a writing model when a text field genuinely needs free text.

拆开是三条：读屏要确定性地读，不让模型看图；决策是选择题，不是生成，因为大多数步骤不需要计划，只需要从一张短列表里挑一个；只有真的要填字时才请语言模型。

于是每步从「截图 + 多模态推理 + 等几秒」变成「读状态 + 一次 Choice + 执行」。

JEV 原生操作的是浏览器里的一个 tab。我想要的更多一点：操作我那块真实桌面，让指针真的动起来。

三、怎么接上去

链路改成这样：

CDP 读结构化 DOM（46ms，截图不进任何模型）
        │
        ▼
TypeSafe jev-latest 一次 Choice
  ├─ operation    : CLICK / SCROLL_DOWN / SCROLL_UP / DONE / BLOCKED
  └─ click_target : 编号元素表（带 covered 遮挡标记）
        │
        ▼
XTEST 真实输入（指针移动、点击、滚轮）
        │
        ▼
read / decide / act 分段计时 → JSON

动手前我先验证了三个前提，不然写完发现走不通就白干。

读屏这块直接拿 JEV 的 snapshot.js 用。它本来就在做「原子性地读可见控件、保留真实 DOM 节点、算遮挡」，我实测 46 毫秒读完 72 个可点元素。

动作这块，装了 python-xlib 之后测出 XTEST: True，指针可以真的移动和点击。用 CDP 自己的合成事件也能点，但那样指针不动，录屏上看像页面自己在变，说服力不够。

坐标这块，Chrome 用 --start-fullscreen 起来之后我测了一下：视口 2560×1440，屏幕 2560×1440，screenX/screenY 都是 0。视口坐标就是屏幕坐标，窗口偏移和标题栏高度那套换算全省了。

四、改完之后的逐步数据

8 步，27.41 秒，平均每步 3.08 秒：

步	操作	置信度	本步	read	decide	act
1	SCROLL_DOWN	0.77	7.20s	4450ms	1020ms	1725ms
2	SCROLL_DOWN	0.66	2.29s	81ms	915ms	1292ms
3	SCROLL_DOWN	0.68	3.19s	343ms	1404ms	1445ms
4	CLICK e35	0.70	1.39s	75ms	922ms	389ms
5	SCROLL_DOWN	0.17	2.81s	373ms	986ms	1447ms
6	SCROLL_DOWN	0.84	2.93s	746ms	894ms	1293ms
7	SCROLL_DOWN	0.30	3.74s	2536ms	970ms	231ms
8	DONE	0.33	1.07s	66ms	1006ms	0ms

第 4 步是它自己认出并点中库里那篇 THE ATHLETIC: CURRY'S CHOICE SHAPES WARRIORS FUTURE，最后停在 nba.com/news/steph-curry-decision-warriors-future。

第 1 步 read 花了 4.45 秒，原因是首次读屏撞上页面正在加载，不是链路本身的问题。分段计时就是为了能一眼看出这种事。

五、JEV 的优势在哪

省下 9.9 倍的根源是读屏方式。改之前每步都要把一张 2560×1440 的图送进模型，再等它看完；JEV 读的是结构化 DOM，元素的角色、标签、能不能点、有没有被盖住，全是确定字段，46 毫秒读完，而且读屏这件事不再产生模型费用。每步从 19.4 秒降到 3.08 秒，省掉的 16 秒就是图像编码、传输和模型看图那一趟往返。

决策被还原成一道选择题。模型拿到的是一张编号元素表，它只需要回答「操作是哪个、目标是几号」。不用写描述，不用输出坐标或者选择器。JEV 的代码层从元素表里解析出每个可执行目标，模型输出永远不会变成选择器、坐标或可执行 JS。这既省时间，也把注入面收窄了。

概率和置信度是模型原生的。每步都返回一整套概率分布加一个校准过的 confidence，上表八步从 0.17 到 0.84 都有。这意味着链路可以按置信度分流：低置信就不落地、重新读屏，连续几次低置信直接停下，而不是硬点。我自己的 fork 里加了这层门控。

遮挡被当成一条事实交给模型。JEV 的读法会把「被别的控件盖住、点了会被拒」的元素标成 covered。模型看到这个标记，会先去滚动或者先关掉遮住它的东西，而不是反复点一个点不到的按钮。NBA 首页有 cookie 弹窗，改之前那版就卡在这里空转了 28 轮。

再补一条实际感受。改之前那版靠截图理解页面，cookie 弹窗或者横幅广告一盖住正文，它没法判断下面还有没有内容，只好先挪鼠标把这些浮层一个个关掉再往下走，光这一件事就能吃掉几十秒。JEV 读的是 DOM，遮挡关系是直接读出来的事实：哪个元素被盖住了、被谁盖住、盖住之后那个元素还能不能点，全都写在元素表里。模型不用先处理遮挡才知道正文在哪，能点就直接点，不能点就去点那个遮挡物。省下来的不是点那一下的时间，是试探和来回试的时间。

动作是真动作。XTEST 走的是真实指针和真实按键，页面收到的是正常用户输入。配合全屏 Chrome，整条链路里没有一处坐标换算。

每一步都能复盘。read、decide、act 三段分开计时，每步的置信度和落点都存成 JSON。哪一段忽然变慢，看一眼就知道。

六、还不行的地方

decide 那一秒现在是最大的单项开销。JEV 官方 README 报的是 0.13 到 0.38 秒，我这里是 894 到 1404 毫秒，差的部分应该在到 TypeSafe 的网络往返上。

act 也有水分，1.3 到 1.7 秒是因为 14 个滚轮 tick 每个都 sync 了一次显示，间隔还能再压。

还有一条要说清楚：这套只在页面能被 CDP 读到的时候成立。原生桌面应用没有 DOM，那类场景仍然要走 OCR 加无障碍树那条路。这一版没做 OCR 回退，是明确的缺口。

改之前那版也不是没有可取之处。它每步都截图确认，所以不太会点错。慢和稳本来就是一件事的两面。

七、想试的话，这三个地方能免费用

除了去官网申请 Waitlist，还有三个渠道可以直接体验 Jev：

Vercel AI Gateway：目前输入、输出都免费，限免到 9 月 25 日，适合直接接 API，模型名写 typesafe-ai/jev。→ vercel.com/ai-gateway/models/jev
OpenCode Zen：官方已经列出「Jev 1.13 Free」，限时免费，还没公布结束日期，需要登录拿 Key。→ opencode.ai/docs/en/zen
Venice API：新账户有每日免费额度加 500 welcome credits，不用信用卡，Jev 只支持 API，属于额度内体验。→ venice.ai/lp/jev

这三个都是各家自己公布的限免政策，随时可能变，以官方页面为准。

Ben Lee

好帖必须点赞，JEV是新玩家福利，跟着楼主学习起来

Xiaote

数据很扎实，尤其把 read/decide/act 分段计时——这一步就比大多数「体感快多了」的分享有价值。补几点，把结论钉死、也方便别人复现：

9.9× 是「读屏方式 + 决策方式 + 动作注入」三个变量一起换的结果（还叠了 13 步→8 步的步数差）。想归因就做个 2×2：{截图 / DOM} × {自由生成 / Choice}，动作层固定成同一个（都用 XTEST 或都用 CDP 合成）。耗时同时给「每步」和「每动作」两种口径，否则读者会拿 271/13=20.9s 对 27.4/8=3.4s 说事。
decide 的 894–1404ms，先量网络往返：同链路 ping / 一次空 Choice 的 RTT，差额才是分类器本身。若 RTT 占大头，本地小分类器或裁剪/缓存元素表，可能比换模型更有效。JEV README 报的 0.13–0.38s 大概率是近端数字，跨洋对不上属正常，写清这点即可。
confidence 门控方向对，但当概率用之前先做校准：拿一批带标签的步画 reliability diagram，或至少按操作类型分阈值（DONE/BLOCKED 与 CLICK 代价不对称）。低置信重读要设上限，否则会退化成另一种空转。
act 的 1.3–1.7s：14 个 wheel tick 每次 XSync 是纯浪费，合成一批事件后一次 flush，或减少 tick、加大单次滚动量；给「14 次 sync vs 一次 flush」一组对照就有说服力。
原生桌面缺口，除了 OCR，Linux 上还有 AT-SPI（pyatspi）这条确定性读法：能拿角色、名称、可执行动作和几何，和 JEV「确定性读 + Choice」是同一套哲学，比 OCR 稳且便宜；OCR 留最后回退。
安全面提醒：元素表是模型输入，页面文本（label/aria）就成了不可信输入，可能诱导 Choice；元素文本要限长、去控制字符。XTEST 是全局坐标，跑的时候别把凭据/私聊窗口留在同一屏。
单个任务的方差可能很大（第 1 步 read 就吃了 4.45s 的加载）。建议固定 10 个站点 × 3 次取中位数，连同 JSON trace 一起发，别人才能真复现。

terry

我刚做视频说这玩意没啥鸟用，看来有点用，置顶起来，不能因为我的个人好恶错误引导。

Queen Laura

@terry 说:

我刚做视频说这玩意没啥鸟用，看来有点用，置顶起来，不能因为我的个人好恶错误引导。

我是想抽点业余时间用这个优化后的 computer-use,结合 Deepseek V4.1 的多模态识图，开发一个自动报销的应用。
我们公司用 concur 报销太麻烦了，用手点的步骤很多，又都是重复性的创建报销类目，填税号，金额，上传发票啥的。都让AI操作computer-use做就挺好，我只管告诉他行程日期范围，然后一股脑的把发票都丢给他就好了 XD.
之前那个computer-use skill差不多每次操作都要截图+OCR，太慢了。现在换成Jev Ultrafast速度真的飞起来。

kos or

感謝分享, 這解決了Agent操作瀏覽器緩慢的問題, 可能Jev有針對DOM 做強化訓練, 速度真快

unafyang

感觉就是不需要用脑子的地方交给jev，稍微有点难度就歇菜。但我们老特喷的也一点都没问题，老老实实说你在特定场景提速就行，还宣称什么“零幻觉”，然后深入研究发现就是“拍脑子做决定”。反正这个营销直接喷烂他。我的态度就是区分“格式保证”和“认知可靠性”

snailium

其实把截图分析改成CDP就已经加速很多了。但是有些靠脚本加载的网页，从DOM那里读出来的就是一堆JS调用，还要fallback到截图分析。对应Hermes里面就是browser（看DOM）和browser_vision（看截图）两个工具。

JEV实际加速了多少，要跟没有JEV的DOM路线对比

crazypeace

@snailium

对, 我也这么觉得.
从截图到操作DOM, 这一步加速我猜测是加速幅度最大的.

Queen Laura

@snailium 说:

其实把截图分析改成CDP就已经加速很多了。但是有些靠脚本加载的网页，从DOM那里读出来的就是一堆JS调用，还要fallback到截图分析。对应Hermes里面就是browser（看DOM）和browser_vision（看截图）两个工具。

JEV实际加速了多少，要跟没有JEV的DOM路线对比

对，你说的有道理，测试还是得控制变量才行。我这几天实际用下来，感觉也是像你说的“截图分析改成CDP就已经加速很多了”

williamlouis

它准确率不是100%
应用到财务流程中？

Queen Laura

@williamlouis 说:

它准确率不是100%
应用到财务流程中？

也不算严格用在财务流程里吧，我想做的其实就是一个自动化创建、提交报销单的应用，输入出差时长，或者报销类目的简单自然语言的描述，以及发票，水单之类的文件，然后这个应用自动化分析，审核，最终提交报销单，达到减少员工的报销工时的目的。我们现在报销攒的多了，至少花一下午，甚至花一天去做提交
只要报销单正确率能到90%左右就好，这个应该可以实测多轮以后加一些自动化审核流程做到。最终提交的报销单有些小错误也不要紧，有外包的人员来审核报销单的错误，打回来再由人来改就好了。

抡锤者