官方文章 · 发布日期：2026年3月24日
src: https://www.anthropic.com/engineering/harness-design-long-running-apps(Harness design for long-running application development)
Anthropic 工程技术团队 (Engineering at Anthropic) 发布时间： 2026年3月24日
作者： Prithvi Rajasekaran，Labs 团队成员
导语
支架设计（Harness design）是提升智能体编程前沿性能的关键。以下是我们如何在前端设计和长时间运行的自主软件工程中进一步提升 Claude 的表现。
在过去的几个月里，我一直致力于解决两个相互关联的问题：让 Claude 生成高质量的前端设计，以及让它在没有人类干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计技能和长时间运行的编码智能体支架上的努力，当时我和我的同事们能够通过提示词工程和支架设计将 Claude 的性能提升到远超基线的水平——但两者最终都遇到了瓶颈。
为了取得突破，我寻找能够在两个截然不同的领域（一个由主观品味定义，另一个由可验证的正确性和可用性定义）中通用的新型 AI 工程方法。受到生成对抗网络（GANs）的启发，我设计了一个包含生成器和评估器智能体的多智能体结构。构建一个能够可靠且有品位地对输出进行评分的评估器，意味着首先需要开发一套标准，能够将“这个设计好吗？”等主观判断转化为具体的、可评分的条款。
然后，我将这些技术应用于长时间运行的自主编码，并继承了我们早期支架工作中的两个经验：将构建过程分解为易于处理的块（chunks），并使用结构化的制品在会话之间传递上下文。最终的结果是一个由规划器、生成器和评估器组成的三智能体架构，能够在数小时的自主编码会话中生成丰富的全栈应用程序。
为什么简单的实现会失败
我们之前已经证明，支架设计对长时间运行的智能体编码的有效性有着重大影响。在早期的实验中，我们使用了一个初始化智能体将产品说明书分解为任务列表，以及一个编码智能体，每次实现一个功能，然后移交制品以在会话之间保留上下文。更广泛的开发者社区也得出了类似的见解，比如使用钩子或脚本让智能体保持在持续迭代周期中的“Ralph Wiggum”方法。
但一些问题仍然持续存在。对于更复杂的任务，智能体随着时间的推移仍然容易脱轨。在分解这个问题时，我们观察到智能体执行此类任务时常见的两种失败模式。
首先，当上下文窗口填满时，模型往往会在冗长的任务上失去连贯性。有些模型还表现出“上下文焦虑”，即当它们接近自己认为的上下文限制时，就会过早地开始收尾工作。上下文重置——完全清除上下文窗口并启动一个新的智能体，结合携带前一个智能体状态和后续步骤的结构化交接——解决了这两个问题。
这不同于压缩（compaction），压缩是对对话的早期部分进行就地总结，以便同一个智能体可以在缩短的历史记录上继续运行。虽然压缩保留了连续性，它并没有给智能体一个全新的开始，这意味着上下文焦虑可能仍然存在。重置提供了一个全新的开始，代价是移交的制品必须具有足够的状态，以便下一个智能体能够干净利落地接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 表现出强烈的上下文焦虑，以至于仅靠压缩不足以实现强大的长任务性能，因此上下文重置成为支架设计中必不可少的部分。这解决了核心问题，但增加了每次支架运行的编排复杂性、Token 开销和延迟。
第二个问题，我们之前没有解决的，是自我评估。当被要求评估它们产生的作品时，智能体倾向于自信地赞美自己的工作——即使在人类观察者看来，质量显然很平庸。这个问题在像设计这样的主观任务中尤为明显，因为在那里没有等同于可验证软件测试的二元检查。布局感觉是精致的还是普通的，这是一种判断，而智能体在评估自己的工作时总是可靠地偏向正面。
然而，即使在确实有可验证结果的任务上，智能体有时仍会表现出糟糕的判断力，这阻碍了它们完成任务的表现。将执行工作的智能体与评估它的智能体分离开来，被证明是解决这个问题的有力杠杆。这种分离本身并不能立即消除那种宽容；评估器仍然是一个 LLM，它倾向于对 LLM 生成的输出表现出慷慨。但是，调整一个独立的评估器使其保持怀疑态度，被证明比让一个生成器批评自己的工作要容易得多，而且一旦存在外部反馈，生成器就有了具体的东西可以用来迭代。
前端设计：让主观质量变得可评分
我从在前端设计上进行实验开始，那里的自我评估问题最为明显。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局，这些布局在技术上能起作用，但在视觉上却很普通。
有两个见解塑造了我为前端设计构建的支架。首先，虽然美学不能完全简化为一个分数——而且个人品味总是各不相同——但它们可以通过编码了设计原则和偏好的评分标准来改善。“这个设计漂亮吗？”很难给出一贯的回答，但“这遵循我们优秀设计的原则吗？”给了 Claude 一些具体的东西来评分。其次，通过将前端生成与前端评估分离，我们可以创建一个反馈循环，驱使生成器产生更强大的输出。
考虑到这一点，我编写了四个评分标准，并在生成器和评估器智能体的提示词中提供了它们：
- 设计质量（Design quality）：设计感觉像是一个连贯的整体，还是一堆零件的集合？这里出色的工作意味着颜色、排版、布局、图像和其他细节结合在一起，创造出一种独特的氛围和标识。
- 原创性（Originality）：是否有定制决策的证据，或者这是模板布局、库默认值和 AI 生成的模式？人类设计师应该能认出深思熟虑的创意选择。未经修改的库存组件——或者像白色卡片上紫色渐变这种 AI 生成的明显迹象——在这里是不及格的。
- 工艺（Craft）：技术执行：排版层级、间距一致性、色彩和谐度、对比度。这是一种能力检查，而不是创造力检查。在默认情况下，大多数合理的实现都能在这里表现良好；不及格意味着基础被破坏。
- 功能性（Functionality）：独立于美学的可用性。用户能理解界面的功能，找到主要操作，并在无需猜测的情况下完成任务吗？
我强调设计质量和原创性高于工艺和功能性。Claude 在默认情况下已经在工艺和功能性上得分很高，因为所需的技术能力倾向于在模型中自然而然地体现。但在设计和原创性上，Claude 经常产生充其量只能算是平淡无奇的输出。该标准明确惩罚了高度通用的“AI垃圾（AI slop）”模式，并且通过赋予设计和原创性更高的权重，它推动模型承担更多的美学风险。
我使用带有详细分数明细的少样本（few-shot）示例对评估器进行了校准。这确保了评估器的判断与我的偏好一致，并减少了跨迭代的分数漂移。
我基于 Claude Agent SDK 构建了这个循环，这保持了编排的直观性。生成器智能体首先根据用户提示词创建了一个 HTML/CSS/JS 前端。我给评估器提供了 Playwright MCP，让它可以直接与实时页面交互，然后再对每个标准进行评分并撰写详细的评论。在实践中，评估器会自行浏览页面，截取屏幕截图并仔细研究实现细节，然后得出评估结果。这些反馈会流回生成器，作为下一次迭代的输入。每次生成我运行 5 到 15 次迭代，随着生成器响应评估器的评论，每次迭代通常会将生成器推向一个更具特色的方向。因为评估器正在积极地浏览页面，而不是对静态屏幕截图进行评分，所以每个周期都花费了真实的挂钟时间。完整的运行时间长达四个小时。我还指示生成器在每次评估后做出战略性决定：如果分数趋势良好，则完善当前方向；如果该方法不起作用，则转向完全不同的美学风格。
在多次运行中，评估器的评估结果在迭代过程中有所改善，然后趋于平稳，但仍有提升空间。一些生成逐渐完善。而另一些则在迭代之间发生了急剧的美学转变。
这些标准的措辞以我未曾完全预料到的方式引导着生成器。包含“最好的设计是博物馆级的质量”这样的短语将设计推向了一种特定的视觉趋同，这表明与标准相关的提示词直接塑造了输出的特征。
虽然分数在迭代中通常有所提高，但这种模式并不总是纯粹线性的。后期的实现整体上往往更好，但我经常看到我更喜欢中间某次迭代而不是最后一次的情况。随着生成器为了响应评估器的反馈而寻求更雄心勃勃的解决方案，实现复杂度也倾向于在不同轮次中增加。即使在第一次迭代中，输出也明显优于没有任何提示词的基线，这表明这些标准及其相关语言本身就引导模型远离了通用默认值，甚至在任何评估器反馈导致进一步完善之前就是如此。
在一个值得注意的例子中，我提示模型为一个荷兰艺术博物馆创建一个网站。到了第九次迭代时，它为一个虚构的博物馆生成了一个干净的、深色主题的登陆页面。该页面视觉上很精致，但主要符合我的预期。然后，在第十个周期，它完全放弃了这种方法，并将该网站重新想象成一种空间体验：一个使用 CSS 透视渲染出来的有格子地板的 3D 房间，艺术品以自由形式悬挂在墙上，并且在画廊房间之间使用了基于门口的导航而不是滚动或点击。这种创造性的飞跃是我在单遍生成中从未见过的。
扩展到全栈编码
有了这些发现，我将这种受 GAN 启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期上，在那里，代码审查和 QA 扮演着与设计评估器相同的结构性角色。
架构
在我们早期的长时间运行支架中，我们通过一个初始化智能体、一个一次开发一个功能的编码智能体以及会话间的上下文重置，解决了连贯的多会话编码问题。上下文重置是一个关键的解锁：该支架使用了 Sonnet 4.5，它表现出了前面提到的“上下文焦虑”倾向。创建一个能够在上下文重置之间良好运行的支架，对于让模型保持在任务状态至关重要。Opus 4.5 在很大程度上自动消除了这种行为，因此我能够从该支架中完全去掉上下文重置。智能体在整个构建过程中作为一个连续会话运行，并由 Claude Agent SDK 的自动压缩功能在沿途处理上下文的增长。
对于这项工作，我在原始支架的基础上建立了一个三智能体系统，每个智能体都解决了我之前运行中观察到的一个特定空白。该系统包含以下智能体角色：
- 规划器（Planner）：我们之前长时间运行的支架要求用户预先提供详细的说明书。我想自动化这一步，所以我创建了一个规划器智能体，它接收一个简单的 1-4 句话的提示词，并将其扩展为完整的产品说明书。我提示它在范围上要有野心，并保持专注于产品上下文和高级技术设计，而不是详细的技术实现。这种强调是因为担心，如果规划器试图预先指定细粒度的技术细节却弄错了什么，说明书中的错误就会级联到下游的实现中。限制智能体要生产的可交付成果，并让它们在工作时自行找出路径，似乎是更聪明的做法。我还要求规划器寻找将 AI 功能融入产品说明书的机会。（参见底部附录中的示例。）
- 生成器（Generator）：早期支架中一次一个功能的方法在范围管理方面效果很好。我在这里应用了类似的模型，指示生成器在冲刺（sprints）中工作，每次从说明书中提取一个功能。每个冲刺都使用 React、Vite、FastAPI 和 SQLite（后来的 PostgreSQL）技术栈实现该应用程序，并指示生成器在每个冲刺结束时进行自我评估，然后移交给 QA。它还拥有用于版本控制的 git。
- 评估器（Evaluator）：早期支架生成的应用程序通常看起来令人印象深刻，但当你真正尝试使用它们时仍然存在真正的 bug。为了捕捉到这些，评估器使用 Playwright MCP 像用户一样点击正在运行的应用程序，测试 UI 功能、API 端点和数据库状态。然后，它根据其发现的错误和一套模拟前端实验的标准对每个冲刺进行评分，这里进行了调整以涵盖产品深度、功能性、视觉设计和代码质量。每个标准都有一个硬性阈值，如果其中任何一个低于阈值，冲刺就会失败，生成器就会得到关于出了什么问题的详细反馈。
在每次冲刺之前，生成器和评估器会协商一份冲刺契约：在编写任何代码之前商定这块工作“完成”是什么样子的。这是因为产品说明书被故意设置得比较高层，我想要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，而评估器审查该提案以确保生成器正在构建正确的东西。两者反复迭代直到达成一致。
通信是通过文件处理的：一个智能体会写入一个文件，另一个智能体会读取它，并在该文件内回复，或者用一个新文件回复，让前一个智能体依次读取。然后，生成器在将工作移交给 QA 之前，根据商定好的契约进行构建。这使得工作忠实于说明书，又不会过早地过度指定实现细节。
运行支架
对于这个支架的第一个版本，我使用了 Claude Opus 4.5，对比全支架系统和单智能体系统来运行用户提示词以进行比较。我使用 Opus 4.5 是因为当我开始这些实验时，它是我们最好的编码模型。
我编写了以下提示词来生成一个复古视频游戏制作器：
创建一个具有关卡编辑器、精灵编辑器、实体行为和可玩测试模式等功能的 2D 复古游戏制作器。
下表显示了支架类型、运行长度和总成本：
| 支架类型 (Harness) | 持续时间 (Duration) | 成本 (Cost) |
|---|---|---|
| 单独运行 (Solo) | 20分钟 | $9 |
| 完整支架 (Full harness) | 6小时 | $200 |
该支架的成本要贵 20 倍以上，但在输出质量上的差异立竿见影。
我期待这样一个界面：我可以在其中构建一个关卡及其组成部分（精灵、实体、切片布局），然后点击播放来实际游玩这个关卡。我首先打开了单独运行的输出，初始应用程序似乎符合这些期望。
然而，当我点击浏览时，问题开始出现。布局浪费了空间，固定高度的面板留下了大部分视口空白。工作流程很僵硬。试图填充一个关卡会提示我首先创建精灵和实体，但 UI 中没有任何东西引导我走向那个顺序。更重要的一点是，实际的游戏崩溃了。我的实体出现在屏幕上，但没有任何东西对输入做出响应。深入研究代码后发现，实体定义和游戏运行时之间的连线断开了，并且表面上没有任何指示断在哪里的迹象。
Opening screen
Sprite editor
Game play
(图注：打开屏幕、精灵编辑器、游戏试玩。单独支架创建的应用程序打开时的初始屏幕。在单独支架制作的精灵编辑器中创建精灵。尝试玩我创建的关卡但失败了。)
在评估了单独运行后，我将注意力转向了支架运行。这次运行从同一个一句话提示词开始，但是规划器步骤将该提示词扩展为一个包含 16 个功能、分布在十个冲刺中的说明书。它远远超出了单独运行尝试的范围。除了核心编辑器和游玩模式之外，说明书还要求一个精灵动画系统、行为模板、音效和音乐、一个 AI 辅助的精灵生成器和关卡设计师，以及带有可分享链接的游戏导出功能。我赋予了规划器访问我们前端设计技能的权限，它读取并利用这些技能为应用程序创建了视觉设计语言，作为说明书的一部分。对于每个冲刺，生成器和评估器都会协商一份契约，定义冲刺的具体实现细节以及将被测试以验证完成情况的可测试行为。
这款应用立刻展现出比单独运行更高的完成度与流畅度。画布使用了完整的视口，面板的尺寸设计得很合理，并且界面拥有与说明书中的设计方向一致的统一视觉形象。我在单独运行中看到的一些笨拙感确实保留了下来——工作流程仍然没有弄清楚你应该在尝试填充关卡之前构建精灵和实体，我不得不通过到处乱点才弄明白这一点。这被解读为基础模型产品直觉上的空白，而不是支架设计要解决的问题，尽管这确实表明在支架内部进行有针对性的迭代可以帮助进一步提高输出质量。
在编辑器中工作时，新运行相较于单独运行的优势变得更加明显。精灵编辑器更丰富、功能更全，具有更干净的工具调色板、更好的颜色选择器以及更实用的缩放控制。
因为我曾要求规划器将 AI 功能融入其说明书中，该应用程序还内置了 Claude 集成，让我可以通过提示来生成游戏的不同部分。这极大地加快了工作流程。
Opening screen
Sprite editor
AI game design
AI game design
Game play
(图注：打开屏幕、精灵编辑器、AI游戏设计、AI游戏设计、游戏试玩。初始屏幕：在完整支架构建的应用程序中创建一个新游戏。精灵编辑器感觉更干净、更易于使用。使用内置的 AI 功能生成关卡。使用内置的 AI 功能生成关卡。游玩我生成出来的游戏。)
最大的区别在于试玩模式。我实际上可以移动我的实体并玩游戏了。物理效果有一些粗糙的边缘——我的角色跳上了一个平台，但最终与平台重叠了，这在直觉上感觉不对——但核心功能起作用了，而单独运行没有做到这一点。在四处走动了一会儿后，我确实碰到了 AI 游戏关卡构建的一些限制。有一堵高墙我跳不过去，所以我被困住了。这表明支架可以处理一些常识性的改进和边缘情况，以进一步完善应用程序。
仔细阅读日志后，很明显评估器使实现与说明书保持了一致。在每个冲刺中，它都会遍历冲刺契约的测试标准，并通过 Playwright 运行应用程序，针对任何偏离预期行为的地方提交 bug。契约是细化的——仅冲刺 3 就有 27 个涵盖关卡编辑器的标准——并且评估器的发现足够具体，无需额外调查即可采取行动。下表显示了我们的评估器识别出的几个问题示例：
| 契约标准 (Contract criterion) | 评估器发现 (Evaluator finding) |
|---|---|
| 矩形填充工具允许通过点击拖动用选定的图块填充矩形区域 | 失败 (FAIL) — 工具仅在拖动起点/终点放置图块，而不是填充该区域。fillRectangle 函数存在，但在 mouseUp 时未正确触发。 |
| 用户可以选择并删除放置的实体生成点 | 失败 (FAIL) — LevelEditor.tsx:892 处的 Delete 键处理程序要求同时设置 selection 和 selectedEntityId，但点击实体仅会设置 selectedEntityId。条件应为 selection || (selectedEntityId && activeLayer === 'entity')。 |
| 用户可以通过 API 重新排序动画帧 | 失败 (FAIL) — PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 'reorder' 匹配为 frame_id 整数并返回 422：“无法将字符串解析为整数。” |
让评估器在这个水平上发挥作用需要费些功夫。开箱即用的 Claude 是一个糟糕的 QA 智能体。在早期的运行中，我看着它识别出合理的问题，然后说服自己决定这些问题没什么大不了的，无论如何都批准了工作。它还倾向于进行表面测试，而不是探测边缘情况，因此更微妙的 bug 经常成为漏网之鱼。调整循环是读取评估器的日志，找到它的判断与我产生分歧的例子，然后更新 QA 的提示词以解决这些问题。在这个开发循环经过几轮之后，评估器的评分方式才达到我认为合理的程度。即使那样，支架的输出仍然显示了模型 QA 能力的局限性：小的布局问题、在某些地方感觉不直观的交互，以及评估器没有彻底执行的更深层嵌套功能中未发现的 bug。显然，随着进一步的微调，还有更多的验证提升空间。但与单独运行相比（在单独运行中应用的核心功能根本不起作用），这种提升是显而易见的。
在支架上迭代
第一组支架的结果令人鼓舞，但它也显得庞大、缓慢且昂贵。合乎逻辑的下一步是寻找在不降低其性能的情况下简化支架的方法。这部分是常识，部分是一个更普遍原则的作用：支架中的每个组件都编码了关于模型自身无法做什么的假设，而这些假设值得进行压力测试，这既是因为它们可能是不正确的，也是因为随着模型的改进它们很快就会过时。我们关于《构建有效智能体》的博客文章将基本理念框架化为“找到可能的最简单的解决方案，并且仅在需要时才增加复杂性”，这是任何维护智能体支架的人都会一致看到的模式。
在第一次尝试简化时，我从根本上削减了支架，并尝试了一些富有创意的新想法，但我未能复制原始版本的性能。也很难分辨出支架设计中的哪些部分实际起到了承重的作用，以及以什么方式。基于这段经验，我转向了一种更系统的方法，一次移除一个组件并检查它对最终结果有什么影响。
在经历这些迭代周期时，我们还发布了 Opus 4.6，这为降低支架复杂性提供了进一步的动力。我们有充分的理由期望 4.6 会比 4.5 需要更少的脚手架。正如我们的发布博客中所说：“[Opus 4.6] 规划得更仔细，能够持续处理更长时间的智能体任务，能在更大的代码库中更可靠地运行，并具有更好的代码审查和调试技能以捕获自身的错误。”它还在长上下文检索方面有了实质性的改进。这些正是支架旨在去补充的能力。
移除冲刺结构
我首先完全移除了冲刺结构。冲刺结构曾有助于将工作分解成块，以便模型可以连贯地工作。鉴于 Opus 4.6 的改进，有充分理由相信该模型能够在没有这种分解的情况下原生地处理这项工作。
我保留了规划器和评估器，因为它们各自继续增加明显的价值。没有规划器，生成器就会缩小范围：给定原始的提示词，它会在没有首先为其工作写说明书的情况下开始构建，最终创建出一个不如规划器做的功能丰富的应用程序。
移除冲刺结构后，我将评估器移至运行结束时进行单次通过，而不是针对每个冲刺进行评分。由于模型的能力强得多，它改变了评估器对于某些运行的承重程度，其有用性取决于任务相对于模型能够独立可靠完成的任务所处的位置。在 4.5 上，该边界很近：我们的构建正处于生成器可以单独出色完成的工作边缘，而评估器捕获了整个构建过程中的实质性问题。在 4.6 上，模型的原始能力提升了，所以该边界向外移动了。过去需要评估器检查才能连贯实现的任务现在通常属于生成器自己就能处理好的范围，而对于该边界内的任务，评估器成了不必要的开销。但对于构建中仍处于生成器能力边缘的部分，评估器继续提供了真正的提升。
实际的含义是，评估器并不是一个非黑即白的固定决定。当任务超出了当前模型可以独立可靠完成的范围时，它就是值得付出成本的。
除了结构简化之外，我还添加了提示词，以改善支架在每个应用程序中构建 AI 功能的方式，具体来说就是让生成器构建一个合适的智能体，它可以通过工具来驱动应用程序自身的功能。这确实需要迭代，因为相关知识足够新，以至于 Claude 的训练数据对其覆盖得很薄。但经过足够的微调，生成器能够正确地构建智能体。
更新后的支架的结果
为了对更新后的支架进行测试，我使用了以下提示词来生成一个数字音频工作站（DAW），这是一款用于作曲、录音和混音的音乐制作程序：
使用 Web Audio API 在浏览器中构建一个功能齐全的 DAW。
这次运行仍然漫长且昂贵，大约耗时 4 小时，Token 成本为 124 美元。
大部分时间花在了构建器（builder）上，它连贯地运行了两个多小时，而不需要 Opus 4.5 曾经需要的冲刺分解。
| 智能体与阶段 (Agent & Phase) | 持续时间 (Duration) | 成本 (Cost) |
|---|---|---|
| 规划器 (Planner) | 4.7分钟 | $0.46 |
| 构建 第1轮 (Build Round 1) | 2小时7分钟 | $71.08 |
| QA 第1轮 (QA Round 1) | 8.8分钟 | $3.24 |
| 构建 第2轮 (Build Round 2) | 1小时2分钟 | $36.89 |
| QA 第2轮 (QA Round 2) | 6.8分钟 | $3.09 |
| 构建 第3轮 (Build Round 3) | 10.9分钟 | $5.88 |
| QA 第3轮 (QA Round 3) | 9.6分钟 | $4.06 |
| 总计 V2 支架 (Total V2 Harness) | 3小时50分钟 | $124.70 |
与之前的支架一样，规划器将这一行提示词扩展为一份完整的说明书。从日志中，我可以看到生成器模型在规划应用程序和智能体设计、连接智能体以及在移交给 QA 之前测试它方面做得很好。
话虽如此，QA 智能体仍然发现了真正的漏洞。在它的第一轮反馈中，它指出：
“这是一款出色的应用程序，具有极佳的设计保真度、可靠的 AI 智能体和良好的后端。主要的失败点在于功能完整性（Feature Completeness）——虽然这款应用程序看起来令人印象深刻且 AI 整合运作良好，但几个核心的 DAW 功能仅作展示而缺乏交互深度：片段不能在时间轴上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有视觉效果编辑器（EQ 曲线、压缩器仪表）。这些不是边缘案例——它们是让 DAW 可用的核心交互，而说明书明确要求了它们。”
在第二轮反馈中，它再次抓到了几个功能漏洞：
剩余差距：
- 音频录制仍然只是一个存根（按钮可以切换，但没有麦克风捕获）
- 尚未实现通过拖动边缘调整片段大小和拆分片段
- 效果可视化是数字滑块，而不是图形化的（没有 EQ 曲线）
当生成器被任由其自己发挥时，它仍然容易遗漏细节或存根功能，而 QA 在捕捉那些最后一英里的问题以供生成器修复方面仍然具有增值作用。
根据提示词，我期待一个可以创建旋律、和声和鼓模式，将它们排列成一首歌，并在过程中获得集成智能体帮助的程序。
这款应用离专业的音乐制作程序还差得很远，而且智能体的歌曲创作技能显然还需要大量改进。此外，Claude 实际上听不见，这使得 QA 反馈循环在音乐品味方面不太有效。
但最终的应用具备了一个功能性音乐制作程序的所有核心部件：在浏览器中运行的工作排列视图、混音器和走带控制系统。除此之外，我能够完全通过提示词来拼凑出一小段歌曲片段：智能体设置了速度和调性，铺设了旋律，建立了一条鼓轨，调整了混音器电平，并添加了混响。用于歌曲创作的核心基元都存在了，智能体可以自主驱动它们，使用工具端到端地创建简单的制作。你可以说它还达不到音高完美的程度——但它正在朝着那个方向发展。
接下来是什么
随着模型的不断改进，我们可以大致期望它们能够工作更长时间，处理更复杂的任务。在某些情况下，这意味着围绕模型的脚手架随着时间的推移将变得不那么重要，开发者可以等待下一个模型，看着某些问题自我解决。另一方面，模型变得越好，开发能够完成超出模型基线能力的复杂任务的支架的空间就越大。
考虑到这一点，这项工作中有一些经验教训值得传承。对你正在使用的模型进行实验、阅读它在现实问题上的踪迹，并调整它的表现以实现你期望的结果，始终是一个很好的实践。在处理更复杂的任务时，分解任务并针对问题的各个方面应用专门的智能体，有时会带来提升的空间。而当新模型问世时，重新检查支架通常是一个好做法，剥离不再承担性能重任的部件，并添加新的部件以实现以前可能无法实现的更强大能力。
通过这项工作，我坚信，有趣的支架组合空间不会随着模型的改进而缩小。相反，它是在移动的，对于 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 Retro Game Maker
Overview
RetroForge is a web-based creative studio for designing and building 2D retro-style video games. It combines the nostalgic charm of classic 8-bit and 16-bit game aesthetics with modern, intuitive editing tools—enabling anyone from hobbyist creators to indie developers to bring their game ideas to life without writing traditional code.
The platform provides four integrated creative modules: a tile-based Level Editor for designing game worlds, a pixel-art Sprite Editor for crafting visual assets, a visual Entity Behavior system for defining game logic, and an instant Playable Test Mode for real-time gameplay testing. By weaving AI assistance throughout (powered by Claude), RetroForge accelerates the creative process—helping users generate sprites, design levels, and configure behaviors through natural language interaction.
RetroForge targets creators who love retro gaming aesthetics but want modern conveniences. Whether recreating the platformers, RPGs, or action games of their childhood, or inventing entirely new experiences within retro constraints, users can prototype rapidly, iterate visually, and share their creations with others.
Features
1. Project Dashboard & Management
The Project Dashboard is the home base for all creative work in RetroForge. Users need a clear, organized way to manage their game projects—creating new ones, returning to works-in-progress, and understanding what each project contains at a glance.
User Stories: As a user, I want to:
- Create a new game project with a name and description, so that I can begin designing my game
- See all my existing projects displayed as visual cards showing the project name, last modified date, and a thumbnail preview, so that I can quickly find and continue my work
- Open any project to enter the full game editor workspace, so that I can work on my game
- Delete projects I no longer need, with a confirmation dialog to prevent accidents, so that I can keep my workspace organized
- Duplicate an existing project as a starting point for a new game, so that I can reuse my previous work
Project Data Model: Each project contains:
Project metadata (name, description, created/modified timestamps)
Canvas settings (resolution: e.g., 256x224, 320x240, or 160x144)
Tile size configuration (8x8, 16x16, or 32x32 pixels)
Color palette selection
All associated sprites, tilesets, levels, and entity definitions
...结语
第三百七十四篇博文写完，开心！！！！
今天，也是充满希望的一天。
