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 站点上会不会被反复触发——那是这类「按页面静默期同步」的设计最容易崩的地方。