← 返回首页

当 AI 学会自我批判：Anthropic 的 Generator-Evaluator 模式

2026/3/28
AIAgentAnthropicHarness EngineeringMulti-Agent

当 AI 学会自我批判：Anthropic 的 Generator-Evaluator 模式

“Every component in a harness encodes an assumption about what the model can’t do on its own.”

— Prithvi Rajasekaran, Anthropic Labs

两个顽固问题

Anthropic Labs 的工程师 Prithvi Rajasekaran 在过去几个月里一直在解决两个看似不同但深度关联的问题：

  1. 让 Claude 产出高质量的前端设计（主观判断问题）
  2. 让 Claude 长时间自主构建完整应用（正确性验证问题）

这两者背后，是两个持续困扰 AI agent 的顽疾：

问题一：Context Anxiety

当 context window 快满时，模型会表现出一种奇特的”焦虑”——提前收工。明明还有工作要做，但模型觉得”差不多了，该结束了”。

Compaction（压缩历史对话）并不能完全解决这个问题，因为模型并没有获得一个”干净的开始”。真正的解药是 context reset：清空 context window，通过结构化的 handoff artifact 把状态传给下一个全新的 agent。

代价：增加了编排复杂度、token 开销和延迟。

问题二：自我评估过度正面

让 agent 评估自己的工作？结果往往是：自信满满地表扬一通，即使工作质量明显平庸。

这在设计类任务中尤其明显。“这个设计好看吗？“是主观判断，没有类似单元测试的二进制检验标准。Agent 会稳定地给自己的作品打高分。

即使是可验证的编程任务，agent 仍可能表现出糟糕的判断力——分离执行者和评估者，是一个强有力的杠杆。

GAN 启发：Generator-Evaluator 模式

受到 Generative Adversarial Networks (GANs) 的启发，Prithvi 设计了一个双 agent 架构：

┌─────────────────────────────────────────────────┐
│                                                 │
│   Generator          →          Evaluator      │
│   （生成内容）                   （评估内容）      │
│        ↑                              │        │
│        └──────── Feedback ────────────┘        │
│                                                 │
└─────────────────────────────────────────────────┘

这个模式的精髓在于：

  1. 把主观判断转化为具体可评估标准
  2. 执行者和评估者分离
  3. Evaluator 使用 Playwright MCP 实际操作页面进行评估

为什么这有效？

调优一个独立的 evaluator 使其变得挑剔（skeptical），远比让 generator 对自己的工作挑剔要容易得多。一旦外部反馈存在，generator 就有了具体的东西可以迭代。

前端设计实验：把美学变成可打分的标准

四项评估标准

Prithvi 为 generator 和 evaluator 编写了四个评估标准：

标准含义权重
Design Quality是否是一个连贯的整体？色彩、排版、布局是否创造独特的氛围和身份？高
Originality是否有定制决策的痕迹？还是模板、库默认值、AI 生成的模式？高
Craft技术执行：排版层次、间距一致性、色彩和谐度、对比度中
Functionality用户能否理解界面、找到主要操作、无需猜测完成任务？中

Claude 默认在 Craft 和 Functionality 上已经做得不错，但在 Design 和 Originality 上往往产出”平淡无奇”的结果。这些标准明确惩罚了高度通用的”AI slop”模式。

评估循环

  1. Generator 根据 prompt 创建 HTML/CSS/JS 前端
  2. Evaluator 使用 Playwright MCP 与实时页面交互
  3. Evaluator 截图、研究实现、评分、写出详细批评
  4. 反馈返回给 Generator，开始下一轮迭代

每轮迭代通常需要真实的墙上时钟时间——完整运行可长达 4 小时。

荷兰美术馆的意外突破

在一次实验中，Prithvi prompt 模型创建一个荷兰美术馆网站。

到第 9 次迭代，产出的是干净的深色主题落地页——视觉精致但符合预期。

第 10 次迭代发生了质的飞跃：模型彻底抛弃了之前的方向，将网站重新构想为空间体验——一个用 CSS perspective 渲染的 3D 房间，棋盘格地板，艺术品以自由形式挂在墙上，通过门口在画廊房间之间导航，而不是滚动或点击。

