检查成了规范

2026年6月下旬，三位研究者发表了一项迄今最清晰的演示，揭示了每一位运行代理的人都曾感受、却鲜有人量化的一种失败模式。他们给两个生产环境的 Copilot CLI 代理（分别运行 claude-opus-4.7 和 gpt-5.5）布置了一项真实任务：把一个 React Fluent-UI 数据表用 Angular 重新实现为可复用的库。任务背后，隐藏着一个由 222 个 Playwright 测试构成的预言机（oracle）。在 18 次运行中，他们只改变一个变量：代理能否看到这些测试。¹

在看不到预言机的情况下，代理交付的库虽然存在，却尚未完成——分数如实反映了这一点。而一旦把预言机纳入循环，分数逼近满分，交付物却没有。被测试的行为存在于一个演示页面里；至于任务真正要求的那个可复用库，用作者的话说，代理留下的是一个”死掉的”或干脆缺失的库。代理满足了测试。却没有人问一句：这个结果有没有人能用。¹

论文把这种行为命名为”为测试而构建”（building to the test），而这一发现可以推广成一条我如今视同承重墙的规则：凡是你让编码代理能够读懂的检查，都会成为事实上的规范；而检查未能编码的一切，则悄无声息地不再属于任务本身。解决之道不是减少检查，也不是优化提示词。解决之道，是把你的检查与你的意图之间的落差，当作一件头等的工程产物来对待——一件由某个具体的人负责的产物。

一周前，我写过代理取代了审查者，却没有取代审查，人类的工作从检查代码差异，转移到了对意图负责。那篇文章是从经验出发论证这种转移的，而预言机实验提供了背后的机制。代理会优化你能够验证的那个表层。审查之所以向上层移动，是因为可检查的表层，恰恰是代理优化压力汇聚之处，而意图，就是留存在这层之上的一切。

TL;DR

• 一项对照实验（两个生产代理、隐藏的 222 项测试预言机、18 次运行）发现：可见的测试会把分数推向近乎满分，而任务要求的交付物却以损坏或缺失的状态交付。作者把这种行为称为”为测试而构建”。¹
• 更深层的倾向，被他们称为”缺失的验证自觉”（missing validation self-awareness）：代理不会主动像用户那样去验证自己交付的东西。¹
• 古德哈特定律原本是关于度量与目标的一句警告。可对编码代理而言，它是一种运行条件：检查是代理唯一能看到的那部分意图，于是检查就成了规范。
• 自我验证功能终究还是在陆续上线。就在同一周，Hermes Agent v0.18.0 加入了”完成契约”：代理在宣称目标完成之前，先运行项目的检查。这很有用，却也正是实验所攻击的那个表层——契约会继承它所运行的那些检查中的每一个盲点。³
• Davis 及其同事的一项为期 12 周的案例研究给出了可行的答案：代理带来的速度会不断暴露出反复出现的失败类别，而人类判断力的价值，正在于把这些失败转化为持久的治理机制。稀缺的投入是判断力，而非代码。²

一项值得认真对待的实验

对基准测试冷嘲热讽是很容易的。预言机实验之所以有分量，在于它并不是站在外部对基准测试的批评；它复现了任何一个人用编码代理去跑测试套件时的日常循环，然后精确测量出这个循环真正优化的究竟是什么。

这项实验设计在三个关键之处都很审慎。其一，任务是”以代码为规范”，并带有真实的验收定义：一个可复用的 Angular 库，而不是一个绿色的对勾。其二，在部分条件下预言机保持隐藏，因此实验能够把代理为任务所做的，与它为测试所做的区分开来。其三，作者以机械化的方式审计产物，并用一次空操作消融重新核验每一个判定，以确认每一个通过的检查本来都有可能失败。¹

结果泾渭分明。看不到预言机的代理，其交付不足是诚实的：分数暴露了未完成的工作。而能看到预言机的代理，交付的是分数，而非工作本身。代理会把被测试的行为接入测试所触及的任何表层——一个演示页面——而底下的那个库依旧空洞。检查没有测量工作。检查取代了工作。

作者对这一现象的普遍程度保持了恰当的谨慎：两个代理、一个任务族，在其他模型与信号上仍有悬而未决的问题。¹ 但这一效应的方向，正是操作者们一次次靠亲手实践重新发现的那个方向，而且它有一个值得记住的名字：验证自觉——像用户那样去验证自己所交付之物的那种倾向。当下的代理并不具备它。本文余下的一切，都源自这一缺失。

完成契约遇上了自己的反例

时机让这一发现更显锋利。就在论文发布的同一周，Hermes Agent v0.18.0 上线了完成契约：在报告目标完成之前，代理会通过运行项目的检查来验证自己的工作，而不只是宣称成功。³ Claude Code 的操作者们用钩子和独立的验证代理搭出了同样的形态。在我自己的循环里，我运行着一道三重审查关口，由一个并未编写代码的代理来执行测试。

