ZhenYu's 知识库

外观

[转载] 长时间运行应用开发的 Harness 设计

约 2781 字大约 9 分钟

AIClaude CodeAgentHarness

2026-03-30

原文链接：Harness Design for Long-Running Application Development 作者：Prithvi Rajasekaran, Anthropic Labs 发布时间：2026 年 3 月 24 日

这篇文章探讨了如何借鉴 GAN（生成对抗网络）的思想，设计多 Agent 架构来提升 Claude 在复杂任务上的表现——特别是前端设计和全栈应用开发。作者开发了一套"生成器 + 评估器"模式，突破了单 Agent 的性能天花板。

为什么朴素的实现方式行不通

此前的实验已经能成功地将产品规格拆解为任务列表，按顺序逐个实现功能，并在会话之间进行上下文交接。但两个顽固的失败模式始终存在：

上下文管理难题

模型在长任务中会逐渐丧失连贯性。随着上下文窗口被填满，Claude Sonnet 4.5 表现出了一种"上下文焦虑"现象——当模型感知到自己接近上下文限制时，会过早地开始收尾工作。

上下文重置（清空窗口、通过结构化交接重新开始）比单纯的压缩更有效，但引入了额外的编排复杂度和延迟。

自我评估偏差

当要求 Agent 评估自己产出的工作时，它们倾向于自信地称赞这些工作——即使对于人类观察者来说，质量明显平庸。

将生成和评估分离开来，比让生成器自我批评更容易实现。外部反馈使得迭代有了具体的改进目标。

前端设计：让主观质量可评分

实验发现 Claude 天然倾向于生成技术上功能完备、但视觉上平淡无奇的布局。两个洞察塑造了 Harness 的设计方向：

  1. 美学可以根据具体设计原则打分，而非纯粹的审美品味
  2. 分离生成与评估可以创造出高产的反馈循环

四个评分维度

维度说明
设计质量 (Design Quality)元素是否融为一个有独特个性的整体，而非拼凑的零件
原创性 (Originality)是否有自主设计决策，而非模板默认值和 AI 生成的套路
工艺 (Craft)排版、间距、配色和谐度、对比度等技术执行力
功能性 (Functionality)任务完成度和界面清晰度（独立于美学之外）

作者有意强调设计质量和原创性，弱化工艺和功能性——因为 Claude 在技术执行方面已经足够出色。

评估器校准

评估器使用 few-shot 示例进行校准，附带详细的评分拆解，以对齐评估标准与具体偏好，防止评分漂移。

基于 Claude Agent SDK 构建，生成器创建 HTML/CSS/JavaScript 前端，评估器使用 Playwright MCP 与实时页面直接交互。循环运行 5-15 次迭代，评估器在打分前截图并检查实现效果。完整运行时间可达四小时。

生成器会策略性地决定是根据评分趋势继续优化当前方向，还是在方法停滞时进行美学转向。

一个惊喜的例子

当提示创建一个荷兰艺术博物馆网站时：

  • 第 9 次迭代：产出了一个简洁的暗色主题着陆页
  • 第 10 次迭代：生成器完全重构了概念——变成了一个 3D 空间体验：CSS 渲染的棋盘格地板、自由排列的艺术品、基于门洞的画廊导航，取代了传统滚动浏览

这种创造性的重新构思展示了出乎意料的生成能力。

扩展到全栈开发

三 Agent 架构

作者将生成器-评估器模式应用到全栈开发中。与之前使用 Sonnet 4.5 并需要上下文重置不同，Opus 4.5 基本消除了上下文焦虑，允许连续会话运行，自动压缩管理上下文增长。

┌─────────────┐     规格文档      ┌─────────────┐     Sprint合约    ┌─────────────┐
│   Planner   │ ──────────────▶  │  Generator  │ ◀──────────────▶ │  Evaluator  │
│   规划器     │                  │   生成器     │    反馈/评分      │   评估器     │
└─────────────┘                  └─────────────┘                  └─────────────┘
  扩展简短提示                      逐功能实现                       Playwright 测试
  识别AI集成机会                    React+Vite+FastAPI              Bug评分+阈值判定
  高级技术设计                      Git版本控制                      Sprint合约协商

规划器 (Planner)：从 1-4 句的简短提示自动扩展为完整的产品规格。优先考虑雄心勃勃的范围和高级技术设计，而非细粒度的实现细节。识别在产品中集成 AI 功能的机会。

生成器 (Generator)：按照基于 Sprint 的分解方式逐个实现功能。技术栈为 React、Vite、FastAPI 和 SQLite（后来改为 PostgreSQL）。生成器在提交 QA 之前会先自我评估，并使用 Git 进行版本控制。

评估器 (Evaluator)：使用 Playwright MCP 像终端用户一样测试运行中的应用，操作 UI 功能、API 端点和数据库状态。根据发现的 Bug 和自适应标准（产品深度、功能性、视觉设计、代码质量）对 Sprint 进行评分。每个标准有硬性阈值，未达标则触发详细反馈。

