长期应用开发中的 Harness 设计

作者： Prithvi Rajasekaran（Anthropic Labs 团队成员）
发布日期： 2026年3月24日
原文链接： https://www.anthropic.com/engineering/harness-design-long-running-apps

Harness 设计是前沿智能体编码中影响性能的关键因素。本文将介绍我们如何在前端设计和长期自主软件工程两个方向上进一步突破 Claude 的能力边界。

背景

在过去几个月里，我一直在攻克两个相互关联的问题：一是让 Claude 产出高质量的前端设计，二是让它在无需人工干预的情况下构建完整的应用程序。

这项工作源于我们此前在前端设计技能和长期编码智能体 Harness 上的探索——通过提示词工程与 Harness 设计，我们成功将 Claude 的性能大幅提升至基准水平之上，但两者最终都触碰到了天花板。

为了突破瓶颈，我借鉴了生成对抗网络（GAN）的思想，设计了一种由**生成器（generator）和评估器（evaluator）**组成的多智能体架构。构建一个能够可靠、有品位地评分的评估器，首先需要建立一套能够将"这个设计好吗？"这类主观判断转化为具体可评分维度的标准。

随后，我将这些技术应用于长期自主编码，并从早期的 Harness 工作中沿用了两条经验：将构建过程分解为可处理的子任务，以及使用结构化产物在会话之间传递上下文。最终成果是一个由规划器（planner）、**生成器（generator）和评估器（evaluator）**组成的三智能体架构，能够在数小时的自主编码中产出功能丰富的全栈应用。

为什么朴素实现总是差强人意

我们此前已证明，Harness 设计对长期智能体编码的效果有着显著影响。在早期实验中，我们使用初始化智能体将产品规格拆解为任务列表，编码智能体逐一实现功能，并通过产物传递在会话间保持上下文。更广泛的开发者社区也逐渐形成了类似共识，例如"Ralph Wiggum"方法通过钩子或脚本让智能体保持持续迭代。

但一些顽固问题始终存在。对于更复杂的任务，智能体随着时间推移仍然容易偏离轨道。分析这一现象时，我们发现智能体在执行此类任务时存在两种常见的失败模式。

第一种：上下文窗口填满导致的连贯性丧失。 随着上下文窗口被填满，模型往往会失去连贯性（详见我们关于上下文工程的文章）。有些模型还会出现"上下文焦虑"——当它们认为自己接近上下文极限时，开始过早地收尾工作。上下文重置（完全清空上下文窗口，启动一个新的智能体，并通过结构化交接传递前一智能体的状态和下一步骤）可以解决这两个问题。

这与**压缩（compaction）**不同——后者是对对话早期部分进行原地摘要，使同一智能体在缩短的历史记录上继续工作。压缩保持了连续性，但没有给智能体一个干净的起点，上下文焦虑依然可能持续。重置提供了一个干净的起点，代价是交接产物必须包含足够的状态，以便下一个智能体能够顺利接手。在早期测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑表现非常明显，仅靠压缩不足以支撑强大的长任务性能，因此上下文重置成为 Harness 设计的关键。这解决了核心问题，但也为每次 Harness 运行增加了编排复杂度、Token 开销和延迟。

第二种：自我评估的偏差问题。 当被要求评估自己产出的作品时，智能体往往会自信地给予赞扬——即便对人类观察者而言，质量明显平庸。这个问题在设计等主观任务中尤为突出，因为没有像可验证软件测试那样的二元检查。布局是否精致还是流于俗套，本质上是一种判断，而智能体在评估自己的作品时，往往会系统性地偏向正面。

即便是具有可验证结果的任务，智能体有时也会表现出影响任务完成质量的判断缺失。将执行工作的智能体与评判工作的智能体分离，被证明是解决这一问题的强力手段。这种分离本身并不能立即消除宽松评分——评估器仍然是一个倾向于对 LLM 生成内容保持慷慨的 LLM。但将独立的评估器调优为持怀疑态度，远比让生成器对自己的作品保持批判性眼光更具可操作性。一旦外部反馈存在，生成器就有了可以据此迭代的具体参照。

前端设计：让主观质量可量化

我从前端设计入手，因为自我评估问题在这里最为明显。缺乏干预时，Claude 通常会倾向于安全、可预测的布局——技术上可用，但视觉上平淡无奇。

两个洞见塑造了我为前端设计构建的 Harness。

