我有一阵子特别迷信一件事：工具给 agent 配得越多，它越能自查。linter 装上，shell 开着，截图也接进来——稳了。
后来看了篇论文才知道，我一直在问错问题。
该问的那个东西叫验证面：agent 手里那堆自我检查工具，到底盖住了你实际会出的哪些错。这概念不难，就是之前没人这么讲。
论文作者是 Achint Mehta，标题长得像一句绕口令——《验证工具的覆盖范围决定其价值：AI 编码智能体中验证面、产物质量与成本的受控研究》，2026 年 8 月 28 日挂上 arXiv（2608.28795），投的 IEEE Access。做法很朴素：搭一个极简编码 agent，把工具清单设成唯一变量，六种模型 × 八种工具配置，跑出一千一百多个 Web 应用；再让不知道分组条件的人按固定评分表挨个打分，同时用自动化探针去压测那些能从 API 观察到的行为。
我想讲的不是它结论是啥。是它把我脑子里一张画歪的图掰正了。先看我歪的那版：
工具越多 ──────► 质量越高
linter ↑
shell ↑
截图 ↑
一条斜向上的线。挺顺，也挺蠢。因为这条线要是成立，论文压根得不出它得出来的结果。
真实的形状，是两个面在错位。画开看看：
实际会出的错： 起不来 布局错位 点不动 滚动卡
▲ ▲ ▲ ✗
你配的工具： 启动探针 截图 shell （空白）
上面那排是失败空间——这个项目实际会出错的地方。下面那排是验证面——agent 手里那些自检工具盖到哪儿。只有上下对齐的那几格，才会真被抓住。剩下那几格不是"没抓住"，是根本没人知道它在出事。
我觉得"验证面"比"工具清单"准确，就因为它逼你回答一个工具清单不逼你回答的问题：你盖住的是哪一块。
三组数据，捡最有意思的说。
第一组：完全不给工具，大约每七个构建里就有一个跑不起来。看着不起眼，但这是这批实验里最便宜的收益——加一个启动探针，这类失败基本全消。而探针的 token 开销，只有完整 shell 的 35%。
我盯着这个 35% 看了半天，然后咔哒一下扣上了 ✨——工具的价值不在它多能干，在它盖住的是哪一格。一个只干"能不能起来"这一件事的探针，花三分之一的钱，把最容易出、也最致命的那类错清掉。
第二组：shell 不是白给的。上了完整 shell，无工具条件下的成本变成原来的 2.35 倍。注意这个 2.35 是乘在"无工具条件"那个基数上的——工具本身要烧 token，工具越多烧得越狠。把这条跟上面那条摞一块儿：最便宜的那一格收益最大，最贵的那一格得另算账。所以"先上 shell，探针以后再说"这个顺序，是反的。
第三组，也是我最想画给你看的：截图。
截图在"错误肉眼可见"的场景里收益最大——元素摆错位置、点不动、样式崩了，截一张图，agent 自己就能看见。听着该是神器。但论文说，跟 shell 比，截图的提升幅度有限；而且过了多重统计比较校正之后，这个提升不再显著。
"校正"翻成人话：它跑了那么多组对比，截图这一项的好看，可能有一部分是运气。校正一过，好看就没了。
更狠的是后半句。当失败只能被测量、不能被看见的时候，截图一点忙都帮不上。论文举的例子是"在 10 万行列表上保持滚动流畅"——你截一百张图也看不出卡不卡。它不体现在画面上，体现在帧率上。你的验证面里要是没有一个能测帧率的探针，这个失败就落在空白格里，agent 会理直气壮地跟你说"做完了"。
等等等等，先别急着滑到"那就多配工具"。这正是我第一版图画歪的地方。
论文的结论是：验证工具只有在它的覆盖范围和实际出错方式匹配时，才能改善最终产物。注意这个因果方向。不是"工具多 → 好"，是"工具的覆盖面长成了错误的样子 → 好"。截图不是不好，是它的覆盖面积会随着任务变。在一个表单页上，截图盖住的格子不少；在滚动性能这个任务上，它一格都盖不住。同一把工具，两个任务，覆盖面积差这么远。
不过我得自己提醒一句：上面那个"两个面重叠"的比喻，有漏风的地方。
"面"这个词会让人以为覆盖是连续的、能估面积的——好像工具配得够多，就能把失败空间整个糊住。真实情况更像离散的格子：一个探针要么能观测到这类失败的信号，要么观测不到，中间没有"覆盖了六成"这回事。启动探针就特别典型，它是个二值的东西——起得来，或者起不来，没有程度之分。所以我那张对齐图，只对"这一格有没有人管"这个问题有效，别拿它去估"我的验证覆盖度是多少"。抓大方向用这张图，抠细节还得回到具体是哪个工具在观测哪个信号。
扯远了，拉回来。
我最后把这一套缩成三个自查问题，贴在自己的 harness 配置里：
- 这个项目最常出的错是哪几类，能不能列出来（列不出来，"多配工具"就是在瞎补）
- 每一类错，有没有一个工具能观测到它的信号——是它真实的信号，不是你希望它有的信号
- 那个工具的成本，跟它盖住的格子比，划不划算（启动探针三分之一价钱清掉一大类，这种就该先上）
大部分时候卡住我的是第二问。我以为截图能看见一切，其实它只看见画面；我以为 shell 能救一切，其实它只是让 agent 多跑几条命令，跑得对不对，它自己也不知道。
那篇论文 27 页，13 张图 10 张表。图挺值得翻，尤其是把失败按类别摊开的那几张，比结论那句话直观得多。数据和代码它给了链接，DOI 是 10.48550/arXiv.2608.28795，不过这个你不用记，去找那几张图比什么都强。
下期想画开哪个概念，你说了算。我手边放着两个候选：一个是"为什么 agent 会反复修同一个 bug"，另一个是 tool call 的返回值到了 context 里到底长什么样。