长时间运行应用开发的 Harness 设计作者:Prithvi Rajasekaran（Anthropic Labs）发布日期:2026年3月24日来源:Anthropic Engineering BlogHarness 设计是 Agent 编程前沿性能的关键。本文展示了我们如何在前端设计和长时间自主软件工程中进一步推动 Claude 的能力边界。在过去几个月里，我一直致力于两个相互关联的问题：让 Claude 产出高质量的前端设计，以及让它在没有人类干预的情况下构建完整的应用程序。这项工作源于我们早期的前端设计技能和长时间运行编程 Agent harness，在这些工作中，我和同事们通过提示工程和 harness 设计将 Claude 的表现提升到了远超基线的水平——但两者最终都遇到了瓶颈。为了突破瓶颈，我寻找了能够在两个截然不同的领域（一个由主观品味定义，另一个由可验证的正确性和可用性定义）中都适用的 AI 工程方法。受到**生成对抗网络（GAN）**的启发，我设计了一个包含生成器和评估器 Agent 的多 Agent 结构。构建一个能够可靠地——并带有品味地——评分的评估器，意味着首先要制定一套能够将"这个设计好吗？"这类主观判断转化为具体、可评分术语的标准。然后，我将这些技术应用于长时间自主编程，借鉴了我们早期 harness 工作的两个经验：将构建分解为可处理的小块，以及使用结构化工件在会话之间传递上下文。最终结果是一个三 Agent 架构——规划器、生成器和评估器——在数小时的自主编程会话中产出了丰富的全栈应用程序。为什么简单实现不够用我们之前已经表明，harness 设计对长时间运行的 Agent 编程效果有重大影响。在早期实验中，我们使用初始化 Agent 将产品规格分解为任务列表，编程 Agent 逐个实现功能，然后在会话之间传递工件来携带上下文。更广泛的开发者社区也形成了类似的见解，例如"Ralph Wiggum"方法使用 hooks 或脚本让 Agent 保持持续迭代循环。但一些问题仍然持续存在。对于更复杂的任务，Agent 仍然会随着时间推移而偏离轨道。在分解这个问题时，我们观察到 Agent 执行这类任务时的两种常见失败模式。首先，模型在长时间任务中随着上下文窗口填满而倾向于失去连贯性。一些模型还表现出**“上下文焦虑”**——它们在接近自己认为的上下文限制时开始过早地结束工作。上下文重置——完全清除上下文窗口并启动一个新的 Agent，结合携带前一个 Agent 状态和下一步的结构化交接——可以解决这两个问题。这与压缩不同，压缩是将对话的早期部分原地总结，以便同一个 Agent 可以在缩短的历史记录上继续工作。虽然压缩保持了连续性，但它没有给 Agent 一个干净的状态，这意味着上下文焦虑仍然可能持续。重置提供了一个干净的状态，代价是交接工件需要有足够的状态让下一个 Agent 干净地接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑非常强烈，仅靠压缩不足以实现强大的长任务性能，因此上下文重置成为 harness 设计的关键。第二个问题，我们之前没有讨论过，是自我评估。当被要求评估自己产出的工作时，Agent 倾向于自信地赞美工作——即使对人类观察者来说质量明显平庸。这个问题在设计等主观任务上尤其明显，因为没有等同于可验证软件测试的二元检查。然而，即使在有可验证结果的任务上，Agent 有时也会表现出影响其完成任务表现的糟糕判断。将执行工作的 Agent 与评判工作的 Agent 分开是解决这个问题的有力手段。这种分离本身并不能立即消除那种宽容；评估器仍然是一个倾向于对 LLM 生成输出慷慨的 LLM。但将独立的评估器调校为持怀疑态度，远比让生成器对自己的工作持批判态度要容易得多，而且一旦外部反馈存在，生成器就有了具体的东西来迭代改进。前端设计：让主观质量可评分我从前端设计开始实验，这是自我评估问题最明显的领域。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局，技术上可用但视觉上平淡无奇。两个洞见塑造了我为前端设计构建的 harness。首先，虽然美学不能完全简化为分数——个人品味总是会有所不同——但可以通过编码设计原则和偏好的评分标准来改进。"这个设计美吗？"很难一致地回答，但"这个设计遵循我们的好设计原则吗？"给了 Claude 具体的东西来评分。其次，通过将前端生成与前端评分分离，