这是单次生成中从未见过的创造性跳跃。

三 Agent 架构：从设计到全栈

将 Generator-Evaluator 模式扩展到全栈开发，Prithvi 构建了一个三 agent 系统：

架构组件

Agent职责关键特性
Planner把 1-4 句需求扩展为完整产品规格关注产品上下文和高层次技术设计，而非细节实现
Generator按 sprint 一个功能一个功能实现每个 sprint 后自评，交给 QA
Evaluator用 Playwright 测试，按标准评分每个 criterion 有硬阈值，任一不达标则 sprint 失败

Sprint Contract：事先定义”完成”

在每个 sprint 之前，generator 和 evaluator 协商一个 sprint contract：

  • generator 提议要构建什么
  • 如何验证成功
  • evaluator 审查提案，确保构建的是正确的东西
  • 两者迭代直到达成一致

这填补了高层次产品规格和可测试实现之间的鸿沟。

Context Reset vs Compaction

模型Context 策略原因
Opus 4.5需要 context resetContext anxiety 明显，compaction 不够
Opus 4.6只需 compaction自动 compaction 够用，能力提升

实验数据：20 倍成本，质的飞跃

复古游戏制作器实验

Prompt：

Create a 2D retro game maker with features including a level editor, 
sprite editor, entity behaviors, and a playable test mode.
Harness时长成本结果
Solo（单 Agent）20 分钟$9游戏核心功能坏了
Full Harness（Opus 4.5）6 小时$200功能完整，evaluator 发现具体 bug

Solo 的失败模式

  • 布局浪费空间，固定高度面板留下大部分 viewport 空白
  • 工作流僵化，UI 不引导正确顺序
  • 最致命：实体出现在屏幕上但不响应输入——entity definitions 和 game runtime 之间的连接断裂

Full Harness 的成功

Planner 将一句话 prompt 扩展为 16 个功能、10 个 sprint 的规格：

  • 核心编辑器和 play mode
  • 精灵动画系统
  • 行为模板
  • 音效和音乐
  • AI 辅助精灵生成器和关卡设计器
  • 游戏导出与分享链接

Evaluator 发现的具体 bug：

Contract CriterionEvaluator Finding
矩形填充工具允许点击拖动填充矩形区域FAIL — 工具只在拖动起点/终点放置瓦片，而非填充区域
用户可以选择和删除放置的实体生成点FAIL — 删除键处理器需要同时设置 selection 和 selectedEntityId，但点击实体只设置后者
用户可以通过 API 重新排序动画帧FAIL — PUT /frames/reorder 路由定义在 /{frame_id} 之后，FastAPI 将 ‘reorder’ 匹配为 frame_id 整数，返回 422

这些是真实的、具体的、可操作的 bug。

Harness 简化：随着模型进步做减法

核心原则

“Every component in a harness encodes an assumption about what the model can’t do on its own.”

“The space of interesting harness combinations doesn’t shrink as models improve. Instead, it moves.”

当 Opus 4.6 发布时，Prithvi 开始系统性地简化 harness：

  1. 去掉 sprint 结构

    • 4.5 需要 sprint 分解任务保持连贯性
    • 4.6 原生能处理，无需人工分解

  2. Evaluator 改为最后一次性评估

    • 不再 per-sprint 评估
    • 对于模型能力范围内的任务，evaluator 变成不必要开销
    • 对于仍在边界的任务，evaluator 仍有价值

  3. Evaluator 不是固定选择

    • 取决于任务是否超出模型独立完成能力
    • 边界会随着模型进步向外移动

简化 Harness 的结果（Opus 4.6）

Harness时长成本
Full Harness（Opus 4.5）6 小时$200
简化 Harness（Opus 4.6）4 小时$124

DAW 实验：在浏览器中构建数字音频工作站

Prompt：

Build a fully featured DAW in the browser using the Web Audio API.

运行明细

