为长周期应用开发设计智能体框架

过去几个月，我一直在研究两个相互关联的问题：让 Claude 生成高质量的前端设计，以及让它无需人工干预就能构建完整的应用程序。这项工作源于我们早期在前端设计技能和长周期编码智能体框架上的努力，我和同事们通过提示工程和框架设计，成功将 Claude 的性能提升到远高于基线水平——但两者最终都遇到了瓶颈。

为了突破瓶颈，我探索了新颖的 AI 工程方法，这些方法适用于两个截然不同的领域：一个由主观审美定义，另一个由可验证的正确性和可用性定义。受生成对抗网络的启发，我设计了一个包含生成器和评估器智能体的多智能体结构。构建一个能够可靠评估输出（并且具备审美品味）的评估器，首先需要制定一套标准，将“这个设计好吗？”这类主观判断转化为具体、可分级的标准。

随后，我将这些技术应用于长周期自主编码，并借鉴了早期框架工作中的两个经验：将构建过程分解为可管理的模块，以及使用结构化工件在会话间传递上下文。最终成果是一个三智能体架构——规划器、生成器和评估器——能够在数小时的自主编码会话中生成丰富的全栈应用程序。

我们之前已经证明，框架设计对长周期智能体编码的有效性有重大影响。在早期的实验中，我们使用初始化智能体将产品规格分解为任务列表，并使用编码智能体逐个功能实现任务，然后通过传递工件在会话间保持上下文。更广泛的开发者社区也达成了类似见解，例如“Ralph Wiggum”方法使用钩子或脚本来保持智能体处于持续迭代循环中。

但一些问题仍然持续存在。对于更复杂的任务，智能体随着时间的推移仍然容易偏离轨道。在分解这个问题时，我们观察到智能体执行此类任务时常见的两种失败模式。

首先是模型在长任务上容易失去连贯性，因为上下文窗口会逐渐填满（参见我们关于上下文工程的文章）。一些模型还表现出“上下文焦虑”，即当它们接近自认为的上下文限制时，会过早地结束工作。上下文重置——完全清除上下文窗口并启动一个新的智能体，结合结构化交接来传递前一个智能体的状态和后续步骤——解决了这两个问题。

这与压缩不同，压缩是总结对话的早期部分，以便同一智能体能够在缩短的历史记录中继续工作。虽然压缩保持了连续性，但它没有给智能体一个干净的状态，这意味着上下文焦虑可能仍然存在。重置提供了一个干净的状态，代价是交接工件需要包含足够的状态，以便下一个智能体能够清晰地接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 表现出强烈的上下文焦虑，仅靠压缩不足以实现强大的长任务性能，因此上下文重置成为框架设计的关键。这解决了核心问题，但增加了每次框架运行的编排复杂性、令牌开销和延迟。

第二个问题是我们之前未曾解决的：自我评估。当要求评估自己完成的工作时，智能体倾向于自信地赞扬自己的工作——即使对人类观察者来说，质量明显平庸。这个问题在主观任务（如设计）中尤为突出，因为没有类似于可验证软件测试的二元检查。布局感觉精致还是普通是一种主观判断，智能体在评估自己的工作时总是偏向积极。

然而，即使在有可验证结果的任务上，智能体有时仍然表现出较差的判断力，从而影响其任务完成性能。将执行工作的智能体与评估工作的智能体分开，被证明是解决这个问题的有力杠杆。这种分离本身并不能立即消除这种宽容性；评估器仍然是一个倾向于对 LLM 生成输出宽容的 LLM。但调整一个独立的评估器使其保持怀疑态度，远比让生成器批判自己的工作要容易得多。一旦有了外部反馈，生成器就有了具体的迭代依据。

我从前端设计开始实验，因为自评估问题在这里最为明显。在没有干预的情况下，Claude 通常会倾向于安全、可预测的布局，这些布局在技术上功能完备，但视觉上平淡无奇。

