本文作者 Prithvi Rajasekaran，Labs 团队成员。
过去几个月，我一直在攻克两个彼此交织的难题：让 Claude 产出高质量的前端设计，以及让它在没有人工干预的情况下独立构建完整应用。这项工作源于我们此前在前端设计技能（frontend design skill）和长时间编码智能体编排框架（harness）上的探索——我和同事们通过提示工程与编排框架设计，将 Claude 的表现大幅提升到了远超基线的水平，但最终都遇到了天花板。
为了突破瓶颈，我开始寻找能够在两个截然不同的领域都奏效的 AI 工程方法——一个领域由主观审美定义，另一个则由可验证的正确性和易用性衡量。受生成对抗网络（GAN）的启发，我设计了一种由**生成器**（generator）和**评估器**（evaluator）组成的多智能体结构。要打造一个既能可靠打分、又具备审美品味的评估器，首先意味着我需要制定一套标准，把”这个设计好不好？“这样的主观判断转化为具体的、可量化的评价维度。
随后，我将这些方法迁移到了长时间自主编码场景中，并带上了早期编排框架工作的两个核心经验：将构建任务分解为可管控的小块，以及使用结构化工件在会话间传递上下文。最终，我搭建了一个由规划器（planner）、生成器（generator）和评估器（evaluator）组成的三智能体架构，能够在长达数小时的自主编码过程中产出功能丰富的全栈应用。
为什么朴素的实现方式力不从心
我们此前已经展示过，编排框架的设计对长时间智能体编码的效果有着显著影响。在早期的一次实验中，我们使用一个初始化智能体将产品规格分解为任务列表，然后由编码智能体逐个实现功能，最后通过交接工件在会话间传递上下文。更广泛的开发者社区也得出了类似的结论，比如”Ralph Wiggum”方法（社区对一种让 AI 智能体持续迭代的工程方法的俗称，名称源自《辛普森一家》中的角色），通过钩子或脚本让智能体持续处于迭代循环中。
但有些问题始终挥之不去。面对更复杂的任务，智能体仍然会随着时间推移逐渐脱轨。深入拆解这个问题后，我们观察到智能体在执行此类任务时有两种常见的失败模式。
第一种是模型在长任务中随着上下文窗口的填满而逐渐失去连贯性（参见我们关于上下文工程的文章）。部分模型还会表现出”上下文焦虑”（context anxiety）——当它们认为自己正在逼近上下文窗口的极限时，就会提前开始收尾工作。上下文重置（context resets）——即彻底清空上下文窗口、启动一个全新的智能体，同时通过结构化的交接将前一个智能体的状态和后续步骤传递过去——能够同时解决这两个问题。
这与上下文压缩（compaction）有所不同。压缩是对对话早期部分进行原地摘要，让同一个智能体在缩短后的历史上继续工作。虽然压缩保持了连续性，但它无法给智能体一个全新的起点，这意味着上下文焦虑仍然可能持续存在。重置则提供了一个全新的起点，代价是交接工件必须包含足够的状态信息，以便下一个智能体能顺利接手。在早期测试中，我们发现 Claude Sonnet 4.5 表现出的上下文焦虑强烈到仅靠压缩不足以支撑长任务的出色表现，因此上下文重置成为了编排框架设计中不可或缺的一环。这解决了核心问题，但也给每次编排运行增加了编排复杂度、token 开销和延迟。
第二个问题是我们此前未曾正面处理的：自我评估（self-evaluation）。当要求智能体评价自己的产出时，它们往往会自信满满地大加赞赏——哪怕在人类观察者看来，质量明显平庸。这个问题在设计这类主观任务中尤为突出，因为不存在像可验证的软件测试那样的二元检查。一个布局是精致还是平庸，本质上是一个判断问题，而智能体在给自己打分时可靠地偏向正面。
不过，即便是在有可验证结果的任务中，智能体有时也会在执行过程中表现出糟糕的判断力，拖累自身表现。将”做事的智能体”和”评判的智能体”分离开来，证明了这是解决这一问题的有力杠杆。这种分离本身并不会立刻消除宽松倾向——评估器仍然是一个 LLM，天然倾向于对 LLM 生成的内容手下留情。但调教一个独立的评估器使其保持怀疑态度，远比让生成器对自己的作品变得挑剔要容易得多；而一旦有了这种外部反馈，生成器就有了具体的迭代目标。
前端设计：让主观质量变得可评分
我从前端设计入手展开实验，因为自我评估的问题在这里表现得最为明显。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局——功能上没问题，但视觉上毫无亮点。
两个关键洞察塑造了我为前端设计构建的编排框架。首先，虽然审美不可能完全被量化为一个分数——个人品味也永远因人而异——但通过编码设计原则和偏好的评分标准，审美是可以被提升的。“这个设计美不美？“很难得到一致的回答，但”它是否遵循了我们定义的好设计原则？“则给了 Claude 一个具体的打分依据。其次，将前端生成与前端评分分离，可以构建出一个驱动生成器产出更强结果的反馈循环。
基于这些思考，我撰写了四条评分标准，同时写入了生成器和评估器的提示词中：
- 设计质量： 设计是否呈现为一个连贯的整体，而非零件的堆砌？这项指标的高分意味着配色、字体、布局、图像及其他细节共同营造出了一种独特的氛围和品牌感。
- 原创性： 是否有自主设计的痕迹，还是在照搬模板布局、组件库默认样式和 AI 生成的套路？人类设计师应该能辨认出有意为之的创意抉择。未经修改的现成组件——或紫色渐变搭配白色卡片这类 AI 生成的典型特征——在此项不及格。
- 工艺： 技术执行层面：字体层级、间距一致性、配色和谐度、对比度。这是一项能力检验而非创意检验。大多数合理的实现默认就能做到不错；不及格意味着基本功有硬伤。
- 功能性： 脱离美学来看的可用性。用户是否能理解界面的功能、找到主要操作入口、不靠猜测就能完成任务？
我刻意强调设计质量和原创性的权重高于工艺和功能性。Claude 在工艺和功能性方面默认得分就不错，因为模型天然具备所需的技术能力。但在设计和原创性上，Claude 的产出往往乏善可陈。评分标准中明确对高度雷同的”AI 味十足的平庸设计”进行扣分，同时通过加大设计和原创性的权重，推动模型在审美上更敢于冒险。
我使用包含详细评分拆解的少样本示例（few-shot examples）来校准评估器。这确保了评估器的判断与我的偏好对齐，也减少了跨迭代的评分漂移。
整个循环构建在 Claude Agent SDK 之上，编排逻辑因此相当简洁。生成器智能体首先根据用户提示生成一个 HTML/CSS/JS 前端。我给评估器配备了 Playwright MCP，使其能直接与页面进行实时交互，然后对每一项标准打分并撰写详细的评语。在实际运行中，评估器会自主浏览页面，截图并仔细审视实现效果，之后才给出评估。这些反馈作为输入流回生成器，供下一轮迭代使用。每次生成我会运行 5 到 15 轮迭代，每一轮通常都会推动生成器朝着更具辨识度的方向演进——因为它在回应评估器的批评。由于评估器是在实际浏览页面而非审视静态截图，每个循环都需要真实的实际耗时（wall-clock time），完整运行可以长达四个小时。我还要求生成器在每次评估后做出策略性决策：如果分数趋势向好，就继续打磨当前方向；如果当前路线行不通，就彻底转向一种全新的审美。
纵观多次运行，评估器的评分在迭代过程中先升后趋于平稳，且仍有提升空间。有些生成过程是渐进式打磨，另一些则在迭代之间经历了剧烈的审美转向。
评分标准中的措辞以出人意料的方式引导了生成器。比如加入”最好的设计达到博物馆级别”这样的表述后，设计产出呈现出某种视觉趋同，这表明与评分标准关联的提示词直接塑造了输出的风格特征。
虽然分数总体上随迭代提升，但并非总是线性递增。后期的实现整体上往往更好，但我经常发现自己更偏爱某个中间迭代而非最终版本。实现的复杂度也倾向于随轮次递增——生成器在评估器的反馈驱动下不断追求更有野心的方案。值得注意的是，即便在第一轮迭代中，产出就已明显优于完全没有提示工程的基线，这说明评分标准本身及其关联的表述就足以让模型偏离千篇一律的默认风格，而评估器的反馈则带来了进一步的精进。
荷兰艺术博物馆案例
我让模型为一家荷兰艺术博物馆创建网站。到第九轮迭代时，它交出了一个干净的深色主题着陆页，服务于一家虚构的博物馆。页面视觉上颇为精致，但基本在我的预期范围内。然而到了第十轮，它推翻了整个方案，将网站重新构想为一种空间体验：一个用 CSS 透视渲染的带有棋盘格地板的 3D 房间，艺术品以自由布局的方式悬挂在墙壁上，通过门廊而非滚动或点击来导航不同的展厅。这种创造性的飞跃，是我在单次生成中从未见过的。
扩展到全栈开发
有了前面的这些发现，我把这个受 GAN 启发的模式应用到了全栈开发中。生成器-评估器循环天然地映射到软件开发生命周期上——代码评审和 QA（质量保证）在结构上扮演的角色，与设计评估器如出一辙。
架构设计
在我们之前的长时间运行编排框架中，我们已经解决了跨多会话的连贯编码问题：通过一个初始化智能体、一个逐个处理功能的编码智能体，以及会话之间的上下文重置来实现。上下文重置是一个关键突破——当时的编排框架使用 Sonnet 4.5，而这个模型表现出了前面提到的”上下文焦虑”倾向。打造一个能在上下文重置之间良好运作的编排框架，是让模型保持专注的关键。Opus 4.5 基本上自行消除了这种行为，因此我得以从这个编排框架中完全移除上下文重置。所有智能体作为一个连续会话贯穿整个构建过程，由 Claude Agent SDK 的自动上下文压缩机制沿途处理上下文增长的问题。
在这项工作中，我在原有编排框架的基础上构建了一个三智能体系统，每个智能体针对我在之前运行中观察到的特定短板。系统包含以下智能体角色：
规划器： 我们之前的长时间运行编排框架要求用户在开始前提供详细的规格说明。我想把这一步自动化，于是创建了一个规划器智能体，它接收一段简短的 1-4 句提示，然后扩展成完整的产品规格。我在提示中要求它对范围保持雄心，同时聚焦于产品上下文和高层技术设计，而非细节化的技术实现。这样做是因为我担心：如果规划器试图预先指定细粒度的技术细节却出了差错，规格说明中的错误会级联传导到下游实现中。更聪明的做法是约束智能体要交付的成果，让它们在工作过程中自行摸索路径。我还要求规划器在产品规格中寻找机会融入 AI 功能。（示例见文末附录。）
生成器： 之前编排框架中逐个功能推进的方式在范围管理上效果很好。我在这里采用了类似的模型，指示生成器以冲刺（sprint）的方式工作，每次从规格中选取一个功能来实现。每个冲刺使用 React、Vite、FastAPI 和 SQLite（后来换成 PostgreSQL）技术栈来实现应用，生成器被要求在每个冲刺结束时进行自我评估，然后再移交给 QA。它还使用 git 进行版本控制。
评估器： 之前编排框架产出的应用看起来往往令人印象深刻，但当你真正去用的时候，还是有不少真实的 bug。为了捕获这些问题，评估器使用 Playwright MCP 像真实用户那样点击运行中的应用，测试 UI 功能、API 端点和数据库状态。然后，它按照一套改编自前端实验的评分标准对每个冲刺进行打分，这些标准覆盖了产品深度、功能性、视觉设计和代码质量。每个标准都有硬性阈值，任何一项低于阈值，该冲刺就判定失败，生成器会收到关于问题所在的详细反馈。
在每个冲刺开始前，生成器和评估器会协商一份冲刺合约（sprint contract）：在写任何代码之前，先就”完成”的定义达成共识。之所以需要这一步，是因为产品规格有意保持在高层次，而我需要一个环节来弥合用户故事和可测试实现之间的鸿沟。生成器提出它要构建什么以及如何验证成功，评估器审查这个提案以确保生成器在做正确的事。双方反复迭代，直到达成一致。
通信通过文件来完成：一个智能体写文件，另一个读取并在文件内回复，或者创建一个新文件供前一个智能体读取。然后生成器按照商定的合约进行构建，完成后移交给 QA。这种方式使工作忠实于规格说明，同时避免过早地过度指定实现细节。
运行编排框架
对于这个编排框架的第一个版本，我使用了 Claude Opus 4.5，将用户提示分别跑在完整编排框架和单智能体系统上进行对比。我选择 Opus 4.5，因为那时它是我们最好的编码模型。
我写了如下提示来生成一个复古电子游戏制作器：
创建一个 2D 复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为系统，以及可玩的测试模式。
下表展示了编排框架类型、运行时长和总成本。
| 编排框架 | 耗时 | 成本 |
|---|---|---|
| 单智能体 | 20 分钟 | $9 |
| 完整编排框架 | 6 小时 | $200 |
编排框架的成本超过了 20 倍，但输出质量的差距一目了然。
我期望得到的是这样一个界面：我可以构建一个关卡及其组成部分（精灵、实体、地图布局），然后点击播放来实际体验这个关卡。我先打开了单智能体的输出，初始界面看起来似乎符合预期。
然而随着我的点击探索，问题开始浮现。布局浪费了大量空间，固定高度的面板使得视口大部分区域空空如也。工作流程也很死板。当我尝试填充关卡时，系统提示我需要先创建精灵和实体，但 UI 中没有任何引导来指明这个操作顺序。更关键的是，游戏本身是坏的。我的实体出现在了屏幕上，但没有任何东西响应输入。深入代码后发现，实体定义和游戏运行时之间的连接是断裂的，而且界面上没有任何线索表明问题出在哪里。
打开单智能体编排框架创建的应用时的初始界面。
在评估完单智能体的结果后，我把注意力转向了编排框架的输出。这次运行同样从那一句话的提示开始，但规划器将其扩展成了一份包含 16 个功能、分布在 10 个冲刺中的规格说明。它远远超越了单智能体所尝试的范围。除了核心的编辑器和游戏模式外，规格还涵盖了精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及支持分享链接的游戏导出功能。我给了规划器访问我们前端设计技能的权限，它读取并利用这些内容，在规格说明中为应用创建了一套视觉设计语言。对于每个冲刺，生成器和评估器会协商一份合约，定义该冲刺的具体实现细节以及用于验证完成情况的可测试行为。
应用立刻展现出比单智能体更高的精致度和流畅度。画布占满了整个视口，面板尺寸合理，界面有着与规格说明中的设计方向一致的统一视觉风格。单智能体中看到的一些笨拙之处依然存在——工作流程仍然没有清楚地告诉你应该先构建精灵和实体再去填充关卡，我得自己摸索着搞明白。这更像是基础模型在产品直觉上的不足，而非编排框架设计上的问题，不过这也提示了一个方向：在编排框架内进行针对性的迭代，或许能进一步提升输出质量。
深入使用各个编辑器后，编排框架相对于单智能体的优势变得更加明显。精灵编辑器更丰富、功能更完整，拥有更整洁的工具面板、更好用的取色器和更实用的缩放控件。
因为我要求规划器在规格说明中融入 AI 功能，这个应用还自带了一个 Claude 集成，让我可以通过提示来生成游戏的各个组成部分。这显著加速了工作流程。
初始界面：在完整编排框架构建的应用中创建新游戏
最大的差异体现在游戏模式上。我确实能够移动角色并玩这个游戏了。物理效果还有些粗糙——我的角色跳上了一个平台但最终与平台重叠，这在直觉上感觉不对——但核心功能是能跑的，而单智能体版本连这一点都没做到。移动一阵之后，我也确实遇到了 AI 构建的游戏关卡的一些局限。有一堵大墙我怎么也跳不过去，就卡住了。这说明编排框架在处理常识性改进和边缘情况方面还有提升空间，可以进一步打磨应用。
阅读日志后，评估器将实现牢牢地拉在了规格说明的轨道上，这一点一目了然。每个冲刺，它都会遍历冲刺合约中的测试标准，通过 Playwright 操作运行中的应用，对任何偏离预期行为的地方提交 bug。这些合约非常细致——仅冲刺 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 错误：“unable to parse string as an integer。” |
让评估器达到这种水准是下了功夫的。开箱即用的 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（Digital Audio Workstation），即一个用于作曲、录音和混音的音乐制作程序：
使用 Web Audio API 在浏览器中构建一个功能完整的 DAW。
这次运行依然耗时且昂贵，大约 4 小时，token 成本 $124。
大部分时间花在了构建器上，它在没有 Opus 4.5 所需的冲刺分解的情况下，连贯运行了超过两个小时。
| 智能体与阶段 | 耗时 | 成本 |
|---|---|---|
| 规划器 | 4.7 分钟 | $0.46 |
| 构建（第 1 轮） | 2 小时 7 分钟 | $71.08 |
| QA（第 1 轮） | 8.8 分钟 | $3.24 |
| 构建（第 2 轮） | 1 小时 2 分钟 | $36.89 |
| QA（第 2 轮） | 6.8 分钟 | $3.09 |
| 构建（第 3 轮） | 10.9 分钟 | $5.88 |
| QA（第 3 轮） | 9.6 分钟 | $4.06 |
| V2 编排框架总计 | 3 小时 50 分钟 | $124.70 |
与之前的编排框架一样，规划器将一行提示扩展成了完整的规格说明。从日志中可以看到，生成器在规划应用和智能体设计、连接智能体、以及移交 QA 前的测试方面都做得很好。
话虽如此，QA 智能体仍然捕获了真实的不足。在第一轮反馈中，它指出：
这是一个设计还原度高、AI 智能体扎实、后端良好的强大应用。主要失败点在功能完整性上——虽然应用外观令人印象深刻且 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
...