由 Prithvi Rajasekaran 撰写，他是我们 实验室 团队的一员。
在过去的几个月里，我一直在研究两个相互关联的问题：让 Claude 产生高质量的前端设计，以及让它无需人工干预就能构建完整的应用程序。这项工作源于我们之前对 前端设计技能（frontend design skill） 和 长时间运行的编码代理工具（long-running coding agent harness） 的努力，在那里我和我的同事们能够通过提示工程和工具设计将 Claude 的性能显著提升到基线水平以上——但两者最终都遇到了瓶颈。
为了实现突破，我寻求了能够在两个截然不同的领域都适用的创新人工智能工程方法，一个领域由主观品味定义，另一个领域由可验证的正确性和可用性定义。我从 生成对抗网络（Generative Adversarial Networks） (GANs) 中获得灵感，设计了一个包含 生成器（generator） 和 评估器（evaluator） 的多智能体结构。构建一个能够可靠地评估输出并具有品味的评估器，首先需要开发一套标准，能够将"这个设计好吗？"等主观判断转化为具体可评分的术语。
随后，我将这些技术应用于长期运行的自主编程（autonomous coding），从我们早期的工作中借鉴了两个经验教训：将构建分解为可管理的模块，并使用结构化工件（structured artifacts）在会话之间传递上下文。最终结果是一个三智能体架构（three-agent architecture）——规划器（planner）、生成器（generator）和评估器（evaluator）——能够在数小时的自主编程会话中生成丰富的全栈应用程序（full-stack applications）。
为什么简单的实现会不足
我们之前已经证明，harness设计（harness design）对长时间运行的agentic coding的有效性有重大影响。在早期的实验中，我们使用了一个initializer agent（初始化代理）将产品规格分解为任务列表，以及一个coding agent（编码代理）一次实现一个任务，然后在会话之间移交artifacts（工件）以保持上下文。更广泛的开发者社区已经达成了类似的见解，采用了类似"Ralph Wiggum"的方法，使用hooks（钩子）或scripts（脚本）来保持代理在连续的迭代周期中。
但一些问题仍然存在。对于更复杂的任务，代理（agent）仍然倾向于随着时间的推移而偏离轨道。在分解这个问题时，我们观察到代理在执行这类任务时存在两种常见的失败模式。
首先是模型在上下文窗口填满时，在长时间任务上往往会失去连贯性（请参阅我们关于上下文工程（context engineering）的文章）。一些模型还会表现出"上下文焦虑（context anxiety）"，即当接近它们认为的上下文限制时，它们会过早地结束工作。上下文重置——完全清除上下文窗口并启动一个新的智能体，结合一个结构化的交接，传递前一个智能体的状态和下一步骤——可以解决这两个问题。
这与压缩（compaction）不同，在压缩中，对话的早期部分会被就地总结，以便同一个代理可以在缩短的历史记录中继续进行。虽然压缩保持了连续性，但它没有给代理一个干净的起点，这意味着上下文焦虑（context anxiety）仍然可能存在。重置提供了一个干净的起点，但代价是交接工件（handoff artifact）需要有足够的状态，以便下一个代理能够干净地接手工作。在我们早期的测试中，我们发现Claude Sonnet 4.5表现出的上下文焦虑足够强烈，以至于仅靠压缩不足以实现强大的长期任务性能，因此上下文重置成为了工具（harness）设计中的必要部分。这解决了核心问题，但为每次工具运行增加了编排复杂性、令牌开销和延迟。
我们尚未解决的第二个问题是自我评估。当被要求评估自己完成的工作时，智能体往往会自信地赞扬这些工作——即使对人类观察者来说，质量明显平庸。这个问题在主观性任务（如设计）中尤为突出，因为这类任务没有类似于可验证软件测试的二进制检查。布局是显得精致还是普通，这是一个主观判断，而智能体在评估自己的工作时，总是倾向于给出积极的评价。
然而，即使在那些具有可验证结果的任务中，代理（agents）有时仍会表现出糟糕的判断力，这阻碍了它们在完成任务时的表现。将执行工作的代理与评估它的代理分离开来，被证明是解决此问题的有力杠杆。这种分离本身并不会立即消除那种宽松态度；评估者仍然是一个大语言模型（LLM），倾向于对大语言模型生成的输出慷慨大方。但调整独立的评估者使其保持怀疑态度，结果证明比让生成者对自己的作品持批判态度要容易得多，而且一旦存在这种外部反馈，生成者就有具体的东西可以迭代改进。
前端设计：使主观质量可评估
我从前端设计开始实验，因为自我评估问题在这里最为明显。在没有干预的情况下，Claude 通常倾向于选择安全、可预测的布局，这些布局在技术上是功能性的，但在视觉上并不突出。
两个见解塑造了我为前端设计构建的框架。首先，虽然美学（aesthetics）无法完全简化为一个分数，并且个人品味总是各不相同，但可以通过编码设计原则和偏好的评分标准来改进美学。"这个设计漂亮吗？"很难一致地回答，但"这个设计是否符合我们良好的设计原则？"为Claude提供了具体的评分依据。其次，通过将前端生成（frontend generation）与前端评分（frontend grading）分离，我们可以创建一个反馈循环，推动生成器产生更强的输出。
基于这一点，我编写了四个评分标准，我将它们提供给生成器（generator）和评估器（evaluator）代理的提示中：
- 设计质量： 设计是否感觉像一个连贯的整体，而不是零件的集合？在这方面表现出色意味着颜色、字体、排版、图像和其他细节结合在一起，创造出独特的氛围和身份。
- 原创性： 是否有自定义决策的证据，还是这只是模板布局、库默认设置和AI生成的模式？人类设计师应该能够识别出有创意的刻意选择。未经修改的库存组件——或AI生成的明显迹象，比如白色卡片上的紫色渐变——在这里无法通过。
- 工艺: 技术执行：排版层次（typography hierarchy）、间距一致性（spacing consistency）、色彩和谐（color harmony）、对比度（contrast ratios）。这是能力测试而非创意测试。大多数合理的实现默认表现良好；失败意味着基础不牢固。
- 功能性: 独立于美学的可用性（Usability）。用户能否理解界面的功能，找到主要操作，并在不猜测的情况下完成任务？
我强调设计质量和原创性胜过工艺和功能性。Claude 在工艺和功能性方面已经默认表现良好，因为所需的技术能力往往自然而然地体现在模型中。但在设计和原创性方面，Claude 产生的输出最多只能说是平淡无奇。评判标准明确惩罚高度通用的"AI垃圾"模式，通过更加强调设计和原创性，它推动模型进行更多美学上的冒险。
我使用带有详细分数细分的少样本示例来校准评估器。这确保了评估器的判断与我的偏好保持一致，并减少了跨迭代过程中的分数漂移。
我在 Claude Agent SDK（Claude Agent SDK）上构建了这个循环，这使编排变得简单直接。一个生成器代理首先根据用户提示创建了一个 HTML/CSS/JS 前端。我给评估器提供了 Playwright MCP（Playwright MCP），使其能够在对每个标准评分并撰写详细批评之前直接与实时页面交互。实际上，评估器会自行浏览页面，截图并仔细研究实现，然后才做出评估。这些反馈流回生成器，作为下一次迭代的输入。每次生成我运行了 5 到 15 次迭代，每次迭代通常都会推动生成器朝着更独特的方向发展，因为它会响应评估器的批评。由于评估器是主动浏览页面而不是对静态截图进行评分，每个周期都需要真实的挂钟时间。完整的运行时间长达四小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好，则改进当前方向；如果方法不奏效，则转向完全不同的美学风格。
在多次运行中，评估者的评估随着迭代而改善，最终趋于稳定，但仍有余地。有些生成结果是逐步优化的。其他则在迭代之间发生了急剧的美学转变。
标准的措辞以我未曾完全预料的方式引导了生成器。包含"最佳设计应达到博物馆品质"等短语，推动设计朝向特定的视觉收敛，这表明与标准相关的提示直接塑造了输出的特性。
虽然分数通常在迭代（iterations）过程中有所提高，但模式并不总是完全线性的。后来的实现（implementations）整体上往往更好，但我经常看到我更喜欢中间迭代而不是最后一次迭代的情况。实现复杂度也倾向于在各轮次中增加，生成器（generator）根据评估器（evaluator）的反馈寻求更雄心勃勃的解决方案。即使在第一次迭代中，输出也比完全没有提示的基线（baseline）明显更好，这表明标准和相关语言本身在评估器反馈导致进一步优化之前，就将模型引导远离了通用默认值。
在一个显著的例子中，我提示模型为荷兰艺术博物馆创建一个网站。到第九次迭代时，它已经为虚构的博物馆制作了一个干净、深色主题的着陆页。这个页面在视觉上很精致，但基本符合我的预期。然后，在第十个周期，它完全放弃了这种方法，重新将网站构想为一种空间体验：一个具有棋盘地板的3D房间，使用CSS透视渲染，艺术品以自由形式悬挂在墙上，以及基于门廊的画廊房间导航，而不是滚动或点击。这是我从未见过的单次生成中的那种创造性飞跃。
扩展到全栈编码
基于这些发现，我将这种受GAN（生成对抗网络）启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期中，代码审查和QA（质量保证）发挥着与设计评估器相同的作用。
架构
在我们早期的长时间运行的测试工具（long-running harness），我们已经解决了多会话编程的连贯性问题，通过一个初始化代理、一个一次处理一个功能的编程代理，以及会话之间的上下文重置。上下文重置是一个关键突破：该测试工具使用了 Sonnet 4.5，它表现出前面提到的"上下文焦虑"倾向。创建一个能够在上下文重置之间良好运行的测试工具对于保持模型专注于任务至关重要。Opus 4.5 大大地自行消除了这种行为，因此我能够完全从此测试工具中移除上下文重置。代理在整个构建过程中作为一个连续会话运行，使用Claude Agent SDK（Claude Agent SDK）的自动压缩处理来处理过程中的上下文增长。
在这项工作中，我在原始工具的基础上构建了一个三智能体系统，每个智能体都针对我在先前运行中观察到的一个特定差距。该系统包含以下智能体角色：
规划器: 我们之前的长期运行工具（harness）要求用户提前提供详细规格（spec）。我希望自动化这一步骤，因此我创建了一个规划器（planner）代理（agent），它接收一个简单的1-4句话的提示，并将其扩展为完整的产品规格（spec）。我提示它在范围上要雄心勃勃，并专注于产品上下文和高层级技术设计，而不是详细的技术实现。这种强调的原因是，如果规划器（planner）试图提前指定细粒度的技术细节并出现错误，规格（spec）中的错误会级联到下游实现中。约束代理（agent）需要交付的成果，让他们在工作过程中找出路径，这似乎更明智。我还要求规划器（planner）寻找将AI功能融入产品规格（spec）的机会。（请参阅底部的附录中的示例。）
生成器： 早期测试工具中一次只处理一个功能的方法在范围管理方面效果良好。我在这里应用了类似的模型，指示生成器以冲刺（sprints）方式工作，从规范中一次选择一个功能。每个冲刺都使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）堆栈实现应用程序，并且指示生成器在每个冲刺结束时自行评估其工作，然后移交给 QA（质量保证）。它还使用 git 进行版本控制。
评估者：早期测试框架中的应用程序通常看起来令人印象深刻，但当您实际尝试使用它们时仍然存在真实的错误。为了捕捉这些错误，评估者使用Playwright MCP以用户的方式点击运行中的应用程序，测试UI功能、API端点和数据库状态。然后，评估者根据发现的错误和一组基于前端实验的标准对每个冲刺进行评分，这些标准在此处调整为涵盖产品深度、功能、视觉设计和代码质量。每个标准都有一个硬性阈值，如果任何一项低于该阈值，冲刺就会失败，生成器会收到关于出了什么问题的详细反馈。
在每个冲刺（sprint）之前，生成器（generator）和评估器（evaluator）会协商一个冲刺合同：在编写任何代码之前，就确定那一部分工作的"完成"标准是什么。之所以这样做，是因为产品规格（product spec）是有意保持在高层次上的，而我希望有一个步骤来弥合用户故事（user stories）和可测试实现之间的差距。生成器提出要构建的内容以及如何验证成功，评估者则审查该提案，确保生成器正在构建正确的东西。双方反复协商直到达成一致。
通信通过文件处理：一个代理会写入一个文件，另一个代理会读取它并响应，要么在该文件内响应，要么创建一个新文件，前一个代理会依次读取。然后生成器根据约定的契约进行构建，然后将工作移交给QA。这确保了工作符合规范，而不会过早地过度指定实现细节。
运行测试框架
对于这个测试框架的第一个版本，我使用了Claude Opus 4.5，对完整测试框架和单代理系统运行用户提示以进行比较。我使用Opus 4.5，因为当我开始这些实验时，这是我们的最佳编码模型。
我编写了以下提示词来生成复古视频游戏制作器：
创建一个2D复古游戏制作器，包含关卡编辑器、精灵编辑器、实体行为和可玩的测试模式。
下表显示了测试工具的类型、运行时长和总成本。
测试工具时长成本单人20 分钟$9完整测试工具6 小时$200
测试工具（harness）的价格超过其他选项的20倍，但输出质量的差异是显而易见的。
我期望有一个界面，可以在其中构建关卡及其组成部分（精灵（sprites）、实体（entities）、瓦片布局（tile layout）），然后点击播放来实际游玩关卡。我首先打开了单人运行的结果，初始应用程序似乎符合这些期望。
然而，当我继续点击浏览时，问题开始显现。布局浪费了空间，固定高度的「面板（panel）」使「视口（viewport）」大部分区域保持空白。工作流程非常僵化。尝试填充一个级别时，系统提示我先创建「精灵（sprite）」和「实体（entity）」，但「用户界面（UI）」没有任何引导我遵循这个顺序。更重要的是，实际的游戏已经损坏。我的实体出现在屏幕上，但没有任何响应输入。深入代码后发现，「实体（entity）」定义和游戏「运行时（runtime）」之间的连接已经断开，表面上没有任何迹象表明问题出在哪里。
在评估了单人运行后，我将注意力转向了集成运行。这次运行始于相同的一句话提示，但规划步骤将这个提示扩展成了一个包含16项功能、分布在十个冲刺中的规范。它远远超出了单人运行所尝试的范围。除了核心编辑器和游戏模式外，该规范还要求实现精灵动画系统、行为模板、音效和音乐、AI辅助的精灵生成器和关卡设计器，以及带有可分享链接的游戏导出功能。我让规划器访问了我们的 前端设计技能，它阅读并使用该技能创建了应用的视觉设计语言作为规范的一部分。对于每个冲刺，生成器和评估器会协商一份合同，定义该冲刺的具体实现细节以及将被测试以验证完成度的可测试行为。
应用程序立即展现出比单独运行时更好的精致度和流畅性。画布使用了完整的视口（viewport），面板尺寸合理，界面具有一致的视觉标识（visual identity），遵循了规范（spec）中的设计方向。单独运行时我看到的一些笨拙感（clunkiness）仍然存在—工作流程（workflow）仍然没有明确表明你应该在尝试填充关卡（level）之前构建精灵（sprites）和实体（entities），我不得不通过摸索来弄清楚这一点。这更像是基础模型（base model）产品直觉（product intuition）上的差距，而不是框架（harness）旨在解决的问题，但它确实指出了一个可以在框架内进行针对性迭代（targeted iteration）以进一步提高输出质量（output quality）的地方。
通过编辑器工作，新版本相比单人开发的优点变得更加明显。精灵编辑器功能更丰富、更全面，拥有更简洁的工具面板、更好的颜色选择器和更易用的缩放控制。
因为我要求规划者将 AI 功能整合到规格中，所以应用程序还内置了 Claude 集成，让我可以通过提示生成游戏的不同部分。这显著加快了工作流程。
最大的区别在于游戏模式（play mode）。我实际上能够移动我的实体（entity）并玩游戏。物理引擎（physics）有些粗糙的地方——我的角色跳到平台上但最终与平台重叠，这感觉直观上不对——但核心功能是有效的，这是单人运行无法实现的。移动了一会儿后，我确实遇到了人工智能（AI）游戏关卡构建（game level construction）的一些限制。有一堵高墙我无法跳过去，所以我被困住了。这表明测试框架（harness）可以处理一些常识性的改进和边缘情况，以进一步完善应用程序。
通过查阅日志，很明显评估器（evaluator）使实现（implementation）符合规范（spec）。每个冲刺（sprint）周期，它都会检查冲刺合同（sprint contract）的测试标准（test criteria），并通过 Playwright 运行应用程序，对任何偏离预期行为的问题记录缺陷（bugs）。这些合同非常细致——仅第 3 个冲刺（sprint）就有 27 个关于关卡编辑器（level editor）的标准——评估器的发现足够具体，可以直接采取行动，无需额外调查。下表显示了我们的评估器发现的一些问题示例：
合同标准评估器发现
矩形填充工具允许通过点击拖拽来用选定的瓦片填充矩形区域FAIL — 工具只在拖拽的起点和终点放置瓦片，而不是填充整个区域。 fillRectangle 函数存在，但在鼠标释放(mouseUp)时没有正确触发。
用户可以选择和删除已放置的实体生成点失败— Delete键处理程序在LevelEditor.tsx:892需要同时满足selection和selectedEntityId 被设置，但点击实体只设置了selectedEntityId。条件应该是selection || (selectedEntityId && activeLayer === 'entity')。
用户可以通过 API 重新排序动画帧失败 — PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 'reorder' 解析为 frame_id 整数并返回 422 错误："无法将字符串解析为整数。"
让评估者达到这种性能水平需要付出努力。开箱即用时，Claude 是一个糟糕的 QA（质量保证）代理。在早期运行中，我看到它能识别出合法的问题，然后说服自己认为这些问题不是什么大事，无论如何都批准了工作。它也倾向于进行表面测试，而不是探测边缘情况，因此更微妙的错误常常被忽略。调整循环是阅读评估者的日志，找出其判断与我存在分歧的例子，并更新 QA 的提示以解决这些问题。经过几轮这样的开发循环后，评估者才以我认为合理的方式进行评分。即便如此，测试套件的输出显示了模型 QA 能力的局限性：小的布局问题、在某些地方感觉不直观的交互，以及评估者没有彻底测试的更深层次功能中尚未发现的错误。很明显，通过进一步调整还有更多的验证空间可以挖掘。但与单独运行相比（应用程序的核心功能根本无法工作），改进是显而易见的。
优化测试框架
第一套测试工具（harness）的结果令人鼓舞，但它也显得笨重、缓慢且昂贵。合乎逻辑的下一步是找到简化测试工具的方法，同时不降低其性能。这部分是出于常识，部分源于一个更普遍的原则：测试工具中的每个组件都编码了一个关于模型自身无法做什么的假设，这些假设值得进行压力测试，不仅因为它们可能不正确，还因为随着模型的改进，它们可能会迅速过时。我们的博客文章 构建有效的智能体（Agents）将核心理念框定为"尽可能找到最简单的解决方案，仅在必要时增加复杂度"，对于任何维护智能体测试工具（agent harness）的人来说，这是一个持续出现的模式。
在我第一次尝试简化时，我大幅削减了线束（harness）并尝试了一些创新的新想法，但我无法复制原始设计的性能。同时，也很难判断线束设计中的哪些部分实际上是承重的，以及它们是如何承重的。基于那次经验，我转向了一种更有条理的方法，一次移除一个组件，并审查它对最终结果的影响。
在我经历这些迭代周期时，我们还发布了 Opus 4.6，这进一步激励我们降低测试工具（harness）的复杂性。有充分的理由预期 4.6 比 4.5 需要更少的脚手架（scaffolding）。从我们的 发布博客： "[Opus 4.6] 计划更加周密，能够更长时间地维持智能体（agentic）任务，可以在更大的代码库中更可靠地运行，并且拥有更好的代码审查和调试技能来捕捉自己的错误。" 它还在长上下文检索方面有了显著改进。这些都是测试工具（harness）被构建用来补充的能力。
移除冲刺（sprint）结构
我首先完全移除了冲刺（sprint）结构。冲刺结构曾帮助将工作分解为块，以便模型能够连贯地处理工作。鉴于 Opus 4.6 的改进，有充分的理由相信模型可以原生地处理这项工作，而无需这种分解方式。
我保留了规划器（planner）和评估器（evaluator），因为它们各自继续带来明显的价值。如果没有规划器，生成器（generator）的范围会缩小：给定原始提示，它会直接开始构建，而不先规范其工作，最终创建的应用程序功能不如规划器创建的丰富。
移除了 sprint (冲刺) 构造后，我将 evaluator (评估器) 移到了运行结束时的单次执行，而不是在每个 sprint (冲刺) 进行评分。由于模型能力大幅提升，evaluator (评估器) 在某些运行中的重要性发生了变化，其有用性取决于任务相对于模型自身可靠执行能力的位置。在 4.5 版本中，这个边界很接近：我们的构建处于 generator (生成器) 单独能够良好执行能力的边缘，evaluator (评估器) 在整个构建过程中发现了重要问题。在 4.6 版本中，模型的原始能力提升，因此边界向外扩展。那些曾经需要 evaluator (评估器) 检查才能一致实现的任务，现在通常在 generator (生成器) 自身能够良好处理的范围内，对于这些边界内的任务，evaluator (评估器) 变得不必要且成为开销。但对于构建中仍处于 generator (生成器) 能力边缘的部分，evaluator (评估器) 继续提供了实质性的提升。
实际意义在于，评估者不是一个固定的"是"或"否"的决定。当任务超出了当前模型能够可靠独立完成的范围时，它才值得付出成本。
在进行结构简化的同时，我还添加了提示（prompting）来改进框架（harness）如何将AI功能构建到每个应用程序中，特别是让生成器（generator）构建一个合适的代理（agent），能够通过工具（tools）驱动应用程序自身的功能。这确实需要多次迭代，因为相关知识足够新，以至于Claude的训练数据对其覆盖有限。但经过足够的调整（tuning），生成器能够正确地构建代理了。
更新后的框架（harness）的结果
为了测试更新的测试工具，我使用以下提示来生成数字音频工作站（DAW），这是一个用于作曲、录制和混音的音乐制作程序：
使用 Web Audio API 在浏览器中构建一个功能齐全的 DAW。
运行过程仍然耗时且昂贵，耗时约4小时，代币成本为124美元。
大部分时间都花在了构建器上，它连续运行了两个多小时，而 Opus 4.5 需要的冲刺分解在这里并未出现。
代理 & 阶段持续时间成本规划师4.7 分钟$0.46构建（第1轮）2 小时 7 分钟$71.08质量保证（第1轮）8.8 分钟$3.24构建（第2轮）1 小时 2 分钟$36.89质量保证（第2轮）6.8 分钟$3.09
构建（第3轮）10.9 分钟$5.88质量保证（第3轮）9.6 分钟$4.06V2 总体测试套件3 小时 50 分钟$124.70
与之前的测试套件一样，规划者将单行提示扩展为完整规格。从日志中，我可以看到生成器模型在规划应用程序和代理设计、连接代理以及将其移交给质量保证团队之前进行测试方面做得很好。
话虽如此，质量保证代理（QA agent）仍然发现了实际存在的问题。在第一轮反馈中，它指出：
这是一个功能强大的应用，具有出色的设计保真度、坚实的AI代理（AI agent）和良好的后端。主要失败点是功能完整性（Feature Completeness）——尽管应用看起来令人印象深刻且AI集成运行良好，但几个核心的数字音频工作站（DAW）功能仅作展示，缺乏交互深度：音频片段（clips）无法在时间轴（timeline）上拖动/移动，没有乐器UI面板（如合成器旋钮synth knobs、鼓垫drum pads），也没有视觉效果编辑器（如均衡器曲线EQ curves、压缩器表盘compressor meters）。这些不是边缘情况——它们是使数字音频工作站（DAW）可用的核心交互，且规格明确要求了这些功能。
在第二轮反馈中，它再次发现了一些功能缺陷：
剩余的缺陷：
- 音频录制仍然是仅存框架（按钮可以切换但没有麦克风捕获）
- 通过边缘拖拽调整剪辑大小和剪辑分割功能未实现
- 效果可视化是数字滑块，而非图形化（没有均衡器曲线）
当自主运行时，生成器仍然可能会遗漏细节或仅实现框架功能，而质量保证（QA）仍然在捕捉那些需要生成器修复的最终问题方面增加了价值。
根据提示，我期待的是一个程序，可以在其中创建旋律（melodies）、和声（harmonies）和鼓点模式（drum patterns），将它们编排成一首歌曲，并在整个过程中获得集成代理（integrated agent）的帮助。下面的视频展示了结果。
该应用程序远非专业音乐制作程序（professional music production program），而且代理的歌曲创作技能（song composition skills）显然还需要大量改进。此外，Claude实际上无法听到声音，这使得关于音乐品味的QA反馈循环（QA feedback loop）效果较差。
But the final app had all the core pieces of a functional music production program: a working arrangement view, mixer, and transport running in the browser. Beyond that, I was able to put together a short song snippet entirely through prompting: the agent set the tempo and key, laid down a melody, built a drum track, adjusted mixer levels, and added reverb. The core primitives for song composition were present, and the agent could drive them autonomously, using tools to create a simple production from end to end. You might say it’s not pitch-perfect yet—but it’s getting there.
What comes next
随着模型的持续改进，我们可以大致期望它们能够工作更长时间，并处理更复杂的任务。在某些情况下，这意味着围绕模型的支撑结构随时间推移变得不那么重要，开发者可以等待下一个模型，并看到某些问题自行解决。另一方面，模型越好，就有更多空间来开发能够实现模型基础能力之外复杂任务的工具。
考虑到这一点，这项工作中有一些值得借鉴的经验教训。始终对你正在构建的模型进行实验，在真实问题上读取其痕迹，并调整其性能以实现你期望的结果，这是很好的实践。在处理更复杂的任务时，有时通过分解任务并将专业代理应用于问题的各个方面，可以提升性能空间。当新模型出现时，重新审视测试框架，剥离不再对性能有支撑作用的组件，并添加新组件以实现可能之前无法达到的更大能力，这通常也是很好的实践。
通过这项工作，我确信随着模型的改进，有趣的组合空间并不会缩小。相反，它会移动，而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位游戏的美学魅力与现代直观的编辑工具相结合——让从业余创作者到独立开发者的任何人都能不编写传统代码就实现他们的游戏创意。
该平台提供四个集成创意模块：基于瓦片的关卡编辑器（Level Editor）用于设计游戏世界，像素艺术精灵编辑器（Sprite Editor）用于制作视觉资源，可视化实体行为系统（Entity Behavior system）用于定义游戏逻辑，以及即时可玩测试模式（Playable Test Mode）用于实时游戏测试。通过将AI辅助（由Claude提供）贯穿整个流程，RetroForge 加速了创作过程——帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。
RetroForge 面向喜爱复古游戏美学但需要现代便利性的创作者。无论是重现他们童年时代的平台游戏（platformers）、角色扮演游戏（RPGs）或动作游戏，还是在复古限制内创造全新体验，用户都可以快速原型设计、视觉迭代并与他人分享他们的创作。
功能
1. 项目仪表板（Project Dashboard）& 管理
项目仪表板是 RetroForge 中所有创意工作的基地。用户需要一个清晰、有序的方式来管理他们的游戏项目——创建新项目、继续进行中的工作，并一目了然地了解每个项目的内容。
用户故事：作为用户，我想要：
- 创建一个带有名称和描述的新游戏项目，以便开始设计我的游戏
- 将所有现有项目显示为可视化卡片，展示项目名称、最后修改日期和缩略图预览，以便快速找到并继续我的工作
- 打开任何项目进入完整的游戏编辑器工作区，以便我可以处理我的游戏
- 删除不再需要的项目，带有确认对话框以防止意外操作，以便我可以保持工作区整洁
- 复制现有项目作为新游戏的起点，以便我可以重用之前的工作
项目数据模型：每个项目包含：
项目元数据（名称、描述、创建/修改时间戳）
画布设置（分辨率：例如，256x224、320x240或160x144）
瓦片大小配置（8x8、16x16或32x32像素）
调色板选择
所有相关的精灵、瓦片集（tilesets）、关卡和实体定义
...