vlad-terin/jev-use 是一个为 Codex 等代理工具设计的技能与运行时（Skill and Runtime），旨在通过 Jev 模型，让浏览器和桌面自动化任务的执行更加高效！
核心功能：减少往返，提升效率
Jev Use 的核心在于优化任务编排，而非替换原有的操作工具。它通过将“观察 → 选择 → 操作 → 验证”这一循环封装在单次调用中，减少了代理模型（如 Codex）与工具之间的往返次数。
⚙️ 工作原理与核心优势
Jev Use 的工作流程建立在 Codex 负责规划和处理异常的基础上。Codex 提供高层次指导，Jev 则负责在连续循环中选择具体的操作元素，而 Codex 的工具执行实际的浏览器或应用操作。
其核心优势包括：
- 单次调用，连续执行：代理提供一次性的方向性指导（如概念、类别），Jev 即可在无需额外规划调用的情况下完成多步导航。
- 有界并发与状态验证：运行时支持有界并发浏览器任务、快照范围的目标重新验证、明确的交付状态以及每一步的结果检查，最终返回一个紧凑的结果。
- 增强的观察能力：Jev 为了重新验证，会进行更多的 CUA 观察，而非减少，这有助于提升可靠性
Jev Use 让浏览器自动化提速 2.6 倍，核心不是模型更强，而是让代理少说话！
一个叫 Jev Use 的工具把代理和浏览器之间的废话砍掉了 90%，这怎么做到的？
Jev Use 是一个为 Codex 等代理工具设计的技能与运行时，它让 Jev 模型在连续循环中自主选择浏览器操作元素，从而把“观察-选择-操作-验证”的往返次数压缩到极致。测试显示，计算器任务从 19.62 秒降到 7.43 秒，文本编辑任务从 7.96 秒降到 3.02 秒，提速均超过 2.6 倍。
代理每走一步都要问模型，这是浏览器自动化慢的真正病根
浏览器自动化的速度瓶颈从来不在模型有多聪明，而在代理和模型之间的对话轮次太多。每做一个操作，代理都要先截图或者读页面，把结果发给大模型，大模型返回一个选择，代理执行，然后再次截图验证。这个循环走一遍至少要两次网络往返，复杂任务走上几十步，光通信开销就吃掉了大部分时间。
Jev Use 换了一条路走。它不改变代理使用的浏览器工具，也不替换 Codex 的规划能力，而是把“选哪个元素”这个高频决策从大模型手里拿走，交给 Jev 来做。Jev 是 TypeSafe AI 推出的决策专用模型，它不生成文字，只返回选项、分数和概率。代理只需要在任务开始时给 Jev 一次方向性指导，后面每一步的“选哪个按钮、填哪个框”都由 Jev 在单次网络请求里完成。
这个设计带来的差异在数据上非常直白。逐步操作的 Codex CUA 方案在计算器任务上跑了 19.62 秒，在文本编辑任务上跑了 7.96 秒。Jev Use 把计算器压到 7.43 秒，把文本编辑压到 3.02 秒，两个任务都提速 2.64 倍。三次热运行的中位数，18 次运行全部成功。这些数字来自仓库的对比文档，计时包含了主机工具调用的间隙，但不包含初始任务规划与设置。
等等，但这只是两个简单任务。计算器和文本编辑的操作步骤本来就少，代理往返次数的绝对值不大，提速倍数看起来漂亮但不一定说明通用场景的问题。如果换成需要几十步的复杂网页操作，减少往返带来的收益会不会被其他瓶颈吃掉？事情没那么简单！
协议调用砍掉 90% 只换来 25% 提速，这里面藏着一个反直觉的账
Jev 生态里有一个叫 Jev Ultrafast 的项目，是 browser-use 团队做的浏览器代理，同样基于 Jev 模型。它在一项 Google Flights 机票搜索任务上跑了 7.073 秒，从苏黎世搜到伦敦。这个数字本身已经很快了，但它背后有一组更有意思的数据。
同一批测试里，浏览器协议调用次数从 1,092 次降到了 101 次，砍掉了 90.8%。但是，墙上时钟时间只从 9.450 秒降到了 7.092 秒，降幅只有 25%。砍掉了将近十倍的操作次数，时间只省了四分之一。
这就怪了。如果代理的慢就是因为往返次数太多，那砍掉 90% 的往返应该带来接近 90% 的提速。现实是砍掉的 991 次协议调用里，大部分调用本身耗时极短，真正吃掉时间的是 Jev 请求本身的延迟、页面加载的等待、以及文本生成模型在需要打字时的介入。Jev 每次调用的延迟大约在 300 毫秒左右，一个任务里仍然有 17 次 Jev 请求，光这些请求就消耗了大约 5 秒。
这个账算清楚之后，反常识的结论就浮出来了：减少往返次数当然有用，但它解决的是一部分问题，不是全部问题。Jev Use 在计算器和文本编辑任务上的 2.6 倍提速，恰恰是因为这两个任务的耗时大头就在往返间隙上。换成页面加载慢、需要等待的网站，提速倍数就会缩水。但这不代表 Jev Use 的设计错了，它只说明“减少往返”这个策略的收益是有上限的，上限取决于任务本身的时间构成。
Jev 不截图、不猜坐标、不写代码，它只从编号列表里挑一个号
Jev Use 之所以能把往返压下去，靠的是一个很具体的机制设计。代理在每一步开始前，不是把页面截图扔给模型，而是执行一次原子 DOM 快照。这次快照把所有可见控件读出来，做成一张编号的元素表，每个元素带着它的角色、可访问名称和当前值。
Jev 收到这张表之后，只做一件事：从编号列表里选一个号。操作类型是封闭的八个选项，点击、输入文本、选择、上滚、下滚、等待、完成、受阻。目标元素被拆成多个“头”，点击目标只包含可点击的元素，输入目标只包含可输入的元素，两个问题在同一个网络请求里同时发出，Jev 返回一个操作类型，代理只取匹配的那个目标。
这个机制的关键在于，模型输出永远不会变成选择器、坐标、Shell 命令或者可执行 JavaScript。每一个执行的目标都解析自一个已经被观察到的节点，执行器在动作前还会重新检查页面新鲜度和点击遮挡。Jev 不猜页面上有什么，它只从已经读到的清单里挑。
但是，这个机制有一个明显的软肋。视觉专属的控件和脚本动态创建的弹窗，Jev Use 处理不了，需要主机工具介入。页面文本也会被发送到 TypeSafe 服务器。这两个限制意味着 Jev Use 还不是一个可以无脑部署的方案。另外，当页面元素超过 255 个时，Jev 的单次选择空间会被撑满，TypeSafe 的 Choice 原语只允许 255 个选项，Jev Use 把其中一个留给“none”。大页面的处理要靠分块和并行请求来兜底，分块会丢失跨块上下文，这是一个已知的工程折中。
代理负责想，Jev 负责选，Codex 负责兜底，三者各干各的活
Jev Use 的工作流程可以拆成三个明确的角色。Codex 负责任务规划，它决定这个任务要做什么、做到什么程度算完成、遇到什么情况需要介入。Jev 负责执行层面的高频选择，在每一次观察-选择-操作-验证的循环里，由它来决定“下一步操作什么元素”。浏览器工具负责实际执行，点击、输入、滚动都由 Codex 已有的 CUA 工具来完成。
这个分工里最容易被忽略的是 Codex 的角色。Jev Use 并不是让 Codex 完全退出循环，而是让它在连续运行器跑不动的时候重新进场。连续运行器在遇到需要帮助的步骤时会把控制权交还给 Codex，Codex 处理后可以把任务重新丢回连续循环。运行器还会记录每一次选择、观察、动作和总运行时间，设置和规划的时间单独计量。
这个设计解决了一个很实际的问题。纯逐步代理的问题不在于模型不够聪明，而在于每一步都要“重新请示”。Jev Use 让代理在任务开始时请示一次，后面由 Jev 在这个被批准的框架里自主选择。Codex 不用为每个按钮的点击开会了，它只在真正需要判断的时候才发言。
2.6 倍提速的任务有边界，换一个网页就不一定成立
回到计算器和文本编辑那两个任务。它们的共同特征是操作步骤少、页面状态变化简单、不需要长时间等待。Jev Use 在这两个任务上的 2.6 倍提速是真实的，但这个倍数不能直接外推到所有浏览器自动化场景。
Jev Ultrafast 的 Google Flights 任务就是一个反例。那个任务的协议调用砍了 90%，但最终只提速 25%，因为页面加载和 Jev 请求本身的延迟构成了时间底盘。一个需要在酒店列表页筛选、翻页、对比价格的任务，涉及的操作步骤更多，但每一步的决策复杂度并不比机票搜索高多少，Jev 的选择开销占比反而可能更大。
还有一个更隐蔽的边界。Jev Use 的连续循环在页面结构稳定的时候运转得最好。如果页面频繁触发脚本重绘，或者目标元素在点击前被遮挡，连续运行器就需要更多的验证步骤，往返次数会回升。Jev Use 在点击前会重新检查 DOM 和遮挡状态，这个检查本身是安全的，但它也在消耗时间。
Jev Use 和 Jev Ultrafast 都在文档里承认了自身的局限性。Jev Ultrafast 的测试是三轮单任务单配置，不是通用基准，性能和模型、站点、网络强相关。Jev Use 的实验性质更明显，它明确标注为“实验性、仅浏览器”，连续适配器只和 Codex 的浏览器运行时做过测试。
让代理少说话这件事，做到 2.6 倍之后还剩多少空间
Jev Use 把“代理与模型之间的往返”这个变量从浏览器自动化的方程里抽出来，单独优化了。计算器和文本编辑任务证明这个变量确实值 2.6 倍，Google Flights 任务证明当时间底盘被页面加载和模型延迟占住之后，这个变量的收益会被压缩到 25%。
这两个数字放在一起看，指向一个更根本的问题。浏览器自动化的时间构成里，往返间隙、模型推理、页面等待、执行开销各占一块。Jev Use 把往返间隙这块压到了接近零，但其他三块没有动。TypeSafe 的 Jev 调用延迟大约 300 毫秒，17 次调用就是 5 秒左右，这个底盘在页面操作步骤多的时候会更重。
有一个细节值得单独拿出来看。Jev Use 在每一步验证时重新生成元素表，页面一变就刷新，不靠截图理解。这个设计意味着 Jev 比逐步方案做了更多的观察动作，但每次观察的成本更低，因为读的是结构化文本而不是像素。更多观察、更少推理、更少的模型往返——这三个变化组合在一起，才是 2.6 倍的来源。
所以 Jev Use 的价值不在于它把浏览器自动化变快了 2.6 倍，而在于它把“代理在哪里花时间”这件事拆得更清楚了。你知道往返间隙值多少，知道页面加载值多少，知道 Jev 请求值多少。这个拆解本身就是一种进展。
SEO备选标题：
1. Jev Use 把浏览器自动化提速 2.6 倍，但协议调用砍掉 90% 只换来 25% 时间节省！
2. 代理和模型之间的废话正在拖慢你的浏览器自动化，Jev Use 用一次请求干掉 90% 往返！
3. Jev Use 实测：计算器任务 19.62 秒变 7.43 秒，文本编辑 7.96 秒变 3.02 秒！
4. 浏览器自动化提速的关键不是换模型，是让 Codex 少和 Jev 说话！
jev-use-codex-browser-automation-speedup