我构建的前端设计框架基于两点洞察。首先，虽然美学无法完全简化为一个分数——个人品味总会有所不同——但可以通过编码了设计原则和偏好的评分标准来改进。"这个设计美吗？" 这个问题很难一致地回答，但"这个设计是否遵循了我们的优秀设计原则？"则为 Claude 提供了具体的评分依据。其次，通过将前端生成与前端评估分离，我们可以创建一个反馈循环，推动生成器产生更出色的输出。

基于此，我为生成器和评估器智能体在提示词中编写了四条评分标准：

我强调设计质量和原创性，而非工艺和功能性。Claude 在工艺和功能性上默认已经做得很好，因为所需的技术能力往往是模型自然具备的。但在设计和原创性方面，Claude 常常产生的结果充其量是平淡无奇的。这些标准明确惩罚了高度通用的"AI 垃圾"模式，并通过更重视设计和原创性，推动模型进行更具美学风险的尝试。

我使用带有详细分数分解的小样本示例来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了跨迭代的分数漂移。

我在 Claude Agent SDK 上构建了这个循环，这使得编排变得简单明了。生成器智能体首先根据用户提示创建一个 HTML/CSS/JS 前端。我为评估器提供了 Playwright MCP，使其能够在评分每条标准并撰写详细评论之前，直接与实时页面交互。在实践中，评估器会自行导航页面，截图并仔细研究实现，然后才进行评估。该反馈会作为下一次迭代的输入流回生成器。每次生成我运行 5 到 15 次迭代，每次迭代通常都会推动生成器朝着更具特色的方向发展，以响应评估器的批评。由于评估器是主动导航页面而非对静态截图评分，每个周期都需要实际的时间。完整的运行时间长达四个小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好，则完善当前方向；如果方法不奏效，则转向完全不同的美学风格。

在多次运行中，评估器的评估在迭代中有所改进，然后趋于平稳，但仍有提升空间。有些生成是渐进式完善的。另一些则在迭代之间发生了剧烈的美学转向。

评分标准的措辞以我未能完全预料的方式引导着生成器。包含诸如"最佳设计是博物馆级别的"这样的短语，将设计推向特定的视觉趋同，这表明与标准相关的提示词直接塑造了输出的特征。

虽然分数通常在迭代中有所提高，但这种模式并不总是完全线性的。后期的实现整体上往往更好，但我经常看到我更喜欢中间迭代而非最后一次迭代的情况。实现的复杂性也往往随着轮次增加而增加，生成器会响应评估器的反馈，寻求更雄心勃勃的解决方案。即使在第一次迭代中，输出也明显优于没有任何提示的基线，这表明评分标准及其相关语言本身在评估器反馈导致进一步优化之前，就已经引导模型远离了通用的默认模式。

在一个值得注意的例子中，我提示模型为一个荷兰艺术博物馆创建一个网站。到第九次迭代时，它已经为一个虚构的博物馆创建了一个简洁、深色主题的着陆页。该页面视觉上很精致，但基本符合我的预期。然后，在第十个周期，它完全抛弃了这种方法，将网站重新构想为一个空间体验：一个用 CSS 透视渲染的、带有棋盘格地板的 3D 房间，艺术品以自由形式的位置挂在墙上，画廊房间之间的导航基于门口而非滚动或点击。这是一种我之前从未在单次生成中见过的创造性飞跃。

基于这些发现，我将这种受GAN启发的模式应用到全栈开发中。生成器-评估器循环自然地映射到软件开发生命周期，其中代码审查和QA扮演着与设计评估器相同的结构性角色。

在我们早期的长周期运行框架中，我们通过初始化代理、按功能逐个工作的编码代理以及会话间的上下文重置，解决了多会话编码的连贯性问题。上下文重置是关键突破：该框架使用了Sonnet 4.5，该模型表现出前文提到的"上下文焦虑"倾向。创建一个能在上下文重置中良好工作的框架，是保持模型专注任务的关键。Opus 4.5在很大程度上自行消除了这种行为，因此我能够完全从这个框架中移除上下文重置。代理在整个构建过程中作为一个连续会话运行，Claude Agent SDK的自动压缩机制处理了上下文增长问题。

