在AI辅助编码领域，有两个根本性的挑战一直让人头疼：
- 前端设计的主观性问题——Claude 天生喜欢生成安全但平庸的界面，缺乏创意和个性，跟“设计感”基本不沾边。
- 长周期任务的连贯性问题——随着上下文窗口越塞越满，模型开始“失忆”，部分模型甚至出现“上下文焦虑”现象，提前撂挑子不干了。
Anthropic 的工程师 Prithvi Rajasekaran 借鉴了生成对抗网络（GAN）的思路，设计了一套 Generator-Evaluator 多智能体架构，还真就把这两个问题给拿下了。
一、核心思想：从单Agent到多智能体协作
传统单Agent的致命缺陷
让一个 Agent 自己评估自己？结果往往是“过度自信”——哪怕输出质量平庸到不行，它也会自信满满地给自己鼓掌。这在主观任务（比如设计）里尤其明显，因为没有二元可验证的测试。就算换成客观任务，Agent 的判断力也经常成为完成任务的绊脚石。
解决之道：生成和评估必须分家。
把“干活的 Agent”和“打分的 Agent”拆开，虽然不能立刻消除 LLM 对 LLM 输出的宽容倾向，但调优一个独立的评估者让它保持怀疑态度，比让生成者自己挑自己毛病要容易得多。一旦外部反馈到位，生成者就有了具体可追的迭代目标。
二、前端设计：让主观质量可量化
四大评估标准
Anthropic 为前端设计制定了四个能量化的评估维度：
| 评估维度 | 核心问题 | 关键指标 |
|---|---|---|
| 设计质量 | 设计是否是一个连贯的整体？ | 色彩、排版、布局、图像等细节创造了独特的情绪和身份 |
| 原创性 | 是否有定制的决策？ | 拒绝模板化、库默认值、AI 生成模式（比如紫色渐变+白色卡片） |
| 工艺 | 技术执行是否到位？ | 排版层级、间距一致性、色彩和谐、对比度 |
| 功能性 | 用户能否独立使用界面？ | 是否能理解界面功能、找到主要操作、完成任务 |
关键策略：
- 给“设计质量”和“原创性”加权重（因为 Claude 在工艺和功能上天生就干得不赖）
- 明确惩罚那些通用的“AI slop”模式
- 用 Few-shot 示例校准评估者，确保它和人类的审美偏好对齐
实现机制
- Generator Agent：根据用户提示创建 HTML/CSS/JS 前端
- Evaluator Agent：用 Playwright MCP 跟实时页面交互——导航、截图、仔细研究实现，然后按每个标准打分，并写出详细的批评意见
- 反馈循环：评估结果传回 Generator，作为下一次迭代的输入
每个生成任务跑 5-15 次迭代，评估标准在迭代中不断改进，直到进入平台期。
实际效果：从平庸到惊艳的蜕变
拿一个荷兰艺术博物馆网站的实验来说：
- 前 9 次迭代：生成了一个深色主题的着陆页，符合预期但毫无惊喜
- 第 10 次迭代：彻底推翻原方案，创造了一个 3D 空间体验——用 CSS 透视渲染棋盘地板、自由位置悬挂艺术品、通过门口导航替代滚动/点击
这种创造性的飞跃，在单次生成任务里前所未见。
三、全栈开发：三智能体架构
架构设计
┌─────────────────────────────────────────────────┐
│ Planner Agent │
│ (将1-4句提示扩展为完整产品规格) │
└───────────────┬─────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ Generator Agent │
│ (按sprint实现功能，使用React/Vite/FastAPI/SQLite) │
└───────────────┬─────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────┐
│ Evaluator Agent │
│ (使用Playwright MCP测试UI/API/数据库，评估质量) │
└─────────────────────────────────────────────────┘
三个核心Agent的职责
1. Planner Agent（规划者）
输入：简单提示词（1-4句话）
输出：完整产品规格
核心原则：
- 只聚焦产品上下文和高层技术设计，避免陷入细节技术实现
- 如果规划者预先指定了错误的技术细节，错误会级联到下游实现，后果很严重
- 主动寻找机会在产品规格中融入 AI 特性
2. Generator Agent（生成者）
- 按 sprint 逐个功能实现
- 技术栈：React, Vite, FastAPI, SQLite/PostgreSQL
- 每个 sprint 结束时自我评估工作
- 使用 git 进行版本控制
3. Evaluator Agent（评估者）
- 用 Playwright MCP 像真实用户一样点击应用
- 测试 UI 功能、API 端点、数据库状态
- 对每个 sprint 进行评分（产品深度、功能性、视觉设计、代码质量）
- 每个标准都有硬阈值，低于阈值则 sprint 失败
Sprint Contract（冲刺合同）机制
在每个 sprint 开始前，Generator 和 Evaluator 会谈判达成一份 sprint 合同：
- Generator 提出将要构建的内容和成功验证方式
- Evaluator 审查提案，确保 Generator 构建正确的东西
- 两者迭代直到达成一致
通信方式：通过文件传递——一个 Agent 写入文件，另一个读取并响应。这确保了工作忠实于规格，不会过早过度指定实现细节。
四、实战对比：$9 vs $200 的巨大差异
测试任务
（一个2D游戏关卡编辑器）
结果对比
| 指标 | 单Agent模式 | 完整Harness |
|---|---|---|
| 耗时 | 20分钟 | 6小时 |
| 成本 | $9 | $200 |
| 功能数量 | 基础编辑器 | 16个功能（含AI辅助） |
| 游戏可玩性 | ❌ 无法移动实体 | ✅ 可以正常游戏 |
单Agent的致命缺陷
- 布局浪费空间：固定高度面板留下大量空白视口
- 工作流僵化：没有 UI 引导用户先创建精灵/实体再填充关卡
- 核心功能崩溃：实体定义与游戏时运行连线断裂，而且表面没有任何提示
Harness的显著优势
Planner 把单句提示扩展成了10个 sprint、16个功能的规格：
- 精灵动画系统
- 行为模板
- 音效和音乐
- AI 辅助精灵生成器和关卡设计器
- 游戏导出和可分享链接
应用立刻就展现出了比单 Agent 版本更多的打磨和流畅感：画布用上了完整视口，面板尺寸合理，界面有统一的视觉身份。
Evaluator捕捉到的关键Bug示例
| 合同标准 | Evaluator发现 |
|---|---|
| 矩形填充工具允许拖拽填充 | FAIL - 工具仅在拖拽起点/终点放置瓦片，未填充区域。fillRectangle函数存在但未在mouseUp上正确触发 |
| 用户可以选择和删除已放置的实体生成点 | FAIL - 删除键处理器要求同时设置selection和selectedEntityId，但点击实体只设置selectedEntityId |
| 用户可以通过API重新排序动画帧 | FAIL - PUT /frames/reorder路由定义在/{frame_id}路由之后。FastAPI将'reorder'匹配为frame_id整数并返回422 |
调优Evaluator的挑战：
早期运行中，Claude 是一个糟糕的 QA 袋里——它会识别出合法问题，然后说服自己“这些不是大问题”，批准通过。它还倾向于只做浅层测试，边缘案例很容易溜走。经过几轮开发循环（阅读评估日志，找到判断分歧，更新提示词），评估器才勉强达到了合理的评分水平。
五、Harness迭代：简化而不降级
核心原则
（保持原文信息）
方法论：渐进式简化
- 第一次尝试：彻底削减 Harness，尝试创新想法 → 无法复现原版性能
- 教训：难以区分哪些设计是承重结构
- 修正方法：每次只移除一个组件，审查对最终结果的影响
关键决策：移除Sprint结构
背景： 随着 Opus 4.6 的发布，模型原生能力有了显著提升。
Opus 4.6 的改进：
- 规划更谨慎
- 更长时间维持 Agent 任务
- 在更大代码库中更可靠运行
- 更好的代码审查和调试技能
- 大幅改善长上下文检索
改动：
- 移除 sprint 结构（原来是为了把工作分解成模型可处理的块）
- 保留 Planner 和 Evaluator（仍然明显有价值）
- Evaluator 移至单次通过（而不是每次 sprint 评估）
发现：
- 在 Opus 4.5 上，评估器对整个构建都能捕获有意义的问题
- 在 Opus 4.6 上，模型原始能力提升，边界外移
- 评估器不是固定的“是/否”决策，只有当任务超出当前模型可靠能力时才值得投入成本
实战验证：浏览器DAW（数字音频工作站）
任务：“使用 Web Audio API 在浏览器中构建一个全功能 DAW。”
性能指标：
- 总耗时：3小时50分钟
- 总成本：$124.70
- Builder 阶段连续运行超过 2 小时（无需 Opus 4.5 所需的 sprint 分解）
QA Agent仍能捕捉到的关键缺陷
Round 1 反馈：（原文省略，保留结构）
Round 2 反馈：
- 音频录制仍仅为存根（按钮切换但无麦克风捕获）
- 未实现边缘拖拽的片段调整大小和片段分割
- 效果可视化是数字滑块，而非图形化（无 EQ 曲线）
最终成果
应用远非专业音乐制作程序，AI 的歌曲作曲技能显然还有很大改进空间。而且 Claude 实际上听不到声音，这使得 QA 反馈循环在音乐品味方面效果较差。但最终的应用拥有功能性音乐制作程序的所有核心部分：工作中的编曲视图、混音器、传输控制。可以完全通过提示来组合简短的歌曲片段——Agent 设置速度和键位，铺设旋律，构建鼓轨，调整混音器电平，添加混响。歌曲创作的核心原语都存在，Agent 可以自主驱动它们，用工具从头到尾创建简单的制作。
六、关键洞察与未来方向
核心发现
- 实验至关重要：针对构建的模型做实验，在真实问题上阅读它的轨迹，调优性能以实现期望结果。
- 任务分解仍有价值：在复杂任务中，把任务分解并应用专门 Agent 仍有提升空间。
- 持续简化：新模型发布时重新审视 Harness，移除不再影响性能的部分，添加新部分以实现以前不可能的能力。
- 评估器是动态决策：它不是固定的是/否决策，只有当任务超出当前模型可靠能力时才值得投入成本。随着模型能力提升，边界外移。
认知的演变
（保留原文信息）
实践建议
何时需要 Evaluator？
- 任务超出当前模型可靠能力时
- 评估器成本与任务复杂度匹配
- 边界任务：既不是模型轻松完成，也不是完全超出能力
何时需要 Planner？
- 输入是简单提示词而非详细规格时
- 需要扩展功能范围时
- 需要整合 AI 特性时
何时可以移除 Sprint？
- 模型原生能力足以处理完整任务
- 上下文管理能力显著提升
- 需要减少复杂性和成本时
七、启示录：AI工程的未来
从“教模型”到“设计系统”
这项工作的真正价值在于展示了 AI 工程的范式转变：
- 过去：通过 prompt engineering 教模型做特定任务
- 现在：设计多智能体系统，让模型各司其职，相互制衡
质量vs成本的权衡矩阵
| 场景 | 建议方案 | 成本预估 | 质量期望 |
|---|---|---|---|
| 简单原型/快速验证 | 单Agent | $5-20 | ⭐⭐ |
| 中等复杂度应用 | Planner + 单次Evaluator | $50-100 | ⭐⭐⭐ |
| 生产级应用 | 完整多Agent Harness | $100-300 | ⭐⭐⭐⭐⭐ |
| 关键系统 | Harness + 人工审查 | $300+ | ⭐⭐⭐⭐⭐ |
持续迭代的工程文化
随着模型能力提升，Harness 设计也在进化：不是一次性设计，而是持续优化；不是追求最复杂，而是寻找最简单有效；不是固定架构，而是动态调整。
八、技术实现细节
上下文焦虑 vs 上下文压缩
Context Anxiety（上下文焦虑）：
- 模型在接近感知的上下文限制时开始提前结束工作
- Sonnet 4.5 表现强烈
- 单靠压缩不足以实现强大的长任务性能
- 需要上下文重置：清除整个上下文窗口并开始新的 Agent
Context Compaction（上下文压缩）：
- 总结对话的较早部分，让同一 Agent 在缩短的历史上继续
- 保留连续性但不提供完全重置
- 上下文焦虑可能仍然存在
关键选择：
- 重置提供完全重启，但需要足够状态的传递工件
- 重置增加了编排复杂性、token 开销和延迟
- Opus 4.5 需要重置，Opus 4.6 可以仅用压缩管理上下文增长
Agent间通信机制
文件传递模式：
# Generator写入计划
generator.write("sprint_plan.md", plan_content)
# Evaluator读取并回应
plan = evaluator.read("sprint_plan.md")
evaluator.write("sprint_plan.md", response_content)
# Generator读取回应后执行
final_plan = generator.read("sprint_plan.md")
这种模式确保：
- 工作忠实于规格
- 不过早过度指定实现细节
- Agent 之间有明确的协商记录
Playwright MCP的深度应用
Evaluator 使用 Playwright MCP 进行深度测试：导航实时页面（不是静态截图），截图并仔细研究实现，测试 UI 功能、API 端点、数据库状态，像用户一样点击、填写表单、验证结果。这使每次迭代都需要真实的挂钟时间，完整运行长达 4 小时。
九、挑战与局限性
当前限制
- 成本高昂：完整 Harness 运行成本是单 Agent 的 20 倍
- 时间长：复杂任务可能需要数小时
- 模型依赖：Harness 设计随模型能力变化而需调整
- QA能力上限：即使调优后，仍有边界 Bug 可能漏掉
评估器的局限
即使在调优后，Harness 输出仍显示模型 QA 能力的限制：小布局问题、某些地方感觉不直观的交互、更深层嵌套功能中未发现的 Bug（评估者未彻底测试）。显然还有更多验证空间可以通过进一步调优来捕获。
工作流和产品直觉的差距
Harness 设计中仍然存在一些问题：工作流没有明确说明在尝试填充关卡之前应该构建精灵和实体，用户必须通过探索自己弄清楚。这读作基础模型产品直觉的差距，而不是 Harness 设计本身能解决的问题。
十、最佳实践指南
Harness设计原则
- 从简单开始：找到最简单的解决方案，只在需要时增加复杂性
- 实验驱动：针对构建的模型进行实验，阅读轨迹，调优性能
- 渐进式简化：新模型发布时，重新审视哪些组件不再需要
- 功能分离：将执行和评估分离，获得更好的质量控制
- 明确标准：将主观判断转化为可量化的标准
适用场景判断
使用单Agent：
- 简单、线性任务
- 快速原型验证
- 成本敏感场景
- 质量要求不高
使用多Agent Harness：
- 复杂、非线性任务
- 需要高可维护性和可扩展性
- 质量要求严格
- 有足够的时间和预算
混合方案：
- Planner + 单次Evaluator
- 只在关键节点用Evaluator
- 根据任务复杂度动态调整
调优循环
- 观察日志：阅读 Agent 的执行轨迹
- 识别模式：找到判断分歧的地方
- 更新提示词：解决发现的问题
- 验证效果：在真实任务上测试
- 重复循环：持续改进
