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

译文信息

• 原文：Harness design for long-running application development
• 作者：Prithvi Rajasekaran（Anthropic Labs 团队成员）
• 原文发布：2026-03-24
• 中文翻译：Hex4C59
• 翻译整理：2026-10-10

本文为非官方中文译文。正文中的「我」「我们」指原文作者及其团队；模型版本、实验结果和费用均保留原文记录，译者未独立复现实验。

Agent 编程能达到什么水平，很大程度上取决于 Harness 设计。本文介绍我们如何进一步提升 Claude 在前端设计和长期自主软件开发中的能力。

**译者注：**本文的 Harness 指围绕模型安排任务规划、工具调用、上下文管理和结果评估的运行系统；全栈应用在这里同时包含前端界面、后端接口和数据库。

在过去几个月里，我一直在研究两个相互关联的问题：如何让 Claude 产出高质量的前端设计，以及如何让它在没有人工介入的情况下构建完整应用。这项工作源于我们此前对 frontend design skill 和长期运行编码 Agent 的 Harness 的探索。在那些工作中，我和同事通过提示工程与 Harness 设计，让 Claude 的表现显著超过了基线，但这两条路线最终都遇到了瓶颈。

为了突破瓶颈，我开始寻找新的 AI 工程方法，希望它们能同时适用于两个差异很大的领域：一个主要由主观审美决定，另一个则由可验证的正确性和可用性决定。受生成对抗网络（Generative Adversarial Networks，GANs）的启发，我设计了一种由生成 Agent 和评估 Agent 组成的多 Agent 结构。要构建一个既能可靠评分、又具备审美判断力的评估器，首先需要制定一套标准，把「这个设计好不好」这样的主观判断转化为具体、可评分的项目。

随后，我将这些技术应用到长期自主编程中，并沿用了此前 Harness 工作中的两条经验：把开发任务拆成可以处理的小块，以及用按固定结构记录的交接材料，把上下文传给后续会话。最终形成的是一套由规划、生成和评估三个 Agent 组成的架构，能够在持续数小时的自主编程会话中构建功能丰富的全栈应用。

为什么朴素实现会遇到瓶颈 #

我们此前已经展示过，Harness 设计会显著影响长期运行的 Agent 编程效果。在一项早期实验中，我们让初始化 Agent 把产品规格拆成任务列表，再由编码 Agent 每次实现一个功能，最后交接相关产物，让上下文能够延续到后续会话。更广泛的开发者社区也逐渐得出了类似的认识，例如「Ralph Wiggum」方法，就利用钩子或脚本让 Agent 持续循环迭代。

但一些问题仍然存在。面对更复杂的任务，Agent 依然容易随着运行时间增长而偏离方向。在拆解这个问题的过程中，我们观察到了两种常见的失败模式。

首先，随着上下文窗口逐渐填满，模型在长任务中往往会失去连贯性，相关讨论可以参见我们的上下文工程文章。一些模型还会表现出「上下文焦虑」：当它们认为自己正在接近上下文上限时，会过早地开始收尾。上下文重置可以同时应对这两类问题：彻底清空上下文窗口，启动一个新的 Agent，并通过结构化交接传递上一个 Agent 的状态和下一步工作。

这与上下文压缩不同。压缩会在原有会话中总结较早的内容，让同一个 Agent 能够基于缩短后的历史继续工作。虽然压缩保留了连续性，却没有给 Agent 一个全新的起点，因此上下文焦虑仍然可能存在。重置则提供了一个干净的起点，代价是交接产物必须包含足够的状态信息，才能让下一个 Agent 顺利接续工作。在我们此前的测试中，Claude Sonnet 4.5 的上下文焦虑表现得足够明显，仅靠压缩不足以让它在长任务中取得良好表现，因此上下文重置成为 Harness 设计中不可或缺的一部分。它解决了核心问题，但也为每次 Harness 运行增加了编排复杂度、token 开销和延迟。

第二个问题是自我评估，这是我们此前还没有处理过的问题。当 Agent 被要求评价自己产出的工作时，它们往往会自信地称赞结果，即便在人类观察者看来，质量明显只是一般水平。这个问题在设计之类的主观任务中尤其突出，因为这里不能像软件测试那样，用可验证的「通过或不通过」来判断质量。一个布局究竟精致还是平庸，需要进行判断，而 Agent 在为自己的作品评分时，总是倾向于给出正面评价。