在这项工作中，我在原始框架的基础上构建了一个三代理系统，每个代理都针对我在先前运行中观察到的特定差距。该系统包含以下代理角色：

规划器： 我们之前的长周期运行框架要求用户预先提供详细规格说明。我希望自动化这一步，因此创建了一个规划器代理，它接收简单的1-4句话提示，并将其扩展为完整的产品规格说明。我提示它在范围上要有雄心，并专注于产品上下文和高级技术设计，而不是详细的技术实现。这种强调是因为担心如果规划器试图预先指定细粒度的技术细节并出错，规格说明中的错误会级联影响下游实现。更明智的做法似乎是约束代理要交付的成果，让它们在工作中自行找到实现路径。我还要求规划器寻找将AI功能融入产品规格说明的机会。（参见底部附录中的示例。）

生成器： 早期框架中"一次一个功能"的方法在范围管理方面效果良好。我在这里应用了类似的模型，指示生成器以冲刺方式工作，从规格说明中逐个选取功能进行实现。每个冲刺都使用React、Vite、FastAPI和SQLite（后来改为PostgreSQL）技术栈实现应用，并指示生成器在每个冲刺结束时进行自我评估，然后再交给QA。它还使用git进行版本控制。

评估器： 早期框架构建的应用通常看起来令人印象深刻，但在实际使用时仍然存在真正的错误。为了捕捉这些问题，评估器使用Playwright MCP像用户一样点击运行中的应用，测试UI功能、API端点和数据库状态。然后，它根据发现的错误和一组标准对每个冲刺进行评分，这些标准基于前端实验建模，并在此调整为涵盖产品深度、功能、视觉设计和代码质量。每个标准都有硬性阈值，如果任何一项低于阈值，冲刺就失败，生成器会收到关于问题所在的详细反馈。 在每个冲刺之前，生成器和评估器会协商一个冲刺契约：在编写任何代码之前，就这部分工作的"完成"标准达成一致。这是因为产品规格说明是故意保持高层次的，我需要一个步骤来弥合用户故事和可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，评估器审查该提案以确保生成器构建的是正确的东西。两者迭代直到达成一致。

通信通过文件处理：一个代理写入文件，另一个代理读取该文件并响应，要么在同一文件中，要么通过新文件，然后前一个代理再读取该文件。生成器然后根据商定的契约进行构建，再将工作交给QA。这确保了工作忠实于规格说明，而不会过早过度指定实现细节。

在这个测试框架的第一个版本中，我使用了 Claude Opus 4.5，分别用完整框架和单智能体系统运行用户提示以进行比较。我选择 Opus 4.5 是因为在我开始这些实验时，它是我们最好的编码模型。

我写了以下提示来生成一个复古视频游戏制作工具：

> 创建一个具有关卡编辑器、精灵编辑器、实体行为和可玩测试模式等功能的 2D 复古游戏制作工具。

下表显示了测试框架的类型、运行时长和总成本。

| 测试框架 | 运行时长 | 成本 | | --- | --- | --- | | 单智能体 | 20 分钟 | 9 美元 | | 完整框架 | 6 小时 | 200 美元 |

完整框架的成本高出 20 多倍，但输出质量的差异是显而易见的。

我期望的是一个可以构建关卡及其组成部分（精灵、实体、瓦片布局）的界面，然后点击播放即可实际游玩该关卡。我首先打开了单智能体运行的输出，初始应用程序似乎符合这些期望。

然而，当我点击操作时，问题开始浮现。布局浪费了空间，固定高度的面板导致视口大部分区域空置。工作流程僵化。尝试填充关卡时，系统提示我先创建精灵和实体，但用户界面中没有任何地方引导我遵循这个顺序。更重要的是，实际的游戏是损坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入代码后发现，实体定义和游戏运行时之间的连接是断开的，而且表面上没有任何迹象表明问题出在哪里。

打开由单智能体框架创建的应用程序时的初始屏幕。

在单智能体框架制作的精灵编辑器中创建精灵

尝试游玩我创建的关卡但未成功

