浏览器 Agent 为什么慢？这个开源项目把每步决策压成了一次选择
写过浏览器 Agent 的人大概都有这个体会：让它点个按钮、填个表单，模型要在每一步把当前页面读一遍、想一遍、再输出一段结构化 JSON。
页面元素一多，光是把这些内容塞进 prompt 就是几千 token。一步慢一点，十步下来就是几十秒。
问题往往不在模型不够聪明，而在每一步的决策成本太高。
jev-ultrafast 这个项目，就是冲着这件事去的。
01 它解决的是哪一段慢
浏览器自动化的链路其实很长：取页面 → 理解结构 → 决定点哪 → 执行 → 等加载 → 再理解。
传统做法里，"理解页面"和"决定动作"是绑在一起的，每次都交给同一个大模型。
jev-ultrafast 把这两件事拆开了。
02 它到底是什么
browser-use 团队开源的一个浏览器 Agent，Python 写。核心是 TypeSafe 的 Jev——一个动态的、索引化的动作空间。
说白了就是：每次观察页面后，不把整个页面丢给模型，而是生成一张带编号的元素表。
[1] button Change ticket type · Round trip
[2] combobox Where from? · San Francisco
[3] combobox Where to? · empty
[4] textbox Departure · empty
模型要做的只有两件事：挑一个编号，挑一个操作。
操作集合是固定的八个：CLICK、TYPE_TEXT、SELECT、SCROLL_UP、SCROLL_DOWN、WAIT、DONE、BLOCKED。
而且不是把所有操作都摆出来，只提供当前元素真正支持的那几个。按钮就没法 TYPE_TEXT，下拉框只给 SELECT。
这个仓库在 GitHub 上已经有上万 Star，不过更值得看的是它的设计。
03 最值得关注的三点
第一，只有需要写字的时候才叫语言模型。
这是我觉得最聪明的地方。
点按钮、滚动、等加载，这些不需要生成任何文字，那就不该让 LLM 去"写"。只有当操作是 TYPE_TEXT 时——比如在"出发地"里填 Zürich——小模型才出场，写一段文本。
也就是说，大量步骤里模型只做选择，不做生成。选择比生成便宜太多。
第二，元素表是动态重建的。
每次观察都产出新的编号表，Agent 不需要记住"第 3 个元素是什么"，它只看当下这一张。页面变了，表也变了。
这就绕开了很多 Agent 框架里最麻烦的部分：状态维护。
第三，性能是公开测量过的。
README 给的例子很具体：Google Flights 搜 Zürich → London，7.1 秒。这个数字里包含了真实的文本生成和加载等待。
仓库里有 docs/performance.md 专门放测量方法。敢把测量过程放出来，比单纯喊快要可信。
04 如果是我，我会重点看什么
一，jev_ultrafast/agent.py。README 直接把这个文件标成主循环，它是理解整套机制的入口。
二，动作空间是怎么被裁剪的。"只提供支持的操作和目标"这话听着简单，但要实现它，得先把页面元素的能力描述清楚。这是整个方案能成立的前提。
三，判断"什么时候该叫语言模型"的逻辑放在哪、怎么触发。这决定了这套设计能不能迁移到你自己的场景。
05 关于运行，我得实话实说
这个仓库目前的 README 主推的是 Browser Use Cloud 的等待列表，本地怎么跑、要配什么，并没有摆在最显眼的位置。
所以我不打算在这里编一条安装命令给你。
想上手的话，建议按这个顺序：先把仓库 clone 下来，读 agent.py 和 performance.md，搞清楚它依赖什么、需要什么凭证，再决定要不要真正跑起来。
06 它能拿来做什么
表单类自动化。
机票查询、酒店预订、后台里的批量录入，共同点是元素数量有限、操作种类固定。索引化的动作空间在这种场景下效率最高。
给你现有的 Agent 做减法。
如果你手上的 Agent 每步都在输出一大段 JSON，可以对照看看：哪些字段其实是模型不必写的？
研究提速思路。
不一定非要用它。它提供了一个很干净的样本——把决策和生成分开，把连续的自然语言输出换成离散的编号选择。
07 上手前要留意的几点
它还在早期。Cloud 版本还在 waitlist 阶段，说明整个项目在快速推进，接口和实现随时可能变。
它依赖 TypeSafe 的 Jev。这不是一个纯本地、自包含的方案，用之前得先看清这条依赖链。
浏览器 Agent 本身就有风险面。它能点页面上的任何东西，也能填任何表单。真拿它去跑真实账号的操作之前，先想清楚权限边界。
08 适合谁，不适合谁
适合：
- 正在做浏览器自动化、被速度卡住的开发者
- 想研究 Agent 动作空间设计的人
- 手上有一堆固定网页流程想自动化的工程师
不太适合：
- 想找个开箱即用工具、不想碰代码的人
- 需要生产级稳定性的项目
- 想完全本地运行、不引入外部依赖的人
09 值不值得试
如果目的是学习，这个项目值得花半小时读一遍 agent.py。它的价值不在功能多，而在于把一件事想得很透：Agent 慢，很多时候不是模型慢，是每一步都让模型做了它不该做的事。
如果想直接拿它跑业务，建议再等等。先去 waitlist 排个队，看清成熟度和依赖成本再说。
项目信息
- 项目：jev-ultrafast
- GitHub：https://github.com/browser-use/jev-ultrafast
- 技术栈：Python
- 项目状态：开发中，README 主推 Browser Use Cloud 等待列表
- 适合人群：研究浏览器 Agent 动作空间设计的开发者
如果你最近也在折腾浏览器自动化，可以先把这个仓库收藏着，等哪天被速度问题卡住了再翻出来看。
你手上还有哪些跑得慢的 Agent 场景？留言说说，我后面继续整理。
本期项目
评论区