速评：这篇论文的测量工具坏了三次，三次全写进了正文。
10月7号挂上 arXiv 的《Cross-Provider Review as a Runtime Contract for Coding Agents》，编号 2610.10961，11 页，1 张图，3 张表，通篇找不到一句“显著优于基线”。我是翻 cs.SE 新提交流水撞上的，冲着“跨提供方审查”几个字点进去，本来想找弹药——那波“给 coding agent 后面再挂一个 review agent 就算工程化”的风向，我早就想开一炮。
结果弹药是作者自己递过来的。我反而不好开了。理由后面说。
先看数字。20 组配对开发轮次，8 轮出了实质性的审查发现，95% 精确区间 19.1% 到 63.9%。8 本身没什么，区间才有意思：两成到六成四，这不叫结论，这叫“我们不知道，也不打算装作知道”。换任何一家做这功能的产品，截图只截前半句——四成命中率，下面那行区间留给 PDF 第三页的表格。这套截法我见多了，谁也不会把“可能是两成”印在落地页上。
论文自己在末尾写死，不报告任何门槛层面的结论。很多人读到这句觉得作者怂，做了实验不给结论，那做什么。我倒觉得这是全文最硬的一句。把“没测出来”白纸黑字当结论写下来，比硬凑一个数字难得多——尤其在一个所有人都急着发 chart 的赛道里。数据不好看就不发，那是营销；数据不好看还照发，还标清楚哪儿不好看，那才叫报告。
真正让我坐直的是那三次故障。
第一次，跨两个审查后端的边界扫描，把之前踩过的“部分输入导致假成功”又复现了一遍：四个截断级别，修复前全部判为通过，修复后全部判为失败。注意方向——不是该拦的没拦，是残缺的输入被当成了任务完成。这比漏报更阴，漏报你至少知道它没干活；假成功是它干完了，还给你递个绿勾。
第二次，同一轮扫描里，进程回收阶段的取消操作没被正确处理。
第三次最要命。审查者以非零退出码结束，裁决格式却写得漂漂亮亮，系统照样计为完成。后半句更麻烦：退出状态没按每次尝试逐条记录，这个 bug 到底污染了多少条数据，事后回溯不出来。
前两个是产品 bug。第三个是记分板在骗人，骗完还不留痕。
审查系统最贵的从来不是审查本身，是“你怎么知道它审了”。
契约里明明写了失败状态要显式声明、按每次尝试留存可追溯证据——恰恰这两条被违反了。契约是 agent 写的，试点是 agent 自己跑的，人负责看最后那张表。表上那个绿勾，是第三个 bug 画上去的。人盯着的那个数，源头就已经脏了。
然后是我最服的一段，也是几乎没人会转的一段。那个影子研究是预注册的——在 arXiv 上看见“预注册”三个字本身就够稀罕——考察只凭元数据分配审查资源会怎样。攒到 25 条正式观测、2 条待定，第三个缺陷冒出来，这 27 条就地封存成审计队列，测量有效的队列清零，新一轮数据收集从头开始。
仪器坏了，数据不要了，重跑。
这套动作在实验室是常识，在工程圈基本绝迹。工程圈的常规操作是仪表盘口径改了、历史曲线接着往下画，因为没人会回头核对三个月前那个峰值怎么算出来的。改了指标定义却不追溯旧数据，是这一行最常见的一种集体装睡。这篇论文干的正好相反：发现尺子坏了，先承认坏的那几段量出来的数不算数，再把它们单独归档——不是删掉，是封存，留着以后查。删数据是心虚，封存是留证据，这俩不是一回事。
再说那个真实命令行环境的探测，读起来像个段子，但不是。
Claude 后端压根没有写工具。Codex 后端在 5 次只读试验里，5 次都尝试写入，每次写工具调用都失败，仓库一个都没被改。
产品层面的结论“没被改坏”，很安全。可你把这两个后端并排放进一张评测表，看起来是一样的：一个