面向长时应用开发的Harness设计

# 长时运行应用开发的 Harness 设计 来源：https://www.anthropic.com/engineering/harness-design-long-running-apps *作者：Prithvi Rajasekaran，我们的 Labs（https://www.anthropic.com/news/introducing-anthropic-labs）团队成员* 过去几个月，我一直在研究两个相互关联的问题：让 Claude 产出高质量的前端设计，以及让它在没有人工干预的情况下构建完整的应用。这项工作源于我们之前在 前端设计技能（https://github.com/anthropics/claude-code/blob/main/plugins/frontend-design/skills/frontend-design/SKILL.md）和 长时运行编码 agent harness（https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents）方面的努力，我和我的同事通过提示工程和 harness 设计显著提升了 Claude 的性能——但两者都遇到了瓶颈。 为了突破瓶颈，我寻找能够在两个截然不同的领域中通用的新型 AI 工程方法：一个由主观审美定义，另一个由可验证的正确性和可用性定义。受 生成对抗网络（https://en.wikipedia.org/wiki/Generative_adversarial_network）（GANs）启发，我设计了一个包含 **生成器（generator）** 和 **评估器（evaluator）** agent 的多 agent 结构。构建一个能够可靠地——并且具备审美品味地——对输出进行评分的评估器，意味着首先要开发一套标准，将"这个设计好吗？"这类主观判断转化为可具体评分的术语。 随后我将这些技术应用于长时自主编码，从早期的 harness 工作中汲取了两个经验：将构建过程分解为可管理的模块，以及使用结构化产物在会话之间传递上下文。最终成果是一个三 agent 架构——规划器（planner）、生成器和评估器——能够在数小时的自主编码会话中产出丰富的全栈应用。 ## 为什么朴素实现不够 我们之前已经证明，harness 设计对长时 agent 编码的有效性有重大影响。在早前的 实验（https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents）中，我们使用初始化 agent 将产品规格分解为任务列表，然后由编码 agent 逐个功能实现，最后将产物移交以跨会话传递上下文。更广泛的开发者社区也得出了类似的见解，比如 "Ralph Wiggum（https://ghuntley.com/ralph/）" 方法使用钩子或脚本让 agent 保持持续迭代循环。 但有些问题依然存在。对于更复杂的任务，agent 随着时间推移仍会偏离轨道。在分解这个问题时，我们观察到 agent 执行这类任务时存在两种常见的失败模式。 首先是模型在冗长任务中随着上下文窗口填满而失去连贯性（参见我们关于 上下文工程（https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents）的文章）。一些模型还表现出"上下文焦虑"，即在接近它们认为的上下文限制时提前收尾。上下文重置——完全清空上下文窗口并启动新的 agent，结合结构化的交接来传递前一个 agent 的状态和后续步骤——可以解决这两个问题。 这与压缩（compaction）不同，后者是将对话的早期部分就地总结，让同一个 agent 在缩短的历史记录上继续。虽然压缩保持了连续性，但它没有给 agent 一个干净的起点，这意味着上下文焦虑仍会持续。重置提供了干净的起点，代价是交接产物需要包含足够的状态，让下一个 agent 能够顺畅地接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑表现足够强烈，仅靠压缩无法支持良好的长任务性能，因此上下文重置成为 harness 设计的核心。这解决了核心问题，但增加了编排复杂性、token 开销和每次 harness 运行的延迟。 第二个问题，也是我们此前未涉及的，是自我评估。当被要求评估自己产出的工作时，agent 往往会自信地赞扬工作——即使对人类观察者而言，质量明显平庸。这个问题在主观任务（如设计）中尤为突出，因为设计没有等同于可验证软件测试的二元检查。布局是否精致或平庸是一种判断，而 agent 在给自己的工作打分时总是偏向正面。 然而，即使在有明确可验证结果的任务中，agent 有时也会表现出影响任务完成的糟糕判断力。将执行工作的 agent 与评判工作的 agent 分离，证明是解决这一问题的有力手段。这种分离本身并不能立即消除那种宽容；评估器仍然是倾向于对 LLM 生成的输出慷慨的 LLM。但将独立的评估器调校为怀疑态度，远比让生成器批判自己的工作更容易实现，而且一旦有了外部反馈，生成器就有了具体的迭代依据。 ## 前端设计：让主观质量可评分 我从前端设计开始实验，因为自我评估问题在这里最为明显。在没有干预的情况下，Claude 通常会倾向于安全、可预测的布局，技术上可行但视觉上平淡无奇。 两个洞见塑造了我为前端设计构建的 harness。首先，虽然美学无法完全简化为分数——个人品味总会存在差异——但可以通过编码设计原则和偏好的评分标准来改进。"这个设计美吗？"难以一致回答，但"这是否遵循了我们关于良好设计的原则？"给了 Claude 具体的评分依据。其次，通过将前端生成与前端评分分离，我们可以创建反馈循环，推动生成器产出更强的结果。 基于这一点，我撰写了四项评分标准，分别提供给生成器和评估器 agent 的提示中： - **设计质量：** 设计是否感觉像一个连贯的整体，而非零件的堆砌？优秀的作品意味着色彩、字体、布局、图像和其他细节结合在一起，创造出独特的氛围和身份认同。 - **原创性：** 是否有定制化决策的证据，还是模板布局、库默认值和 AI 生成模式？人类设计师应该能识别出刻意的创意选择。未经修改的现成组件——或 AI 生成的典型痕迹，如白色卡片上的紫色渐变——在此项会失败。 - **工艺：** 技术执行：字体层级、间距一致性、色彩和谐、对比度。这是能力检查而非创意检查。大多数合理的实现默认都能通过；失败意味着基础功 broken。 - **功能性：** 独立于美学的可用性。用户能否理解界面的功能，找到主要操作，并在无需猜测的情况下完成任务？ 我强调设计质量和原创性，高于工艺和功能性。Claude 在工艺和功能性上默认已经得分良好，因为所需的技术能力对模型来说通常是自然的。但在设计和原创性方面，Claude 经常产出充其量平庸的作品。这些标准明确惩罚高度通用的"AI 垃圾"模式，通过对设计和原创性赋予更高权重，推动模型承担更大的美学风险。 我使用带有详细评分细分的少样本示例来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了跨迭代的分数漂移。 我在 Claude Agent SDK（https://platform.claude.com/docs/en/agent-sdk/overview）上构建了这个循环，使编排保持简洁。生成器 agent 首先基于用户提示创建 HTML/CSS/JS 前端。我给评估器配备了 Playwright MCP，让它能够与实时页面直接交互，然后对每个标准进行评分并撰写详细评论。实际上，评估器会自主导航页面，截图并仔细研究实现，然后再产出评估。该反馈流回生成器，作为下一次迭代的输入。我每次生成运行 5 到 15 次迭代，每次迭代通常推动生成器朝着更独特的方向发展，以回应评估器的批评。由于评估器是主动导航页面而非对静态截图评分，每个循环都需要真实的挂钟时间。完整运行可长达四小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好，则细化当前方向；如果方法不起作用，则转向完全不同的美学。 在各次运行中，评估器的评估在迭代中提升后趋于平稳，仍有提升空间。有些生成是渐进式改进的。另一些在迭代之间发生了急剧的美学转向。 标准的措辞以我没完全预料到的方式引导了生成器。包含"最好的设计具有博物馆品质"这类短语推动设计趋向特定的视觉融合，表明与标准相关的提示直接塑造了输出的特征。 虽然分数通常在迭代中提升，但模式并不总是干净的线性。后续实现整体趋于更好，但我经常遇到更喜欢中间迭代而非最后迭代的情况。实现复杂度也往往在多轮中增加，生成器为回应评估器的反馈而追求更雄心勃勃的解决方案。即使在第一次迭代，输出也比完全没有提示的基线明显更好，这表明标准和相关语言本身就在任何评估器反馈导致进一步细化之前，引导模型远离了通用默认。 在一个显著的例子中，我提示模型为一个荷兰艺术博物馆创建网站。到第九次迭代时，它已经产出了一个干净、深色主题的虚构博物馆落地页。页面视觉上很精致，但基本符合我的预期。然后，在第十次循环中，它完全抛弃了原有方法，将网站重新构想为空间体验：一个带有棋盘格地板的 3D 房间，以 CSS 透视渲染，艺术品以自由形式挂在墙上，基于门廊的导航在画廊房间之间切换，而非滚动或点击。这是我以前在单次生成中从未见过的创意飞跃。 ## 扩展到全栈编码 基于这些发现，我将这种受 GAN 启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期，其中代码审查和 QA 扮演着与设计评估器相同的结构角色。 ### 架构 在我们早期的 长时运行 harness（https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents）中，我们通过初始化 agent、逐个功能工作的编码 agent，以及会话之间的上下文重置，解决了多会话连贯编码的问题。上下文重置是关键突破：该 harness 使用了 Sonnet 4.5，它表现出前面提到的"上下文焦虑"倾向。创建一个在上下文重置中表现良好的 harness 是保持模型专注任务的关键。Opus 4.5 基本移除了这种行为，因此我能够完全从该 harness 中移除上下文重置。Agent 在整个构建过程中作为一次连续会话运行，Claude Agent SDK（https://platform.claude.com/docs/en/agent-sdk/overview）的自动压缩处理沿途的上下文增长。 对于这项工作，我在原始 harness 的基础上构建了一个三 agent 系统，每个 agent 解决我在先前运行中观察到的特定差距。系统包含以下 agent 角色： **规划器（Planner）：** 我们之前的长时运行 harness 要求用户预先提供详细的规格。我希望自动化这一步骤，因此创建了规划器 agent，它接收简单的 1-4 句提示，并将其扩展为完整的产品规格。我提示它在范围上要大胆，并专注于产品上下文和高层技术设计，而非详细的技术实现。这种强调是因为担心如果规划器试图预先指定细粒度技术细节且出错，规格中的错误会级联到下游实现。更明智的做法似乎是约束 agent 要交付的产物，让它们在工作中自行寻找路径。我还要求规划器寻找将 AI 功能融入产品规格的机会。（参见底部的附录示例。） **生成器：** 早期 harness 中一次一个功能的方法在范围管理上表现良好。我在这里应用了类似的模式，指示生成器以冲刺方式工作，从规格中逐个选取功能。每次冲刺使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）技术栈实现应用，生成器被指示在每次冲刺结束时自我评估工作，然后移交给 QA。它还使用 git 进行版本控制。 **评估器：** 早期 harness 中的应用往往看起来令人印象深刻，但实际使用时仍有真正的 bug。为了捕捉这些问题，评估器使用 Playwright MCP 像用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态。然后它根据发现的 bug 和一组基于前端实验改编的标准对每个冲刺进行评分，涵盖产品深度、功能性、视觉设计和代码质量。每个标准都有硬阈值，如果有任何一项低于阈值，冲刺即失败，生成器会收到关于问题所在的详细反馈。 在每次冲刺之前，生成器和评估器协商冲刺合约：在任何代码编写之前，就工作块的"完成"标准达成一致。这存在是因为产品规格故意保持高层级，我需要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提议它将构建什么以及如何验证成功，评估器审查该提议以确保生成器在构建正确的东西。两者迭代直至达成一致。 通信通过文件处理：一个 agent 写入文件，另一个 agent 读取它并在该文件中回复，或用新文件回复，前一个 agent 再依次读取。然后生成器根据商定的合约进行构建，再将工作移交给 QA。这保持了工作对规格的忠实，同时避免了过早过度指定实现。 ### 运行 harness 对于该 harness 的第一个版本，我使用 Claude Opus 4.5，针对完整 harness 和单 agent 系统运行用户提示进行对比。我使用 Opus 4.5 是因为这是我开始这些实验时我们最好的编码模型。 我撰写了以下提示来生成复古视频游戏制作器： > *创建一个 2D 复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为和可玩的测试模式。* 下表显示了 harness 类型、运行时长和总成本。 **Harness****Duration**