用一个 Agent 校验另一个 Agent 的输出
系列入口：如何使用 Agent。本篇是 M5 编排模块的收官。
一、核心原则：产出者不应是唯一裁判
人写完东西自查，容易受自己思路限制；Agent 也一样——它产出一个方案或代码后，往往倾向于认为没问题，因为它的检查仍困在原来的假设里。输出校验模式针对的就是这个盲区：让一个独立的 Agent，带着明确判据去判断另一个 Agent 的产出是否合格，通过才放行，不合格就打回。
这个校验角色常被叫做 Reviewer（审查者）或 Guard（守门员）。它的价值不在多干活，而在提供一双「不护短、视角独立」的眼睛。
二、校验者为什么要「上下文独立」
校验要有效，关键是让 Reviewer 别建立在产出者的自我叙述上。如果它只看产出者「我已经处理好 X、Y、Z」的说法，很容易被带偏。正确做法：
- 让校验者直接面对原始产出和原始材料（代码、需求、数据），自己核对；
- 默认上下文隔离，只把「待验产出 + 验收标准」给它，而不是连带产出者的全部推理；
- 要求它给出证据：指出在哪个位置、依据什么判据判定合格或不合格。
独立，才能发现产出者自己看不到的错。
三、给校验者明确的「判据」
空泛地说「帮我看看对不对」，校验结果会很飘。要给它客观、可判定的验收标准（在下任务时就定好）。常见校验类型：
| 校验类型 | 判据举例 |
|---|---|
| 正确性 | 测试是否通过、关键输入是否给出预期输出 |
| 规范一致 | 是否符合项目规则、格式、约定式提交 |
| 安全 | 有无注入风险、明文密钥、越权操作 |
| 事实一致 | 描述是否与实际代码/数据相符，有无编造 |
| 范围 | 是否只改了允许的文件、有无夹带 |
判据越具体，校验结论越可靠，主 Agent 或你也更容易消费结果。
四、和其他模式 / 工具的关系
- 与 Planner-Coder-Reviewer：校验模式正是其中 Reviewer 角色的通用化抽象——不只用于代码，任何 Agent 的任何产出都可以挂一个独立校验者。
- 与 Hooks：Hooks 适合执行确定的、可脚本化的检查（跑测试、lint、拦截命令）；独立校验 Agent 适合需要理解和判断、无法简单写成规则的审查。两者常配合：Hooks 先做机械把关，校验 Agent 再做语义层面的复核。
- 与你的职责：校验 Agent 是帮你过滤，但最终签收责任仍在你（驾驶员心智），尤其在关键任务上，它的「通过」是参考而非免责。
五、一个完整实战：校验一段自动生成的迁移脚本
来看一个适合加校验层的例子。产出 Agent 写了一段数据库迁移脚本，准备执行。迁移一旦跑错可能损坏数据，不能只听它说「我检查过了，没问题」。
你派一个校验 Agent，只给它两样东西：待验脚本 + 验收标准（迁移是否可回滚、对大表是否有锁风险、字段类型与目标是否一致、是否只动了应改的表）。校验 Agent 默认上下文隔离，自己直接读脚本和相关表结构，逐项核对，并给出带证据的结论——哪一条满足、哪一条不满足、依据在脚本哪一行。如果发现脚本不可回滚，就打回产出 Agent 并附上问题；全部满足才放行，最后仍由你决定是否真正执行。
这里的关键，一是校验者独立直接读，不被产出者的自述带偏；二是判据事先客观可判定，而不是模糊地说「看看对不对」。两者具备，这一道门禁才真正挡得住错。
六、用好该模式的要点
- 判据要在动手前就定好，且尽量客观、可判定；空泛判据只会得到飘忽结论。
- 校验者默认隔离、直接面对原始产出与材料，并要求给出证据。
- 打回要附具体问题，让产出者能据此修正。
- 重要产出才加这一层，简单低风险任务不必增加开销。
- 它的「通过」是参考，最终签收仍在你，尤其涉及不可逆操作时。
七、常见问题
Q：校验 Agent 和 Reviewer 是一回事吗？ Reviewer 可以看作校验模式在代码场景的具体角色；校验模式更通用——任何 Agent 的任何产出（方案、文档、配置）都可以挂一个独立校验者。
Q：怎么防止校验者也走过场？ 要求它独立读原始材料、给出具体位置和依据，而不是复述结论；必要时你抽查它指出的证据是否属实。
Q：Hook 已经能跑测试了，还需要校验 Agent 吗？ 二者互补：Hook 做确定、可脚本化的机械检查；校验 Agent 处理需要理解、无法写成规则的语义与事实核对，常配合使用。
七点五、为什么「自己不能当自己的裁判」
输出校验模式背后是一条非常朴素、却极易被忽视的原则：产出一件东西的人，不应该是判断它是否合格的唯一裁判。 这不是对能力的怀疑，而是由「立场」和「视角」决定的客观局限，对人和对 Agent 都成立。
当一个 Agent 沿着特定思路产出了方案或代码，它的整个推理都建立在它自己选择的假设和路径上。让它回头检查自己，本质上是要求同一套思路去发现这套思路自身的盲区，这在逻辑上就很困难——它不知道自己不知道什么。更微妙的是，产出者往往还带有一种为自己成果辩护的倾向，会倾向于认为「我已经处理好了」，这种自信并非撒谎，而是身处其中时真实的感受。
破解之道只能是引入立场不同的另一方。一个独立校验者没有参与构建，因而不背负「证明自己做对了」的包袱；它面对的是「这东西到底合不合格」这一个问题，而不是「我刚才的思路有没有道理」。立场一变，关注点立刻不同：产出者略过的边界，校验者会去探；产出者默认成立的假设，校验者会去质疑。人类社会里强调第三方审计、同行评议、分权制衡，背后都是同一条逻辑——有效的质量判断，需要一个与产出利益无关的独立立场。
理解这一层，你就会明白输出校验的关键不是「再多看一遍」，而是「换一个立场看」。这也解释了为什么校验者必须上下文独立、直接面对原始事实——只有切断它与产出者思路的脐带，它才能真正站到裁判的位置上，而不是成为产出者的回声。
七点六、校验这一层如何与整个协作体系咬合
独立校验不是孤立存在的，它在一个更大的协作体系里有明确的位置。看清它如何与其他机制咬合，你才能在实际工作中用对地方，而不是重复建设或留下空档。
在多 Agent 流水线里，校验常常充当「汇聚前的最后一道门禁」：上游多个执行者各自交回的成果，在被整合成最终交付前，先经过一个独立校验者按统一判据把关。这样做的好处是把问题挡在合并之前——比起在一个已经拼合、互相纠缠的成品里找错，在分散阶段逐一校验成本更低、定位更准。这与 Planner-Coder-Reviewer 中审查者的作用同源，只是被泛化到了任意产出上。
它与 Hook 构成互补的两层防线。Hook 负责那些「无需理解、只需执行」的机械规则——测试过不过、格式对不对、命令是否在黑名单上，这些确定性检查交给机制最可靠；校验 Agent 负责那些「必须理解才能判断」的部分——描述与代码是否一致、逻辑是否真正满足需求、有无看似合理实则错误的编造。前者像安检门，按固定规则报警；后者像有经验的审查员，能动脑判断。实际体系里，通常让机械把关在前、语义复核在后，两层各守其位。
而在所有这些自动化之上，始终有一个无法外包的环节——你的最终签收。校验层能极大减轻你逐行核对的负担、过滤掉大量低级问题，但在真正重要、尤其不可逆的事情上，它的「通过」是给你的专业参考，而不是替你免责。把「独立校验做门禁、Hook 做机械把关、你做最终裁决」这三者的咬合关系理清，你就拥有了一套层次分明、既高效又不失控的质量保障结构。
七点七、校验失效的几种隐蔽方式
独立校验听起来稳妥，但它并非一旦设立就必然有效。实际中，这道门禁会以几种相当隐蔽的方式悄悄失效，了解它们，才能确保你加的这一层真正在起作用。
第一种是判据空泛。如果给校验者的标准只是「看看对不对」「质量高不高」，它就失去了客观落点，只能给出飘忽、主观的判断，今天放行明天打回，门禁形同随机。第二种是立场被污染，也就是校验者虽然名义独立，实际却只接收产出者的自述、或建立在产出者整理好的材料上，它看到的是被筛选过的世界，自然难以发现盲区。第三种是只下结论不留证据，校验者说「没问题」却指不出核对了哪里、依据是什么，你无从复核，它也更容易滑过表面。
第四种尤其需要警惕——校验者与产出者共享同一个错误前提。如果一个误解早在更上游就已形成，并被当作「事实」同时传给了两者，那么再独立的校验也只是在错误前提下做独立推理，同样会放行。对付这种情况，需要让校验者有机会回到最原始的需求和材料，而不是只在被加工过的结论之间打转。识别出这几种失效方式，你就会特别关注：判据是否客观可判定、立场是否真正独立、结论是否带证据、以及校验者能否触达最原始的事实。
七点八、让校验「轻而有效」的分寸
加一层校验必然带来额外成本，如何让它既挡住错误、又不把流程压得过重，是一道需要拿捏的分寸题。目标不是让校验无所不包，而是把力气花在最值得的地方，做到「轻而有效」。
一个核心思路是按风险聚焦校验范围。与其让校验者对产出做漫无边际的全面复查，不如事先识别这次最可能出错、也最错不起的几个关键点，让它带着这些重点去核对。比如一段迁移脚本，最关键的是可回滚和不锁表，那就把校验火力集中在这些点上，而不是平均用力于无关紧要的风格细节。聚焦让校验更短、更便宜，结论也更锐利。
另一个思路是分层把关、各取所长，前面也提到过：让 Hook 先把那些确定、机械的检查自动完成，校验者只需在机械检查之上，专注处理需要理解和判断的部分，而不必重复机器已经做过的事。这样校验层承担的是真正增值的语义核对，整体成本被压到最低。
最后要守住的，还是那条不能外包的底线——校验者的放行是帮你过滤，而不是替你负责。让它保持轻量、聚焦、独立，你既能显著减少逐行核对的负担，又始终把最终签收握在自己手里。当校验做到「范围对准风险、机械与语义分层、结论可供你复核」，这一道门禁才算轻得下来、也硬得起来。
七点九、事实一致：最容易被忽视的一类校验
在诸多判据里，有一类尤其容易被跳过、却频繁造成实际事故，那就是事实一致——产出中的每一句陈述，是否都能在真实代码或数据中找到依据，而不是看似合理的编造。 它隐蔽，因为问题往往不在格式或逻辑，而在一个信以为真、实则不存在的「事实」。
这类风险在 Agent 产出调研报告、接口说明、影响分析时最突出。它可能言之凿凿地写下「这个函数在三处被调用」「该接口返回这几个字段」，措辞专业、结构完整，但其中某处是它在信息不足时补全的猜测。读的人很难仅凭文风察觉，因为编造的部分和真实的部分同样自信。尤其当这份产出又被下游 Agent 当作事实继承，错误会迅速扩散。
对治的关键，是把「关键陈述必须可溯源」作为硬性判据：要求校验者对产出中的重要论断，逐条回到原始代码或数据核对其是否属实，而不只是检查内部逻辑自洽。一个陈述内部再自洽，若与外部事实不符，依然是错的。 让事实一致与正确性、安全性并列，你才能挡住这类最会伪装的错误。
七点十、校验者与产出者的「距离」该多远
独立校验强调「距离」，但这个距离并非越远越好，这里有一个值得拿捏的尺度。距离太近，校验会被产出者思路同化；距离太远，校验者又可能因缺乏必要背景而误判，把正确的设计也打回。
什么是恰当的距离？可以这样理解：要切断的是「推理与立场的共享」，但不必切断「必要事实的共享」。 校验者不应看到产出者完整的自我辩护过程，以免被引导；但完成判断所需的客观背景——需求、相关约束、验收标准——应当充分提供，否则它同样在信息不全下猜测，独立性换来的可能只是另一种偏差。
实践中，这意味着给校验者的是一份精心裁剪过的输入：原始产出、原始材料、客观判据，而不是产出者的全部心路；让它基于事实独立推理，却不被剥夺推理所需的信息。把握好这个「立场独立、信息充足」的距离，校验层才既挡得住盲区、又不会制造无谓的打回，真正成为一道可靠而高效的质量门禁。
八、什么时候值得加这一层
- 产出重要、错了代价大：核心逻辑、对外内容、安全相关；
- 你想减少逐行自查负担，让独立视角先过滤；
- 多个 Agent 协作时，作为汇聚前的质量门禁。
简单低风险的任务不必加，否则徒增成本。这和所有多 Agent 模式一样，是在「多一层的开销」和「多一道的可靠性」之间做权衡。
总结
别让产出者自己说了算：派一个上下文独立的校验 Agent，带着客观验收标准直接核对原始产出、给出带证据的通过或打回——它与 Hooks 互补（一个管判断、一个管机械规则），是重要产出汇聚前一道值得加的质量门禁。