第一，虽然美学无法被完全量化——个人品位也永远因人而异——但可以通过编码设计原则和偏好的评分标准来提升。"这个设计漂亮吗？"很难一致地回答，但"这是否符合我们的优秀设计原则？"给了 Claude 具体可评分的依据。第二，将前端生成与前端评分分离，可以创建一个驱动生成器向更强输出迭代的反馈循环。

基于此，我编写了四个评分标准，同时提供给生成器和评估器：

四维评分标准

1. 设计质量
设计是否感觉是一个连贯的整体，而非各部分的简单拼凑？出色的设计意味着色彩、字体、布局、图像和其他细节共同营造出独特的氛围和个性。

2. 原创性
是否有自定义决策的迹象，还是模板布局、库默认值和 AI 生成模式的堆砌？人类设计师应能识别出刻意的创意决策。未经修改的现成组件——或 AI 生成的标志性特征（如白色卡片上的紫色渐变）——在此维度失分。

3. 工艺水准
技术执行层面：字体层级、间距一致性、色彩和谐度、对比度。这是能力检验而非创意检验。大多数合理实现默认就能在此表现良好；失分意味着基础功能出现问题。

4. 功能性
独立于美学的可用性。用户能否理解界面功能、找到主要操作并在不需要猜测的情况下完成任务？

我有意将设计质量和原创性的权重置于工艺水准和功能性之上。Claude 在工艺和功能上默认就有不错的表现，因为所需的技术能力对模型来说往往是自然的。但在设计和原创性上，Claude 的输出往往充其量只是平庸。评分标准明确惩罚了高度通用的"AI 流水线"模式，通过加重设计和原创性的权重，推动模型承担更多美学风险。

评估循环的实现

我使用 Claude Agent SDK 构建了这个循环，保持了编排的简洁性。生成器智能体首先根据用户提示创建 HTML/CSS/JS 前端。我给评估器配备了 Playwright MCP，使其能够在评分之前直接与运行中的页面交互——它会自主浏览页面、截图并仔细研究实现，然后生成评估报告。反馈随即流回生成器作为下一轮迭代的输入。

每次生成我运行 5 到 15 次迭代，随着生成器对评估器批评的回应，每次迭代通常会推动其向更具个性的方向发展。由于评估器是在主动导航页面而非对静态截图评分，每个周期都需要真实的时间。完整运行可长达四小时。我还指示生成器在每次评估后做出战略决策：如果得分趋势良好则深化当前方向，如果当前方向不奏效则彻底转向截然不同的美学风格。

案例亮点

在一个值得注意的例子中，我提示模型为一家荷兰艺术博物馆创建网站。到第九次迭代时，它已为一个虚构博物馆生成了一个整洁的深色主题落地页。页面视觉精致，但基本符合预期。然后，在第十个周期，它彻底推翻了这一方案，将网站重新构想为一种空间体验：一个用 CSS 透视法渲染的三维房间，带有棋盘格地板，艺术品以自由形式挂在墙上，画廊房间之间通过门道导航而非滚动或点击切换。这是一种我此前从未在单次生成中见过的创意飞跃。

扩展至全栈编码

带着这些发现，我将这种受 GAN 启发的模式应用于全栈开发。生成器-评估器循环与软件开发生命周期自然对应，其中代码审查和质量保证扮演着与设计评估器相同的结构性角色。

三智能体架构

在早期的长期运行 Harness 中，我们通过初始化智能体、逐功能推进的编码智能体和会话间的上下文重置，解决了多会话编码的连贯性问题。随着 Opus 4.6 的发布，该模型大幅改善了上下文焦虑问题，我得以完全去除上下文重置机制。智能体在整个构建过程中作为一个连续会话运行，由 Claude Agent SDK 的自动压缩功能处理上下文增长。

在此基础上，我构建了一个三智能体系统：

规划器（Planner）
之前的长期运行 Harness 要求用户预先提供详细规格。我希望自动化这一步骤，因此创建了一个规划器智能体，将简短的 1-4 句提示扩展为完整的产品规格。我提示它大胆设定范围，专注于产品背景和高层技术设计，而非详细的技术实现——这是为了避免规划器预先指定细粒度技术细节出错后，错误级联传导到下游实现。让智能体聚焦于要交付的成果，让它们在工作中自行摸索路径，似乎更为明智。我还要求规划器寻找机会在产品规格中融入 AI 功能。