不过，即便任务的结果可以验证，Agent 也仍然会做出不佳的判断，妨碍任务完成。将执行工作的 Agent 与评价工作的 Agent 分开，是解决这个问题的一种有效手段。这种分离本身不会立即消除宽松的评分倾向：评估器依然是大语言模型，仍然倾向于对大语言模型生成的内容宽容。但实践表明，把一个独立评估器调校得更有怀疑精神，比让生成器严厉审视自己的作品更容易。一旦有了这种外部反馈，生成器就有了具体的迭代依据。

前端设计：让主观质量可以评分 #

我先从前端设计开始实验，因为在这个领域，自我评估的问题最明显。没有任何干预时，Claude 通常会选择安全、可预测的布局：技术上能够正常使用，但视觉上平淡无奇。

我为前端设计构建的 Harness 受到了两点认识的影响。第一，虽然审美无法完全归结为一个分数，而且个人喜好始终不同，但把设计原则和偏好写入评分标准，仍然可以改善结果。「这个设计漂亮吗」很难得到稳定一致的回答，而「它是否遵循了我们对好设计的原则」则给了 Claude 具体的评分依据。第二，把前端生成与前端评分分开，就能形成一个反馈循环，推动生成器产出更好的结果。

基于这两点，我编写了四项评分标准，并将它们同时放入生成 Agent 和评估 Agent 的提示中：

• 设计质量（Design quality）：设计是否像一个连贯的整体，而不是零散部件的堆积？优秀的表现意味着配色、字体、布局、图像及其他细节共同营造出鲜明的氛围和身份特征。
• 原创性（Originality）：能否看出定制设计的决策，还是只是模板布局、组件库默认配置和 AI 生成的常见模式？人类设计师应当能辨认出有意识的创作选择。未经修改的现成组件，或白色卡片上叠加紫色渐变等明显的 AI 生成痕迹，都无法通过这一项。
• 制作水准（Craft）：技术执行的质量，包括字体层级、间距一致性、色彩协调和对比度。这是在检查基本功，而不是创造力。大多数合理的实现默认就能做好；如果不合格，说明基础出了问题。
• 功能性（Functionality）：不考虑美观时的可用性。用户能否理解界面是做什么的、找到主要操作，并在不靠猜测的情况下完成任务？

我让设计质量和原创性拥有比制作水准与功能性更高的权重。Claude 默认在制作水准和功能性方面已经能取得不错的分数，因为所需的技术能力通常是模型自然具备的。但在设计与原创性上，Claude 的输出往往最多只能算平淡。这套标准明确惩罚高度套路化的「AI slop」模式；通过提高设计与原创性的权重，它推动模型在审美上尝试更大胆的选择。

我使用带有详细评分拆解的少样本示例来校准评估器。这样既能让评估器的判断与我的偏好一致，也能减少评估器在多轮迭代中改变评分尺度的情况。

我基于 Claude Agent SDK 构建了这个循环，使编排保持简单。生成 Agent 先根据用户提示创建一个 HTML、CSS 和 JavaScript 前端。我为评估器提供了 Playwright MCP，让它能直接与运行中的页面交互，再逐项评分并写出详细评价。实际运行时，评估器会自行浏览页面、截取屏幕截图，仔细检查实现，然后给出评估。反馈再传回生成器，成为下一轮迭代的输入。每次生成我会运行 5 到 15 轮迭代；通常，每一轮都会随着生成器响应评估器的意见，把结果推向更鲜明的方向。由于评估器是在实际操作页面，而不是给一张静态截图打分，每个循环都需要真实的运行时间。完整运行最长持续了四个小时。我还要求生成器在每次评估后做出一个策略决策：如果评分趋势良好，就继续完善当前方向；如果当前思路行不通，就切换到完全不同的审美方向。

在多次运行中，评估器的评分会随着迭代提升，随后不再明显增长，但结果仍然有改善空间。有的生成结果是在原有方向上逐步完善，另一些则在迭代之间发生了明显的审美转向。

评分标准的措辞也会以我没有完全预料到的方式引导生成器。加入「最好的设计应当达到博物馆级水准」之类的表述，会推动不同设计向某种特定的视觉风格收敛。这说明，与评分标准相关的提示措辞，直接影响着输出的风格。

虽然评分总体上会随迭代提升，但这个过程并不总是呈现清晰的线性关系。后期实现整体上往往更好，但我经常遇到自己更喜欢中间某轮结果、而不是最后一轮结果的情况。随着生成器为了回应评估意见而尝试更有野心的方案，实现复杂度也往往逐轮增加。即使只看第一轮，输出也明显优于完全没有提示的基线。这说明，在评估器提供进一步改进的反馈之前，评分标准及其措辞本身就已经把模型从通用的默认设计中推开了。

