审查Agent — 分离构建者与标记者

写代码的Agent不能给它打分。审查者是一个具有不同系统提示、不同目标和对构建者产出只读访问的第二个循环。构建者和审查者之间的差距是大多数可靠性的所在。

类型： 构建 语言： Python（标准库） 前置条件： Phase 14 · 38（验证门） 时间： ~55分钟

学习目标

• 陈述为什么同一Agent不能可靠地审查自己的工作。
• 构建消费构建者工件并发出结构化审查报告的审查Agent循环。
• 编写评分具体维度而非感觉的审查评分标准。
• 将审查者连接到工作台，使人类审查步骤从真实工件开始。

问题所在

你让Agent修复bug。它编辑四个文件，运行测试，报告完成。验证门确认验收运行且范围保持。门说 passed: true。你合并。两天后你发现修复解决了bug的错误一半。

验收是必要的，不是充分的。审查者问验收无法问的问题：这解决了正确的问题吗？它在没有标记的情况下扩大范围了吗？它记录了应该被质疑的假设吗？它使工作台处于下一个会话可以接续的状态吗？

核心概念

审查评分标准

五个维度，每个评分0到2。

总分10分。低于7分是软失败；低于5分是硬失败。

审查者是独立角色，不是独立模型

你可以用与构建者相同的模型运行审查者。纪律是角色分离：不同的系统提示、不同的输入、对diff无写访问。姿态的变化就是信号的变化。

审查者不能编辑diff

审查者读取diff、状态、反馈、裁决。它写报告。它不修补diff。如果报告说”修复这个”，下一个构建者轮次做修复；审查者回到审查。混合角色会击败差距。

审查评分标准 vs 验证门

门检查确定性事实：验收是否运行、规则是否通过、范围是否保持。审查者做定性判断：这是否是正确的工作、是否有文档、交接是否可用。两者都需要。

生产模式

• 专家池，不是一个大审查者。 一个带5维度评分标准的审查者适用于独立仓库。一旦代码库有安全关键、性能关键和文档表面，拆分为带更小提示的专家。协调器做去重；专家从不运行完整评分标准。
• 偏差缓解作为设计要求。 LLM评判显示四种可靠偏差：位置偏差、冗长偏差、自我偏好、权威偏差。缓解：评估两种排序并仅计算一致获胜；使用明确奖励简洁的1-4量表；跨模型族轮换评判；评分前剥离作者姓名。
• 校准集，不是感觉。 一个10-20任务的历史集，带有已知正确裁决。在每次提示变更时运行审查者。如果与历史记录的一致性低于80%，评分标准需要在审查者发布前修订。
• 与门的混合规范。 验证门处理确定性检查。审查者处理语义检查。不要要求审查者重做门已经证明的东西。

实践

code/main.py实现：捆绑审查者读取工件的 ReviewerInputs 数据类、每个维度一个函数的评分器、带五个分数和裁决的 review_report.json 写入器，以及两个演示案例（干净变更和”正确测试，错误问题”变更）。

交付

outputs/skill-reviewer-agent.md生成项目特定的审查评分标准、连接到构建者工件的审查Agent存根，以及与验证门的集成。

练习

1. 添加特定于你产品领域的第六维度。辩护为什么它不被现有五个吸收。
2. 用两个不同系统提示（简洁、冗长）运行审查者。哪个产生人类更可能阅读的报告？
3. 为每个维度添加 confidence 字段。当最低维度置信度低于0.6时拒绝发布报告。
4. 构建校准集：10个带已知正确裁决的历史任务关闭。运行审查者。它在哪里与历史记录不一致？
5. 添加”请求更多证据”功能：审查者可以在评分前要求构建者运行特定测试。什么是正确的退避策略使这不循环？

关键术语

延伸阅读

• Cloudflare, Orchestrating AI Code Review at Scale — 7专家+协调器架构
• Agent-as-a-Judge (OpenReview / ICLR) — DevAI基准
• MLflow, LLM-as-a-Judge Evaluation — 分离构建者/评估者的生产工具