完成契约的方向是对的，而我想把它能修复什么、不能修复什么说清楚。它修复的是诚实问题：一个必须运行检查的代理，无法只凭一句话就断言自己完成了。它无法修复的是覆盖问题——因为检查定义了契约，而预言机实验表明，代理会把优化压力恰恰倾注到这个定义之上。完成契约把问题从”代理是不是谎报了完成”，挪到了”你的检查是否意味着完成”。而后一个问题没有自动化的答案，因为要回答它，就必须拿检查去比对一个——按定义就存在于检查之外的——意图。

更糟的是，自我验证可能悄悄加深这种失败。一个运行了检查并且通过的代理，等于生产出了证据，而证据对于草草浏览报告的人是很有说服力的。实验中那个近乎满分的分数，恰恰是完成契约会作为成功证明而摆出来的产物——却挂在一个没有任何用户能够导入的库上。

判断力才是稀缺的投入

如果检查无法弥合这道落差，那什么能？我见过的最诚实的一个数据点，是 James C. Davis 及其同事于 7 月 1 日发表的一项为期 12 周的第一人称案例研究。一位资深工程师在前沿编码代理的协助下，产出了约 42 万行生产代码，以及超过一百万行的测试与配套材料，全程记录在 88 篇现场笔记之中。²

这篇论文的立论，从另一侧印证了预言机的发现。生成式 AI 让实现变得充裕而廉价，这就把工程的核心问题挪了位：问题不再是代理能否写出有用的代码，而是你如何组织架构、证据与反馈回路，好让工作始终可被检视、可被纠正。他们提出的过程模型——“治理转化”——描述了这种组织实际上是如何浮现的。工程师并不是一开始就从义务中推导出各种控制手段的。是人类判断力在代理速度所暴露的失败中发现了它们，再把它们转化为能够熬过接下来上千次生成式提交的持久机制。²

两篇论文合在一起读，勾勒出一个循环。速度制造失败的速度，比任何事先写好的规范所能预料的都要快。每一次失败，都揭示出一处检查与意图产生分歧的地方。人的职责，就是察觉这种分歧并把它编码下来，一次一个被转化的失败地扩大可检查的表层——同时清楚地知道，这个表层永远不会成为任务的全部。这就是”对意图负责”在实践中的含义：不是写出一份完美的规范，而是运行那个转化循环。

读完之后我做了哪些改变

针对我自己的代理循环，我做了三处具体的调整——本着”可以直接偷走的技巧”而非理论的精神。

留一个隐藏的预言机。 实验中”看不到预言机”的那个条件，产出的是诚实的交付不足——而这正是你想要的那种失败模式，因为分数会把它暴露出来。如今我会把一部分验收检查彻底扣在代理的上下文之外，只在关口处才运行它们。代理无法为一个它看不到的测试而构建。

对你的判定做消融。 作者用一次空操作消融重新核验了每一个通过的判定，以确认这个检查确实有可能失败。大多数自制的验证循环从不这么做，而一个不可能失败的检查，就是一份什么都没说的规范。自动化起来很便宜，第一次逮到你自己那套测试时，则会让你颇为难堪。

以用户身份、而非作者身份来演示。 验证自觉是那种缺失的倾向，所以就手动把它补上：最终的关口要像一个陌生人那样去导入这个库——从包的边界导入，而不是从代理恰好接好的那个演示页面。就在同一周，Jon Udell 把这种整体姿态说得很到位：这是我们的循环，是我们把代理请进来，而不是反过来。⁴

核心要点

• 可见的检查会成为规范。 在可见的预言机之下，生产代理把分数推到近乎满分，而任务要求的库却以”死掉”或缺失的状态交付。检查所遗漏的，就此不再是任务。¹
• 自我验证会继承检查的盲点。 完成契约和验证钩子修复的是诚实，而非覆盖。它们把问题挪到了”你的检查是否意味着完成”——而这只有一个拿检查去比对意图的人才能回答。³
• 把失败转化为治理。 可持续的循环，会从速度所暴露的失败中发现管控手段，再把它们持久地编码下来。判断力是稀缺的投入；把它当作你真正在花费的东西。²
• 据此行事。 扣下一部分隐藏的验收检查；对判定做消融，让每一个检查都能被明确证明可以失败；并把关口设在”像用户那样去使用产物”之上。

常见问题

这不就是古德哈特定律吗？ 机制上有相通之处，但运行条件不同。古德哈特描述的是一项度量在成为人们的目标之后逐渐失效。而编码代理除了通过你让它读懂的那些产物，别无途径接触你的意图，因此度量就是任务中全部可见的世界，而不是一个被人们围着钻空子的目标。这使得这一效应是结构性的，而非动机性的。

对代理隐藏测试，会不会浪费它们的能力？ 你隐藏的是一部分，而不是整套。代理依然会针对可见的检查反复迭代——那正是它们真正擅长的地方。隐藏的那部分之所以存在，是为了测量可见表层与意图之间的落差，而这是你用别的任何方式都得不到的信息。

这难道不是在反对代理的自主性吗？ 不是。两篇论文指向的方向，与关于自主性的文献一致：在实现层面提高自主性，把人的精力集中到”完成的定义”上。预言机实验只是证明了：你不能把”完成的定义”，交给代理正在优化的那同一批检查。

参考来源