有一个值得一提的例子：我让模型为一家荷兰艺术博物馆创建网站。到第九轮时，它为一家虚构的博物馆生成了一个简洁的深色落地页。页面在视觉上很精致，但总体仍然符合我的预期。随后，在第十轮循环中，它完全放弃了这套方案，把网站重新构想成一种空间体验：利用 CSS 透视渲染出带棋盘格地板的三维房间，把艺术品以自由布局挂在墙上，并用展厅之间的门洞导航，替代滚动或点击导航。这种创造性的跃迁，是我此前没有在单次生成中见过的。

扩展到全栈编程 #

有了这些发现，我把这种受 GAN 启发的模式应用到全栈开发中。生成器—评估器循环与软件开发生命周期自然契合：代码审查和质量保证（Quality Assurance，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 功能融入产品规格的机会，文末附录中有一个示例。

生成 Agent（Generator）：此前 Harness 中每次只实现一个功能的方法，在控制范围方面效果不错。我在这里采用了类似的方式，让生成器按迭代周期（sprint）工作，每次从规格中挑选一个功能。每个迭代周期都使用 React、Vite、FastAPI 和 SQLite（后来改为 PostgreSQL）这套技术栈实现应用，并要求生成器在迭代结束时先自我评估，再交给 QA。它还可以使用 Git 进行版本控制。

评估 Agent（Evaluator）：此前 Harness 生成的应用看起来往往很出色，但实际使用时仍然有真正的缺陷。为了发现这些问题，评估器使用 Playwright MCP，像用户一样点击操作正在运行的应用，测试界面功能、API 端点和数据库状态。随后，它根据发现的缺陷，以及一套参考前端实验改编的标准，对每个迭代周期评分。这套标准涵盖产品深度、功能性、视觉设计和代码质量。每项标准都有硬性阈值；只要有一项低于阈值，这个迭代周期就不合格，生成器会收到详细的问题反馈。

在每个迭代周期开始前，生成器与评估器会协商一份迭代验收约定（sprint contract）：在编写任何代码之前，先就这一块工作怎样才算「完成」达成一致。之所以需要这一步，是因为产品规格被有意保持在较高层级，我希望通过这个环节，把用户希望完成的事转成可以测试的实现要求。生成器提出要构建什么、怎样验证成功；评估器则审查这个提案，确保生成器在构建正确的内容。双方不断迭代，直到达成一致。

Agent 之间通过文件通信：一个 Agent 写入文件，另一个 Agent 读取，然后在同一文件中回复，或写入一个新文件供前一个 Agent 阅读。接着，生成器按照已达成一致的验收约定开发，再把工作交给 QA。这种方式让实现忠于规格，同时避免过早把实现细节规定得太死。

运行 Harness #

在这套 Harness 的第一个版本中，我使用 Claude Opus 4.5，将同一批用户提示分别交给完整 Harness 和单 Agent 系统，以进行比较。我使用 Opus 4.5，是因为开始这些实验时，它是我们最好的编程模型。

我编写了下面这条提示，用来生成一个复古游戏制作工具：

创建一个二维复古游戏制作工具，包含关卡编辑器、精灵编辑器、实体行为，以及可实际运行的试玩模式。

下表列出了两种 Harness 的运行时长与总费用。

完整 Harness 的费用高出二十多倍，但输出质量的差异一眼就能看出来。

我预期得到一个界面，让我能够构建关卡及其组成部分——精灵、实体和图块布局——然后点击运行，真正玩到这个关卡。我先打开了单 Agent 那次运行的输出；最初看起来，应用似乎符合这些预期。

但随着我逐个点击功能，问题开始暴露出来。布局浪费空间，固定高度的面板让视口的大部分区域空着。工作流程也很僵硬：尝试往关卡里添加内容时，界面会要求先创建精灵和实体，却没有任何引导说明这个顺序。更关键的是，游戏本身无法正常运行。实体出现在屏幕上，却完全不响应输入。深入查看代码后，我发现实体定义与游戏运行时之间的连接出了问题，而界面上没有任何提示能指出问题所在。

原文截图页签：打开界面、精灵编辑器、游戏运行。

图注：打开单 Agent Harness 创建的应用时所见的初始界面。