Agent & Phase时长成本
Planner4.7 min$0.46
Build (Round 1)2 hr 7 min$71.08
QA (Round 1)8.8 min$3.24
Build (Round 2)1 hr 2 min$36.89
QA (Round 2)6.8 min$3.09
Build (Round 3)10.9 min$5.88
QA (Round 3)9.6 min$4.06
Total3 hr 50 min$124.70

QA 发现的差距

Round 1 反馈：

这是一个强大的应用，有出色的设计保真度、坚实的 AI agent 和良好的后端。主要失败点是 Feature Completeness —— 虽然应用看起来令人印象深刻，AI 集成工作良好，但几个核心 DAW 功能只是展示性的，缺乏交互深度：

  • clips 不能在时间线上拖动/移动
  • 没有乐器 UI 面板（合成器旋钮、鼓垫）
  • 没有可视效果编辑器（EQ 曲线、压缩器仪表）

Round 2 反馈：

剩余差距：

  • 音频录制仍然是 stub-only（按钮切换但没有麦克风捕获）
  • 通过边缘拖动的 clip 调整大小和 clip 分割未实现
  • 效果可视化是数字滑块，不是图形化的（没有 EQ 曲线）

最终结果

  • 工作的 arrangement view、mixer 和 transport
  • 可以完全通过 prompt 制作简短的歌曲片段：
    • Agent 设置节奏和调性
    • 放下旋律
    • 构建鼓轨
    • 调整 mixer 电平
    • 添加混响

不是音高完美的，但正在接近。

核心洞见与未来方向

Harness Engineering 的本质

Harness 组件 = 编码"模型无法独自完成什么"的假设

随着模型进步：

  1. 某些假设会过时 → 简化 harness，去掉不再 load-bearing 的组件
  2. 新的可能性出现 → 添加新组件，实现以前不可能的能力

评估器的位置

Evaluator 的价值取决于任务相对于模型能力边界的位置：

任务难度 ──────────────────────────────→
         │                      │
         │  模型独立完成区        │  需要 evaluator 区
         │  （evaluator 是开销）  │  （evaluator 有价值）
         │                      │

随着模型进步，边界向右移动。

实践建议

  1. 用你构建的模型做实验

    • 阅读它在真实问题上的 traces
    • 调优以达到期望的结果

  2. 复杂任务：考虑分解和专业化 agent

    • 每个 agent 处理问题的一个方面

  3. 新模型发布时：重新审视 harness

    • 剥离不再 load-bearing 的组件
    • 添加新组件以实现更大的能力

最后的思考

“The space of interesting harness combinations doesn’t shrink as models improve. Instead, it moves, and the interesting work for AI engineers is to keep finding the next novel combination.”

这不是一个收敛的过程——不是”等模型够强就不需要 harness 了”。

这是一个移动的目标：模型越强，能构建的 harness 空间越大，能完成的任务越复杂。

AI 工程师的工作，是持续找到下一个 novel combination。

附录：Planner 生成的规格示例

RetroForge - 2D Retro Game Maker

Overview

RetroForge is a web-based creative studio for designing and building 2D retro-style video games. It combines the nostalgic charm of classic 8-bit and 16-bit game aesthetics with modern, intuitive editing tools—enabling anyone from hobbyist creators to indie developers to bring their game ideas to life without writing traditional code.

The platform provides four integrated creative modules: a tile-based Level Editor for designing game worlds, a pixel-art Sprite Editor for crafting visual assets, a visual Entity Behavior system for defining game logic, and an instant Playable Test Mode for real-time gameplay testing. By weaving AI assistance throughout (powered by Claude), RetroForge accelerates the creative process—helping users generate sprites, design levels, and configure behaviors through natural language interaction.

Features（16 个功能，10 个 sprint）：

  1. Project Dashboard & Management
  2. Sprite Editor
  3. Tileset Manager
  4. Level Editor
  5. Entity Behavior System
  6. Playable Test Mode
  7. AI Sprite Generator
  8. AI Level Designer
  9. Sound Effects & Music
  10. Game Export & Sharing …（详细 user stories 和数据模型）

参考资料

📝 文章反馈