核心要点
- 生成器-评估器（GAN 启发）架构：将代码生成与质量评估分离为独立 Agent，可有效解决 LLM 自我评价过于宽容的问题
- 主观质量可评分化：通过制定具体的评分标准（设计质量、原创性、工艺、功能性），将"好不好看"这类主观判断转化为可量化的评估维度
- 三 Agent 协作架构：规划器（Planner）+ 生成器（Generator）+ 评估器（Evaluator），在多小时自主编码中产出完整全栈应用
- Harness 需随模型进化而简化：每个 Harness 组件都编码了"模型做不到什么"的假设，新模型发布后应重新检验这些假设，移除不再需要的脚手架
- 评估器的价值取决于任务边界：当任务处于模型独立能力的边界时，评估器提供最大增益；模型能力范围内的任务则无需额外评估开销
原文链接 English Original — Anthropic Engineering Blog, by Prithvi Rajasekaran
作者：Prithvi Rajasekaran，Anthropic Labs 团队成员。
过去几个月来，我一直在研究两个相互关联的问题：让 Claude 产出高质量的前端设计，以及让它在无人干预的情况下构建完整应用。这项工作源自我们早期在前端设计技能和长时间运行编码 Agent Harness 上的工作——我和同事通过提示工程 (Prompt Engineering) 和 Harness 设计将 Claude 的表现提升到了远超基线的水平，但两者最终都遇到了瓶颈。
为了突破瓶颈，我探索了在两个截然不同领域中都适用的新型 AI 工程方法——一个由主观审美定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GANs）的启发，我设计了一个包含生成器 (Generator) 和评估器 (Evaluator) 的多 Agent 结构。构建一个能可靠评分——且具有品味的评估器，意味着首先要开发一套标准，将"这个设计好不好？"这样的主观判断转化为具体的、可评分的维度。
随后我将这些技术应用于长时间自主编码，沿用了早期 Harness 工作中的两个经验：将构建任务分解为可控的模块，以及使用结构化产物在会话间传递上下文。最终成果是一个三 Agent 架构——规划器、生成器和评估器——能够在持续数小时的自主编码会话中产出丰富的全栈应用。
我们此前已经证明，Harness 设计对长时间 Agent 编码的效果有重大影响。在一次早期实验中，我们使用初始化 Agent 将产品规格分解为任务列表，由编码 Agent 逐个功能实现，然后通过产物传递在会话间延续上下文。更广泛的开发者社区也汇聚到了类似的洞察上，比如 "Ralph Wiggum" 方法使用钩子 (Hooks) 或脚本让 Agent 保持在持续迭代循环中。
但一些问题仍然顽固存在。对于更复杂的任务，Agent 随时间推移仍然容易偏离正轨。在分解这个问题时，我们观察到 Agent 执行此类任务时的两种常见失败模式。
第一种是模型在上下文窗口填满时倾向于失去连贯性（参见我们关于上下文工程的文章）。部分模型还表现出"上下文焦虑 (Context Anxiety)"——当它们认为自己接近上下文限制时，会过早地开始收尾工作。上下文重置 (Context Reset)——完全清空上下文窗口并启动新 Agent，结合携带前一个 Agent 状态和下一步计划的结构化交接——可以同时解决这两个问题。
这与压缩 (Compaction) 不同。压缩是将对话早期部分就地总结，让同一个 Agent 在缩短的历史上继续工作。虽然压缩保持了连续性，但它不会给 Agent 一个全新的起点，这意味着上下文焦虑仍可能持续。重置提供了全新起点，代价是交接产物需要包含足够的状态，让下一个 Agent 能够顺利接手。在早期测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑表现得相当强烈，仅靠压缩不足以支撑强大的长任务性能，因此上下文重置成为了 Harness 设计的关键组成部分。这解决了核心问题，但为每次 Harness 运行增加了编排复杂性、Token 开销和延迟。
第二个问题——我们之前未曾解决的——是自我评估 (Self-evaluation)。当被要求评估自己产出的工作时，Agent 倾向于自信地赞扬自己的作品——即使在人类观察者看来，质量显然平庸。这个问题在设计这类主观任务中尤为突出，因为没有类似可验证软件测试的二元检查。一个布局是精致还是平庸是一个判断问题，而 Agent 在给自己的作品打分时总是稳定地偏向正面。
然而，即使在有可验证结果的任务上，Agent 有时仍然表现出阻碍其完成任务的判断力不足。将做工作的 Agent 与评判工作的 Agent 分离，被证明是解决这一问题的有力杠杆。这种分离本身并不会立即消除宽容倾向；评估器仍然是一个倾向于对 LLM 生成内容慷慨相待的 LLM。但事实证明，调整独立评估器使其保持怀疑态度，远比让生成器对自己的工作保持批判性要容易得多，而一旦有了外部反馈，生成器就有了可以具体改进的方向。
我从前端设计开始实验，因为自我评估问题在这里最为明显。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局——技术上可用但视觉上平淡无奇。
两个洞察塑造了我为前端设计构建的 Harness。首先，虽然美学不能完全简化为一个分数——个人品味也总会有差异——但可以通过编码设计原则和偏好的评分标准来改进。"这个设计漂亮吗？"很难一致地回答，但"这个设计是否遵循了我们的良好设计原则？"给了 Claude 具体的评分依据。其次，通过将前端生成与前端评分分离，我们可以创建一个反馈循环，推动生成器产出更强的结果。
基于此，我编写了四个评分标准，分别提供给生成器和评估器 Agent 的提示词：
我着重强调了设计质量和原创性，而非工艺和功能性。Claude 在工艺和功能性方面默认表现已经不错，因为所需的技术能力对模型来说是自然而然的。但在设计和原创性方面，Claude 经常产出乏善可陈的结果。评分标准明确惩罚高度模板化的"AI 泔水 (AI Slop)"模式，并通过加重设计和原创性的权重，推动模型进行更多审美层面的冒险。
我使用包含详细评分分解的少样本示例来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了跨迭代的评分漂移。
我在 Claude Agent SDK 上构建了循环，保持编排的简洁性。生成器 Agent 首先基于用户提示创建 HTML/CSS/JS 前端。我给评估器配备了 Playwright MCP，使其能在评分每个标准并撰写详细批评之前，直接与活页面交互。在实践中，评估器会自行导航页面，截图并仔细研究实现，然后产出评估结果。反馈作为下一次迭代的输入回流给生成器。每次生成运行 5 到 15 次迭代，每次迭代通常推动生成器朝更具特色的方向发展，因为它在回应评估器的批评。由于评估器是在主动导航页面而非评分静态截图，每个周期都需要实际的时钟时间。完整运行最长可达四小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好则微调当前方向，如果方法不奏效则转向完全不同的美学风格。
跨多次运行，评估器的评估在迭代过程中逐步改善然后趋于平台期，但仍有提升空间。有些生成逐步微调，有些则在迭代之间出现剧烈的美学转向。
评分标准的措辞以我未完全预料到的方式引导了生成器。包含诸如"最佳设计应达到博物馆级别"这样的表述，推动设计朝特定的视觉趋同方向发展，这表明与标准相关联的提示措辞直接塑造了输出的特征。
虽然分数通常随迭代而提高，但模式并不总是线性的。后期实现整体趋向更好，但我经常发现自己更偏好某个中间迭代而非最后一个。实现复杂度也倾向于跨轮次增加，生成器在评估器反馈的推动下尝试更雄心勃勃的方案。即使在第一次迭代中，输出就明显优于完全没有提示的基线，这表明评分标准及其关联的语言本身就在任何评估器反馈导致进一步改进之前，已经将模型引离了模板化的默认方向。
在一个值得注意的案例中，我让模型为一家荷兰艺术博物馆创建网站。到第九次迭代时，它产出了一个虚构博物馆的干净、深色主题着陆页。页面视觉上很精致，但基本符合我的预期。然后，在第十个周期，它彻底推翻了之前的方案，将网站重新构想为一种空间体验：一个用 CSS 透视渲染的棋盘格地板 3D 房间，画作以自由形式挂在墙上，通过门廊式导航在画廊房间之间穿梭，而非传统的滚动或点击。这是那种我之前从未在单次生成中见过的创造性飞跃。
有了这些发现，我将这种 GAN 启发的模式应用到全栈开发中。生成器-评估器循环自然地映射到软件开发生命周期——代码审查和 QA 承担着与设计评估器相同的结构性角色。
在我们早期的长时间运行 Harness 中，我们通过初始化 Agent、逐功能工作的编码 Agent 以及会话间的上下文重置，解决了连贯的多会话编码问题。上下文重置是关键突破：Harness 使用了 Sonnet 4.5，该模型表现出前述的"上下文焦虑"倾向。设计一个能良好跨上下文重置工作的 Harness 是保持模型专注的关键。Opus 4.5 在很大程度上自行消除了这种行为，因此我能够从本次 Harness 中完全移除上下文重置。Agent 作为一个连续会话在整个构建过程中运行，Claude Agent SDK 的自动压缩处理了过程中的上下文增长。
在这项工作中，我基于原始 Harness 的基础构建了一个三 Agent 系统，每个 Agent 解决我在先前运行中观察到的特定不足。系统包含以下 Agent 角色：
规划器 (Planner)： 我们之前的长时间运行 Harness 需要用户预先提供详细的规格说明。我想自动化这一步骤，所以创建了一个规划器 Agent，它接收简单的 1-4 句提示并将其扩展为完整的产品规格。我引导它在范围上要有雄心，并专注于产品上下文和高层技术设计，而非详细的技术实现。这是因为如果规划器试图预先指定细粒度的技术细节并出了错，规格中的错误会级联传导到下游实现中。让 Agent 在交付物上受约束、而在实现路径上自行摸索似乎更明智。我还要求规划器寻找机会将 AI 功能融入产品规格中。（参见附录中的示例。）
生成器 (Generator)： 早期 Harness 的逐功能实现方式在范围管理上效果良好。我在这里采用了类似模型，指示生成器以冲刺 (Sprint) 的方式工作，从规格中逐一拾取功能进行实现。每个冲刺使用 React、Vite、FastAPI 和 SQLite（后改为 PostgreSQL）技术栈实现应用，生成器被指示在每个冲刺结束时自我评估工作，然后交付给 QA。它还拥有 git 进行版本控制。
评估器 (Evaluator)： 早期 Harness 产出的应用往往看起来令人印象深刻，但实际使用时仍有真实的 bug。为了捕获这些问题，评估器使用 Playwright MCP 像用户一样点击浏览运行中的应用，测试 UI 功能、API 端点和数据库状态。然后它按照基于前端实验改编的一套标准，对每个冲刺进行评分——涵盖产品深度、功能性、视觉设计和代码质量。每个标准都有硬阈值，如果任何一项低于阈值，冲刺就会失败，生成器会收到关于哪里出了问题的详细反馈。
在每个冲刺之前，生成器和评估器会协商一份冲刺合同 (Sprint Contract)：在编写任何代码之前就"完成"的定义达成一致。这是因为产品规格是有意保持高层次的，我想要一个步骤来弥合用户故事与可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，评估器审查该提案以确保生成器在构建正确的东西。两者反复迭代直到达成一致。
通信通过文件处理：一个 Agent 写文件，另一个 Agent 读取并在该文件内或通过新文件回应。生成器然后按照商定的合同进行构建，完成后交付给 QA。这使工作忠实于规格，同时又不会过早地过度指定实现。
对于这个 Harness 的第一个版本，我使用了 Claude Opus 4.5，将用户提示同时在完整 Harness 和单 Agent 系统上运行以进行对比。我选择 Opus 4.5 是因为在我开始这些实验时，它是我们最好的编码模型。
我写了以下提示来生成一个复古电子游戏制作工具：
创建一个 2D 复古游戏制作器，包含关卡编辑器、精灵编辑器、实体行为和可玩测试模式等功能。
下表显示了 Harness 类型、运行时长和总成本。
| Harness | 时长 | 成本 |
|---|---|---|
| 单 Agent | 20 分钟 | $9 |
| 完整 Harness | 6 小时 | $200 |
Harness 的成本超过了 20 倍，但输出质量的差异立刻显而易见。
我期望得到一个界面，能让我构建关卡及其组成部分（精灵、实体、地块布局），然后按下播放键来实际玩关卡。我先打开了单 Agent 运行的输出，初始应用看起来符合这些预期。
但随着我深入点击，问题开始浮现。布局浪费空间，固定高度的面板让视口大部分空置。工作流僵硬。尝试填充关卡时提示我先创建精灵和实体，但 UI 中没有任何引导来指明这个顺序。更关键的是，实际游戏是坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入代码发现实体定义和游戏运行时之间的连接是断开的，界面上没有任何线索表明问题出在哪里。
评估完单 Agent 运行后，我转向了 Harness 运行。这次运行从同一句话的提示开始，但规划器步骤将该提示扩展为一个跨越十个冲刺的 16 功能规格。它远远超出了单 Agent 运行的尝试范围。除了核心编辑器和播放模式外，规格还包括精灵动画系统、行为模板、音效和音乐、AI 辅助精灵生成器和关卡设计器，以及带有可分享链接的游戏导出。我给规划器提供了我们的前端设计技能的访问权限，它读取并使用该技能为应用创建了视觉设计语言作为规格的一部分。对于每个冲刺，生成器和评估器协商了一份合同，定义了冲刺的具体实现细节以及将用于验证完成的可测试行为。
应用立刻展现出比单 Agent 运行更多的精致和流畅。画布使用了全视口，面板尺寸合理，界面有一致的视觉身份，追踪了规格中的设计方向。我在单 Agent 运行中看到的一些笨拙仍然存在——工作流仍然没有明确提示你应该先构建精灵和实体再尝试填充关卡，我不得不自己摸索。这看起来像是基础模型的产品直觉不足，而非 Harness 设计的目标范围，尽管它确实暗示了 Harness 内的针对性迭代可能进一步提升输出质量的方向。
深入使用编辑器后，新运行相比单 Agent 的优势变得更加明显。精灵编辑器更丰富、功能更完整，有更干净的工具面板、更好的颜色选择器和更可用的缩放控制。
因为我要求规划器将 AI 功能融入其规格中，应用还内置了 Claude 集成，让我可以通过提示生成游戏的不同部分。这显著加速了工作流。
最大的差异在播放模式中。我实际上能够移动我的实体并玩游戏。物理效果有些粗糙边缘——我的角色跳到平台上但最终与之重叠，直觉上感觉不对——但核心功能是工作的，而单 Agent 运行做不到这一点。移动一会儿后，我确实遇到了 AI 关卡构建的一些局限。有一面大墙我无法跳过，所以被卡住了。这表明 Harness 还有一些常识性改进和边缘情况需要处理来进一步完善应用。
阅读日志可以清楚地看到，评估器保持了实现与规格的一致性。每个冲刺中，它遍历冲刺合同的测试标准，通过 Playwright 操作运行中的应用，对任何偏离预期行为的地方提出 bug。合同是细粒度的——仅冲刺 3 就有 27 个覆盖关卡编辑器的标准——评估器的发现具体到可以直接行动，无需额外调查。下表展示了评估器发现的几个问题示例：
| 合同标准 | 评估器发现 |
|---|---|
| 矩形填充工具允许点击拖动以用选定地块填充矩形区域 | 失败 — 工具仅在拖动起点/终点放置地块，而非填充区域。fillRectangle 函数存在但未在 mouseUp 时正确触发。 |
| 用户可以选择并删除已放置的实体生成点 | 失败 — LevelEditor.tsx:892 处的 Delete 键处理器要求同时设置 selection 和 selectedEntityId，但点击实体仅设置了 selectedEntityId。条件应为 selection || (selectedEntityId && activeLayer === 'entity')。 |
| 用户可以通过 API 重新排序动画帧 | 失败 — PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 reorder 作为 frame_id 整数匹配，返回 422："unable to parse string as an integer." |
让评估器达到这个水平需要大量工作。开箱即用时，Claude 是一个糟糕的 QA Agent。在早期运行中，我看着它发现了合理的问题，然后说服自己认为这些不是大问题并批准了工作。它还倾向于浅层测试而非探查边缘情况，因此更微妙的 bug 经常被放过。调优循环是阅读评估器的日志，找到其判断与我不一致的例子，然后更新 QA 的提示词来解决这些问题。经过几轮这样的开发循环后，评估器的评分才达到了我认为合理的水平。即便如此，Harness 输出仍然展示了模型 QA 能力的局限：小的布局问题、某些地方感觉不直觉的交互，以及评估器未充分测试的更深层嵌套功能中的未发现 bug。显然还有更多验证空间可以通过进一步调优来捕获。但与单 Agent 运行相比——应用的核心功能根本不工作——提升是显而易见的。
第一组 Harness 结果令人鼓舞，但也显得笨重、缓慢且昂贵。合乎逻辑的下一步是找到简化 Harness 又不降低其性能的方法。这部分是常识，部分是一个更普遍原则的体现：Harness 中的每个组件都编码了对"模型自身做不到什么"的假设，这些假设值得进行压力测试——因为它们可能是不正确的，也因为随着模型改进它们会很快过时。我们的博文构建有效的 Agent 将其背后的理念表述为"找到最简可能的方案，只在需要时才增加复杂性"——这是每个维护 Agent Harness 的人都会反复遇到的模式。
在我第一次简化尝试中，我大幅削减了 Harness 并尝试了一些有创意的新想法，但无法复现原始版本的性能。也变得难以分辨 Harness 设计中哪些部分实际上是承重的，以及以何种方式承重。基于这次经验，我转向了更系统的方法，每次只移除一个组件并审查其对最终结果的影响。
在经历这些迭代周期的同时，我们还发布了 Opus 4.6，这进一步推动了降低 Harness 复杂性。有充分理由预期 4.6 需要比 4.5 更少的脚手架。引用我们的发布博文："[Opus 4.6] 计划更周密，持续 Agent 任务更持久，能在更大的代码库中更可靠地运行，并且具有更好的代码审查和调试技能来捕获自身的错误。"它在长上下文检索方面也有实质性改进。这些都是 Harness 原本用来补充的能力。
我首先完全移除了冲刺结构。冲刺结构此前帮助将工作分解为模块以保持模型的连贯性。鉴于 Opus 4.6 的改进，有充分理由相信模型可以原生处理这项工作而无需这种分解。
我保留了规划器和评估器，因为两者都持续带来明显的价值。没有规划器，生成器会缩小范围：给定原始提示，它会直接开始构建而不先编写规格，最终创建的应用功能不如规划器所能产出的丰富。
移除冲刺结构后，我将评估器改为在运行结束时进行单次评估，而非按冲刺评分。由于模型能力大幅增强，这改变了评估器在不同运行中的承重程度，其价值取决于任务相对于模型独立能力边界的位置。在 4.5 上，这个边界很近：我们的构建处于生成器独立完成的能力边缘，评估器在整个构建过程中捕获了有意义的问题。在 4.6 上，模型的原始能力增强了，边界向外移动。曾经需要评估器检查才能连贯实现的任务，现在通常在生成器自行处理的范围内，对于这些任务，评估器变成了不必要的开销。但对于仍处于生成器能力边缘的构建部分，评估器继续提供真实的提升。
实际含义是，评估器不是一个固定的"要或不要"的决策。当任务超出当前模型独立可靠完成的范围时，评估器的成本是值得的。
在结构简化的同时，我还添加了提示词来改善 Harness 将 AI 功能构建到每个应用中的方式，特别是让生成器构建一个能通过工具驱动应用自身功能的适当 Agent。这需要真正的迭代，因为相关知识足够新，Claude 的训练数据覆盖较薄。但经过足够的调优，生成器能够正确地构建 Agent。
为了测试更新后的 Harness，我使用以下提示生成了一个数字音频工作站（DAW），一个用于作曲、录制和混音的音乐制作程序：
在浏览器中使用 Web Audio API 构建一个功能完整的 DAW。
运行仍然耗时且昂贵，大约 4 小时，Token 成本 $124。
大部分时间花在了构建器上，它连贯运行了超过两小时，无需 Opus 4.5 所需的冲刺分解。
| 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 |
与之前的 Harness 一样，规划器将一行提示扩展为完整规格。从日志中可以看到，生成器模型在规划应用和 Agent 设计、连接 Agent 和测试方面做得很好，然后才交付给 QA。
尽管如此，QA Agent 仍然捕获了真实的不足。在第一轮反馈中，它指出：
这是一个设计保真度出色、AI Agent 扎实、后端良好的强大应用。主要失败点在功能完整性——虽然应用看起来令人印象深刻且 AI 集成运作良好，但几个核心 DAW 功能仅为展示而缺乏交互深度：片段无法在时间线上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化效果编辑器（EQ 曲线、压缩器仪表）。这些不是边缘情况——它们是使 DAW 可用的核心交互，规格中明确要求了这些功能。
在第二轮反馈中，它再次捕获了几个功能缺口：
剩余不足：
- 音频录制仍为存根状态（按钮切换但未进行麦克风采集）
- 未实现通过边缘拖动调整片段大小和片段分割
- 效果可视化为数字滑块，非图形化（无 EQ 曲线）
生成器在无人监督时仍然容易遗漏细节或留下存根功能，QA 在捕获这些最后一公里的问题上仍然为生成器的修复提供了价值。
基于提示，我期望得到一个程序，能够创建旋律、和声和鼓点模式，将它们编排成一首歌，并在过程中得到集成 Agent 的帮助。
这个应用远非专业的音乐制作程序，Agent 的作曲能力显然还有很大提升空间。此外，Claude 实际上听不到声音，这使得 QA 反馈循环在音乐品味方面的有效性降低。
但最终应用具备了功能性音乐制作程序的所有核心组件：一个在浏览器中运行的编曲视图、混音器和走带控制。除此之外，我完全通过提示组装了一段短曲片段：Agent 设置了速度和调号，铺设了旋律，构建了鼓轨，调整了混音器电平，并添加了混响。作曲的核心原语都已就位，Agent 可以自主驱动它们，使用工具从头到尾创建一个简单的制作。可以说还没到完美的程度——但正在接近。
随着模型持续改进，我们大致可以预期它们能够工作更长时间、处理更复杂的任务。在某些情况下，这意味着模型周围的脚手架将随时间变得不那么重要，开发者可以等待下一个模型，看到某些问题自行解决。另一方面，模型越好，开发 Harness 以实现超出模型基线能力的复杂任务的空间就越大。
考虑到这一点，有几个来自这项工作的经验值得带入未来。与目标模型进行实验、在真实问题上阅读其执行轨迹并调优性能以达到期望的结果，始终是好的实践。在处理更复杂的任务时，将任务分解并为问题的每个方面应用专门的 Agent，有时能带来提升空间。当新模型发布时，重新审视 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 在文章撰写中的帮助。