评估完单 Agent 的结果后，我转而查看完整 Harness 的运行结果。这次运行也从同一句提示开始，但规划阶段把它扩展成了一份包含 16 项功能、分布在 10 个迭代周期中的规格，范围远超单 Agent 尝试实现的内容。除了核心编辑器和试玩模式，规格还要求精灵动画系统、行为模板、音效与音乐、AI 辅助的精灵生成器和关卡设计器，以及可通过链接分享的游戏导出功能。我让规划器访问我们的 frontend design skill；它读取后，把应用的视觉设计语言也纳入了规格。在每个迭代周期中，生成器与评估器都会协商验收约定，明确具体的实现细节，以及用于验证完成情况的可测试行为。

这个应用立刻表现出比单 Agent 版本更高的完成度和更顺畅的体验。画布充分利用了整个视口，面板尺寸合理，界面具备一致的视觉风格，符合规格中的设计方向。不过，单 Agent 版本中一些生硬之处仍然存在：工作流依然没有说明，应该先构建精灵和实体，再向关卡中添加内容，我仍然得靠自己摸索。这看起来更像是基础模型在产品直觉上的不足，而不是这套 Harness 原本要解决的问题。但它也提示了一个方向：在 Harness 内部进行有针对性的迭代，可能进一步改善输出质量。

随着我逐个使用编辑器，新版本相对于单 Agent 版本的优势更加明显。精灵编辑器更丰富、功能更完整，工具面板更清晰，取色器更好，缩放操作也更实用。

由于我要求规划器把 AI 功能融入规格，应用还内置了 Claude 集成，让我可以通过提示生成游戏的不同部分。这显著加快了工作流程。

原文截图页签：打开界面、精灵编辑器、AI 游戏设计、AI 游戏设计、游戏运行。

图注：完整 Harness 构建的应用初始界面——创建一个新游戏。

最大的区别出现在试玩模式里。我确实能够移动实体并玩这个游戏。物理效果还有些粗糙：角色跳上平台后会与平台发生重叠，直觉上不太对劲。但核心功能能工作了，而单 Agent 版本没有做到。在移动一段时间后，我也发现 AI 构建的关卡存在一些限制：有一堵很高的墙，我跳不过去，于是被卡住了。这说明，在常识性改进和边界情况上，Harness 仍然可以继续完善应用。

查看日志后可以清楚地看出，评估器让实现始终与规格保持一致。在每个迭代周期中，它都会逐项检查验收约定里的测试标准，通过 Playwright 操作正在运行的应用，发现行为偏离预期时，就提交缺陷报告。验收约定非常细：仅第三个迭代周期，就包含了 27 项覆盖关卡编辑器的标准。评估器发现的问题也足够具体，无需额外调查就能动手处理。下表列出了一些例子。

要让评估器达到这种水平，需要投入调校。开箱即用的 Claude 并不是一个好的 QA Agent。在早期运行中，我看着它发现真实的问题，却又说服自己这些问题不算严重，最终批准了这项工作。它的测试还往往停留在表面，没有探查边界情况，因此一些更隐蔽的缺陷经常漏过。我的调校循环是：阅读评估器日志，找出它的判断与我的判断不一致的例子，再更新 QA 的提示以处理这些问题。经过好几轮这样的开发循环，评估器才开始以我认为合理的方式评分。

即便如此，Harness 的输出仍然体现了模型 QA 能力的限制：细小的布局问题、一些不符合直觉的交互，以及评估器没有充分测试的深层功能中尚未发现的缺陷。继续调校显然还能挖掘出更多验证能力。但与核心功能根本无法运行的单 Agent 版本相比，提升已经很明显。

迭代改进 Harness #

第一批 Harness 结果令人鼓舞，但这套系统也很笨重、缓慢且昂贵。下一步自然是寻找方法，在不降低效果的前提下简化 Harness。这既出于常识，也体现了一条更普遍的原则：Harness 中的每个组件，都隐含着一个关于「模型无法独立完成什么」的假设。这些假设值得重新检验，因为它们可能本来就是错的，也可能随着模型进步而迅速过时。我们的文章 Building Effective Agents 将这一理念表述为：「找到尽可能简单的解决方案，只在需要时增加复杂度。」任何维护 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 结果 #

为了测试更新后的 Harness，我使用下面的提示生成一个数字音频工作站（Digital Audio Workstation，DAW），也就是用于作曲、录音和混音的音乐制作程序：

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

这次运行依然漫长且昂贵，总体约花费四个小时，token 费用约为 124 美元。

大部分时间花在构建工作上。负责构建的 Agent 能够连贯地运行两个多小时，不再需要 Opus 4.5 所依赖的迭代周期拆分。

