生成器-评估器架构
创建时间： 2026-04-27
来源： [[sources/Harness design for long-running application development]]
相关： Harness-Engineering、Agent-First-Repository-Design
起源
生成器-评估器架构的灵感来自生成对抗网络（GAN）。在 GAN 中，一个生成器网络和一个判别器网络相互对抗训练。将这一结构类比应用于 AI 编码智能体：生成器智能体（创建者）产生输出，评估器智能体（评判者）对输出进行评分并提供反馈。这种分离解决了智能体无法可靠评估自己工作的问题。
将执行工作的智能体与评判工作的智能体分离，被证明是解决自评价问题的有力杠杆。
为什么需要分离
当被要求评估自己生成的输出时，智能体会自信地赞扬自己的工作——即使质量在人类观察者看来明显平庸。这个问题在两类任务中都存在：
- 主观性任务（设计）：没有类似于可验证软件测试的二元检验。布局是”精致”还是”普通”是主观判断。
- 客观性任务（带有可验证结果的编码）：即使有可验证的目标，智能体仍会在完成任务过程中表现出不良判断力，阻碍其进展。
“分离”并不能立即消除这种宽容——评估器仍然是一个倾向于对 LLM 生成输出持宽容态度的 LLM。“但是，将一个独立的评估器调校为持怀疑态度，远比让生成器批判自己的工作更容易。而一旦外部反馈到位，生成器就有了具体的迭代目标。“
前端的四标准评估体系
Prithvi Rajasekaran 通过首先在前端设计领域进行实验，开发了一套评分标准，将主观判断转化为具体、可评分的维度：
| 标准 | 问题 | 评分逻辑 |
|---|---|---|
| 设计质量 | 设计是否感觉像一个连贯的整体，而非零散部分的集合？ | 颜色、排版、布局、图像和细节共同创造出独特的氛围与身份认同 |
| 原创性 | 是否存在自定义决策的痕迹？还是模板布局、库默认值和 AI 生成模式？ | 显式惩罚”AI 味道”——紫色渐变配白色卡片、未经修改的基础组件 |
| 工艺 | 技术执行：排版层次、间距一致性、色彩和谐度、对比度 | 能力检查，默认情况下大多数合理实现均可通过 |
| 功能性 | 可用性独立于美学 | 用户是否能理解界面功能、找到主要操作、无需猜测完成目标任务 |
权重设定：设计质量和原创性被赋予更高权重。Claude 在工艺和功能性上默认已经得分良好，但在设计和原创性上往往产出平淡。通过加大前者权重，将模型推向更大的美学风险承担。
评估器校准
通过**少量示例（few-shot）**与详细评分分解进行校准。这确保评估器的判断与人类偏好保持一致，并减少跨迭代的评分漂移。
评估器使用 Playwright MCP 直接与实时页面交互——自行导航、截图和仔细研究实现——而非评审静态截图。然后对每个标准进行评分，撰写详细批评意见，将反馈返回给生成器进行下一次迭代。
每次运行 5 到 15 次迭代，每次迭代通常推动生成器朝着更独特的方向发展。完整运行时间可达 4 小时。
扩展到全栈开发：三智能体架构
将该模式从设计扩展到完整软件开发：
规划器（Planner） 生成器（Generator） 评估器（Evaluator）
───────────────── ────────────────── ─────────────────
1-4 句话提示 → 每个冲刺实施一个特性 通过 Playwright 点击运行中的应用
完整产品规格 与评估器协商冲刺合同 测试 UI 特性、API 端点、数据库状态
设定范围 自我评估 根据功能完整性与 bug 进行评分
融入 AI 功能 使用 React/Vite/ 详细反馈
FastAPI/SQLite/PG 四个标准的硬性阈值：
任一不达标，冲刺即为失败
冲刺合同
每个冲刺开始前，生成器与评估器协商一份冲刺合同：就”完成”的定义达成一致。产品规格故意保持高层次，合同弥合了用户故事与可测试实现之间的差距。
- 生成器提议：将构建什么，如何验证成功
- 评估器审核：确保构建的是正确的东西
- 双方迭代，直到达成一致
示例：冲刺 3（关卡编辑器）——仅此冲刺就包含 27 条标准，涵盖矩形填充工具、实体删除和动画帧排序。
通信机制
智能体通过文件进行通信：一个智能体写入文件，另一个智能体读取该文件，并在同一个文件或一个新文件中做出响应，前一个智能体再读取这个文件。
评估器调校循环
开箱即用的 Claude 作为质量保证智能体表现较差。在早期运行中，它发现了真正的问题，然后说服自己这些问题不重要，仍然批准了该工作。它还倾向于表面测试而非探索边缘情况。
调校循环：
阅读评估器日志
→ 发现判断与自身判断偏离之处
→ 更新质量保证提示词以解决这些问题
→ 重复多次，直到评估器合理
即使经过调校，评估器仍会漏掉一些 edge-case bug 和较深嵌套的功能问题。但相比于 solo 运行（核心功能根本不工作），提升是显著的。
Opus 4.6 驱动下的架构简化
随着 Opus 4.6 的发布，多个负载组件变得不再必需：
| 组件 | Opus 4.5 必要性 | Opus 4.6 状态 |
|---|---|---|
| 冲刺分解结构 | 模型在无分解的情况下难以保持连贯 | 已移除——模型可以原生处理 |
| 上下文重置 | Sonnet 4.5 的上下文焦虑需要它 | 已移除——Opus 4.6 无此行为，支持连续会话 |
| 每冲刺评估器 | 对于发现中期问题至关重要 | 移至仅结束时单次通过 |
评估器的实用性现在取决于任务相对于模型可靠 solo 能力的位置。对于模型可以自己可靠处理的任务，评估器变成不必要的开销。对于仍处于极限边缘的任务，评估器能提供真正的提升。
核心原则
每个 harness 组件都编码了一个关于”模型不能独立完成什么”的假设。这些假设值得进行压力测试——既因为它们可能是不正确的，也因为它们会随着模型的改进而迅速过时。
找到最简单的可行方案，仅在必要时增加复杂度。
随着模型的改进，有趣的 harness 组合空间并不会缩小——它会移动。对于 AI 工程师来说，有趣的工作是不断寻找下一个新颖的组合。
参考资料
- 来源：Anthropic《Harness design for long-running application development》——Prithvi Rajasekaran
- 相关概念：GAN（生成对抗网络）——Ian Goodfellow 等人，2014 年