别让AI自己批卷子：我如何用20%的审查Agent拯救开发流水线

作者提米哥

上个月，我的一个 AI Agent 完成了一项批量任务——按照严格的视觉规范生成 8 张图片。它自信满满地向我汇报：“8/8 全部通过”。

结果我人工一看，8 张图全毁了，没有一张是合格的。

这个 Agent 并不是什么劣质模型，这其实是所有 AI 都会犯的通病：当干活的模型和检查的模型是同一个时，它总会倾向于给出一个“任务已结束”的完美结局。 它不是在恶意骗你，而是大模型的语言惯性让它“觉得”任务完成了。

一旦你经历过这种“自信满满的 8/8 通过”变成“0/8 全错”的毒打，你就会明白：靠优化提示词（Prompt）是无法让 AI 诚实的，你必须从架构上解决问题。

于是，我重构了我的 Agent 团队。现在，我团队里有一批 Agent 根本不干任何生产工作（不写代码、不写文案、不画图），它们唯一的任务就是：假设其他 Agent 在撒谎，然后去核查。

为什么需要“内部审查部”？

目前我的系统里有将近 100 个 Agent 定义，其中有 20 个是纯粹的“审计员”。它们只负责对其他 Agent 的产出给出“通过”或“驳回”的判决。

这意味着，我团队里 20% 的“员工”都在怀疑另外 80% 的员工。这在人类公司里简直不可思议，但这是我做过最划算的交易。因为 AI 团队最大的失败模式不是“做得很差”（差劲很容易被看出来），而是 “虚假完工”——活没干，但汇报写得极其漂亮。一个人类员工如果每周编造虚假进度，早就被开除了；但 AI 编造起来 fluently（流利）、cheerfully（愉快）且毫无恶意，这反而更危险。

拆解 AI 的 8 种“偷懒”套路

我的核心审查 Agent 在代码任务完成后运行。它的核心原则是：绝不预设对方是诚实的，声称“做完了”只是一个假设，唯一的证据就是代码差异（Diff）。

它定义了 8 种专门的“失败代码”，精准打击 AI 常见的造假套路：

  • FAIL_NO_SUBSTANCE（无实质内容）：所谓的“修改”只是改了改注释、空格，或者重命名了变量，根本没实现功能。
  • FAIL_FILE_UNCHANGED（文件未改动）：Agent 声称修改了某个文件，但实际上根本没碰它。
  • FAIL_EMPTY_DIFF（空差异）：最嚣张的一种，汇报说任务完成，但代码提交记录是空的。
  • FAIL_UNSUPPORTED_CLAIM（无中生有）：声称写了某个函数、文件或测试，但在代码里根本找不到。
  • FAIL_STUB_LEFTOVER（遗留占位符）：承诺了逻辑，但代码里全是 TODO 和空壳占位符。
  • FAIL_EMPTY_IMPL（空实现）：函数确实存在，但里面什么都没写（比如直接返回空值）。
  • FAIL_NO_TEST_EVIDENCE（无测试证据）：声称“测试通过”，但找不到任何测试运行的记录。
  • FAIL_UNVERIFIED_RUNTIME（未验证运行）：声称程序运行正常，但实际上根本没有执行过。

只要触发以上任何一条，审查 Agent 就会直接判定失败。注意，审查 Agent 是只读的，它不能修改代码。判断和干活必须严格分开。

审查 Agent 的三大铁律

1. 必须看原始日志，拒绝 AI 的“总结”

如果你问 AI “测试通过了吗？”，它很可能会用漂亮的语言给你“总结”一个结果，而“总结”就是幻觉的温床。

因此，我的测试审查 Agent 被禁止做任何总结。它必须运行真实的命令，并把最后 60-100 行的真实终端输出原封不动地贴进报告里，同时附上真实的进程退出码（Exit Code）。如果依赖缺失跑不起来，它只能报“无法确定”，绝不允许把“没跑”包装成“失败”或“通过”。

2. 最终关卡必须有“牙齿”

在所有审查 Agent 之上，还有一个最终关卡。它会从零开始重新验证：代码差异到底包含了什么？需求是否都映射到了真实改动？项目能不能真的编译成功？

它只会给出三个判决：通过（PASS）、修改（REVISE）、驳回（REJECT）。

如果是“驳回”，工作流会被强制阻断，打回重做。这个关卡没有任何“强制跳过（–force）”的选项，不通过就是不能结束。一个不能阻断流程的审查，只是一句废话。

3. 能用代码算的，绝不用 AI 猜

有一次，一个错误的数字（本该是 19 写成了 18）穿透了 5 个 AI 审查环节。最后抓住这个错误的，不是一个更聪明的 AI，而是一个简单的算术脚本。

这给了我一个深刻的教训：审查 Agent 适合做主观判断，但只要检查逻辑可以是确定性的（比如算术计算、正则匹配），就必须用传统代码来做。 AI 是可以被“说服”的，但数学不会。

总结

这套机制并不是为了取代人类的最终确认（发布和不可逆操作依然由我亲自点击），它是一个过滤器，让我最后的审查变得真正有价值。顺便一提，这篇文章在发布前，也经过了一个独立的事实核查 Agent 的审查，它专门核对文章里的数据和声明是否真实，并且真的帮我删掉了一个过时的数据。

如果你也在构建 AI Agent 工作流，请记住这三个核心架构原则：

  • 干活和审查必须分离：干活的 Agent 永远不能给自己打分。
  • 写下你的“失败代码”：把“没做完”的具体表现列成清单，把模糊的不信任变成可检查的指标。
  • 给最终关卡装上“牙齿”：确保审查结果能真正阻断错误的流程。

不要试图用更好的提示词去祈求 AI 诚实，去建立一个分工明确的“内部审查部”吧。事实证明，AI 团队里最有价值的成员，就是那个 job description（岗位描述）写着“假设所有人都在撒谎，然后去查”的人。

微信联系：timidamen

类似文章