评估完单智能体运行后，我将注意力转向了完整框架运行。这次运行从同一个一句话提示开始，但规划步骤将该提示扩展为一个包含 16 个功能、跨越十个冲刺周期的规格说明。它远远超出了单智能体运行的尝试范围。除了核心编辑器和游玩模式外，规格说明还要求包含精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及带有可分享链接的游戏导出功能。我让规划器访问了我们的前端设计技能，它读取并利用该技能为应用程序创建了视觉设计语言，作为规格说明的一部分。对于每个冲刺周期，生成器和评估器会协商一份合同，定义该冲刺的具体实现细节，以及用于验证完成情况的可测试行为。

该应用程序立即显示出比单智能体运行更精致和流畅的效果。画布使用了完整的视口，面板大小合理，界面具有一致的视觉标识，遵循了规格说明中的设计方向。我在单智能体运行中看到的一些笨拙之处仍然存在——工作流程仍然没有明确说明在尝试填充关卡之前应该先构建精灵和实体，我必须通过摸索来弄清楚这一点。这似乎是基础模型在产品直觉上的一个缺陷，而不是测试框架设计要解决的问题，尽管它确实表明，在框架内进行有针对性的迭代可以帮助进一步提高输出质量。

在使用各个编辑器的过程中，新运行相对于单智能体的优势变得更加明显。精灵编辑器更丰富、功能更全面，拥有更简洁的工具面板、更好的颜色选择器和更易用的缩放控件。

因为我要求规划器在其规格说明中融入 AI 功能，所以该应用程序还内置了 Claude 集成，让我可以通过提示生成游戏的不同部分。这显著加快了工作流程。

初始屏幕：在使用完整框架构建的应用程序中创建新游戏

精灵编辑器感觉更简洁、更易用

使用内置 AI 功能生成关卡

使用内置 AI 功能生成关卡

游玩我生成的游戏

最大的区别在于游玩模式。我实际上能够移动我的实体并游玩游戏。物理效果有一些粗糙的边缘——我的角色跳上一个平台，但最终与平台重叠，这感觉直觉上不对——但核心功能是有效的，而单智能体运行未能做到这一点。在移动了一会儿之后，我确实遇到了 AI 游戏关卡构建的一些限制。有一堵大墙我无法跳过，所以我被困住了。这表明测试框架可以处理一些常识性改进和边缘情况，以进一步优化应用程序。

阅读日志后，很明显评估器确保了实现与规格说明保持一致。每个冲刺周期，它都会遍历冲刺合同中的测试标准，并通过 Playwright 运行应用程序，对任何偏离预期行为的地方提交错误报告。合同非常细致——仅冲刺 3 就有 27 条标准，涵盖了关卡编辑器——而且评估器的发现足够具体，无需额外调查即可采取行动。下表显示了我们的评估器发现的几个问题示例：

| 合同标准 | 评估器发现 | | --- | --- | | 矩形填充工具允许通过点击拖动用选定瓦片填充矩形区域 | 失败 — 工具仅在拖动开始/结束点放置瓦片，而不是填充整个区域。fillRectangle 函数存在，但未在 mouseUp 时正确触发。 | | 用户可以选择并删除已放置的实体生成点 | 失败 — 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 能力的局限性：小的布局问题、某些地方感觉不直观的交互，以及评估器未彻底测试的更深层功能中未被发现的错误。显然，通过进一步调整，还有更多的验证空间可以挖掘。但与单智能体运行相比——其应用程序的核心功能根本无法工作——提升是显而易见的。

第一轮测试框架的结果令人鼓舞，但它也存在笨重、缓慢且成本高昂的问题。逻辑上的下一步是寻找简化测试框架的方法，同时不降低其性能。这既是常识使然，也遵循一个更普遍的原则：测试框架中的每个组件都编码了一个关于模型自身无法完成什么的假设，而这些假设值得进行压力测试，既因为它们可能不正确，也因为随着模型改进，它们可能很快过时。我们的博客文章《构建高效智能体》将这一核心理念概括为"寻找最简单的解决方案，仅在需要时增加复杂性"，对于任何维护智能体测试框架的人来说，这都是一种反复出现的模式。

