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

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

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

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

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

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

传统单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透视渲染棋盘地板、自由位置悬挂艺术品、通过门口导航替代滚动/点击

这种创造性飞跃在单次生成中前所未见。

三、全栈开发：三智能体架构

架构设计

scss 复制代码

┌─────────────────────────────────────────────────┐
│                   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写入文件，另一个读取并响应。这确保工作忠实于规格，不过早过度指定实现细节。

四、实战对比： <math xmlns="http://www.w3.org/1998/Math/MathML"> 9 v s 9 vs </math>9vs200的巨大差异

测试任务

"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的致命缺陷

布局浪费空间：固定高度面板留下大量空白视口
工作流僵化：没有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迭代：简化而不降级

核心原则

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

方法论：渐进式简化

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

关键决策：移除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可以自主驱动它们，使用工具从头到尾创建简单的制作。

六、关键洞察与未来方向

核心发现

实验至关重要：
- 针对构建的模型进行实验
- 在真实问题上阅读其轨迹
- 调优性能以实现期望结果
任务分解仍有价值：
- 在复杂任务中，将任务分解并应用专门Agent仍有提升空间
持续简化：
- 新模型发布时重新审视Harness
- 移除不再影响性能的部分
- 添加新部分以实现以前不可能的能力
评估器是动态决策：
- 评估器不是固定的是/否决策
- 只有当任务超出当前模型可靠能力时才值得投入成本
- 随着模型能力提升，边界外移

认知的演变

"我的信念是，随着模型改进，有趣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间通信机制

文件传递模式：

python 复制代码

# 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小时。

九、挑战与局限性

当前限制

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

评估器的局限

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

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

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

工作流和产品直觉的差距

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

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

十、最佳实践指南

Harness设计原则

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

适用场景判断

使用单Agent：

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

使用多Agent Harness：

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

混合方案：

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

调优循环

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