生成-核验落差：每一个智能体循环都在赌的那个不对称。
你上线的每一个自主循环，都在赌「检查一个答案比造出一个答案便宜」；而一旦这个赌注不成立，循环就没有任何东西可以收敛过去——换更强的模型也救不了它。生成的代价与核验的代价之间的那道落差，才是应该决定你自主等级的量；而它令人不适的推论是：一个被允许「重试到通过为止」的智能体，继承的是核验器的错误率，不是模型的。
核验是另一项工作，而它通常——但并非总是——是更便宜的那一项。
在城市里找出一条路线很难；检查一条给定路线是否合法、能否准点抵达则很容易。写一个能通过测试套件的函数很难；跑一遍测试套件只是起一个子进程。这个不对称，是智能体系统里几乎一切能跑通的东西底下那块承重的事实；而给它一个名字是值得的，因为这样设计问题才被摆到台面上：对这项任务而言，检查比做便宜多少？
「核验器」这个家族比人们以为的宽，而且成员之间在代价与可信度上相差几个数量级：
- 精确的判据（oracle）——编译器、schema 校验器、类型检查器、
terraform plan、单元测试、一条要么能解析要么不能的 SQL。便宜、确定，而且它们不会在自己所检查的事情上撒谎。它们同时也很窄：测试通过，对那条没人为之写过测试的需求一个字也没说。 - 可靠的检查器——linter、策略引擎、仿真器、在智能体之下强制执行的物理约束。它们拒掉的是「真正错误」的一个超集，而这正是不精确时该偏向的那个方向。
- 学出来的裁判——用另一个模型给输出打分。单次调用便宜、什么都能评，也是这张清单上唯一一个「错误与生成方相关」的成员，而这正是它危险的那条性质。参见 面向智能体的 LLM 裁判。
- 人——最通用的核验器，也是唯一一个「你流量涨了它的成本却不降」的核验器。评审工时是决定一条工作流能否扩张的预算，所以人工复核的成本首先是一个经济学问题，其次才是质量问题。
这道落差不是模型的属性，而是任务的属性，外加你愿意为它建多少测量设施。两个团队拿同一个模型去做同一个问题，落差可以完全不同——因为其中一个团队把检查器写出来了。
循环只会朝着「不是智能体自己写出来的信号」收敛。
智能体循环就是迭代：行动、观察、修正。而迭代能改进答案，前提是观察带来了模型原本没有的信息。当观察就是模型对自己作品的看法时，它通常没有。
这是这个领域里被复现得最多的一条否定性结果。内生的自我纠错——让模型在没有任何外部信号的情况下审查并修改自己的答案——在推理任务上并不能可靠地提升准确率，而且经常让它变差，因为被要求发现错误的，正是造出这个错误的那个模型。外生的自我纠错——修改由工具、测试、检索到的文档或第二方来驱动——则是有效的。对这批文献的批判性综述给出了一个利落的总结：自我审查真正有帮助的，是那些可分解的任务；而那恰恰正是「核验确实比生成容易」的那一类。
有两个熟悉的系统，就是同一个想法的不加掩饰版。投机解码是纯粹形态——廉价模型起草、昂贵模型核验，而由于核验是对许多令牌的一次前向传播，你白得了这份加速，且输出可被证明完全一致。带可验证奖励的强化学习则是训练期的那一版：它在数学和代码上有效，因为存在一个检查器；而一旦你把它指向没人写得出检查器的任务，它就停滞（RLVR 与 GRPO）。同一个不对称，出现在技术栈的三层。
实践上的读法：当你没办法让一个循环收敛时，第一嫌疑人不是模型的推理能力，而是这个循环正在盲跑——智能体在同一个脑袋里既生成又评分，而迭代次数只是一笔正在被花掉的预算。
「重试到通过为止」，等于把你的错误率交给核验器。
下面这一段是让团队在生产里吃惊的部分。假设你的核验器每见到一个错误答案，有 5% 的概率会放它过去——这已经是个相当不错的裁判了。一个错误率 20% 的单次系统，会有 20% 的时候发出错误答案。现在让智能体一直重试，直到核验器满意为止。每一个真正正确的答案都会通过；而每一个活下来的错误答案，都是核验器挥手放行的那种错误答案。于是系统的残余错误不再由「模型多久错一次」决定，而是由「检查器多久被骗一次」决定——并且这个重试循环正在主动搜索那些能骗过它的输入。
这与奖励攻陷是同一个机制，只不过发生在推理期而非训练期（奖励设计与奖励攻陷）。它有三个直接后果：
- 对一个被允许迭代的智能体来说，误接受（false accept）是核验器唯一重要的指标。误拒绝花掉的是令牌和延迟；误接受花掉的是一场事故。把它单独上报，永远不要藏在一个综合准确率后面。
- 重试预算是一个安全参数，不是性能参数。对着一个软性核验器无限重试，会收敛到它的盲区上。给尝试次数设上限，然后升级上报，而不是让循环一直磨。
- 独立性比准确率更值钱。一个稍弱但「错法与生成方不同」的核验器，胜过一个更强但「错法一样」的——不同的证据、不同的模型家族、不同的提示词，最好干脆是一套机制而不是一个模型。这也是为什么「智能体自己写的测试」是一个比「递给它的测试」弱得多的检查。
编码智能体之所以扛得住这一条，是因为 pytest 是没法被花言巧语打动的，只能靠改断言来钻空子——所以每一个认真的外壳都会把「智能体改动了测试」当成一个独立的、被监控的事件来处理（补丁生成与测试驱动循环）。
用你手上的核验器来定自主等级，而不是用你买来的模型。
把这道落差当成它本来就是的那条决策规则用。在给一个系统划范围之前，先回答三个问题，让答案去挑形态：
- 存在一个便宜、可靠、独立的检查吗？那这项任务就是真自主的候选：跑循环、给重试设上限、对已通过的输出抽样，把误接受率盯诚实。这正是更高自主等级站得住脚的区间。
- 核验做得到但很贵——只有人能判？那你面对的是吞吐问题，不是能力问题。设计问题变成了如何花掉稀缺的评审：批量处理、按智能体自身的不确定性排序、把「有把握且可机检」的那些绕过队列（人在回路、不确定性与校准）。
- 核验真的和生成一样难？开放式战略、全新的研究综合、语气。那你在造的是一个有人类归属的起草工具，而且你应该这么说出来。在这里增加迭代，消耗的是预算，产出的是自信，不是正确性。
智能体系统里的大部分工程杠杆，都在于把一项任务从第三档搬到第一档；而这份工作几乎没有一点是提示词工作。它是把检查器写出来：给一段本来是散文的输出定一个 schema、给一个本来不可逆的动作做一个仿真器、拿一份反正会送达的真值去做一次对账、用一个金标集把一种感觉变成一次测量（评测入门）。
先造核验器，再造智能体。如果你没法用一句话说清「什么会告诉你智能体的输出是错的」，以及这个检查要花多少钱，那你手上还不是一项智能体任务，而是一个演示。而一旦核验器建好了，把它的误接受率放到和智能体成功率同一块看板上——因为第一个重试循环上线之后，那个数字就是你的质量。
延伸：规划与终止讲什么在告诉一个循环该停了，智能体评估讲如何给整条轨迹而不是单个答案打分，核验器引导的搜索讲如何有意地把推理算力花在一个检查器上。