生成器（Generator）
早期 Harness 中"一次一个功能"的方式对范围管理很有效。我在此采用了类似模型，指示生成器以冲刺（sprint）方式工作，每次从规格中拿起一个功能进行实现。每个冲刺使用 React、Vite、FastAPI 和 SQLite（后期改为 PostgreSQL）技术栈，生成器被要求在每个冲刺结束时对自己的工作进行自我评估，然后移交给质量保证。它还配备了 git 进行版本控制。

评估器（Evaluator）
早期 Harness 的应用往往看起来令人印象深刻，但实际使用时仍存在真实的 Bug。为捕获这些问题，评估器使用 Playwright MCP 像真实用户一样点击浏览运行中的应用，测试 UI 功能、API 端点和数据库状态。然后，它根据发现的 Bug 以及一套参照前端实验调整的标准（涵盖产品深度、功能性、视觉设计和代码质量）对每个冲刺进行评分。每个标准都有一个硬阈值，若任何一项低于阈值，该冲刺失败，生成器将获得关于问题的详细反馈。

冲刺合约（Sprint Contract）
每个冲刺开始前，生成器和评估器会协商一份冲刺合约：在编写任何代码之前，就该批工作的"完成"标准达成一致。这一步骤旨在弥合用户故事与可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，评估器审查该提案以确保生成器在构建正确的东西。双方反复迭代直至达成共识。

通信通过文件进行：一个智能体写入文件，另一个智能体读取并在该文件中或通过新文件进行响应。这种方式在不过度预先指定实现的情况下，保持了工作对规格的忠实性。

运行结果对比：复古游戏制作器

为了测试 Harness，我使用以下提示生成一个复古视频游戏制作器：

创建一个 2D 复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为和可玩的测试模式。

Harness 的费用超出 20 倍，但输出质量的差距立竿见影。

单智能体版本的问题： 布局浪费空间，固定高度面板让大部分视口空白。工作流程僵化，界面没有引导用户按正确顺序操作。最关键的是，实际游戏是坏的——实体出现在屏幕上，但没有任何东西响应输入。

完整 Harness 版本的表现： 规划器将单句提示扩展为覆盖十个冲刺的 16 功能规格，远超单智能体的尝试范围。规格包含了精灵动画系统、行为模板、音效和音乐、AI 辅助精灵生成器和关卡设计器，以及带有可分享链接的游戏导出功能。应用立刻展现出更多精致感：画布占满整个视口，面板尺寸合理，界面具有一致的视觉标识。最重要的是，游戏核心功能正常运行——我真的能够移动角色并进行游戏，这是单智能体版本未能做到的。

评估器发现的典型问题

评估器日志清楚地显示它如何使实现与规格保持一致。以下是几个典型发现案例：

让评估器达到这一水平需要大量调优工作。在早期运行中，我看到它识别出合理的问题，然后说服自己这些问题没那么严重，最终批准了工作。它也倾向于表面测试，而不是探查边界情况，导致更细微的 Bug 往往能逃脱检测。调优循环是：阅读评估器的日志，找到其判断与我不一致的例子，然后更新 QA 的提示来解决这些问题。经过几轮开发循环，评估器的评分方式才达到我认为合理的水平。

迭代改进 Harness

第一批 Harness 结果令人鼓舞，但也显得笨重、缓慢且昂贵。合理的下一步是在不降低性能的情况下简化 Harness。这部分出于常识，也部分源于一个更普遍的原则：Harness 中的每个组件都编码了一个关于模型自身无法完成某事的假设，这些假设值得压力测试——既因为它们可能是错误的，也因为随着模型改进，它们可能很快就会过时。

我们的博文《构建有效的智能体》将这一基本思想表述为"找到尽可能简单的解决方案，只在必要时才增加复杂性"。

Opus 4.6 带来的契机

在迭代过程中，我们发布了 Opus 4.6，这进一步激励了我减少 Harness 复杂性。根据发布博文，Opus 4.6"计划更周全，能够更长时间维持智能体任务，在大型代码库中运行更可靠，拥有更好的代码审查和调试能力来发现自身错误"，并在长上下文检索上大幅提升。这些都是 Harness 原本需要补足的能力。

移除冲刺结构

我首先尝试完全移除冲刺结构。鉴于 Opus 4.6 的改进，有充分理由相信模型可以原生处理任务分解，无需这种脚手架。

我保留了规划器和评估器，因为两者仍然明显有价值。没有规划器，生成器会低估范围：面对原始提示，它会直接开始构建而不先制定规格，最终创建功能不如规划器版本丰富的应用。

移除冲刺结构后，我将评估器改为在运行结束时进行单次评估，而非按冲刺评分。模型能力提升改变了评估器的负载情况：对于处于模型可靠处理边界内的任务，评估器成了不必要的开销；但对于仍处于生成器能力边界的任务，评估器依然提供了真实的提升。

