多 Agent Harness
GAN 启发的三 Agent 架构 — 规划器、生成器和评估器协同工作，在数小时的自主会话中构建完整应用
超越双 Agent
初始化器/编码器 Harness 解决了多会话问题，但性能遇到瓶颈。两个相互关联的挑战仍然存在：
- 前端设计质量 — 模型产出功能正常但千篇一律的设计。主观质量判断（“这个设计好吗？“）难以简单验证。
- 自我评估偏差 — 被要求评估自己工作的 Agent 会自信地赞美平庸的输出。这在不存在二元测试的主观任务中尤为明显。
突破口：从 GAN（生成对抗网络） 中汲取灵感 — 将做工作的 Agent 和评判工作的 Agent 分离。
三 Agent 架构
规划 Agent (Planner)
将简单的 1-4 句用户提示扩展为完整的产品规格：
- 关注产品上下文和高层技术设计，而非细粒度的实现细节
- 强调范围雄心，同时避免过度具体的前期决策导致的级联错误
- 识别将 AI 功能融入产品规格的机会
规划器故意避免微观管理实现。过度指定的计划造成脆弱性 — 如果一个细节有误，下游工作继承该错误。规划器只设定方向，让生成器做战术决策。
生成 Agent (Generator)
逐个功能实现应用，应用来自长时运行 Harness 模式的逐个功能方法：
- 以集中的构建轮次工作，在 QA 交接前自我评估
- 使用 git 进行版本控制和回滚
- 连贯运行数小时 — Claude Opus 4.6 消除了迭代分解的需要
评估 Agent (QA)
使用浏览器自动化（Playwright MCP）像真实用户一样与运行中的应用交互：
- 测试 UI 功能、API 端点和数据库状态
- 根据硬阈值对每个标准进行评分
- 为生成器提供详细、可操作的反馈
- 可以让构建轮次失败，迫使生成器在继续之前修复问题
评估器是关键创新。通过将生成与评估分离，Harness 避免了自我评估陷阱：调整独立评估器使其持怀疑态度，比让生成器自我批判要容易得多。
让主观质量可衡量
对于前端设计，评估器使用四个明确的标准：
| 标准 | 权重 | 衡量内容 |
|---|---|---|
| 设计质量 | 高 | 设计是否作为整体协调一致？色彩、排版、布局组合成独特的视觉识别 |
| 原创性 | 高 | 是否有自定义决策的证据，而非模板默认值和”AI 流水线”模式 |
| 工艺 | 普通 | 技术执行 — 间距一致性、色彩和谐、对比度比率 |
| 功能性 | 普通 | 可用性 — 用户能否理解界面并完成任务？ |
设计质量和原创性权重更高，因为模型在工艺和功能性方面天然表现良好。权重推动模型冒审美风险，远离千篇一律的紫色渐变白色卡片模式。
Sprint 合约协议
在每个构建轮次之前，生成器和评估器协商一个 Sprint 合约：
- 生成器提议将构建什么以及如何验证完成
- 评估器审查提议 — 是否在构建正确的东西？
- 双方迭代直到就”完成”的定义达成一致
这弥合了用户故事和可测试实现之间的差距。没有它，评估器可能会根据生成器在该轮次中从未打算解决的标准来评判。
使用 Claude Opus 4.6 后，Sprint 分解被完全移除。模型能在长会话中原生处理任务连贯性。评估器的价值变为依赖于任务，而非普遍需要。
迭代动态
生成器–评估器循环每个构建轮次运行 5-15 次迭代。关键观察：
- 评估器的评价在迭代中改善，然后趋于平稳
- 提示词措辞以意想不到的方式引导输出 — “museum quality” 这样的短语推向视觉趋同而非多样性
- 改善不是线性的 — 有时中间迭代优于最终迭代
- 实现复杂度在轮次中递增，因为生成器尝试更有雄心的方案
- 第一次迭代就已超越基线 — 标准语言本身就将模型引离通用默认值，甚至在评估器反馈之前
实际结果
复古电子游戏制作器
提示: “创建一个 2D 复古游戏制作器，包含关卡编辑器、精灵编辑器、实体行为和可玩测试模式。“
| 指标 | 单独 Agent | 完整 Harness |
|---|---|---|
| 耗时 | 20 分钟 | 6 小时 |
| 成本 | $9 | $200 |
| 功能 | 1 个规格功能 | 16 个功能，10 个 Sprint |
| 核心缺陷 | 实体输入损坏，游戏运行时连接失败 | 核心玩法可用，实体响应输入 |
| 设计 | 空间浪费，布局僵硬 | 全视口，一致的视觉识别 |
| AI | 无 | AI 辅助精灵生成 |
数字音频工作站（简化 Harness）
在为 Opus 4.6 移除 Sprint 分解后：
提示: “使用 Web Audio API 在浏览器中构建一个全功能 DAW。“
| 阶段 | 耗时 | 成本 |
|---|---|---|
| 规划器 | 4.7 分钟 | $0.46 |
| 构建轮次 1 | 2 小时 7 分钟 | $71.08 |
| QA 轮次 1 | 8.8 分钟 | $3.24 |
| 构建轮次 2 | 1 小时 2 分钟 | $36.89 |
| QA 轮次 2 | 6.8 分钟 | $3.09 |
| 构建轮次 3 | 10.9 分钟 | $5.88 |
| QA 轮次 3 | 9.6 分钟 | $4.06 |
| 总计 | 3 小时 50 分钟 | $124.70 |
生成器在没有 Sprint 分解的情况下连贯运行了超过两个小时。最终应用包含可用的编排视图、混音器、传输控制，以及一个能自主作曲的 AI Agent。
QA Agent 的挑战
构建有效的评估器需要自身的迭代：
- 初始 QA Agent 判断力差 — 识别了合理的问题但将其合理化，测试浮于表面而非深入边界情况
- 调优循环: 阅读评估器日志 → 识别与人类标准的判断偏差 → 更新 QA 提示词
- 剩余差距: 布局问题、不直观的交互、深层嵌套功能中的缺陷
评估器不是已解决的问题 — 它是一个持续调优的组件。但即使不完美的评估也大幅优于自我评估。
Harness 简化原则
对 Harness 工程师最重要的启示：
“每个 Harness 组件都编码了对模型能力的假设。这些假设值得压力测试 — 它们可能是错误的，并且会随着模型的改进而迅速过时。”
当 Claude Opus 4.6 带着改进的长期规划和调试能力到来时，Sprint 结构被移除了。结果：更简单的 Harness，同等或更好的输出。
工作流程：始终在目标模型上实验 → 在真实问题上阅读执行轨迹 → 调优性能 → 当新模型到来时，重新审视 Harness 并剥离不再承重的组件。
更好的模型需要更少的脚手架。但它们也为实现先前不可能的能力的更雄心勃勃的 Harness 创造了空间。Harness 工程的工作是找到正确的平衡 — 既不过度约束能力强的模型，也不对能力有限的模型支持不足。
来源
Harness Design for Long-Running Application Development — Prithvi Rajasekaran, Anthropic, 2026.03.