Harness Engineering：Anthropic实现让 AI 6小时无人干预生成完整项目

6小时生成价值$200的代码，比单Agent提升20倍质量的秘诀

在AI辅助编码领域，面临两个根本性挑战：

1. 前端设计的主观性问题：Claude倾向于生成安全但平庸的界面，缺乏创意和个性
2. 长周期任务的连贯性问题：随着上下文窗口填充，模型会失去连贯性；部分模型甚至出现"上下文焦虑"现象——提前结束任务

Anthropic的工程师Prithvi Rajasekaran通过借鉴 生成对抗网络(GAN) 的思想，设计了Generator-Evaluator多智能体架构，成功解决了这些问题。

---

一、核心思想：从单Agent到多智能体协作

传统单Agent的致命缺陷

当被要求评估自己的工作时，Agent往往会产生"过度自信"问题：

• 即使质量明显平庸，Agent也会自信地赞扬自己的工作
• 这在主观任务（如设计）中尤为突出，因为没有二元的可验证测试
• 即使在客观任务中，Agent的判断力也经常阻碍其完成任务

解决之道：生成-评估分离

将"工作执行的Agent"与"工作评估的Agent"分离，虽然不能立即消除LLM对LLM输出的宽容倾向，但调优一个独立的评估者使其保持怀疑态度，比让生成者自我批评要容易得多。一旦外部反馈存在，生成者就有了具体的迭代目标。

---

二、前端设计：让主观质量可量化

四大评估标准

Anthropic为前端设计制定了四个可量化的评估标准：

评估维度	核心问题	关键指标
设计质量	设计是否是一个连贯的整体？	色彩、排版、布局、图像等细节创造独特的情绪和身份
原创性	是否有定制的决策？	拒绝模板化、库默认值、AI生成模式（如紫色渐变+白色卡片）
工艺	技术执行是否到位？	排版层级、间距一致性、色彩和谐、对比度
功能性	用户能否独立使用界面？	是否能理解界面功能、找到主要操作、完成任务

关键策略：

• 加权设计质量和原创性（Claude在工艺和功能上天生就做得不错）
• 明确惩罚通用的"AI slop"模式
• 通过Few-shot示例校准评估者，确保与人类偏好对齐

实现机制

1. Generator Agent：基于用户提示创建HTML/CSS/JS前端
2. Evaluator Agent：使用Playwright MCP与实时页面交互，导航、截图、研究实现，然后评估每个标准并撰写详细批评
3. 反馈循环：评估结果传回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合同：

1. Generator提出将要构建的内容和成功验证方式
2. Evaluator审查提案，确保Generator构建正确的东西
3. 两者迭代直到达成一致

通信方式：通过文件传递——一个Agent写入文件，另一个读取并响应。这确保工作忠实于规格，不过早过度指定实现细节。

---

四、实战对比：$9 vs$200的巨大差异

测试任务

"Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode."

结果对比

指标	单Agent模式	完整Harness
耗时	20分钟	6小时
成本	$9	$200
功能数量	基础编辑器	16个功能（含AI辅助）
游戏可玩性	❌ 无法移动实体	✅ 可以正常游戏

单Agent的致命缺陷

1. 布局浪费空间：固定高度面板留下大量空白视口
2. 工作流僵化：没有UI引导用户先创建精灵/实体再填充关卡
3. 核心功能崩溃：实体定义与游戏运行时连线断裂，且表面无任何提示

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迭代：简化而不降级

核心原则

"找到尽可能简单的解决方案，只在需要时增加复杂性" —— 来自Anthropic的《构建有效Agent》

方法论：渐进式简化

1. 第一次尝试：彻底削减Harness，尝试创新想法 → 无法复制原版性能
2. 教训：难以区分哪些设计是承重结构
3. 修正方法：每次移除一个组件，审查对最终结果的影响

关键决策：移除Sprint结构

背景：随着Opus 4.6的发布，模型原生能力显著提升

Opus 4.6的改进：

• 规划更谨慎
• 更长时间维持Agent任务
• 在更大代码库中更可靠运行
• 有更好的代码审查和调试技能
• 大幅改善长上下文检索

改动：

• 移除sprint结构（原帮助将工作分解为模型可处理的块）
• 保留Planner和Evaluator（仍然明显有价值）
• Evaluator移至单次通过（而非每次sprint评估）

发现：

• 在Opus 4.5上，评估器对整个构建都捕获了有意义的问题
• 在Opus 4.6上，模型原始能力提升，边界外移
• 评估器不是固定的是/否决策，只有当任务超出当前模型可靠能力时才值得投入成本