在我首次尝试简化时，我大幅削减了测试框架的组件，并尝试了一些创新的新思路，但未能复现原始框架的性能。同时，我也难以分辨测试框架设计中哪些部分真正起到了关键作用，以及它们以何种方式发挥作用。基于这一经验，我转向了一种更系统化的方法：每次移除一个组件，并评估其对最终结果的影响。

在进行这些迭代周期的同时，我们还发布了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 小时，令牌成本为 124 美元。

大部分时间花在了构建阶段，它持续连贯地运行了两个多小时，而不需要像 Opus 4.5 那样进行冲刺分解。

<table class="Table-module-scss-module__Z3bHXa__table"><tbody><tr class="Table-module-scss-module__Z3bHXa__row"><td class="body-3"><strong data-imt-p="1">代理与阶段</strong></td><td class="body-3"><strong data-imt-p="1">持续时间</strong></td><td class="body-3"><strong data-imt-p="1">成本</strong></td></tr><tr class="Table-module-scss-module__Z3bHXa__row"><td class="body-3" data-imt-p="1">规划器</td><td class="body-3" data-imt-p="1">4.7 分钟</td><td class="body-3">$0.46</td></tr><tr class="Table-module-scss-module__Z3bHXa__row"><td class="body-3" data-imt-p="1">构建（第 1 轮）</td><td class="body-3" data-imt-p="1">2 小时 7 分钟</td><td class="body-3">$71.08</td></tr><tr class="Table-module-scss-module__Z3bHXa__row"><td class="body-3" data-imt-p="1">质量保证（第 1 轮）</td><td class="body-3" data-imt-p="1">8.8 分钟</td><td class="body-3">$3.24</td></tr><tr class="Table-module-scss-module__Z3bHXa__row"><td class="body-3" data-imt-p="1">构建（第 2 轮）</td><td class="body-3" data-imt-p="1">1 小时 2 分钟</td><td class="body-3">$36.89</td></tr><tr class="Table-module-scss-module__Z3bHXa__row"><td class="body-3" data-imt-p="1">质量保证（第 2 轮）</td><td class="body-3" data-imt-p="1">6.8 分钟</td><td class="body-3">$3.09</td></tr><tr class="Table-module-scss-module__Z3bHXa__row"><td class="body-3" data-imt-p="1">构建（第 3 轮）</td><td class="body-3" data-imt-p="1">10.9 分钟</td><td class="body-3">$5.88</td></tr><tr class="Table-module-scss-module__Z3bHXa__row"><td class="body-3" data-imt-p="1">质量保证（第 3 轮）</td><td class="body-3" data-imt-p="1">9.6 分钟</td><td class="body-3">$4.06</td></tr><tr class="Table-module-scss-module__Z3bHXa__row"><td class="body-3"><strong data-imt-p="1">V2 框架总计</strong></td><td class="body-3"><strong data-imt-p="1">3 小时 50 分钟</strong></td><td class="body-3"><strong>$124.70</strong></td></tr></tbody></table>

与之前的框架一样，规划器将一行提示词扩展为完整的规格说明。从日志中可以看出，生成模型在规划应用程序和代理设计、连接代理以及测试方面做得很好，然后才将其移交给质量保证。

尽管如此，质量保证代理仍然发现了真正的缺陷。在其第一轮反馈中，它指出：

> 这是一个强大的应用程序，具有出色的设计保真度、坚实的 AI 代理和良好的后端。主要的失败点是功能完整性——虽然应用程序看起来令人印象深刻，AI 集成也运行良好，但几个核心的 DAW 功能只是显示而已，缺乏交互深度：片段不能在时间线上拖拽/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有视觉效果编辑器（EQ 曲线、压缩器仪表）。这些不是边缘情况——它们是使 DAW 可用的核心交互，而规格说明明确要求了这些功能。

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

> 剩余的缺陷： > - 音频录制仍然是存根（按钮可以切换但没有麦克风捕获） > - 通过边缘拖拽调整片段大小和片段分割功能未实现 > - 效果可视化是数字滑块，而非图形化（没有 EQ 曲线）

