过去几个月，我一直在研究两个相互关联的问题：让 Claude 生成高质量的 UI 设计，以及让它在无需人工干预的情况下构建完整应用程序。这项工作源于我们此前在 前端设计技能 和长时运行编码 Agent Harness 上的努力——通过提示工程和 Harness 设计，我的同事们成功将 Claude 的表现提升至远高于基线的水平，但两者最终都遇到了瓶颈。
为了突破瓶颈，我寻找了在两个截然不同的领域中均适用的新型 AI 工程方法：一个由主观审美定义，另一个由可验证的正确性和可用性定义。我从生成对抗网络（GAN）获得灵感，设计了一种包含 生成器（generator） 和评估器（evaluator） Agent 的多 Agent 结构。要构建一个能可靠地——并且有品味地——对输出进行评分的评估器，首先需要制定一套标准，将”这个设计好吗？“这类主观判断转化为具体、可评分的事项。
随后，我将这些技术应用于长时运行的自主编码，延续了早期 Harness 工作的两个经验：将构建过程分解为可处理的块，以及使用结构化产物在会话之间传递上下文。最终的成果是一个三 Agent 架构——规划器（planner）、生成器（generator）和评估器（evaluator）——在数小时的自主编码会话中生产出丰富的全栈应用程序。
为什么朴素实现不够用
我们已经在前文中展示了 Harness 设计对长时运行 Agent 编码效果的重大影响。在之前的实验中，我们使用一个初始化 Agent 将产品规格分解为任务列表，再由一个编码 Agent 一次实现一个特性，然后将产物交接给下一个会话以保持上下文。更广泛的开发者社区也得出了类似的见解，“Ralph Wiggum” 等方法使用钩子或脚本让 Agent 保持持续迭代循环。
但一些问题仍然持续存在。对于更复杂的任务，Agent 仍然会随着时间推移逐渐偏离轨道。在分析这个问题时，我们观察到执行此类任务的 Agent 有两种常见的失败模式。
第一个问题是，随着上下文窗口填满，模型在长时间任务中容易失去连贯性（参见我们关于上下文工程 的文章）。一些模型还表现出”上下文焦虑”，即它们在接近自认为的上下文限制时就开始过早收尾工作。上下文重置——完全清空上下文窗口并启动一个全新的 Agent，结合结构化交接来携带前一个 Agent 的状态和后续步骤——可以解决这两个问题。
这与压缩（compaction）不同，后者是在原处将对话的早期部分总结出来，让同一个 Agent 可以在缩短的历史中继续工作。压缩保留了连续性，但没有给 Agent 一个干净的起点，这意味着上下文焦虑可能仍然存在。重置提供了一个干净的起点，代价是交接产物必须包含足够的上下文以供下一个 Agent 顺利接手。在我们早期的测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑倾向非常强烈，仅靠压缩不足以实现强大的长任务表现，因此上下文重置成为 Harness 设计中不可或缺的组成部分。这解决了核心问题，但也增加了每个 Harness 运行时的编排复杂度、Token 开销和延迟。
第二个问题是我们之前未曾解决的，即自我评估。当被要求评估自己生成的工作时，Agent 往往自信地赞美这些工作——而对于人类观察者来说，质量显然平庸至极。这个问题在设计等主观任务中尤为突出，因为那里没有可验证的软件测试那样的二元检查。一个布局是精致还是普通是一种主观判断，而 Agent 在给自己的工作评分时总是偏向积极。
然而，即使在确实有可验证结果的任务中，Agent 在完成任务时仍然有时会表现出判断失误，从而阻碍任务完成。将执行工作的 Agent 与评判工作的 Agent 分离开来，被证明是解决这个问题的有力杠杆。这种分离本身并不会立即消除宽松倾向——评估器仍然是一个 LLM，它对 LLM 生成的输出倾向于宽厚。但调整一个独立的评估器使其保持怀疑态度，比让生成器批判自己的作品要容易得多，而且一旦外部反馈存在，生成器就有了具体的东西可以迭代改进。
前端设计：将主观质量转化为可评分项
我从前端设计开始实验，那里自我评估问题最为明显。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局——技术上功能正常，但视觉上毫无特色。
两个见解塑造了我为前端设计构建的 Harness。首先，虽然美学不能完全归结为一个分数——而且个人品味总是存在差异——但可以通过编码设计原则和偏好的评分标准来改进。“这个设计美吗？“这个问题很难一致地回答，但”这符合我们对优秀设计的原则吗？“给了 Claude 一个可以具体评分的目标。其次，通过将前端生成与前端评分分离，我们可以创建一个反馈循环，推动生成器产出更强的输出。
基于这些认识，我编写了四个评分标准，并将它们同时给了生成器和评估器 Agent：
- 设计质量（Design quality）： 设计是否感觉是一个连贯的整体而不是零件的集合？在这项上表现强劲意味着颜色、排版、布局、图像和其他细节结合在一起，创造出一种独特的氛围和身份认同。
- 原创性（Originality）： 是否有证据表明做出了自定义决策，还是只是在用模板布局、库默认值和 AI 生成的模式？人类设计师应该能够识别出刻意的创意选择。未修改的库存组件——或者 AI 生成的明显迹象，如白色卡片上的紫色渐变——在这项上不合格。
- 工艺（Craft）： 技术执行：排版层次、间距一致性、色彩和谐度、对比度。这是能力检查而非创造力检查。大多数合理的实现默认在这方面表现良好；失败意味着基础薄弱。
- 功能性（Functionality）： 独立于美学之外的可用性。用户能否理解界面的功能，找到主要操作，并在不猜测的情况下完成任务？
我强调设计质量和原创性，而不是工艺和功能性。Claude 默认情况下在工艺和功能性上已经得分很高，因为所需的技术能力对模型来说往往是自然而然的。但在设计和原创性方面，Claude 的输出往往最多只是平淡无奇。这些标准明确惩罚了高度通用的”AI 垃圾”模式，通过更侧重设计和原创性，推动模型在美学上承担更多风险。
我使用 few-shot 示例配合详细的分数分解来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了跨迭代的分数漂移。
我在 Claude Agent SDK 上构建了这个循环，使编排保持简单直接。生成器 Agent 首先根据用户提示创建一个 HTML/CSS/JS 前端。我为评估器提供了 Playwright MCP，使其能够直接与运行中的页面交互，然后再对每个标准进行评分并写出详细的评论。实际上，评估器会自行导航页面，截图并仔细研究实现，然后才给出评估意见。这份反馈作为下一个迭代的输入流回给生成器。每个生成任务运行 5 到 15 次迭代，每次迭代通常会推动生成器在回应评估器的评论时朝着更有特色的方向发展。由于评估器在积极导航页面而不是对静态截图评分，每个周期都消耗了真实的挂钟时间。完整运行可能长达四个小时。我还指示生成器在每次评估后做出战略性决策：如果分数趋势良好就完善当前方向，或者如果方法不奏效就完全转向不同的美学风格。
在多次运行中，评估器的评估在迭代中有所改善，然后趋于平稳，但仍有提升空间。有些生成是渐进完善的，有些则在迭代之间出现了急剧的美学转向。
这些标准的措辞以一种我未曾完全预料的方式引导了生成器。包含”最好的设计是博物馆级的”这样的短语，将设计推向了一种特定的视觉收敛，表明与标准相关的提示直接塑造了输出的特征。
虽然分数在迭代中总体上有所改善，但模式并非总是干净的线性关系。后来的实现整体上往往更好，但我经常看到我更喜欢中间某个迭代而非最后一个的情况。实现的复杂性也倾向于在轮次中增加，因为生成器在评估器的反馈推动下寻求更具雄心的解决方案。即使在第一次迭代时，输出也明显优于没有任何提示的基线，这表明在评估器反馈带来进一步改进之前，标准及其相关语言本身就引导模型远离了通用默认值。
在一个值得注意的例子中，我让模型为一家荷兰艺术博物馆创建一个网站。到第九次迭代时，它已经为一家虚构的博物馆制作了一个简洁的深色主题着陆页。这个页面视觉上精致，但大体上符合我的预期。然后，在第十个周期，它完全放弃了这种方法，将网站重新想象为一个空间体验：一个用 CSS perspective 渲染的带棋盘格地板的 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 端点和数据库状态。然后它根据发现的 bug 和一套以我们前端实验为模型的标准——针对产品深度、功能性、视觉设计和代码质量进行了调整——对每个冲刺进行评分。每个标准都有一个硬性阈值，如果任何一个低于该阈值，冲刺就失败，生成器会收到关于哪里出了问题的详细反馈。
在每个冲刺之前，生成器和评估器会协商一个冲刺合同：在写任何代码之前，就该工作块的”完成”标准达成一致。这是因为产品规格是有意的高层级的，我需要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提出它将要构建什么以及如何验证成功，评估器审查该提案以确保生成器正在构建正确的东西。两者迭代直到达成一致。
通信通过文件处理：一个 Agent 写一个文件，另一个 Agent 读取它并在该文件内或新文件中回复，然后前一个 Agent 再读取。生成器随后根据商定的合同进行构建，然后再将工作交接给 QA。这保持了工作对规格的忠实性，而不会在过早阶段过度指定实现。
运行 Harness
在这个 Harness 的第一个版本中，我使用了 Claude Opus 4.5，将用户提示分别针对完整 Harness 和单 Agent 系统进行运行以作比较。我使用 Opus 4.5 是因为这是我在开始这些实验时我们最好的编码模型。
我写了以下提示来生成一个复古视频游戏制作工具：
创建一个包含关卡编辑器、精灵编辑器、实体行为和可玩测试模式的 2D 复古游戏制作工具。
下表显示了 Harness 类型、运行时长和总成本。
| Harness | 时长 | 成本 |
|---|---|---|
| Solo | 20 分钟 | $9 |
| 完整 Harness | 6 小时 | $200 |
Harness 贵了 20 多倍，但输出质量的差异立竿见影。
我期望的是一个界面，可以构建关卡及其组件部分（精灵、实体、瓦片布局），然后点击播放来实际游玩这个关卡。我首先打开了 Solo 运行的输出，初始应用程序似乎符合这些预期。
然而，当我点击浏览时，问题开始出现。布局浪费空间，固定高度的面板让视口大部分都是空的。工作流程很死板。试图填充一个关卡会提示我先创建精灵和实体，但 UI 中没有任何东西引导我遵循这个顺序。更重要的是，实际的游戏坏了。我的实体出现在屏幕上但没有任何东西对输入做出反应。深入代码后发现，实体定义和游戏运行时之间的连接断了，而且没有任何表面迹象表明问题出在哪里。
Solo Harness 创建的应用程序打开时的初始屏幕。
Solo Harness 的精灵编辑器中创建精灵
尝试游玩我创建的关卡但未成功
在评估了 Solo 运行后，我将注意力转向了 Harness 运行。这次运行从相同的单句提示开始，但规划器步骤将该提示扩展为一个包含 16 个特性、分布在十个冲刺中的规格。它远远超出了 Solo 运行的尝试范围。除了核心编辑器和播放模式外，规格还要求精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计师，以及带有可分享链接的游戏导出功能。我给了规划器访问我们 前端设计技能 的权限，它读取并使用它来创建应用程序的视觉设计语言作为规格的一部分。对于每个冲刺，生成器和评估器协商了一份合同，定义了该冲刺的具体实现细节以及将用于验证完成的可测试行为。
该应用程序立即显示出比 Solo 运行更多的精致感和流畅性。画布使用了整个视口，面板尺寸合理，界面具有符合规格中设计方向的一致视觉标识。Solo 运行中我看到的一些笨拙确实仍然存在——工作流程仍然没有明确说明你应该先构建精灵和实体，然后再尝试填充关卡，我不得不通过摸索来弄清楚这一点。这被读作基础模型产品直觉的一个差距，而不是 Harness 设计要解决的东西，尽管它确实表明了一个地方，在 Harness 内进行有针对性的迭代可以进一步提高输出质量。
在浏览编辑器时，新运行相对于 Solo 的优势变得更加明显。精灵编辑器更丰富、功能更齐全，工具面板更干净，颜色选择器更好用，缩放控制更可用。
因为我要求规划器将 AI 功能编织到其规格中，应用程序还带有一个内置的 Claude 集成，让我可以通过提示生成游戏的不同部分。这大大加快了工作流程。
初始屏幕：在完整 Harness 构建的应用程序中创建新游戏
精灵编辑器感觉更干净、更易用
使用内置 AI 功能生成关卡
使用内置 AI 功能生成关卡
游玩我生成的游戏的截图
最大的区别在于播放模式。我实际上能够移动我的实体并玩游戏了。物理有一些粗糙的地方——我的角色跳上了一个平台但最终与它重叠了，这感觉上直观地错误——但核心功能是可以运行的，而 Solo 运行没能做到。在四处移动之后，我确实遇到了 AI 游戏关卡构建的一些限制。有一面我无法跳过去的大墙，所以我被卡住了。这表明有一些常识性的改进和边缘情况是 Harness 可以处理以进一步改进应用程序的。
阅读日志，很明显评估器保持了实现与规格的一致性。每个冲刺，它都会按照冲刺合同中的测试标准进行演练，并通过 Playwright 行使运行中的应用程序，对任何偏离预期行为的情况提交 bug。合同是细粒度的——仅 Sprint 3 就有 27 个涵盖关卡编辑器的标准——评估器的发现足够具体，可以直接采取行动而无需额外调查。下表显示了我们评估器识别的几个问题示例：
| 合同标准 | 评估器发现 |
|---|---|
| 矩形填充工具允许点击拖动用所选瓦片填充矩形区域 | FAIL — 工具只在拖动开始/结束点放置瓦片，而不是填充区域。fillRectangle 函数存在但没有在 mouseUp 上正确触发。 |
| 用户可以选择并删除已放置的实体生成点 | FAIL — 删除键处理程序在 LevelEditor.tsx:892 要求同时设置 selection 和 selectedEntityId，但点击一个实体只设置 selectedEntityId。条件应该是 selection || (selectedEntityId && activeLayer === 'entity')。 |
| 用户可以通过 API 重新排序动画帧 | FAIL — PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 ‘reorder’ 匹配为 frame_id 整数并返回 422：“无法将字符串解析为整数”。 |
让评估器达到这个表现水平需要工作。开箱即用，Claude 是一个糟糕的 QA Agent。在早期运行中，我看到它识别出合法的问题，然后说服自己这些问题没什么大不了，并批准了工作。它也倾向于表面化测试，而不是深入边缘案例，因此更微妙的 bug 经常被遗漏。调优循环是阅读评估器的日志，找到其判断与我的判断不同的地方，并更新 QA 的提示以解决这些问题。经过几轮这种开发循环后，评估器的评分方式才变得合理。即便如此，Harness 的输出显示了模型 QA 能力的局限性：小布局问题、某些地方感觉不直观的交互，以及评估器没有彻底测试的更深层功能中未被发现的 bug。显然还有更多的验证空间可以通过进一步调优来获取。但与 Solo 运行相比——应用程序的核心功能根本无法工作——提升是明显的。
迭代 Harness
第一批 Harness 结果令人鼓舞，但它也很笨重、缓慢且昂贵。合理的下一步是在不降低性能的情况下找到简化 Harness 的方法。这部分出于常识，部分出于一个更普遍的原则：Harness 中的每个组件都编码了一个关于模型自身无法做到什么的假设，这些假设值得进行压力测试，因为它们可能是错误的，而且会随着模型改进而迅速过时。我们关于构建有效 Agent 的博客文章将基本思想表述为”找到最简单的解决方案，只有在需要时才增加复杂性”，这是任何维护 Agent Harness 的人都会持续看到的模式。
在第一次简化尝试中，我大幅削减了 Harness 并尝试了一些创意新想法，但无法复制原始性能。这也使得很难判断 Harness 设计的哪些部分是真正起作用的，以及以什么方式。基于这些经验，我转向了一种更有条理的方法，一次移除一个组件并审查它对最终结果的影响。
在我进行这些迭代周期时，我们还发布了 Opus 4.6，这为减少 Harness 复杂性提供了进一步的动力。有充分的理由预期 4.6 会比 4.5 需要更少的脚手架。从我们的发布博客：”\（Opus 4.6）\更仔细地规划，在更长时间内维持 Agent 任务，在更大的代码库中更可靠地运行，并有更好的代码审查和调试技能来 catch 自己的 mistakes。“它还在长期上下文检索方面有了实质性改进。这些都是 Harness 构建来补充的所有能力。
移除 Sprint 构造
我首先完全移除了 Sprint 构造。Sprint 结构有助于将工作分解为块，让模型能够连贯地工作。鉴于 Opus 4.6 的改进，有充分的理由相信模型可以本机处理这项工作，而不需要这种分解。
我保留了规划器和评估器，因为两者继续提供明显的价值。没有规划器，生成器会低估范围：给定原始提示，它会在首先规格化工作之前就开始构建，最终创建一个不如规划器所做的那样功能丰富的应用程序。
随着 Sprint 构造的移除，我将评估器移到了运行结束时的一次性通过，而不是每个 Sprint 都进行评分。由于模型能力更强，它改变了评估器在某些运行中的关键程度，其有用性取决于任务相对于模型自身可靠能做到的边界在哪里。在 4.5 上，这个边界很接近：我们的构建处于生成器单独良好运行的边缘，评估器在整个构建过程中发现了有意义的问题。在 4.6 上，模型的原始能力增加了，所以边界向外移动。曾经需要评估器检查才能连贯实现的任务，现在通常是生成器自身可以处理的，对于这些边界内的任务，评估器变成了不必要的开销。但对于构建中仍然处于生成器能力边缘的部分，评估器继续提供真正的提升。
实际含义是，评估器不是一个固定的二元决策。当任务超出当前模型可靠单独完成的能力时，它才值得付出成本。
除了结构简化，我还添加了提示以改进 Harness 如何在每个应用程序中构建 AI 功能，特别是让生成器构建一个可以通过工具驱动应用程序自身功能的适当 Agent。这需要真正的迭代，因为相关知识足够新，Claude 的训练数据覆盖得很稀疏。但经过足够的调优，生成器能够正确地构建 Agent。
更新后 Harness 的结果
为了测试更新后的 Harness，我使用以下提示生成了一个数字音频工作站（DAW），这是一个用于作曲、录制和混音的音乐制作程序：
使用 Web Audio API 在浏览器中构建一个功能完整的 DAW。
这次运行仍然漫长且昂贵，大约 4 小时，Token 成本 $124。
大部分时间花在了构建器上，它连贯地运行了两个多小时，而不需要 Opus 4.5 所需的 Sprint 分解。
| Agent 和阶段 | 时长 | 成本 |
| Planner | 4.7 分钟 | $0.46 |
| Build（第一轮） | 2 小时 7 分钟 | $71.08 |
| QA（第一轮） | 8.8 分钟 | $3.24 |
| Build（第二轮） | 1 小时 2 分钟 | $36.89 |
| QA（第二轮） | 6.8 分钟 | $3.09 |
| Build（第三轮） | 10.9 分钟 | $5.88 |
| QA（第三轮） | 9.6 分钟 | $4.06 |
| V2 Harness 总计 | 3 小时 50 分钟 | $124.70 |
与之前的 Harness 一样，规划器将一行提示扩展为完整规格。从日志中，我可以看到生成器模型在规划应用程序和 Agent 设计、连接 Agent 以及在交接给 QA 之前进行测试方面做得很好。
也就是说，QA Agent 仍然发现了真正的差距。在第一轮反馈中，它指出：
这是一个强大的应用程序，具有出色的设计保真度、扎实的 AI Agent 和良好的后端。主要失败点是功能完整性——虽然应用程序看起来令人印象深刻，AI 集成也运行良好，但几个核心 DAW 功能只是展示性的，缺乏交互深度：音频块在时间线上无法拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化效果编辑器（EQ 曲线、压缩器电平）。这些不是边缘情况——它们是使 DAW 可用的核心交互，而规格中明确要求了它们。
在第二轮反馈中，它再次发现了几个功能差距：
剩余差距：
- 音频录制仍然是桩（stub-only）（按钮切换但没有麦克风捕获）
- 音频块边缘拖动调整大小和音频块分割未实现
- 效果可视化是数字滑块，而不是图形化的（没有 EQ 曲线）
生成器仍然容易遗漏细节或在独自一人时将功能做成桩，QA 仍然在 catch 生成器需要修复的最后一英里问题上发挥了价值。
根据提示，我期望一个程序，我可以创建旋律、和声和鼓点，将它们编排成一首歌，并在整个过程中获得集成 Agent 的帮助。下面的视频显示了结果。
这个应用程序远非专业的音乐制作程序，而且 Agent 的歌曲创作技能显然还需要大量工作。此外，Claude 实际上无法听到声音，这使得 QA 反馈循环在音乐品味方面效果较差。
但最终应用程序具有功能完整的音乐制作程序的所有核心部分：一个工作的编排视图、混音器和传输在浏览器中运行。除此之外，我完全通过提示组合了一段简短的歌曲片段：Agent 设置了 tempo 和调性，铺设了旋律，构建了鼓轨，调整了混音器电平，并添加了混响。歌曲创作的核心原语都存在，Agent 可以自主驱动它们，使用工具从头到尾创建一个简单的作品。你可能会说它还不完美——但它正在进步。
接下来是什么
随着模型继续改进，我们可以大致预期它们能够工作更长时间，处理更复杂的任务。在某些情况下，这意味着围绕模型的脚手架会随着时间推移变得不那么重要，开发者可以等待下一个模型，看看某些问题自行解决。另一方面，模型越好，就有越大的空间开发能够实现超出模型基线能力的复杂任务的 Harness。
考虑到这一点，这项工作中有一些经验值得延续。在你构建的模型上进行实验、阅读其在现实问题上的 traces 并调整其性能以达到你期望的结果，这始终是最佳实践。在处理更复杂的任务时，有时有空间通过分解任务并将专门的 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 是一个基于网络的创意工作室，用于设计和构建 2D 复古风格视频游戏。它将经典 8 位和 16 位游戏美学的怀旧魅力与现代直观的编辑工具相结合——使从业余创作者到独立开发者的任何人都能在不编写传统代码的情况下将游戏创意变为现实。
该平台提供四个集成的创意模块：一个用于设计游戏世界的基于瓦片的关卡编辑器（Level Editor）、一个用于制作视觉资产的像素艺术精灵编辑器（Sprite Editor）、一个用于定义游戏逻辑的可视化实体行为系统（Entity Behavior），以及一个用于实时游戏测试的即时可玩测试模式（Playable Test Mode）。通过在整个过程中编织 AI 辅助（由 Claude 提供支持），RetroForge 加速了创作过程——帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。
RetroForge 面向喜爱复古游戏美学但希望获得现代便利的创作者。无论是在复古约束下重新创建他们童年的平台游戏、RPG 或动作游戏，还是发明全新的体验，用户都可以快速原型设计、可视化迭代并与他人分享他们的创作。
功能
1. 项目仪表板与管理
项目仪表板是 RetroForge 中所有创意工作的基地。用户需要一个清晰、有条理的方式来管理他们的游戏项目——创建新项目、返回进行中的工作，以及一目了然地了解每个项目包含的内容。
用户故事：作为用户，我想要：
- 创建一个带有名称和描述的新游戏项目，以便开始设计我的游戏
- 看到我所有现有项目显示为视觉卡片，显示项目名称、上次修改日期和缩略图预览，以便我可以快速找到并继续我的工作
- 打开任何项目进入完整的游戏编辑器工作区，以便我可以处理我的游戏
- 删除我不再需要的项目，并带有确认对话框以防止意外，以便我可以保持我的工作区有序
- 复制现有项目作为新游戏的起点，以便我可以重用我以前的工作
项目数据模型：每个项目包含：
项目元数据（名称、描述、创建/修改时间戳）
画布设置（分辨率：如 256x224、320x240 或 160x144）
瓦片大小配置（8x8、16x16 或 32x32 像素）
调色板选择
所有关联的精灵、瓦片集、关卡和实体定义
...