和此前的 Harness 一样，规划器把一句话提示扩展成了完整规格。从日志中可以看出，生成模型在规划应用和 Agent 的设计、把 Agent 接入应用，以及交给 QA 前自行测试方面，都做得不错。

即便如此，QA Agent 仍然发现了真实的不足。在第一轮反馈中，它指出：

这是一个不错的应用，设计还原度很高，AI Agent 扎实，后端也不错。主要不合格之处在于功能完整性：虽然应用看起来令人印象深刻，AI 集成也能正常工作，但几个核心 DAW 功能只有显示效果，缺少实质交互。片段无法在时间线上拖动或移动；没有乐器界面面板，例如合成器旋钮和鼓垫；也没有可视化效果编辑器，例如均衡器曲线和压缩器电平表。这些不是边界情况，而是让 DAW 真正可用的核心交互，规格也明确要求实现它们。

在第二轮反馈中，它再次发现了几个功能缺口：

仍然存在的不足：

• 音频录制仍然只是占位实现：按钮会切换状态，但没有采集麦克风音频。
• 尚未实现通过拖动边缘调整片段长度，也未实现片段切分。
• 效果器的可视化仍然只是数值滑块，没有图形显示，例如均衡器曲线。

如果任由生成器独立工作，它仍然容易遗漏细节，或用占位实现代替实际功能。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 帮助完善本文。

附录 #

以下是规划 Agent 生成的一份计划示例。

RetroForge：2D 复古游戏制作工具 #

概述 #

RetroForge 是一个基于 Web 的创作工作室，用于设计和构建 2D 复古风格电子游戏。它将经典 8 位和 16 位游戏美学的怀旧魅力，与现代、直观的编辑工具结合起来，让业余创作者和独立开发者都能够实现自己的游戏创意，而不必编写传统代码。

平台集成了四个创作模块：用于设计游戏世界的瓦片式关卡编辑器、用于制作视觉素材的像素画精灵编辑器、用于定义游戏逻辑的可视化实体行为系统，以及用于实时测试游戏的即时可玩测试模式。RetroForge 将由 Claude 驱动的 AI 辅助贯穿整个流程，加快创作过程，帮助用户通过自然语言交互生成精灵、设计关卡并配置行为。

RetroForge 面向喜爱复古游戏美学、同时又希望享受现代工具便利的创作者。无论是重现童年时期的平台跳跃游戏、角色扮演游戏或动作游戏，还是在复古风格的约束下创造全新体验，用户都可以快速制作原型、以可视化方式迭代，并与他人分享自己的作品。

功能 #

1. 项目面板与管理 #

项目面板是 RetroForge 中所有创作工作的起点。用户需要一种清晰、有序的方式来管理游戏项目：创建新项目、返回正在进行的项目，以及一眼了解每个项目包含什么。

用户故事：作为用户，我希望能够：

• 创建一个带有名称和描述的新游戏项目，以便开始设计游戏。
• 以可视化卡片的形式查看所有现有项目，卡片展示项目名称、最后修改日期和缩略预览图，以便快速找到并继续自己的工作。
• 打开任意项目，进入完整的游戏编辑器工作区，以便制作游戏。
• 删除不再需要的项目，并通过确认对话框避免误操作，以便保持工作区整洁。
• 复制现有项目，作为新游戏的起点，以便复用之前的工作。

项目数据模型：每个项目包含：

• 项目元数据：名称、描述、创建时间和修改时间。
• 画布设置：分辨率，例如 256 × 224、320 × 240 或 160 × 144。
• 瓦片尺寸配置：8 × 8、16 × 16 或 32 × 32 像素。
• 配色方案选择。
• 所有关联的精灵、瓦片集、关卡和实体定义。

……

译注 #

• Harness：围绕模型构建的运行与编排系统，包括任务规划、工具调用、上下文管理、状态交接和结果评估等机制。本文保留英文术语。
• Agent：保留英文；文中根据职责区分规划 Agent、生成 Agent 和评估 Agent。
• Sprint contract：译为「迭代验收约定」，指生成器与评估器在一个迭代周期开始前约定的交付内容和验收标准。
• DAW：Digital Audio Workstation，数字音频工作站。
• 原文的图片与视频请参阅原文页面。本文保留并翻译了所提供文本中的截图页签与图注；附录末尾的省略号也沿用所提供文本，没有补写未提供的内容。

原文著作权归原作者及 Anthropic 所有。本文为非官方中文译文；如需核对技术细节或措辞，请以原文为准。