作者：Prithvi Rajasekaran (Anthropic Labs Team)
发布日期：2026年3月24日

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

为了突破这一瓶颈，我寻找了适用于两个截然不同领域的新型 AI 工程方法，一个由主观品味定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GANs）的启发，我设计了一个包含生成器和评估器智能体的多智能体结构。构建一个能够可靠地——并且有品味地——评分输出的评估器，意味着首先要开发一套标准，能够将"这个设计好吗？“这样的主观判断转化为具体的、可评分的术语。

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

为什么简单实现会失败

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

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

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

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

第二个问题是自我评估，我们之前没有解决过。当被要求评估自己产出的工作时，智能体倾向于自信地赞扬这些工作——即使对人类观察者来说，质量明显平庸。这个问题在设计等主观任务上尤为突出，因为没有类似可验证软件测试的二元检查。布局是否感觉精致或普通是一个判断性问题，而智能体在评分自己的工作时可靠地倾向于积极评价。

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

前端设计：让主观质量可评分

我从前端设计开始实验，因为自我评估问题在这里最为明显。在没有任何干预的情况下，Claude 通常倾向于安全、可预测的布局，这些布局在技术上是功能性的，但在视觉上并不出众。

两个见解塑造了我为前端设计构建的框架。首先，虽然美学不能完全简化为分数——个人品味总是会有所不同——但可以通过编码设计原则和偏好的评分标准来改进它们。“这个设计漂亮吗？“很难一致地回答，但"这是否遵循我们的良好设计原则？“给了 Claude 一些具体的评分依据。其次，通过将前端生成与前端评分分离，我们可以创建一个反馈循环，推动生成器产出更强的输出。

考虑到这一点，我编写了四个评分标准，并将它们提供给生成器和评估器智能体的提示中：

设计质量： 设计是否感觉像一个连贯的整体，而不是部分的集合？这方面的强大工作意味着颜色、排版、布局、图像和其他细节结合起来创造出独特的氛围和身份。

原创性： 是否有自定义决策的证据，还是这只是模板布局、库默认值和 AI 生成的模式？人类设计师应该能够识别出深思熟虑的创意选择。未修改的库存组件——或 AI 生成的明显迹象，如白色卡片上的紫色渐变——在这里会失败。

工艺： 技术执行：排版层次、间距一致性、色彩和谐、对比度。这是能力检查而不是创造力检查。大多数合理的实现默认情况下在这里表现良好；失败意味着基础被破坏。

功能性： 独立于美学的可用性。用户能否理解界面的功能，找到主要操作，并在不猜测的情况下完成任务？

我强调设计质量和原创性而不是工艺和功能性。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 倍，但输出质量的差异立即显现。

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

然而，当我点击浏览时，问题开始出现。布局浪费空间，固定高度的面板使大部分视口空着。工作流程很僵硬。尝试填充关卡会提示我首先创建精灵和实体，但 UI 中没有任何东西引导我进入该序列。更重要的是，实际的游戏是坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入代码发现，实体定义和游戏运行时之间的连接是断开的，没有表面迹象表明问题出在哪里。

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

该应用程序立即显示出比单智能体运行更多的精致和流畅性。画布使用了完整的视口，面板大小合理，界面具有与规格中的设计方向一致的一致视觉身份。我在单智能体运行中看到的一些笨拙确实仍然存在——工作流程仍然没有明确表示你应该在尝试填充关卡之前构建精灵和实体，我不得不通过摸索来弄清楚这一点。这被解读为基础模型产品直觉的差距，而不是框架旨在解决的问题，尽管它确实表明了框架内有针对性的迭代可以进一步改善输出质量的地方。

浏览编辑器时，新运行相对于单智能体的优势变得更加明显。精灵编辑器更丰富、功能更全面，具有更清晰的工具调色板、更好的颜色选择器和更可用的缩放控件。

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

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

阅读日志，很明显评估器使实现与规格保持一致。每个冲刺，它都会遍历冲刺合同的测试标准，并通过 Playwright 执行运行中的应用程序，对任何偏离预期行为的内容提交错误。合同是细粒度的——仅 Sprint 3 就有 27 个涵盖关卡编辑器的标准——评估器的发现足够具体，可以在不进行额外调查的情况下采取行动。下表显示了我们的评估器识别的几个问题示例：

让评估器达到这个水平需要工作。开箱即用，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 需要的冲刺分解的情况下连贯地运行了两个多小时。

与之前的框架一样，规划器将一行提示扩展为完整的规格。从日志中，我可以看到生成器模型在规划应用程序和智能体设计、连接智能体以及在交给 QA 之前测试它方面做得很好。

话虽如此，QA 智能体仍然捕获了真正的差距。在其第一轮反馈中，它指出：

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

在其第二轮反馈中，它再次捕获了几个功能差距：

剩余差距：

• 音频录制仍然只是存根（按钮切换但没有麦克风捕获）
• 通过边缘拖动调整片段大小和片段分割未实现
• 效果可视化是数字滑块，而不是图形（没有 EQ 曲线）

生成器在自行处理时仍然容易遗漏细节或存根功能，QA 在捕获这些最后一英里问题以供生成器修复方面仍然增加了价值。

根据提示，我期望的是一个程序，我可以在其中创建旋律、和声和鼓模式，将它们编排成一首歌曲，并在此过程中从集成的智能体获得帮助。下面的视频显示了结果。

该应用程序远非专业的音乐制作程序，智能体的歌曲创作技能显然还需要大量工作。此外，Claude 实际上听不到声音，这使得 QA 反馈循环在音乐品味方面效果较差。

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

接下来是什么

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

考虑到这一点，这项工作中有几个值得继续发扬的经验教训。实验你正在构建的模型、阅读其在现实问题上的跟踪并调整其性能以实现你期望的结果始终是良好的实践。在处理更复杂的任务时，有时可以通过分解任务并将专门的智能体应用于问题的每个方面来获得改进空间。当新模型发布时，重新审查框架通常是良好的实践，剥离不再对性能承重的部分，并添加新部分以实现以前可能无法实现的更大能力。

从这项工作中，我的信念是，随着模型的改进，有趣的框架组合空间不会缩小。相反，它会移动，AI 工程师的有趣工作是不断寻找下一个新颖的组合。

致谢

特别感谢 Alex Albert、Erik Schluntz、Mike Krieger 和 Zack Witten 对这项工作的贡献和反馈。