生成器在自行其是时仍然容易遗漏细节或使用存根功能，而质量保证在发现这些最后阶段的问题供生成器修复方面仍然具有价值。

根据提示词，我期望得到一个可以创作旋律、和声和鼓点模式，将它们编排成歌曲，并在此过程中获得集成代理帮助的程序。下面的视频展示了结果。

这个应用程序远非专业的音乐制作程序，代理的歌曲创作能力显然还需要大量改进。此外，Claude 实际上无法“听”音乐，这使得质量保证反馈循环在音乐品味方面效果较差。

但最终的应用程序具备了功能性音乐制作程序的所有核心部分：一个在浏览器中运行的工作编排视图、混音器和传输控制。除此之外，我能够完全通过提示词组合出一个简短的歌曲片段：代理设置了节奏和调性，铺设了旋律，构建了鼓点轨道，调整了混音器电平，并添加了混响。歌曲创作的核心原语已经存在，代理可以自主驱动它们，使用工具从头到尾创建一个简单的作品。你可能会说它还不够完美——但它正在朝着这个方向前进。

随着模型不断改进，我们大致可以预期它们能够处理更长时间、更复杂的任务。在某些情况下，这意味着围绕模型的脚手架随着时间的推移变得不那么重要，开发者可以等待下一个模型，看着某些问题自行解决。另一方面，模型变得越好，就有越大的空间来开发能够实现超出模型基线能力的复杂任务的框架。

考虑到这一点，从这项工作中可以得出一些值得延续的经验教训。始终良好的做法是：针对你正在构建的模型进行实验，在现实问题上阅读其跟踪记录，并调整其性能以达到期望的结果。在处理更复杂的任务时，有时可以通过分解任务并对问题的每个方面应用专门的代理来获得提升空间。当新模型出现时，通常良好的做法是重新审视框架，移除那些不再对性能起关键作用的部分，并添加新的部分以实现以前可能无法达到的更强能力。

从这项工作中，我确信，随着模型的改进，有趣的框架组合空间并不会缩小。相反，它会移动，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 位游戏美学的怀旧魅力与现代直观的编辑工具相结合，使从业余爱好者到独立开发者的任何人都能在无需编写传统代码的情况下，将他们的游戏创意变为现实。

该平台提供四个集成的创意模块：用于设计游戏世界的基于图块的关卡编辑器、用于制作视觉资源的像素艺术精灵编辑器、用于定义游戏逻辑的可视化实体行为系统，以及用于实时游戏测试的即时可玩测试模式。通过在整个过程中融入 AI 辅助（由 Claude 驱动），RetroForge 加速了创作过程——帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。

RetroForge 的目标用户是热爱复古游戏美学但又希望享受现代便利的创作者。无论是重制他们童年时代的平台游戏、RPG 还是动作游戏，还是在复古限制内创造全新的体验，用户都可以快速制作原型、可视化迭代并与他人分享他们的创作。

功能
1. 项目仪表板与管理
项目仪表板是 RetroForge 中所有创意工作的基地。用户需要一个清晰、有组织的方式来管理他们的游戏项目——创建新项目、返回进行中的工作，并一目了然地了解每个项目包含的内容。

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

- 创建一个具有名称和描述的新游戏项目，以便开始设计我的游戏
- 查看我所有现有项目，以视觉卡片形式显示项目名称、最后修改日期和缩略图预览，以便快速找到并继续我的工作
- 打开任何项目以进入完整的游戏编辑器工作区，以便处理我的游戏
- 删除我不再需要的项目，并带有确认对话框以防止误操作，以便保持工作区整洁
- 复制现有项目作为新游戏的起点，以便重用我之前的工作

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

项目元数据（名称、描述、创建/修改时间戳）
画布设置（分辨率：例如 256x224、320x240 或 160x144）
图块大小配置（8x8、16x16 或 32x32 像素）
调色板选择
所有关联的精灵、图块集、关卡和实体定义

...