智猩猩AI整理

编辑：金水

最近，X 上一个名为Jev的模型持续引发关注。

我们此前已经对 Jev 做过详细介绍《》。

与 GPT、Claude 等大语言模型不同，Jev 并不以文本生成为主要任务，而面向高频决策场景，将输入状态映射为预先定义的结构化选项，并输出对应的决策结果与置信度。

打开网易新闻 查看精彩图片

这种模型的核心价值不在于生成长文本，而在于以更低的延迟和成本完成大量高频、离散的判断任务。

Browser-Use 围绕 Jev 开源了 jev-ultrafast 项目，将其用于浏览器 Agent 的高频动作决策。

与传统 Browser Agent 通过截图理解网页、再调用大模型决定下一步操作的方式不同，jev-ultrafast 直接读取浏览器 DOM，将网页中的可交互元素转换成结构化状态，再让 Jev 决定执行什么操作，以及操作哪个元素。

打开网易新闻 查看精彩图片

项目目前已经获得 12.1k GitHub Stars。

从公开演示来看，jev-ultrafast 可以在约 7 秒内完成一次苏黎世到伦敦的航班检索，同时显著减少浏览器协议调用次数和模型调用成本。

更值得关注的是，它并非简单地把一个“更快的模型”接入现有 Agent，而是重新设计了浏览器 Agent 的决策链路。

打开网易新闻 查看精彩图片
打开网易新闻 查看精彩图片

01

Browser-Use 把它塞进了

浏览器 agent

传统 Browser Aent 通常采用：截图 → 视觉理解 → 推理 → 决策 → 执行 → 再截图。

这种方案具有较强的通用性，但每一轮操作都可能涉及截图、视觉编码、大模型推理以及浏览器通信。当任务需要连续执行多个点击、输入和页面跳转时，延迟会不断累积。

jev-ultrafast 采用的是另一种路径：读取 DOM → 结构化页面状态 → Jev 决策 → 执行 → 校验。不再让模型“看截图”，转而直接读取 DOM。

打开网易新闻 查看精彩图片

网页本身已经包含大量结构化信息，按钮、输入框、下拉菜单、链接等交互元素都存在于 DOM 和 ARIA 结构中。对于浏览器操作而言，这些信息比截图中的像素更加直接。

因此，jev-ultrafast 会首先读取当前页面，并生成一个带索引的动态 Action Space，例如：

打开网易新闻 查看精彩图片

模型看到的不再是一张网页截图，是一组结构化的可操作元素。

这样一来，Agent 的任务就从“理解整张网页”转变为“在当前状态下选择正确动作”。一次请求，同时决定“做什么”和“对谁做”。

在传统 Agent 中，一个动作可能需要先判断操作类型，再确定具体目标。

jev-ultrafast 将两个决策合并到一次请求中：

target = [7]

或者：

target = [3]

也就是说，Jev 在一次调用中同时完成，Action 指执行什么操作，Target 指操作哪个元素。

因此，每轮决策只需要一次模型请求，减少了网络往返和中间推理步骤。

对于需要输入具体文本的场景，系统再调用一个小型文本模型生成内容。也就是Jev 负责决策，小模型负责文本生成，浏览器负责执行。

不同模型承担不同类型的任务，而不是让一个大语言模型覆盖整个 Agent Loop。执行层负责校验，而不是直接相信模型输出。

另一个关键设计是，模型的输出并不会直接转换成 Selector、坐标或者 JavaScript。

执行器会根据模型给出的元素索引，重新从当前 DOM 中定位真实节点，并在执行前检查页面状态。

例如元素是否仍然存在；页面是否发生变化；目标元素是否被其他元素遮挡；当前元素是否仍然处于可交互状态。

执行完成后，Agent 再读取新的页面状态，进入下一轮决策。

因此整个过程可以抽象为：结构化状态 → 离散决策 → 确定性执行 → 状态校验。

这也是 jev-ultrafast 与传统视觉 Browser Agent 最大的区别之一。

02

性能评估

对于 Browser Agent 来说，模型本身的响应速度并不能完全代表系统性能。真正影响用户体验的，是端到端任务耗时、浏览器交互次数以及 API 成本。

jev-ultrafast 给出了几组公开测试结果。

  • 7 秒完成航班搜索

在 Google Flights 示例中，Agent 接收到：

Find one-way flights from Zurich to London on September 20, 2026, for one adult in economy.