关键设计：每个 Sprint 开始前，生成器和评估器会协商 Sprint 合约，定义可交付成果和验证标准。Agent 之间通过文件进行通信，保持对规格的忠实性，同时不过度约束实现方式。

V1 运行结果：2D 复古游戏制作器

测试提示："创建一个 2D 复古游戏制作器，包含关卡编辑器、精灵编辑器、实体行为和可玩测试模式。"

指标单 Agent完整 Harness
运行时间20 分钟6 小时
花费$9$200
核心功能破损（实体无法交互）可玩（物理有边界情况）
功能数量基础16 个功能，10 个 Sprint

单 Agent 的产出有僵硬的工作流、低效的布局，以及破损的实体-游戏运行时集成导致游戏完全无法玩。

完整 Harness 产出了精心设计的界面，规划器从一句话提示扩展出了 16 个功能的规格，涵盖精灵动画、行为模板、音效音乐、AI 辅助生成和可分享的游戏导出。内置的 Claude 集成允许用户通过提示生成游戏元素。最关键的是——游戏是可以玩的。

评估器调优

让评估器达到可靠的表现需要大量工作：

  • 初期问题：Claude 能识别出合理的问题，但会将它们合理化为"可以接受"，或者测试过于浅层导致遗漏边界情况
  • 调优方法：在日志中识别判断偏差，相应更新 QA 提示词
  • 需要多轮开发循环才能使评估达到可接受的校准水平
  • 持续局限：小的布局问题、不直观的交互、深层嵌套功能中未发现的 Bug

尽管如此，与单 Agent 运行中核心功能完全失败相比，改进是巨大的。

迭代改进 Harness

方法论

在初始成功之后，作者追求在保持性能的同时简化。最初激进的删减和创造性修改未能匹配原始性能，承重组件不明确。最终采用逐个移除组件并测量影响的方法论。

Opus 4.6 带来的变化

Opus 4.6 的发布为降低复杂度提供了动力。官方博客指出：

Opus 4.6 规划更周密，Agent 任务持续时间更长，能在更大的代码库中可靠运行，并且代码审查和调试能力更强。

它还大幅提升了长上下文检索能力——这些能力此前需要 Harness 脚手架来支撑。

移除 Sprint 结构

作者完全移除了 Sprint 结构，测试 Opus 4.6 是否能在没有显式分解的情况下原生处理连贯的工作。结果发现：

  • 规划器仍然必需：没有规划，生成器会缩小工作范围
  • 评估器视情况而定：在 Opus 4.5 上，评估器在各次构建中都能捕获有意义的问题；在 4.6 上，改进的原生能力将边界向外推移——此前需要评估的任务现在落入了可靠的单 Agent 性能区间
  • 关键洞察：评估器的包含与否应取决于任务复杂度相对于当前模型能力的关系，而非固定的架构决策

V2 运行结果：浏览器 DAW（数字音频工作站）

测试提示："在浏览器中使用 Web Audio API 构建一个全功能的 DAW。"

运行阶段详细分解：

阶段耗时花费
Planner4.7 分钟$0.46
Build Round 12 小时 7 分钟$71.08
QA Round 18.8 分钟$3.24
Build Round 21 小时 2 分钟$36.89
QA Round 26.8 分钟$3.09
Build Round 310.9 分钟$5.88
QA Round 39.6 分钟$4.06
总计约 3 小时 50 分钟$124.70

生成器在没有 Sprint 分解的情况下连贯运行了 2 小时以上——这是 Opus 4.5 做不到的。

QA 反馈揭示的关键问题：

  • 第一轮：设计保真度、AI Agent 集成、后端架构表现良好，但核心 DAW 功能缺乏交互深度——音频片段无法在时间线上移动、没有乐器 UI 面板（合成器旋钮、鼓垫）、效果编辑器只显示数字滑块而非图形化可视化
  • 第二轮：音频录制仍为 stub 实现、片段缩放和分割未实现、缺少图形化效果可视化

最终产出：一个功能性的浏览器音乐制作应用，包含工作的编曲视图、混音器和播放控制。集成的 AI Agent 能自主驱动作曲——设置节拍和调号、构建旋律、编排鼓点、调整混音电平、添加混响效果。

核心经验总结

关键原则

找到最简单的可行方案，只在需要时才增加复杂度。

这与 Anthropic 的 Building Effective Agents 一文的核心理念一致。

实践建议

  1. 用目标模型在真实问题上实验，通过 trace 分析调优性能
  2. 复杂任务可能受益于分解，用专门的 Agent 处理特定方面
  3. 新模型发布时重新审视 Harness——移除不再承重的组件，添加能释放新能力的部分
  4. 每个 Harness 组件都编码了对模型局限性的假设——持续压力测试这些假设，因为它们会过时
  5. 评估器的价值取决于任务难度——简单任务上是浪费，能力边界任务上是救星

模型演进与 Harness 复杂度的关系

随着模型改进：

  • 一些 Harness 脚手架变得多余（如 Sprint 分解）
  • 但更大复杂度的机会也随之出现（如 AI 集成功能、更长的连贯运行）
  • Harness 设计空间不是在缩小，而是在迁移——有趣的 AI 工程在于持续发现新的组合方式