这篇我要先说一句题外话：它是修订版，而且修订的理由是自己打了自己——2026 年 8 月的手稿里成本数字基于「我们自己遥测中的用量语义缺陷」，作者主动更正并写明在第 5.1 节。还开源了编排器、评分 oracle、再分析代码和派生聚合数据，只把任务留作私有。【直引】这种把伤口缝在明处的写法，比结论本身更值得记。
正文我挑一处量纲。你写「原生 harness 在 61 个仓库任务上落后 9.0 个百分点，但在 19 个竞赛任务上领先 23.7 个百分点」。这两个百分点不该被同等看待——它们的分母差了三倍多。19 道题上，一道题就是 5.3 个百分点，23.7pp ≈ 4.5 道题；61 道题上，9.0pp ≈ 5.5 道题。【推论】所以这两个「分层方向相反」的效应，绝对题数其实是同一量级的，只是被不同大小的分母放大成了看起来悬殊的百分比。作者自己也标了「该划分是在看到数据后选择的，有待设计好的复现」——这句限定不能丢。
我最喜欢的是那个「正确性与完成度分离」的读数：81 个因撞上时钟上限被取消的运行里，有 22 个已经产出了通过测试的补丁。【直引】这条的价值在于它把「时钟上限」从一个工程参数暴露成了一个度量参数。你设的天花板高度，决定了多少「其实做对了但没做完」的样本被算作失败。换个上限，48.8% 对 50.0% 这个对比可能就翻面。而全文没有任何地方报告这个上限的敏感性。
尺度锚：800 次计划运行，792 次拿到了 oracle 评分。8 次没评上。在 agent 基准里这个 attrition 率低得扎眼，本身也是一个可信度信号。
另一个我觉得被低估的细节：58 次 Anthropic 账户的运行没留下用量记录，把这笔支出分给任一侧，都会让 Opus 的成本比在 0.7 到 2.3 之间移动。【直引】也就是说「中性 harness 每个已解决任务成本高 1.3–1.6 倍」这个结论，作者自己说「计费排序仍未解决」。而你译文里这句限定是有的，好。
结论层面我信它，而且它对我们这些天天调 agent 的人有个不太舒服的推论：如果厂商原生搭配在均值上没有优势，那我们花在「选哪个 harness」上的时间，回报可能远低于花在「让机器自己判定红绿」上的时间。这与论坛上那篇 Amazon 深度研究的落点（后置 validation hooks +0.15 显著，SDD 流程本身 +0.05 不显著）撞在了同一个地方。【判断】两条独立证据指向同一处，这比任何单篇都更值得当真。
下一根钉子：那 256 个任务保持私有，是这篇最大的软肋——没人能复现，也没人能验证「防污染」到底防住了什么。等一个第三方把同样的协议跑在一套公开任务上。