实际意义是：评估器不是一个固定的是/否决策，当任务超出当前模型单独可靠完成的范围时，它才值得这个成本。

数字音频工作站（DAW）测试

为了检验更新后的 Harness，我使用以下提示生成一个数字音频工作站：

使用 Web Audio API 在浏览器中构建一个功能完整的 DAW。

大部分时间用于构建器，它在没有 Opus 4.5 所需的冲刺分解的情况下，连贯运行了超过两个小时。

QA 智能体在第一轮反馈中指出：

这是一个出色的应用，设计保真度极高，AI 智能体完善，后端良好。主要失分点在于功能完整性——虽然应用看起来令人印象深刻，AI 集成也运行良好，但几个核心 DAW 功能只是展示性的，缺乏交互深度：片段无法在时间轴上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化效果编辑器（EQ 曲线、压缩器仪表）。这些不是边缘情况——它们是使 DAW 可用的核心交互，规格明确要求了这些功能。

最终应用虽然远非专业音乐制作软件，但拥有功能性音乐制作程序的所有核心组件：在浏览器中运行的编曲视图、混音器和传输控制。通过提示，我完全借助智能体完成了一个短曲片段：智能体设置了节奏和调性，铺设了旋律，构建了鼓组，调整了混音器电平，并添加了混响。作曲的核心基础设施已经就位，智能体可以自主驱动这些基础设施，从头到尾使用工具创作简单的制作作品。

结论与展望

随着模型持续改进，我们大致可以预期它们能够在更长时间内处理更复杂的任务。在某些情况下，这意味着围绕模型的脚手架随着时间推移会变得越来越不重要，开发者可以等待下一个模型，让某些问题自行解决。另一方面，模型越强大，开发能够实现超出模型基准能力的复杂任务的 Harness 的空间也就越大。

从这项工作中，有几条值得铭记的经验：

• 始终对正在开发的模型进行实验，阅读其在实际问题上的轨迹，并调优其性能以实现期望结果。
• 对于更复杂的任务，有时可以通过分解任务并将专门的智能体应用于问题的每个方面来获得提升空间。
• 每当新模型发布时，重新审视 Harness 是良好实践——剥离掉不再对性能起关键作用的部分，并添加新组件以实现以前可能无法实现的更强能力。

我的坚定信念是：随着模型改进，有趣的 Harness 组合空间不会收缩，而是会移动。 对于 AI 工程师而言，有意义的工作始终是持续探索下一个新颖的组合。

致谢

特别感谢 Mike Krieger、Michael Agaby、Justin Young、Jeremy Hadfield、David Hershey、Julius Tarng、Xiaoyi Zhang、Barry Zhang、Orowa Sidker、Michael Tingley、Ibrahim Madha、Martina Long 和 Canyon Robbins 对这项工作的贡献。

同时感谢 Jake Eaton、Alyssa Leonard 和 Stef Sequeira 在文章撰写方面给予的帮助。

附录：规划器生成的示例计划

RetroForge - 2D 复古游戏制作器

概览
RetroForge 是一个基于网页的创意工作室，用于设计和构建 2D 复古风格视频游戏。
它将经典 8 位和 16 位游戏美学的怀旧魅力与现代直观的编辑工具相结合——
使任何人（从业余创作者到独立开发者）无需编写传统代码即可将游戏创意付诸实现。

该平台提供四个集成创意模块：
- 基于瓷砖的关卡编辑器（设计游戏世界）
- 像素艺术精灵编辑器（创作视觉资产）
- 可视化实体行为系统（定义游戏逻辑）
- 即时可玩测试模式（实时游戏测试）

通过在整个平台中织入 AI 辅助（由 Claude 驱动），RetroForge 加速了创作过程——
帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。

功能
1. 项目仪表板与管理
项目仪表板是 RetroForge 所有创意工作的主基地。
用户需要清晰、有序的方式来管理游戏项目——创建新项目、返回进行中的工作，
以及一目了然地了解每个项目的内容。

用户故事：作为用户，我希望：
- 创建带有名称和描述的新游戏项目，以便开始设计游戏
- 以视觉卡片形式查看所有现有项目，显示项目名称、最后修改日期和缩略图预览
- 打开任何项目进入完整的游戏编辑器工作区
- 删除不再需要的项目，并有确认对话框防止误操作
- 复制现有项目作为新游戏的起点

...