在智能体编码的前沿领域，框架设计是提升性能的关键。以下是我们如何帮助 Claude 在前端设计和长期自主软件工程方面取得更大进步。
本文由我们实验室团队成员 Prithvi Rajasekaran 撰写。
过去几个月，我一直在研究两个相互关联的问题：一是让 Claude 生成高质量的前端设计，二是让它无需人工干预即可构建完整的应用程序。这项工作源于我们之前对前端设计技能和长期运行的编码代理框架的改进 。当时，我和同事们通过快速的工程设计和框架设计，显著提升了 Claude 的性能，使其远超基准水平——但最终都遇到了瓶颈。
为了取得突破，我寻求能够跨越两个截然不同的领域的新型人工智能工程方法：一个领域以主观喜好为标准，另一个领域则以可验证的正确性和可用性为标准。我从生成对抗网络 （GAN）中汲取灵感，设计了一个包含生成器和评估器的多智能体结构。构建一个能够可靠且有品位地对输出进行评分的评估器，意味着首先要制定一套标准，将“这个设计好不好？”之类的主观判断转化为具体的、可评分的指标。
随后，我将这些技术应用于长时间自主编码，并借鉴了我们之前框架搭建工作中的两个经验：将构建过程分解成易于处理的小块，以及使用结构化工件在不同会话之间传递上下文。最终成果是一个由三个智能体组成的架构——规划器、生成器和评估器——能够在长达数小时的自主编码会话中生成功能丰富的全栈应用程序。
为什么简单的实现方式会失败
我们之前已经证明，框架设计对长时间运行的智能体编码的效率有着显著影响。在早期的实验中，我们使用了一个初始化智能体将产品规格分解成任务列表，并使用一个编码智能体逐个实现这些任务的功能，最后将生成的工件传递给编码智能体，以便在不同会话之间传递上下文信息。更广泛的开发者社区也逐渐形成了类似的认识，例如“ Ralph Wiggum ”方法就利用钩子或脚本来保持智能体持续迭代。
但有些问题依然存在。对于更复杂的任务，智能体仍然容易随着时间的推移而偏离轨道。在分析这个问题时，我们观察到智能体在执行此类任务时存在两种常见的故障模式。
首先，随着上下文窗口逐渐填满，模型在执行长时间任务时往往会失去连贯性（参见我们关于上下文工程的文章）。一些模型还会表现出“上下文焦虑”，即当它们接近自身认为的上下文极限时，就会过早地结束工作。上下文重置——完全清除上下文窗口并启动一个新的智能体，同时配合结构化的交接机制（该机制会传递前一个智能体的状态和后续步骤）——可以解决这两个问题。
这与压缩不同，压缩会将对话的早期部分进行原地概括，以便同一代理能够继续处理缩短后的历史记录。虽然压缩保持了连续性，但它并不能让代理从头开始，这意味着上下文焦虑仍然存在。重置可以提供一个全新的状态，但代价是交接工件会保留足够的状态，以便下一个代理能够顺利地接手工作。在我们之前的测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑非常严重，仅靠压缩不足以实现出色的长时间任务性能，因此上下文重置成为框架设计中必不可少的环节。这解决了核心问题，但增加了编排的复杂性、令牌开销和每次框架运行的延迟。
第二个问题，也是我们之前没有讨论过的，是自我评价。当被要求评价自己完成的工作时，员工往往会自信地称赞自己的作品——即使在人类观察者看来，作品的质量明显平庸。这个问题在设计这类主观性较强的任务中尤为突出，因为这类任务没有像软件测试那样的二元评判标准。一个布局是精致还是平庸完全取决于主观判断，而员工在评价自己的作品时往往会倾向于给出更高的评价。
然而，即使在那些结果可验证的任务中，智能体有时仍然会表现出判断失误，从而影响其完成任务的表现。将执行任务的智能体与评估任务的智能体分开，被证明是解决这一问题的有效方法。这种分离本身并不能立即消除这种宽容；评估者仍然是一个逻辑逻辑模型（LLM），它倾向于对 LLM 生成的输出给予较高的评价。但是，调整一个独立的评估者使其保持怀疑态度，远比让生成器对其自身的工作进行批判性思考要容易得多。一旦有了这种外部反馈，生成器就有了可以迭代的具体依据。
前端设计：使主观质量可分级
我首先从前端设计入手进行实验，因为自我评价的问题在这里最为明显。如果没有人干预，克劳德通常会倾向于安全、可预测的布局，这些布局技术上功能齐全，但视觉上平淡无奇。
我为前端设计构建的框架基于两个关键洞察。首先，虽然美学无法完全用分数来衡量——而且个人品味也总是各不相同——但我们可以通过编码设计原则和偏好的评分标准来提升设计水平。“这个设计美观吗？”很难给出一致的答案，但“它是否符合我们对优秀设计的原则？”则为 Claude 提供了一个具体的评分标准。其次，通过将前端生成与前端评分分离，我们可以创建一个反馈循环，从而驱动生成器输出更优质的内容。
基于此，我编写了四项评分标准，并在提示中将其提供给了生成器和评估器：
设计质量： 设计是否感觉像是一个连贯的整体，而不是各个部分的简单堆砌？优秀的设计意味着色彩、字体、布局、图像和其他细节相互融合，共同营造出独特的氛围和风格。
原创性(Originality)： 是否存在自定义决策的痕迹，还是仅仅使用了模板布局、库默认设置和人工智能生成的图案？一位优秀的设计师应该能够识别出精心设计的创意。未经修改的现成组件——或者像白色卡片上叠加紫色渐变这样的人工智能生成痕迹——都无法体现原创性。
工艺(Craft)： 技术执行：排版层级、间距一致性、色彩和谐、对比度。这考察的是能力，而非创意。大多数合理的实现方式默认都能达标；失败则意味着基本功薄弱。
功能性： 可用性独立于美观性之外。用户能否理解界面功能，找到主要操作，并在不猜测的情况下完成任务？
我更注重设计质量和原创性，而非工艺和功能性。克劳德在工艺和功能性方面本身就表现出色，因为所需的技术能力对这个模型来说往往是与生俱来的。但在设计和原创性方面，克劳德的作品充其量只能算平庸。评分标准明确惩罚了过于通用的“人工智能粗糙”模式，并通过提高设计和原创性的权重，促使模型在美学上进行更多冒险尝试。
我使用少量样本并附有详细的分数细分来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了迭代过程中分数的偏差。
我基于 Claude Agent SDK 构建了循环，这使得流程编排非常简洁。首先，生成器代理会根据用户提示创建一个 HTML/CSS/JS 前端。我为评估者提供了 Playwright MCP，使其能够直接与实时页面交互，然后对每个标准进行评分并撰写详细的评论。实际上，评估者会自行浏览页面，截屏并仔细研究实现方式，然后再进行评估。这些反馈会作为输入返回给生成器，用于下一次迭代。每次生成运行 5 到 15 次迭代，每次迭代通常会根据评估者的评论，引导生成器朝着更明确的方向发展。由于评估者是主动浏览页面而不是对静态截图进行评分，因此每个循环都需要实际运行时间。完整的运行时间最长可达四个小时。我还指示生成器在每次评估后做出战略决策：如果评分趋势良好，则优化当前方向；如果方法无效，则转向完全不同的美学风格。
在多次迭代中，评估者的评价逐渐提高，最终趋于稳定，但仍有提升空间。有些版本是逐步改进的，而另一些版本则在迭代之间发生了显著的审美转变。
这些评判标准的措辞以我未曾完全预料的方式引导了生成器。例如，诸如“最佳设计应达到博物馆级别”之类的表述，促使设计作品朝着特定的视觉方向发展，这表明与这些标准相关的提示直接塑造了输出结果的特征。
虽然分数通常会随着迭代次数的增加而提高，但这种提升并非总是呈现清晰的线性趋势。后期的实现整体上往往更好，但我经常会遇到这样的情况：我更喜欢中间的迭代版本而不是最后一次迭代。实现的复杂度也往往会随着迭代次数的增加而增加，生成器会根据评估者的反馈寻求更复杂的解决方案。即使在第一次迭代中，输出结果也明显优于完全没有提示的基准版本，这表明在评估者的反馈促使模型进一步改进之前，评分标准及其相关语言本身就已经引导模型摆脱了通用的默认设置。
举个例子，我让模型为一家荷兰艺术博物馆设计网站。到了第九次迭代，它生成了一个简洁的深色主题首页，页面内容是虚构的博物馆。页面视觉效果不错，但基本符合我的预期。然而，到了第十次迭代，它彻底放弃了之前的设计思路，将网站重新构想成一个空间体验：一个 3D 房间，房间内铺设着用 CSS 透视渲染的方格地板，艺术品以自由形式悬挂在墙上，展厅之间的导航不再是滚动或点击，而是通过门来切换。这种创造性的飞跃，是我之前从未在单次迭代的模型中见过的。
扩展到全栈编码
基于这些发现，我将这种受生成对抗网络（GAN）启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期中，其中代码审查和质量保证（QA）与设计评估器发挥着相同的结构性作用。
架构
在我们之前长期运行的测试框架中，我们通过初始化代理、一次处理一个功能的编码代理以及会话间的上下文重置，解决了多会话编码的一致性问题。上下文重置是关键所在：该测试框架使用了 Sonnet 4.5，而 Sonnet 4.5 存在之前提到的“上下文焦虑”问题。创建一个能够在上下文重置后依然良好运行的测试框架，是确保模型持续执行任务的关键。Opus 4.5 在很大程度上消除了这种行为，因此我能够完全从该测试框架中移除上下文重置。在整个构建过程中，所有代理都作为一个连续的会话运行， Claude Agent SDK 的自动压缩功能则负责处理过程中不断增长的上下文。
这项工作是在原有框架的基础上，构建了一个三智能体系统，每个智能体都针对我在之前的运行中观察到的特定缺陷进行改进。该系统包含以下智能体角色：
规划器（Planner）： 我们之前长期使用的工具需要用户预先提供详细的规格说明。为了实现这一步骤的自动化，我创建了一个规划器代理，它能够接收 1-4 句话的简单提示，并将其扩展为完整的产品规格说明。我要求它在范围方面设定得更远大一些，并专注于产品背景和高层技术设计，而不是具体的实现细节。之所以这样强调，是因为我们担心，如果规划器试图预先指定细粒度的技术细节，一旦出错，规格说明中的错误就会波及到后续的实现。因此，将代理的工作范围限定在需要交付的成果上，并让它们在工作中逐步摸索，似乎更为明智。我还要求规划器寻找机会，将 AI 功能融入到产品规格说明中。（参见文末附录中的示例。）
生成器（Generator）： 之前框架中采用的一次只开发一个功能的方法在范围管理方面效果很好。我在这里也采用了类似的模型，指示生成器以迭代的方式工作，每次从规范中选取一个功能。每个迭代都使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）技术栈来实现应用程序，并指示生成器在每个迭代结束时进行自我评估，然后再移交给 QA。它还使用了 Git 进行版本控制。
评估员（Evaluator）： 早期框架中的应用程序通常看起来很棒，但实际使用时仍然存在一些实际的缺陷。为了发现这些缺陷，评估员使用 Playwright MCP 模拟用户操作，逐个点击运行中的应用程序，测试 UI 功能、API 端点和数据库状态。然后，评估员根据发现的缺陷以及一套基于前端实验构建的标准对每个迭代进行评分。这套标准经过调整，涵盖产品深度、功能、视觉设计和代码质量。每个标准都有一个硬性阈值，如果任何一项低于该阈值，则该迭代失败，生成器会收到关于失败原因的详细反馈。
每次迭代开始前，开发者和评估者都会协商一份迭代契约：在编写任何代码之前，就该部分工作的“完成”标准达成一致。之所以这样做，是因为产品规格说明有意写得比较概括，而我希望通过这一步骤来弥合用户故事和可测试实现之间的差距。开发者提出要构建的内容以及如何验证成功，评估者则审查该提案，以确保开发者构建的内容是正确的。双方反复沟通，直到达成一致。
通信通过文件进行：一个代理写入一个文件，另一个代理读取该文件并做出响应，响应内容可以是写入该文件本身，也可以是写入一个新文件，供之前的代理读取。生成器随后根据约定的协议进行构建，最后将工作成果交付给质量保证团队。这样既保证了工作成果忠实于规范，又避免了过早地过度定义实现细节。
Running the harness 运行线束
在这个测试框架的第一个版本中，我使用了 Claude Opus 4.5，并针对完整的测试框架和单代理系统运行用户提示以进行比较。之所以选择 Opus 4.5，是因为在开始这些实验时，这是我们当时最好的编码模型。
我编写了以下提示，以生成一个复古视频游戏制作工具：
创建一款 2D 复古游戏制作工具，其功能包括关卡编辑器、精灵编辑器、实体行为和可玩测试模式。
下表显示了安全带类型、运行长度和总成本。
Harness 马具 Duration 期间 Cost 成本
Solo 独自的 20 min 20分钟 $9
Full harness 全套安全带 6 hr 6小时 $200
The harness was over 20x more expensive, but the difference in output quality was immediately apparent.
虽然线束的价格贵了 20 多倍，但输出质量的差异立竿见影。
我原本以为会看到一个可以构建关卡及其组成部分（精灵、实体、图块布局）的界面，然后点击播放按钮即可实际游玩该关卡。我首先打开了单人游戏的输出文件，初始界面看起来与我的预期相符。
然而，随着我不断点击操作，问题开始显现。布局浪费空间，固定高度的面板导致视口大部分区域空空如也。工作流程也十分僵化。尝试填充关卡时，系统提示我先创建精灵和实体，但用户界面没有任何提示引导我完成这些步骤。更重要的是，游戏本身存在问题。我的实体出现在屏幕上，但对任何输入都没有反应。深入研究代码后发现，实体定义和游戏运行时之间的连接出现了故障，但表面上却找不到任何线索。
Opening screen 打开屏幕
Sprite editor 精灵编辑器
Game play 游戏玩法
Initial screen when opening the app created by the solo harness.
打开由 solo Harness 创建的应用程序时的初始屏幕。
在评估完单人测试后，我将注意力转向了团队测试。这次测试同样始于一句提示，但规划步骤将该提示扩展为一个包含 16 项功能的规范，并分十个迭代周期完成。这远远超出了单人测试的尝试范围。除了核心编辑器和游戏模式之外，规范还要求包含精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及带有可分享链接的游戏导出功能。我授予了规划器访问我们前端设计技能的权限，它读取并使用该技能为应用程序创建了一套视觉设计语言，作为规范的一部分。在每个迭代周期，生成器和评估器都会协商一份合同，明确该迭代周期的具体实现细节，以及用于验证完成情况的可测试行为。
与单人运行版本相比，该应用程序立即展现出更高的完善度和流畅度。画布充分利用了视口，面板尺寸合理，界面视觉风格一致，与规范中的设计方向相符。我在单人运行版本中发现的一些笨拙之处仍然存在——工作流程仍然没有明确提示用户在尝试填充关卡之前应该先创建精灵和实体，我不得不摸索一番才能弄明白。这与其说是该框架旨在解决的问题，不如说是基础模型产品直觉上的缺陷，尽管这也表明框架内部的针对性迭代可以进一步提升输出质量。
使用编辑器时，新模式相比单人模式的优势更加明显。精灵编辑器功能更丰富、更完善，工具面板更简洁，颜色选择器更好用，缩放控制也更便捷。
因为我要求规划器在其规格中融入人工智能功能，所以该应用程序还内置了 Claude 集成，让我可以通过提示生成游戏的不同部分。这大大加快了工作流程。
Opening screen 打开屏幕
Sprite editor 精灵编辑器
AI game design 人工智能游戏设计
AI game design 人工智能游戏设计
Game play 游戏玩法
Initial screen: Creating a new game, in the app built with the full harness
初始屏幕：在采用完整组件构建的应用程序中创建新游戏
最大的区别在于游戏模式。我终于可以控制角色移动并进行游戏了。物理引擎还有一些瑕疵——我的角色跳上平台后却和平台重叠了，这感觉很不自然——但核心功能是正常的，而单人游戏模式却没能做到这一点。稍微探索了一番之后，我发现 AI 在关卡设计上存在一些局限性。有一堵高墙我无法跳过，所以被困住了。这表明，该应用还有一些常识性的改进空间，并且可以通过一些特殊情况的处理来进一步完善。
阅读日志后可以明显看出，评估人员严格按照规范执行了开发工作。每个迭代周期，评估人员都会逐一检查迭代合同中的测试标准，并通过 Playwright 对运行中的应用程序进行测试，并对任何偏离预期行为的情况提交错误报告。合同非常细致——仅第三个迭代周期就包含了 27 条涵盖关卡编辑器的标准——评估人员的发现也足够具体，无需额外调查即可采取行动。下表列出了评估人员发现的一些问题示例：
Contract criterion 合同标准 Evaluator finding 评估员发现
Rectangle fill tool allows click-drag to fill a rectangular area with selected tile
矩形填充工具允许通过单击拖动来用选定的图块填充矩形区域。 FAIL — Tool only places tiles at drag start/end points instead of filling the region. fillRectangle function exists but isn’t triggered properly on mouseUp.
失败 ——该工具仅将图块放置在拖动的起点/终点，而不是填充区域。fillRectangle 函数存在，但在 fillRectangle 事件中未正确触发。
User can select and delete placed entity spawn points
用户可以选择并删除已放置的实体生成点 FAIL — Delete key handler at LevelEditor.tsx:892 requires both selection and selectedEntityId to be set, but clicking an entity only sets selectedEntityId. Condition should be selection || (selectedEntityId && activeLayer === ‘entity’).
失败 — LevelEditor.tsx:892 处的删除键处理程序需要同时设置 selection 和 selectedEntityId ，但单击实体只会设置 selectedEntityId 。条件应为 selection || (selectedEntityId && activeLayer === ‘entity’) 。
User can reorder animation frames via API
用户可以通过 API 重新排列动画帧的顺序。 FAIL — PUT /frames/reorder route defined after /{frame_id} routes. FastAPI matches ‘reorder’ as a frame_id integer and returns 422: “unable to parse string as an integer.”
失败 PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 ‘ eorder ‘ 匹配为 frame_id 整数，并返回 422：“无法将字符串解析为整数”。
要让评估器达到这个水平需要付出很多努力。Claude 本身并不是一个合格的质量保证代理。在早期运行中，我发现它虽然识别出了合理的问题，但却会自我安慰，认为这些问题无关紧要，最终还是批准了工作。它也倾向于进行表面测试，而不是深入探究各种极端情况，因此一些更隐蔽的 bug 常常被忽略。调整流程是读取评估器的日志，找出它判断与我不同的例子，并更新质量保证提示以解决这些问题。经过几轮这样的开发循环，评估器的评分方式才最终达到我认可的合理水平。即便如此，测试结果仍然显示出该模型质量保证能力的局限性：一些小的布局问题、某些地方交互体验不够直观，以及评估器尚未彻底测试的更深层嵌套功能中存在的未发现 bug。显然，通过进一步的调整，还有更大的验证空间。但与应用程序核心功能根本无法正常工作的单独运行相比，提升是显而易见的。
Iterating on the harness 反复测试线束
第一组测试结果令人鼓舞，但它也存在体积庞大、速度缓慢且成本高昂的问题。合乎逻辑的下一步是找到在不降低性能的前提下简化测试框架的方法。这部分是出于常识，部分则源于一个更普遍的原则：测试框架中的每个组件都包含着关于模型自身无法完成的任务的假设，而这些假设值得进行压力测试，因为它们可能并不正确，而且随着模型的改进，这些假设也会很快过时。我们的博文 《构建高效代理》 将这一基本理念概括为“找到尽可能简单的解决方案，仅在必要时才增加复杂性”，而对于任何维护代理测试框架的人来说，这都是一个反复出现的模式。
我第一次尝试简化时，大幅削减了安全带，并尝试了一些新的创意，但未能达到原有的性能。同时，也很难分辨安全带设计中哪些部件真正承重，以及它们是如何承重的。基于这次经验，我转而采用更系统的方法，每次移除一个部件，并评估其对最终结果的影响。
在进行这些迭代周期的同时，我们也发布了 Opus 4.6，这进一步激励我们降低框架的复杂性。我们有充分的理由预期 4.6 版本需要的脚手架会比 4.5 版本更少。正如我们在发布博客中所述： “Opus 4.6 的规划更加周密，能够更长时间地维持代理任务，在更大的代码库中运行更加可靠，并且拥有更好的代码审查和调试能力，可以发现自身的错误。” 它在长上下文检索方面也得到了显著改进。这些都是该框架旨在补充的功能。
Removing the sprint construct 移除冲刺结构
我首先彻底移除了迭代周期结构。迭代周期结构有助于将工作分解成若干小块，从而使模型能够协调一致地运行。鉴于 Opus 4.6 的改进，我们有理由相信，即使没有这种分解方式，模型也能原生处理这项工作。
我保留了规划器和评估器，因为它们都持续发挥着显而易见的价值。如果没有规划器，生成器的功能就会不足：给定原始提示，它会在没有事先明确功能需求的情况下就开始构建，最终生成的应用程序功能不如规划器生成的丰富。
移除冲刺机制后，我将评估器改为在每次运行结束时进行一次评估，而不是按冲刺进行评分。由于模型的功能大幅提升，评估器在某些运行中的负载也随之改变，其效用取决于任务相对于模型自身可靠处理能力的程度。在 4.5 版本中，这个临界点很近：我们的构建已经接近生成器独立处理能力的极限，评估器能够发现构建过程中出现的重要问题。在 4.6 版本中，模型的原始能力进一步增强，因此这个临界点向外扩展。过去需要评估器检查才能确保实现一致性的任务，现在通常都在生成器自身能够很好地处理的能力范围之内，对于这些范围内的任务，评估器就成了不必要的开销。但对于那些仍然处于生成器能力极限的构建部分，评估器仍然发挥着重要的作用。
实际意义在于，评估结果并非简单的“是”或“否”。当任务超出当前模型单独可靠完成的能力范围时，这种评估方式是值得的。
除了结构简化之外，我还添加了提示功能，以改进框架将 AI 功能集成到每个应用程序中的方式，特别是让生成器构建一个合适的代理，该代理能够通过工具驱动应用程序自身的功能。这需要反复迭代，因为相关知识比较新，Claude 的训练数据覆盖面不够广。但经过充分的调整，生成器最终能够正确地构建代理。
更新后的测试结果
为了测试更新后的线束，我使用以下提示符生成了一个数字音频工作站 (DAW)，这是一个用于作曲、录音和混音的音乐制作程序：
使用 Web Audio API 在浏览器中构建功能齐全的 DAW。
这次跑步活动仍然耗时很长，而且费用昂贵，大约需要 4 个小时，代币费用为 124 美元。
大部分时间都给了构建者，构建者连续运行了两个多小时，而没有像 Opus 4.5 那样进行冲刺分解。
Agent & Phase 代理和阶段 Duration 期间 Cost 成本
Planner 计划表 4.7 min 4.7分钟 $0.46
Build (Round 1) 构建（第一轮） 2 hr 7 min 2小时7分钟 $71.08
QA (Round 1) 质量保证（第一轮） 8.8 min 8.8分钟 $3.24
Build (Round 2) 构建（第二轮） 1 hr 2 min 1小时2分钟 $36.89
QA (Round 2) 质量保证（第二轮） 6.8 min 6.8分钟 $3.09
Build (Round 3) 构建（第三轮） 10.9 min 10.9分钟 $5.88
QA (Round 3) 质量保证（第三轮） 9.6 min 9.6分钟 $4.06
Total V2 Harness V2 型全套安全带 3 hr 50 min 3小时50分钟 $124.70
与之前的方案一样，规划器将一行提示信息扩展成了完整的规范。从日志中可以看出，生成器模型很好地完成了应用程序和代理的设计规划、代理的配置以及在交付给质量保证团队之前进行的测试。
尽管如此，质检人员还是发现了一些实际存在的问题。在第一轮反馈中，它指出：
这款应用功能强大，设计精美，AI 代理稳定可靠，后端也相当出色。其主要不足之处在于功能完整性——尽管应用界面令人印象深刻，AI 集成也运行良好，但一些核心的 DAW 功能仅供显示，缺乏交互深度：片段无法在时间线上拖拽/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化效果编辑器（均衡器曲线、压缩器电平表）。这些并非个别情况——它们是 DAW 可用的核心交互功能，规范中也明确要求具备这些功能。
在第二轮反馈中，它再次发现了一些功能上的不足：
Remaining gaps: 剩余缺口：
- 音频录制功能仍然很简陋（按钮可以切换，但没有麦克风拾音功能）
- 未实现通过边缘拖动调整剪辑大小和剪辑分割功能
- 效果可视化采用数值滑块，而非图形（无均衡曲线）。
即使让生成器自行运行，它仍然可能遗漏细节或缺少功能，而质量保证人员仍然能够发现这些最后阶段的问题，以便生成器进行修复。
根据提示，我原本以为会是一个可以让我创作旋律、和声和鼓点，并将它们编排成一首歌，同时还能获得内置助手帮助的程序。下面的视频展示了最终成果。
这款应用远非专业的音乐制作软件，经纪人的作曲能力显然还有待提高。此外，克劳德实际上听不见，这使得质量保证反馈机制在音乐品味方面效果不佳。
但最终的应用程序具备了功能齐全的音乐制作程序的所有核心组件：一个可正常工作的编曲视图、混音器和传输控制界面，全部运行在浏览器中。除此之外，我还能完全通过提示完成一小段歌曲：智能体设置了速度和调性，谱写了旋律，创建了鼓点，调整了混音器音量，并添加了混响。歌曲创作的核心要素一应俱全，智能体可以自主运行这些功能，使用各种工具完成从头到尾的简单制作。你可能会说它还不够完美——但它正在朝着这个方向发展。
What comes next 接下来会发生什么？
随着模型不断改进，我们可以大致预期它们能够运行更长时间，并处理更复杂的任务。在某些情况下，这意味着随着时间的推移，模型周围的框架的重要性会降低，开发人员可以等待下一代模型，并看到某些问题自行解决。另一方面，模型越好，就越有空间开发能够完成模型基线功能之外的复杂任务的框架。
鉴于此，这项工作中有一些值得借鉴的经验。始终对正在构建的模型进行实验，分析其在实际问题上的表现，并调整其性能以达到预期结果，这始终是一个好习惯。在处理更复杂的任务时，有时可以通过分解任务并针对问题的各个方面应用专门的代理来提升性能。此外，当新模型上线后，通常最好重新审视其架构，移除不再对性能产生影响的部分，并添加新的部分以实现以前可能无法实现的更强大的功能。
这项研究让我确信，随着模型的改进，有趣的硬件组合空间并不会缩小。相反，它会不断扩展，而人工智能工程师的真正乐趣在于不断寻找下一个新颖的组合。
Acknowledgements 致谢
Special thanks to Mike Krieger, Michael Agaby, Justin Young, Jeremy Hadfield, David Hershey, Julius Tarng, Xiaoyi Zhang, Barry Zhang, Orowa Sidker, Michael Tingley, Ibrahim Madha, Martina Long, and Canyon Robbins for their contributions to this work.
特别感谢 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 对这项工作的贡献。
Thanks also to Jake Eaton, Alyssa Leonard, and Stef Sequeira for their help shaping the post.
还要感谢 Jake Eaton、Alyssa Leonard 和 Stef Sequeira 对本文的撰写提供的帮助。
Appendix 附录
Example plan generated by planner agent.
由规划代理生成的示例计划。
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
- 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
…
我的思考
- 规划器，执行器，评估器，进化器，知识库