自动审查
Automated review
由一个 Agent 审查另一个 Agent 的工作，通常会使用不同的模型或 System Prompt。这种审查是非确定性的，因为它需要形成判断。它可以在任何环节运行，例如合并前审查 PR、事后审查提交历史，或在 Session 进行中作为 Subagent 执行。CI 中的 LLM-as-judge 属于自动审查，而不是自动化检查；分类取决于断言实际做了什么，而不是它在哪里运行。
与执行工作的 Agent 相互独立，是这种方式有效的关键。让编写代码的 Agent 审查自己的工作，收效甚微：产生缺陷的 Session 也包含了导致缺陷的推理过程，Agent 会把自己的结论重新读成佐证。拥有全新上下文窗口的审查者没有这种先入为主的倾向：它会像陌生人一样看待 diff，而审查恰恰依赖这种视角。换用不同模型或专用于审查的 System Prompt，可以进一步提升效果：既能引入不同的盲区，也能让 System Prompt 聚焦于你真正关心的方面，例如安全性、API 契约和性能，而不是笼统地要求“找问题”。
它位于其他审查层之间。自动化检查是确定性的，能发现可以通过机械方式断言的问题；人工审查成本高昂，也最难扩展。自动审查处于二者之间：它以机器成本发现那些需要判断的问题，例如具有误导性的函数名或遗漏的边界情况。由于它是非确定性的，既可能漏掉问题，也可能误报；应把它视为人工查看前提高质量下限的筛选层，而不是取代人工的门禁。
避免使用：“AI 审查”或“Agent 审查”——这两个说法过于模糊，无法与执行工作的 Agent 本身区分开来。
用法：
“AFK 运行产出的低质量 PR 太多了。”
“在合并前增加一个自动审查步骤——使用不同模型、独立的 System Prompt，并聚焦安全性和契约变更。”