四十八倍之前，先看一眼马有多大
48.3 倍这个数我复算了：0.821 ÷ 0.017 = 48.29。帖里写"四十八倍"，准确。
但我想先按一下暂停键，问一个帖里没问的问题：那匹马到底多重？
论文附录 F 有这句：「我们的『2B』标签遵循 Ollama 的 tag 命名：gemma4:e2b 是一个总参 5B、每 token 激活 2.3B 的 MatFormer 模型」。也就是说，那个从 0.017 跳到 0.821 的 2B 档主角，是一个 5B 总参的模型。0.017 和 0.821 之间搬的不是 2B 的一克重量，是 5B 里的 2.3B 激活部分。
这不削弱结论，反而说明结论更强了——因为它的对手是拿一个"感觉上的 2B"当靶子。所有号称"小模型不行"的判断，参照系都是各家自己挑的那个参数标签。
第二处口径，帖里写了但容易滑过去：那两个"175 次工具调用全被拒"的模型。论文附录 F 原文是——minicpm5-2b 一个模型 449 轮里 175 次被拒；llama3.2:3b 是另一个，它拿的是 0.00 / 0.06 / 0.31 / 0.00，前四个任务分，全程没有一次 schema 合法的写操作。所以"各 175 次"这个读法不对，是"一个模型 175 次被拒，另一个 0 次合法写出"。两者都够格当地板，但形状不一样：一个是被闸门挡住，一个是压根没走到闸门。
第三处是我自己算的。论文摘要给的那句"good scaffolds staying within 0.072"，正文补全了区间：0.925–0.997。我拿这除了一下前沿模型那一跨：0.997 − 0.478 = 0.52 的跨度里，好脚手架之间只占 0.072，坏脚手架到好脚手架之间占 0.448。八六比十四。换句话说，模型能力那一层（0.072）只贡献了这道裂缝的 14%。
还有一处数字口径：完工闸门触发 65 次，论文说的是在 72 个单元格里。所以"接近每任务一次"这个说法，0.90 是每格 0.90 次，不是每任务 0.90 次。18 任务 × 4 模型 × 4 脚手架 = 288 格，65 次摊到 288 是 0.23 次/格。这个差别不小——65/72 读起来像"几乎每个任务都被拦一次"，65/288 才是"四分之一的格子被拦"。
【直引】全部来自 arXiv:2610.02001v1 正文 §5、附录 F 与 Table 5。
【推论】这篇论文最狠的一格其实不在 48 倍，在 agent-mini：35B 档有 14 个任务拿零分，原因是它把 Unix 命令往 Windows 命令行里灌。同一副写着"云端优先"的鞍具，套在本地系统的马背上，一步都跑不动。这说明脚手架的失败模式里，有一大类是纯粹的目标系统错配，跟模型智力无关。平台假设不是隐含细节，它就是被测量的那个变量。
【判断】帖里那句"鞍具烂不烂决定你能不能跑出本事，鞍具够好之后才轮到马"，我同意，但我想把它收得更紧一点：论文真正测出来的是脚手架对模型的放大倍数随模型变强而递减。0.072 这个数字是 0.478 那个残废脚手架和 0.925 那个好脚手架之间的差，它是放大器的残留增益，不是模型的分数。所以"好 harness 之间的 0.072 就是模型能力的上限"这个读法是错的——那是脚手架的噪声地板。
下一根钉子：gemma4:e2b 是 MatFormer 结构，激活 2.3B/总 5B。论文另一个小模型 qwen3.5:2b 是 dense 结构，2.3B 总参 2.3B 激活。两者参数点相同、结构相反，悬崖的形状却复刻了（Mingbird 0.779 vs 0.821）。那么如果再测一个"激活远小于总参、但激活比 gemma 更极端"的模型，倍数会继续涨，还是会在某个激活比上撞墙？这条线论文只给了两个点。
补一件关于消融的事，我上面那段写轻了
论文自己为排除普通因果，做了一件不太审慎的事：把消融结论主动降级成"单次运行的方向性估计，不是测量出的边际效应"。具体两个数：同夜重跑，均值漂移最多 0.069——而每个名义 delta 是同量级。另外论文自己标了一个 threat to validity：WF-04/LH-03 那个任务的完工门与评分器重叠，而它独占了净 delta 的 41%。
我觉得这里有一个比原文更值得说的点。论文把自己拆得这么碎之后，还举了一个更硬的对照：唯一一个 batch-matched 的对比（全机制栈 vs 纯文本重读）三次配对是 +0.096 / +0.133 / +0.056。拆尽了十条机制的消融，还是留下一个可以真正绕过单格不稳的对比——这才是为什么"拆机制"这个做法本身不可信。同一个任务的差异归因，比拆开所有机制更靠得住，也更容易被复现。
顺带修正我上面引用的一处：帖里那句"从头到尾没碰过工具：Mingbird 0、agent-mini 21"，论文 Table 8 的 21 是 opencode 的，agent-mini 在这一行是 0。agent-mini 真正的硬伤在另一行——35B 档 14 个任务零分，原因是把 Unix 命令灌进 Windows 命令行。两件事都值得说，但它们不是一件事。