从打开页面到显示符合条件的航班结果，整个任务耗时约 7.073 秒。

打开网易新闻 查看精彩图片

另外两个公开示例中，打开 Wikipedia 上的 Gödel 不完备定理页面2.798 秒，搜索并筛选酒店1.896 秒。

这些结果体现的并不仅仅是 Jev 本身的推理速度，实为整个浏览器 Agent Loop 的压缩。

  • 任务耗时降低约 25%

在相同任务和浏览器环境下进行对比测试：任务中位耗时从9.450 秒到7.092 秒耗时下降约 25%。

打开网易新闻 查看精彩图片

与此同时浏览器协议调用次数从1092 次 到101 次调用次数减少超过一个数量级。

这意味着性能提升来自页面状态获取、模型调用、动作执行和浏览器通信的整体优化。

  • 单次任务成本低至 0.0039 美元

以公开的苏黎世—伦敦航班任务为例，整个任务的 API 调用成本约为$0.0039也就是不到半美分。

其中，Jev 的输入价格为每百万 tokens 0.042 美元，输出不收费；而文本生成任务则由额外的小型文本模型完成。

打开网易新闻 查看精彩图片

因此，在大量简单浏览器操作中，将高频决策从通用大模型中拆分出来，可以显著降低整体调用成本。

但这些数据并非通用 Benchmark，这些性能数字来自项目当前公开的实验和 Demo。

官方说明，这些测试主要在相同任务、相同浏览器环境下重复运行，并不等同于覆盖各种网站和复杂操作的通用 Browser Agent Benchmark。

目前仍存在一些限制，例如Shadow DOM；iframe；canvas；文件上传；部分复杂键盘组件；嵌套滚动等。

因此，jev-ultrafast 当前更适合被理解为一种浏览器 Agent 架构探索和工程实践，而不是已经完成全面验证的通用方案。

03

如何接入自己的电脑

接入自己的电脑也很简单。先把仓库拉下来，用 uv 把依赖一装，没装 uv 就先 pip 装一个：

uv sync

然后 cp 一份环境变量模板，填俩 key，一个是 TypeSafe 的，官网申请现在还得排队，一个是用来打字的文本模型，demo 默认走 OpenRouter 上的 mercury，想换 Gemini、GLM、DeepSeek 也行，只要兼容 OpenAI 格式：

# TEXT_MODEL_API_KEY=你的 OpenRouter Key（也可换 Gemini / GLM / DeepSeek，兼容 OpenAI 格式即可）

Chrome 那边靠 Browser Harness 连，uv sync 时就顺手装好了，头回跑前敲一下 browser-harness --doctor，按提示在 Chrome 里放开远程调试。

完了 uv run jev，开 127.0.0.1:8766，点 Start demo 让它自己跑，你就看着它运行：

uv run jev

想写自己程序也行，import 进来，给个网址加一句大白话目标，剩下的它自己来：

        print(state["elapsed_ms"], state["status"])

仓库里维基和航班俩例子都现成，航班那个还会真的核对路线日期，但绝不帮你下单：

uv run --env-file .env python examples/flights.py --keep-open

04

总结

jev-ultrafast 值得关注的并只是“7 秒完成一次航班搜索”这一单一指标，而在于它展示了 Browser Agent 的另一种技术路线。

jev-ultrafast 尝试将浏览器环境直接结构化，Jev 负责高频决策，小型语言模型负责必要的文本生成，浏览器负责提供结构化状态，执行器负责完成动作与安全检查。

这种架构的核心思想可以概括为：不是让大模型承担 Browser Agent 的所有工作，是根据任务类型，将感知、决策、生成和执行拆分给不同模块。

对于浏览器这类本身具有大量结构化信息的环境，这种方法能够减少视觉编码和长链路推理带来的延迟，同时降低模型调用次数与成本。

当然，jev-ultrafast 目前仍处于早期阶段，在复杂网页结构和更广泛的浏览器操作场景下仍需要进一步验证。

但从技术路线来看，它提供了一个值得关注的方向，当 Agent 可以直接获得结构化环境状态时，是否还需要让大模型通过“看图—理解—推理—生成”的方式完成每一次简单操作？

jev-ultrafast 给出的答案是，对于一部分高频、结构明确的浏览器任务，专用决策模型 + 结构化状态 + 确定性执行，可能是一条更轻量的实现路径。

关注+星标，获取AI前沿进展与开源一线动态