长时间运行应用开发的 Harness 设计
官方原文: https://www.anthropic.com/engineering/harness-design-long-running-apps
发布日期： 2026年3月24日
作者： Prithvi Rajasekaran，Anthropic Labs 团队成员
Harness 设计是决定前沿 Agent 编程表现的关键。本文介绍 Anthropic 如何借此进一步提升 Claude 在前端设计与长时自主软件工程中的能力。
背景
数月间，作者研究了两个互相关联的问题：如何生成高质量前端设计，以及如何在没有人工干预时构建完整应用。这项工作建立在早期的前端设计 Skill 和长时运行 coding agent Harness 之上。Prompt Engineering 与 Harness 设计曾显著提升 Claude 的表现，但两条路径最终都遇到能力上限。
为了突破，作者寻求了跨两个不同领域的新型 AI 工程方法：一个由主观品味定义，另一个由可验证的正确性和可用性定义。从生成对抗网络（GAN）中汲取灵感，设计了一个包含生成器和评估器 Agent 的多 Agent 结构。构建可靠的评估器意味着开发可以将主观判断转化为具体、可评分条件的标准。
这些方法随后被应用到长时自主编码，带来两项经验：将构建工作拆解为可处理的单元，以及用结构化工件在不同 Session 之间交接上下文。最终形成了由规划 Agent、生成 Agent 和评估 Agent 构成的三 Agent 架构，能够在持续数小时的自主编码 Session 中产出功能丰富的全栈应用。
为什么简单实现难以胜任
此前的工作表明，Harness 设计会显著影响长时 Agent 编程的有效性。早期实验中，初始化 Agent 将产品规格拆为任务清单，coding agent 逐项实现功能，并在 Session 间交接工件。开发者社区也得出过类似结论，例如“Ralph Wiggum”方法用 hooks 或脚本驱动持续迭代循环。
但对于复杂任务，持续存在的问题仍然存在。观察到两种常见的失败模式：
连贯性下降： 长任务中，随着 Context Window 被填满，模型往往会逐渐失去连贯性。一些模型还会出现“context anxiety”，即在自认为接近上下文上限时过早结束工作。context reset 会彻底清空 Context Window，再以结构化交接启动新的 Agent，能够同时应对这两类问题。它不同于 compaction：后者是在原地总结早期对话，虽保留连续性，却无法提供真正的全新上下文。早期测试发现，Claude Sonnet 4.5 的 context anxiety 很明显，仅靠 compaction 不够，因此 context reset 不可或缺；代价则是更复杂的编排、更高的 Token 开销和延迟。
自评能力不足： Agent 被要求评估自己的工作时，即使质量明显一般，也容易自信地给出正面评价。设计等主观任务尤为如此，因为它没有可验证软件测试那样的二元检查。将执行工作的 Agent 与负责评判的 Agent 分离，是一个有效杠杆。分离本身不会立刻消除宽松倾向，但将独立评估器调得更审慎，远比要求生成器严厉批评自身成果更可行。有了外部反馈，生成器才有明确依据迭代。
前端设计：使主观质量可评分
作者从前端设计开始实验，那里自我评估问题最为明显。没有干预时，Claude 倾向于安全、可预测的布局，技术上功能齐全但视觉上平淡无奇。
两个洞察塑造了 Harness：
美学虽无法完全归约为分数，却可通过承载设计原则与偏好的评分标准加以改善。与其问“这个设计漂亮吗？”，不如问“它是否符合我们对优秀设计的原则？”后者提供了可具体判断的依据。
通过将前端生成与前端评分分离，反馈循环可以驱动生成器产生更强的输出。
四个评分标准
生成器和评估器 Agent 在它们的提示中都收到了四个评分标准：
- 设计质量： 设计是否感觉像一个连贯的整体而不是部分的集合？颜色、排版、布局、图像和其他细节应该组合在一起创造独特的氛围和身份。
- 原创性： 是否能看出经过自主取舍的设计决策，还是只是模板布局、组件库默认值与常见 AI 生成套路？人类设计师应能识别出有意识的创意选择。未改造的现成组件，或“白色卡片配紫色渐变”这类典型 AI 套路，都会在这一项失分。
- 工艺： 技术执行质量，包括排版层级、间距一致性、色彩和谐与对比度。它考察的是基本功而非创意；合理实现通常能做好，失分则意味着基本规范出了问题。
- 功能性： 独立于美学的可用性。用户能否理解界面、找到主要操作并完成任务而无需猜测？
设计质量和原创性的权重高于工艺与功能性，因为 Claude 默认已能较好满足后两项。标准会明确扣减高度模板化的 AI 产出模式，推动模型在美学上做更多有意识的探索。
评估器使用带有详细分数分解的少样本示例进行校准，确保判断对齐并减少跨迭代的分数漂移。
反馈循环
该循环基于 Claude Agent SDK 构建。生成 Agent 根据用户 prompt 创建 HTML/CSS/JS 前端；评估 Agent 获得 Playwright MCP，可在对各项标准打分、撰写详细意见前直接操作实时页面。实际运行中，评估 Agent 会自行浏览页面、截图并仔细检查实现，再给出评估。
一次生成会运行 5 到 15 轮迭代，每轮通常都会把生成器推向更鲜明的方向。评估 Agent 需要主动浏览页面而非只对静态截图打分，因此每个循环都消耗实际 wall-clock time，完整运行最长可达 4 小时。生成 Agent 会在每次评估后作出策略选择：评分趋势向好就深化当前方向；若路径不奏效，就转向截然不同的审美方向。
结果
评估器的评估在迭代中提高后趋于平稳，仍有提升空间。一些生成进行增量改进；另一些在迭代之间进行了尖锐的美学转向。
标准的措辞以意想不到的方式引导了生成器。包含"最好的设计是博物馆品质"这样的短语将设计推向了特定的视觉收敛，表明提示语言直接塑造了输出特征。
虽然分数普遍提高，但模式并不总是干净地线性。后期实现作为整体趋于更好，但作者经常看到中间迭代比最后一个更受青睐的情况。实现复杂度往往在各轮之间增加。即使在第一次迭代中，输出也明显优于没有提示的基线，表明标准本身在任何评估器反馈之前就将模型从通用默认值中引导出来了。
一个典型案例中，面对荷兰艺术博物馆网站的 prompt，模型到第 9 轮已经产出简洁的深色 landing page；第 10 轮却完全舍弃该方案，将网站重新构思为空间化体验：用 CSS perspective 渲染带棋盘地面的 3D 房间，艺术品以自由位置悬挂墙面，访客通过门洞在展厅间移动，而不再依赖滚动或点击导航。
扩展到全栈编码
受 GAN 启发的模式被应用于全栈开发。生成器-评估器循环自然映射到软件开发生命周期，其中代码审查和 QA 与设计评估器扮演相同的结构角色。
架构
在原始 Harness 的基础上，创建了一个三 Agent 系统：
规划 Agent： 旧 Harness 要求用户预先提供详细规格。新的规划 Agent 接收仅 1 至 4 句话的 prompt，并将其扩展为完整产品规格。它需要在范围上保持进取，但重点放在产品上下文和高层技术设计，而非实现级细节。原因是：若规划阶段写死了细粒度技术细节且判断错误，问题会逐层传导到后续实现。规划 Agent 还需寻找将 AI 功能自然纳入产品规格的机会。
生成 Agent： 延续旧 Harness 的“一次一个功能”方法，生成 Agent 按 sprint 工作，每次从规格中领取一个功能。每个 sprint 使用 React、Vite、FastAPI 和 SQLite（后改为 PostgreSQL）实现应用。生成 Agent 在每个 sprint 结束时先自评，再交给 QA，并通过 Git 进行版本控制。
评估 Agent： 旧 Harness 产出的应用往往看起来不错，却仍存在真实 bug。评估 Agent 通过 Playwright MCP 以用户方式操作运行中的应用，验证 UI 功能、API endpoint 与数据库状态。它依据发现的 bug，以及从前端实验迁移而来的产品深度、功能、视觉设计和代码质量标准，对每个 sprint 评分。每项标准均设硬阈值，任意一项不达标，该 sprint 即判定失败，生成 Agent 将收到详细反馈。
每个 sprint 开始前，生成 Agent 和评估 Agent 会协商一份 sprint contract，即在编码前先对“完成”的标准达成一致。产品规格刻意保持高层，这份约定便弥合了用户故事与可测试实现之间的落差。生成 Agent 提出本轮要构建的内容和验收方式，评估 Agent 审查提案，双方迭代至一致。
各 Agent 通过文件通信：一个写入，另一个读取并回复。这种方式让工作持续贴合规格，又避免过早将实现细节规定得过死。
所用模型为 Claude Opus 4.5。由于 Opus 4.5 已在很大程度上消除 context anxiety，该 Harness 不再使用 context reset。Agent 在整个构建过程中保持一个连续 Session，由 Claude Agent SDK 的自动 compaction 处理上下文增长。
运行 Harness
使用了以下提示：
"创建一个2D复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为和可玩测试模式。"
结果比较：
| Harness | 时长 | 成本 |
|---|---|---|
| 单独运行 | 20分钟 | $9 |
| 完整 Harness | 6小时 | $200 |
Harness 贵了20多倍，但输出质量的差异是显而易见的。
单 Agent 运行的问题： 布局浪费空间，固定高度面板让大部分视口闲置；工作流僵化，未引导用户按合理顺序操作。更关键的是游戏本身无法运行：实体虽显示在画面上，却不响应任何输入，实体定义与游戏运行时之间的连接出了问题。
Harness 运行的结果： 规划 Agent 将一句 prompt 扩展为覆盖 10 个 sprint、16 项功能的产品规格。除核心编辑器与 play mode 外，规格还包括精灵动画、行为模板、音效与音乐、AI 辅助的精灵生成和关卡设计，以及可生成分享链接的游戏导出。规划 Agent 获得前端设计 Skill，并用它为应用定义了视觉设计语言。
应用立即显示出更多的打磨。画布使用了完整的视口，面板大小合理，界面具有一致的视觉身份。精灵编辑器更丰富，工具面板更整洁，颜色选择器更好用，缩放控件更实用。因为规划器被要求将 AI 功能编织到规格中，应用包含了内置的 Claude 集成，通过提示生成游戏部件。
最大的差异在播放模式——用户实际上可以移动实体并玩游戏。物理效果有些粗糙（角色与平台重叠），但核心工作了，这是单独运行没有达到的。
评估 Agent 的表现
从日志可见，评估 Agent 持续让实现对齐规格。每个 sprint，它都会逐项执行 sprint contract 中的验收标准，通过 Playwright 操作运行中的应用，并为所有偏离预期行为的问题提交 bug。验收约定的粒度很细，仅 Sprint 3 的关卡编辑器就有 27 项标准。
评估器发现的示例包括：矩形填充工具只在拖动开始/结束点放置图块而不是填充区域；删除键处理器需要 selection 和 selectedEntityId 但点击只设置了一个；FastAPI 路由排序问题，其中"reorder"被匹配为整数 frame_id。
让评估 Agent 达到这一水平需要投入。未经调优时，Claude 并不是可靠的 QA Agent：早期运行中，它会发现真实问题，却又说服自己问题并不严重，最终仍放行实现；测试也流于表面。调优过程包括阅读评估日志、找出其判断与作者不一致的样本，并修改 QA prompt 解决这些问题。经历数轮迭代后，评估 Agent 才开始给出合理评分。
迭代 Harness
第一组结果令人鼓舞，但系统笨重、缓慢且昂贵。下一步自然是在不降低效果的前提下简化。Harness 中的每个组件都隐含着“模型无法独自完成什么”的假设，这些假设都值得逐一验证。
作者第一次激进简化时未能复现原有表现，也难以区分哪些组件真正不可替代。随后改用更系统的方法：每次移除一个组件，逐项观察影响。
Opus 4.6 提供了进一步减少复杂性的动力。从发布博客中：该模型"计划更仔细，维持 Agent 任务更久，能在更大的代码库中更可靠地运行，并且有更好的代码审查和调试技能。"
移除 sprint 结构
sprint 结构被完全移除。考虑到 Opus 4.6 的改进，模型可能已能不依赖这种拆解来完成工作。规划 Agent 与评估 Agent 仍被保留，因为两者继续带来明显价值：没有规划 Agent，生成 Agent 容易缩小范围，产出的应用功能更少。
sprint 移除后，评估 Agent 在运行结束时统一执行一次检查。在 Opus 4.5 上，构建任务接近生成 Agent 单独可靠完成的边界，评估 Agent 能发现有意义的问题；在 Opus 4.6 上，这条边界向外扩展，先前需要评估 Agent 检查的任务如今常能由生成 Agent 独立完成。但对仍处在能力边界的部分，评估 Agent 仍有显著增益。
实际含义是：只有当任务超出当前模型单独可靠完成的范围时，评估 Agent 才值得其成本。
团队还补充 prompt，以改进 Harness 为各个应用构建 AI 功能的方式，尤其要求生成 Agent 构建能通过工具驱动应用功能的合适 Agent。
更新 Harness 的结果
使用以下提示生成数字音频工作站：
"使用 Web Audio API 在浏览器中构建一个功能齐全的 DAW。"
运行耗时约4小时，Token 成本$124。
分解：
| Agent 和阶段 | 时长 | 成本 |
|---|---|---|
| 规划器 | 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 |
| V2 Harness 总计 | 3小时50分钟 | $124.70 |
生成 Agent 在未采用 Opus 4.5 所需 sprint 拆解的情况下，仍能连贯运行两个多小时。
QA Agent 仍发现了真实缺口。第一轮反馈指出：应用看起来很出色，但几个核心 DAW 功能“只能展示，缺乏可交互的深度”，例如片段无法拖动、没有乐器 UI 面板、没有可视化效果编辑器。第二轮又发现音频录制仅是 stub、缺少片段缩放与拆分，以及效果仅以数字显示等问题。
最终应用具备可用音乐制作程序的核心模块：浏览器中的 arrangement view、mixer 和 transport controls。用户能完全通过 prompt 制作一段简短音乐：Agent 设置速度与调性、编写旋律、搭建鼓轨、调整混音电平并添加混响。歌曲创作所需的核心能力都已具备，Agent 能自主操作这些能力。
下一步
随着模型的持续改进，它们将能够在更复杂的任务上工作更长时间。在某些情况下，脚手架随时间推移变得不那么重要，开发者可以等待下一个模型。另一方面，更好的模型为超越基线能力实现复杂任务的 Harness 创造了更多空间。
这项工作的关键经验：
- 始终围绕实际使用的模型做实验，在真实问题上阅读其执行记录，并据此调优
- 对复杂任务，可尝试拆解任务，并为各部分配置专门 Agent 以获得增益
- 新模型发布后，应重新审视 Harness：移除不再必要的组件，再添加可带来新能力的组件
作者的核心判断是：模型进步不会缩小有价值的 Harness 组合空间，而是会让这个空间发生迁移。
附录
文章包含了规划器 Agent 为"RetroForge - 2D 复古游戏制作器"生成的示例计划，这是一个基于 Web 的创意工作室，用于设计2D复古风格的视频游戏。计划描述了四个集成的创意模块（基于图块的关卡编辑器、像素艺术精灵编辑器、视觉实体行为系统和即时可玩测试模式），AI 辅助功能由 Claude 贯穿其中。该示例展示了项目仪表板和管理功能，包含详细用户故事，涵盖创建、查看、打开、删除和复制项目，以及指定元数据、画布设置、图块大小配置、调色板选择和关联资产的项目数据模型。