实战验证：浏览器DAW（数字音频工作站）

任务："Build a fully featured DAW in the browser using the Web Audio API."

性能指标：

• 总耗时：3小时50分钟
• 总成本：$124.70
• Builder阶段连续运行超过2小时（无需Opus 4.5所需的sprint分解）

QA Agent仍能捕捉到的关键缺陷

Round 1反馈：

"虽然应用看起来令人印象深刻，AI集成工作良好，但几个核心DAW功能仅显示无交互深度：片段无法在时间线上拖拽/移动，没有乐器UI面板（合成器旋钮、鼓垫），没有视觉效果编辑器（EQ曲线、压缩计）。这些不是边缘情况——它们是让DAW可用的核心交互，规格明确要求这些。"

Round 2反馈：

• 音频录制仍仅为存根（按钮切换但无麦克风捕获）
• 未实现边缘拖拽的片段调整大小和片段分割
• 效果可视化是数字滑块，而非图形化（无EQ曲线）

最终成果

应用远非专业的音乐制作程序，AI的歌曲作曲技能显然还有很多改进空间。此外，Claude实际上无法听到声音，这使得QA反馈循环在音乐品味方面效果较差。

但是，最终应用拥有功能性音乐制作程序的所有核心部分：

• 工作中的编曲视图
• 混音器
• 传输控制

可以完全通过提示来组合简短的歌曲片段：Agent设置速度和键位，铺设旋律，构建鼓轨，调整混音器电平，添加混响。歌曲创作的核心原语存在，Agent可以自主驱动它们，使用工具从头到尾创建简单的制作。

---

六、关键洞察与未来方向

核心发现

1. 实验至关重要：

   • 针对构建的模型进行实验
   • 在真实问题上阅读其轨迹
   • 调优性能以实现期望结果

2. 任务分解仍有价值：

   • 在复杂任务中，将任务分解并应用专门Agent仍有提升空间

3. 持续简化：

   • 新模型发布时重新审视Harness
   • 移除不再影响性能的部分
   • 添加新部分以实现以前不可能的能力

4. 评估器是动态决策：

   • 评估器不是固定的是/否决策
   • 只有当任务超出当前模型可靠能力时才值得投入成本
   • 随着模型能力提升，边界外移

认知的演变

"我的信念是，随着模型改进，有趣Harness组合的空间不会缩小。相反，它在移动，AI工程师的有趣工作是继续找到下一个新颖组合。"

实践建议

何时需要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("splan_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小时。

---

九、挑战与局限性

当前限制

1. 成本高昂：完整Harness运行成本是单Agent的20倍
2. 时间长：复杂任务可能需要数小时
3. 模型依赖：Harness设计随模型能力变化而需调整
4. QA能力上限：即使调优后，仍有边界Bug可能漏掉

评估器的局限

即使在调优后，Harness输出仍显示模型QA能力的限制：

• 小布局问题
• 某些地方感觉不直观的交互
• 更深层嵌套功能中未发现的Bug（评估器未彻底测试）

显然有更多验证空间可以通过进一步调优来捕获。

工作流和产品直觉的差距

Harness设计中仍然存在一些问题：

• 工作流没有明确说明在尝试填充关卡之前应该构建精灵和实体
• 用户必须通过探索自己弄清楚
• 这读作基础模型产品直觉的差距，而不是Harness设计解决的问题

---

十、最佳实践指南

Harness设计原则

1. 从简单开始：找到最简单的解决方案，只在需要时增加复杂性
2. 实验驱动：针对构建的模型进行实验，阅读轨迹，调优性能
3. 渐进式简化：新模型发布时，重新审视哪些组件不再需要
4. 功能分离：将执行和评估分离，获得更好的质量控制
5. 明确标准：将主观判断转化为可量化的标准

适用场景判断

使用单Agent：

• 简单、线性任务
• 快速原型验证
• 成本敏感场景
• 质量要求不高

使用多Agent Harness：

• 复杂、非线性任务
• 需要高可维护性和可扩展性
• 质量要求严格
• 有足够的时间和预算

混合方案：

• Planner + 单次Evaluator
• 只在关键节点用Evaluator
• 根据任务复杂度动态调整

调优循环

1. 观察日志：阅读Agent的执行轨迹
2. 识别模式：找到判断分歧的地方
3. 更新提示词：解决发现的问题
4. 验证效果：在真实任务上测试
5. 重复循环：持续改进