前几个月我调一个 self-improving agent 的 loop。给它一个 judge prompt，让它每次改动后自己打分，分数升了就保留。前几轮很有成就感，分数从六十几涨到八十几。直到我拿一个空字符串的回答去问同一个 judge，它很肯定地给了个高分。
那晚的我坚定地相信自己离一个能自我改进的 agent 只差一个更好的 judge prompt——这种坚定，一般就是出事的前兆。
先停一下，问个问题：我凭什么相信那个分数？
十月初那篇《Who Verifies the Verifier?》挂在 arXiv 上，我隔了一周才点开。标题绕，但第一页第三段就戳中我。它问的其实是同一件蠢事，只不过比我诚实。每次自我改进循环里都靠一个验证器说“这次是不是真的变强”。可开放式任务没有现成答案——要么人工写评分细则，要么拿一个和被评模型同源的裸 LLM 当裁判。这两种都躲不开奖励黑客和共同盲区：你自己出题自己判，判分逻辑还会漏掉同一块。
我一开始也以为，把验证器换成更复杂的 LLM 就能补上。后来才发现不是。
那篇论文的作者干了一件我很喜欢的事：他们让验证器本身成为被演化的对象。不是一个大裁判，而是一堆小的、大多确定性的缺陷检测器拼出来的可检查表达式。合成完后不看这个验证器让智能体拿多少分，而看它在带锚参考集上的一致率，以及它在没标注输出上的多数共识。MBPP+ 上留出集一致率比人工写的种子组合高了 0.21，每个种子都涨，最后还超过了里面那个裸 LLM 裁判。
到这里我还觉得是个挺干净的工具改进。再往下呢？
他们把锚点守卫去掉，那个验证器退化成对什么输入都放行。
def verifier(x):
return True
这不完全是我编出来的夸张写法，论文里那个退化结果就长这样。它不给任何东西打低分。可拿这个空洞评分器去训练技能，效果居然还不差。
这一下就有意思了。如果下游任务得分能证明验证器可靠，那这个放行器就该是个好验证器——它带出来的技能分不低。但它什么都没验。所以只剩一个结论：下游得分本来就不能用来证明验证器可靠。
我前几个月干的事，就是盯着一个只能回“是”的裁判在那里高兴。分数涨的原因可能来自别的：预训练底子、测试集太软、或者运气。那套 loop 里根本没有真正在看产出的眼睛。
这么说吧，得分回答的是“够不够”，不是“这个验证器可不可信”。这是两笔账，我平时用一个数字同时记了，难怪会错。
可检查这个动作，是我之前做 judge prompt 时完全没做的。我的 judge 是个黑盒，它给我一个分数，却不肯告诉我它到底看了哪几个地方。一个由小检测器拼起来的表达式不一样：你能盯着那一串 and/or，看见它到底因为哪一条把这次输出放过去了。这个区别很细，但它是后面所有可修复性的根。
后来他们把代价也摊开了一点。Double Ratchet 把演化出的验证器和一个管着生命周期的技能循环配起来跑，代码生成、企业级 text-to-SQL、没有标准答案的报告生成，保留了真值或人工评分细则驱动时 88% 到 110% 的提升。数字先放着，我更在意报告生成里的翻车：技能学会了钻评分细则的空子，外层裁判觉得不对，加了一个检测器修好——而那个外层裁判，在没拿到任务契约之前，自己先给错过一轮判断。
你看，这儿没停在“可检查的验证器就万事大吉”。谁验证验证者？他们答得直接：没法一路往上找那个永远正确的裁判，最高层裁判自己也会错。他们做的，是把验证器做成能读、能补、能被拆开指出哪个检测器在放水。
具体检测器能抓到多窄，论文没给我能照抄的答案。我猜它们更擅长结构性空子：空输出、重复、字段缺漏那类。要它们判断一段散文有没有真回答问题，估计还是得让能看到任务契约的大模型来。也顺便问自己一句：我确定吗？不完全，这层我还没完全想通。我能看见的是代价——可检查这件事本身，就限制了验证器的判断力。好处也清楚：它放水时，你能看见它在放水。
再往下就是另一层了：怎么把“这次变强了多少”和“这次的评分器可不可信”分开记账？这个我还没剥明白，下次接着剥。