生成器-评估器架构
概述
受 GAN（生成对抗网络）启发的多 Agent 设计模式：生成器（Generator）负责产出，评估器（Evaluator）负责评判并给出详细批评，形成反馈闭环驱动质量提升。核心洞见：将生成与评判分离，使评估器可独立调优至"严格"立场。
关键内容
为何需要分离评估
模型的自我评估存在系统性缺陷：被要求评估自己产出时，模型倾向于给出高度正面评价——即使对人类观察者而言质量显然平庸。这在主观任务（如设计审美）尤为突出，但在可验证任务（如 QA 测试）中也会出现"发现问题后自我说服没大事"的现象。
分离的关键价值：把评估器单独调优为"怀疑论者"，比让生成器自我批判更为可行。一旦外部反馈存在，生成器就有具体目标可以迭代。
架构变体
双 Agent（前端设计）
Generator → [HTML/CSS/JS 输出]
↓
Evaluator（Playwright MCP，实际交互页面）→ 评分 + 详细批评
↓
Generator（迭代，必要时完全转向新方向）
运行 5–15 次迭代，评估器主动浏览、截图、研究实现后再打分，每轮真实耗时，全程可达 4 小时。
三 Agent（全栈开发）
Planner（1-4句 prompt → 完整产品规格）
↓
Generator（按规格构建，每 Sprint 先谈合约）← Sprint合约制
↓
Evaluator（Playwright MCP，点击运行应用测试功能、API、数据库状态）
↓
Generator（根据 QA 反馈修复，进入下一轮）
前端设计评分准则（四维）
| 准则 | 权重偏向 | 含义 |
|---|---|---|
| Design Quality（设计质量） | 高 | 色彩、排版、布局、意象是否统一成整体感和独特身份 |
| Originality（原创性） | 高 | 是否有自定义决策？区分于模板默认和 AI 生成套路（如白底紫渐变卡片） |
| Craft（工艺） | 低（模型已擅长） | 排版层级、间距一致、颜色对比度——基本技术执行 |
| Functionality（可用性） | 低（模型已擅长） | 界面是否可理解，操作是否可完成 |
评估器用少样本示例（含详细评分分解）校准，防止分数漂移。措辞影响生成方向：加入 "the best designs are museum quality" 后，输出向特定视觉风格收敛。
全栈开发评分准则（改编版）
- Product Depth（产品深度）
- Functionality（功能完整性）
- Visual Design（视觉设计）
- Code Quality（代码质量）
每项设有硬性门槛，任何一项未达标则 Sprint 失败，触发生成器重新迭代。
工程实现要点
- 基于 Claude Agent SDK 管理 Agent 编排
- 评估器配备 Playwright MCP，可直接与运行中的应用交互（而非评估静态截图）
- Agent 间通信通过文件传递：一个 Agent 写文件，另一个读取并响应，保持规格与实现的一致性
- 评估器的调优是迭代过程：阅读日志 → 找到判断偏差 → 修正评估器 Prompt → 多轮后达到满意水准
评估器实际发现示例（全栈 QA）
| 合约条件 | 评估器发现 |
|---|---|
| 矩形填充工具支持拖拽填充区域 | FAIL — 工具只在拖拽起止点放置砖块，fillRectangle 存在但 mouseUp 未正确触发 |
| 用户可选中并删除实体生成点 | FAIL — LevelEditor.tsx:892 的删除键处理同时要求 selection 和 selectedEntityId，但点击实体只设置后者 |
PUT /frames/reorder 端点工作正常 |
FAIL — 路由定义在 /{frame_id} 之后，FastAPI 将 reorder 解析为整数 frame_id，返回 422 |
与模型能力的动态关系
评估器的价值是条件性的：取决于任务相对于模型当前能力的位置。
实践结论：评估器不是固定的"要或不要"决策，而是需要随模型版本迭代重新评估的设计选择。
来源
- raw/articles/ai-engineering/anthropic-engineering/Harness design for long-running application development.md
相关
- Agent Harness模式 — extends（作为具体 Harness 设计模式的实现）
- LLM-as-Judge — extends（评估器是 LLM-as-Judge 的专门化实例）
- Sprint合约制 — uses（Sprint 前合约谈判是三 Agent 架构的组成部分）
- 上下文焦虑 — related_to（是设计三 Agent 架构时需要解决的问题之一）
- 上下文重置 — related_to（Opus 4.5 哈内斯设计中与本架构配套的技术）
- Prithvi-Rajasekaran — 架构提出者