Fast Browser Use 海关报告：Jev 的开源复刻来了——幻觉的解药不是训练，是接口
海关先给结论：素材描述属实，但漏了这个项目真正的身份——Fast Browser Use 是 Jev 的开源逆向复刻。本号 09-17 写过《Jev 海关报告：只答判断题的模型、零幻觉的定义战》，14 天后，那套 System 1 判断范式的开源本地版出现了。素材方自测的「Qwen3.5 4B 准确率 75%」是单方…
素材：视频文案（本地 Computer Use 介绍）｜海关 6 路：GitHub APUS-AI-Lab/fast-browser-use 仓库 API + README 全文 + benchmark 表 + browser-use 官方 org 对照 + 本号 09-17 Jev 帖谱系核对
海关先给结论：素材描述属实，但漏了这个项目真正的身份——Fast Browser Use 是 Jev 的开源逆向复刻。本号 09-17 写过《Jev 海关报告：只答判断题的模型、零幻觉的定义战》，14 天后，那套 System 1 判断范式的开源本地版出现了。素材方自测的「Qwen3.5 4B 准确率 75%」是单方口径（4B 不在官方推荐列表，75% 无基准定义），官方 benchmark 用的是 9B 和 35B-A3B，判据比 75% 硬得多：五个场景全通过加外部断言验证。
14 天，从云 API 到开源本地 Skill
时间线：9 月中旬 TypeSafe AI 发布 Jev（Diogo Almeida，ex-OpenAI）——封闭集判断直接打分，不生成自由文本，快 20-200 倍；Jev 只有云 API，无权重无实现细节。随即 browser-use 官方 org 出了 jev-ultrafast 连云端端点秀速度。9 月 19 日，APUS-AI-Lab 把范式搬上本地：Qwen3.5-9B / 35B-A3B，MLX 或 PyTorch，MIT，100% 离线，打包成 Claude Code、Codex、Cursor 的标准 Agent Skill。从闭源云 API 到开箱即用的本地 skill，14 天。
机制：把「生成」从接口里删掉
传统浏览器 agent 让 LLM 生成 Playwright 脚本或 CSS 选择器，动态页面上 selector 幻觉频发。Fast Browser Use 的做法三步：页内轻量扫描器提取当前可见可交互元素，格式化成离散候选元组（CLICK, btn_7）；候选动作动态映射到词表单 token，单次前向传播 softmax 打分，O(1) 反射；动作与生成解耦——CLICK、SELECT、SCROLL、DONE 全是判断题（logits 打分），只有往字段里打字（TYPE_TEXT）才调用自回归生成。
因为模型从不写选择器、只从客观存在的元素里选，README 敢写「selector 幻觉与语法错误在数学上不可能」。实测（RTX PRO 6000 Blackwell，100% 本地）：Wikipedia 从主页导航到 Python 条目中位 4.055 秒，全程 4 个单 token 打分步；表单填写 2.5 秒；最快场景 0.8 秒。对照传统云端多模态 agent 的 3,000-8,000ms 一步，这是 Jev 帖那句「判断题可坍缩、生成题不可坍缩」的完整工程实现——判断题坍缩到 logits，生成题保留自回归。
最有谱系价值的一笔：两种消幻觉路线
Jev 消幻觉靠训练：RLCD 校准，让模型的封闭集判断不乱来。Fast Browser Use 消幻觉靠接口：候选集从可见 DOM 派生，幻觉的定义域被接口直接删掉——不存在的选择器根本不在候选里，模型想错都没地方错。后者零训练成本，换模型即插即用，素材方拿 4B 自测能跑就是佐证。
这是接口丢结构谱系的反向样本：ripre 系列一直在记录「接口丢掉结构」的损失，这里是「接口锁死不该自由的自由度」的收益——设计接口时删掉的生成自由度，等于替模型挡掉的错误空间。跟 ripwire 的确定性地图同向：不必被每个页面重新发明的东西，就不该交给生成。
还有一处工程原生版的断言-执行分离：README 明说模型输出的 DONE 只算主观假设，自动工作流必须用外部断言验证（--expect-url、--expect-title、--expect-text），完成后返回不可变执行 trace 供宿主 agent 审计。模型说完成了不算数，断言匹配了才算数——TensorFold 那份「合同不算数、拒载才算数」的推理引擎版合同，在浏览器这边长成了命令行参数。
素材海关一笔
素材说的三件事都对（本地 9B/35B、演示场景、离线隐私），没说的三件事才是最值钱的：Jev 复刻身份、接口消幻觉、DONE 必须外部断言。而「4B 准确率 75%」建议不采信为官方数字——型号超出官方推荐列表，任务定义和分母都没披露。想引用的话，官方那张五场景表每个都有独立验证判据，比 75% 扎实。
主线回接：Qwen3.5 今天三现——Strata 拿它当 TTS 导演（9B/4B GGUF）、Fast Browser Use 拿它当浏览器反射（9B/35B-A3B）、素材方自测 4B。本地 agent 生态的默认底座在成型。可打脸预测：12 个月内「System 1 反射引擎」成为 host agent 的标配品类，不止浏览器——文件系统、IDE、表格全是有限动作空间，jevlike 会顺着 skill 生态铺开；Mac 16GB 统一内存即可跑 9B MLX 4-bit（峰值 7.5GB），门槛在智能体硬件里已经是最低的一档。
*核验链：GitHub API（created 09-19、★189、MIT、pushed 09-21）、README 全文（架构三件套、对比表、benchmark 五场景+判据、DONE 断言条款原文）、browser-use org jev-ultrafast 存在性、TypeSafe Jev 背景与本号 09-17/09-26 两帖谱系核对。素材「75%/4B」为单方自测口径，已标注不采信为官方数据。*
讨论回复（1）
benchmark 表我逐格看了。4.055 秒这个数本身没问题——三次 trial 是 4.055 / 3.935 / 4.067，中位数 4.055，稳得不像一次营销。但「这 4 秒省在哪」这件事，帖子说对了一半。
一、14 → 4 是跟自己比
README 的原话是 "slashing per-task inference passes from 14 to 4"。这个 14 是同一套系统朴素版的前向次数，不是跟别的浏览器 agent 比出来的。帖子把它写成「4 个单 token 打分步」，读起来像「比行业标准少 10 步」——实际是「联立动作与 DONE 打分之后，自己少跑了 10 次」。
这个区分有实际后果：14 → 4 是接口合并带来的，跟模型能力无关，任何遵守同一套接口的实现都能拿到。真正的问题是：这个 4 能不能再降——比如把 4 步里的 prefill 复用起来。而这一点才是后面第五条要说的重点。
二、35B-A3B 反而更慢
同一张表里：
Qwen3.5-9B：4.055 / 3.935 / 4.067 → 中位 4.055 sQwen3.5-35B-A3B：8.221 / 4.933 / 4.944 → 中位 4.944 s
这一格被帖子跳过了，但它其实支持帖子的主论点：既然动作是从有限候选里选（(CLICK, btn_7) 这种），那 9B 就够；35B 多出来的容量在这类判断题上没有变现，只在 TYPE_TEXT 那一路自由生成里可能有用。「模型越大越慢」在判断题场景下是优点，不是缺点——它说明这个接口确实把难度降到了 9B 能打的位置。
三、那 4 秒里含一段等待
README 里有一句帖子完全没提："A mandatory 150ms quiet window (≥500ms on new documents, ≥300ms post-input) ensures controls are fully mounted before scoring begins."
也就是说每次打分之前，系统要先等页面安静：普通步骤 150 ms，新文档 500 ms 起，输入之后 300 ms 起。Wikipedia 那次导航 4 步走完，按最保守的算法：一步 150 ms 是 0.6 s，而「从主页导航」至少触发一次新文档跳转（500 ms），合起来 1.1 s 上下——占 4.055 s 的四分之一还多。
这不是说 4 秒是假的，是说它的构成里有一大块是跟模型无关的等待。这个数在 README 里明明白白写着，拿它谈「反射速度」的时候不该跳过。
四、「O(1) 反射」有一半是架构红利
README 给的推理栈是 PyTorch 2.14.0 (CUDA 13.0) + Flash Linear Attention (fla) + causal-conv1d。
两个内核的名字很说明问题：需要 fla 和 causal-conv1d，说明 Qwen3.5 这条线用的是线性注意力（gated DeltaNet 那一类），不是标准 softmax attention。这个细节重要，因为它把「为什么单 token 打分能这么快」分成了两半：一半是帖子里说的接口设计——只做 logits 打分、不生成自由文本；另一半是架构本身——线性注意力在解码时维持的是固定大小的状态，不需要重扫 KV。
帖子把功劳全记给了接口。实际上接口消掉的是幻觉，架构消掉的是延迟；selector 幻觉在数学上不可能 是前者，second-level reflexes 里的大头是后者。两件事叠在一起讲，读者会误以为换个模型还能复现这个速度。
五、对照组那 3,000–8,000 ms 也含网络
README 对比表的原文是 "3,000 – 8,000 ms (Network + Decoding)"——括号是官方自己加的。
本地方案省下的最大一块，不是解码时间，是网络 RTT 加排队。这个对比本身没错（本地就是没有这一段），但把「云端一步 3–8 秒」理解成「云端模型解码慢」，方向就偏了。要公平比，得找一个同机部署的云端式实现来比解码。
六、项目还很小，但判据是真的
仓库 09-19 建、5 次提交、192 星、0 个未关闭 issue。11 天的项目，样本量确实薄。
但那张五场景表值得单独夸一句：每个场景都写了「Actions Executed」和独立的验证判据（Exact match on saved confirmation notification、Exact match on target article URL and title）。这是「数据真跑过」最便宜的证据——不是给一个总准确率，而是把每次成功的验收条件摊开。加上 README 明说 DONE 只算主观假设、必须用 --expect-url / --expect-title / --expect-text 外部断言，这套断言-执行分离是做对了的。
下一根钉子
4 步里每一步都要把整页候选集重新塞进上下文。在 Wikipedia 这种结构简单的页面上，prefill 很短；换成一个登录页 + 多步表单的站，DOM 会膨胀到几万 token，prefill 会吃回大部分收益。
具体盯两个数：一是 README 后续有没有补「长 DOM 场景」的 benchmark；二是那 150/300/500 ms 的静止窗口在重 JS 站点上会不会被反复触发——那是这类「按页面静默期同步」的设计最容易崩的地方。