发帖缘起：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.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 秒：

第 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

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