用于长期运行的应用开发Agent架构设计｜Anthropic

为什么简单方案通常不够用

我们之前已经证明，长期运行的代理编码是否高效，架构设计影响很大。

在更早的实验里，我们让一个初始化代理先把产品规格拆成任务清单，再让编码代理逐项实现，并用结构化制品（Artifacts）在不同会话之间传递上下文。

很多开发者社区也得出了相似结论。比如用钩子或脚本让代理一直循环迭代的“Ralph Wiggum”方法，本质上也是同一种思路。

但问题仍然存在。任务一复杂，代理往往会越来越偏离目标。分析后我们发现，代理做这类长任务时，常见的故障模式主要有两种。

第一种问题是：任务一旦拉长、上下文窗口逐渐塞满，模型往往会失去连贯性（可以参考我们关于AI 代理上下文工程的文章）。有些模型还会出现“上下文焦虑”：一旦它觉得自己快接近上下文上限，就会过早结束工作。

我们发现，用“上下文重置”——也就是彻底清空上下文窗口，重新启动一个新代理，再通过结构化移交把上一个代理的状态和下一步工作带过去——能同时解决这两个问题。

这和“压缩”不同。

压缩是把对话早期内容就地总结一下，让同一个代理继续在缩短后的历史记录上工作。

压缩能保留连续性，但不能给代理一个真正干净的新起点，所以“上下文焦虑”仍然会存在。

上下文重置则给了代理一个全新起点，但代价是移交制品必须带足够多的状态信息，才能让下一个代理顺利接手。

在我们之前的测试里，Claude Sonnet 4.5 的“上下文焦虑”特别明显，所以只靠压缩根本不够，上下文重置最终成了整个架构的核心。它确实解决了关键问题，但也带来了更复杂的编排、更高的 Token 成本和更长的运行延迟。

第二个我们之前没有解决好的问题，是“自我评估”。

当代理被要求评价自己做的工作时，它通常会非常自信地夸自己的成果——哪怕在人类看来，质量其实只是一般，甚至明显不够好。

这个问题在设计这类主观任务里尤其严重，因为它不像软件测试那样有清晰的对错判断。一个布局到底是精致还是平庸，本身就是主观判断，而代理在给自己打分时，通常会天然偏向正面评价。

不过，即使是在有明确可验证结果的任务里，代理有时判断力也不够好，反而会妨碍任务完成。把“负责执行”的代理和“负责评估”的代理分开，是解决这个问题的有效方法。这样做当然不能自动消除宽容偏差；评估器本质上仍是一个 LLM，也仍可能对 AI 生成内容更宽容。但相比让生成器批评自己，让一个独立评估器被调教成“更怀疑、更严格”，要容易得多。一旦外部反馈建立起来，生成器就有了清晰的改进方向。

前端设计：把主观质量变成可评分的东西

我最先在前端设计上做实验，因为这里的“自我评估失真”最明显。如果不额外干预，Claude 往往会做出安全、标准、可预期的布局：技术上没问题，但视觉上很平庸。

我为前端设计搭建的架构，主要基于两个认识：

第一，审美虽然不能被完全压缩成一个分数，而且不同人品味也不一样，但如果把设计原则和偏好写成一套评分标准，结果确实会更好。“这个设计美吗？”很难稳定回答；但“它是否符合我们定义的好设计原则？”就会变成一个更具体、更容易判断的问题。

第二，只要把“生成前端”和“评价前端”分成两个独立环节，就能形成一个反馈回路，推动生成器做出更好的结果。

基于这个思路，我写了四项评分标准，并把它们同时放进生成器和评估器的提示词里：

设计质量： 整体设计是否像一个有机整体，而不是一堆零件拼起来？高质量设计意味着颜色、排版、布局、图片和细节之间能形成统一的气质和独特的身份感。

原创性： 是否能看出有刻意的定制决策，还是只是套用了模板布局、组件库默认值和常见的 AI 生成套路？人类设计师应该能从中看见真实的创意选择。未经调整的现成组件，或者像“白卡片 + 紫色渐变”这种典型 AI 风格，在这一项都不合格。

工艺： 指技术实现质量，比如排版层级、间距是否一致、颜色是否协调、对比度是否合理。它更多是能力检查，而不是创意检查。大多数正常实现本来就该做到；如果失败，说明基础都没有打牢。

功能性： 与美学无关的可用性。用户是否能理解界面在做什么，是否能找到主要操作，是否能不靠猜测完成任务？

其中，我故意把“设计质量”和“原创性”的权重放得高于“工艺”和“功能性”。因为 Claude 通常在工艺和功能性上已经能拿到不错分数，这些更多是模型本来就具备的技术能力。但在设计感和原创性上，Claude 更容易产出平庸结果。这套标准会明确惩罚那些高度通用的“AI 味很重”的设计模式。通过提高设计感和原创性的比重，我希望推动模型做出更大胆的审美尝试。

我还用带详细评分细则的少样本示例对评估器做了校准。这样能让评估器的判断更贴近我的偏好，也能减少它在多轮迭代里“评分标准漂移”的问题。

我基于Claude Agent SDK搭建了这个循环，因此编排起来并不复杂。

生成器代理先根据用户提示做出 HTML、CSS 和 JS 前端。评估器代理则接入 Playwright MCP，在打分前直接操作真实页面并进行检查。换句话说，评估器不是看一张静态截图来评分，而是真的会自己打开页面、导航、截图、仔细审视实现，再给出评价。

它写出的反馈会回流给生成器，成为下一轮迭代的输入。我通常会跑 5 到 15 轮，每一轮都会根据评估器的批评，让生成器向更独特的方向推进。因为评估器需要主动浏览页面，而不是只看图，所以每一轮都需要真实的挂钟时间，完整运行最长会到四个小时。

我还要求生成器在每轮评估后做一次策略判断：如果分数走势在变好，就继续打磨当前方向；如果这个方向行不通，就大幅改变审美路线。

在多次运行中，我们看到评估器的评分确实会随着迭代上升，之后再趋于平稳，说明还有继续优化的空间。有的生成是慢慢变好，有的则会在两轮之间突然发生很大的审美跃迁。

评分标准里的措辞，甚至会以我原本没预料到的方式影响生成器。

比如我写了“最好的设计应该达到博物馆级”这类句子，结果它会明显把输出拉向某种特定视觉风格。这说明，只要标准的表述发生变化，模型最终产出的特征也会跟着变化。

虽然分数通常会在迭代中上升，但这个过程并不总是线性的。

后期版本整体上往往更强，但很多时候我其实更喜欢中间阶段的某个版本，而不是最后一版。因为随着生成器不断响应评估器反馈、尝试更有野心的方案，实现复杂度也会随之上升。

即使只看第一轮结果，它也已经明显比“不给任何提示、直接让模型生成”的基线要好得多。这说明，光是评分标准本身，以及与之相关的语言，就已经在评估器真正介入反馈之前，把模型从通用默认输出上拉开了。

有一个很典型的例子。

我让模型给一家荷兰艺术博物馆做网站。到第 9 轮时，它已经做出一个很干净的深色着陆页，视觉上也很成熟，但整体还在我预料之中。结果到了第 10 轮，它完全推翻了之前的方法，把网站重新想成一种空间体验：页面变成一个带 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 接口和数据库状态。然后它会根据发现的 Bug，以及一套参考前端实验整理出来的模型标准，对每个冲刺打分。这些标准涵盖产品深度、功能完成度、视觉设计和代码质量。每个标准都有硬阈值，只要有一项低于阈值，这个冲刺就算失败，生成器就会收到一份详细反馈，说明问题出在哪。

在每个冲刺开始前，生成器和评估器会先协商一份“冲刺合同”，也就是先把“做到什么才算完成”谈清楚，再开始写代码。

之所以加这一步，是因为产品规格本身是故意保持高层抽象的，我需要一个中间层，来把用户故事转换成可测试的实现目标。

生成器先提出它准备做什么、如何验证完成；评估器再审核这个提案，确认生成器做的是正确的事。双方会来回迭代，直到合同达成一致。

代理之间的通信通过文件完成：一个代理写文件，另一个代理读文件并回应，可能是在原文件里回复，也可能另开一个新文件。生成器随后依据已经谈妥的合同来构建，再把成果交给 QA。

这样做的好处是：不用在一开始就把实现方式规定得过死，也能让最终工作始终贴着原始规格前进。

运行架构

这个架构的第一个版本，我用的是 Claude Opus 4.5。我把同一个用户提示，分别交给完整架构和单代理系统去跑，用来做对比。当时我选 Opus 4.5，是因为那是我们当时最强的编码模型。

我使用的提示词是：

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

下面这张表是两种架构的运行时长和总成本：

架构	时长	成本
单代理	20 分钟	$9
完整架构	6 小时	$200

完整架构的成本高出了 20 多倍，但产出质量的差别也非常明显。

我原本期待看到的是：一个我可以真正用来搭关卡、制作组件（如精灵、实体和瓷砖布局），并能点击“播放”实际试玩关卡的界面。我先看了单代理系统做出来的版本，刚打开时，它表面上似乎符合这些期待。

但一旦开始点击和操作，问题就出现了。

布局浪费空间，固定高度的面板让大部分视口空着。操作流程也很僵硬。比如我想先往关卡里填内容，系统却要求我必须先创建精灵和实体，但界面没有任何地方提醒我应按这个顺序操作。

更关键的是，真正的游戏部分是坏的。我的实体虽然能出现在屏幕上，但对输入完全没有反应。深入看代码才发现，实体定义和运行时之间其实是断开的，而且从表面根本看不出原因。

看完单代理结果后，我再看完整架构的结果。

它也是从同一句提示词开始，但规划器先把这句话扩成了一套跨 10 个冲刺的、包含 16 个功能的大规格说明，范围远远超出单代理版本。

除了核心编辑器和试玩模式外，规格里还加入了精灵动画系统、行为模板、音效和音乐、AI 辅助精灵生成器、AI 关卡设计器，以及支持可分享链接的游戏导出。

我还让规划器可以访问我们的前端设计技能，于是它把那套技能也读进来，并把一套视觉设计语言写进了产品规格里。

每个冲刺开始前，生成器和评估器都会一起协商一份合同，明确这次要实现哪些具体细节，以及如何通过可测试行为来验证它已经完成。

这个应用一打开，就比单代理版本更精致、更顺滑。画布真正占满了可用视口，面板尺寸更合理，界面也有了和规格里设计方向一致的视觉身份。

我在单代理版本里感受到的一些笨拙感，仍然部分存在——比如系统还是不会明确告诉你，最好先做精灵和实体，再去填关卡，我还是得自己摸索工作顺序。

这更像是基础模型产品直觉上的缺口，而不是架构本身要解决的问题。即便如此，它也提示我们：如果在架构内部做更有针对性的迭代，输出质量还可以继续提高。

当我真正开始使用编辑器时，新架构相对单代理的优势就更明显了。精灵编辑器更丰富、更成熟，工具面板更整洁，颜色选择器更好用，缩放控制也更顺手。

因为我要求规划器把 AI 功能织进产品规格里，这个应用还内置了 Claude 集成，我可以直接用提示词生成游戏的不同部分。这让整个创作流程明显更快。

最大的差别出现在试玩模式里。

这一次，我真的能移动实体，也真的能玩这个游戏。

虽然物理系统还有些粗糙——比如角色跳到平台上后会和平台发生重叠，这在直觉上很奇怪——但核心玩法已经能跑起来了，而单代理版本根本做不到。

玩了一会儿以后，我也确实遇到了一些 AI 做游戏关卡时常见的问题：比如有一面很高的墙，我根本跳不过去，于是被困住了。这说明架构仍然可以继续处理一些常识性改进和边界情况，让应用更完善。

查看运行日志后，可以很清楚地看到评估器确实让实现更贴着规格走。

每个冲刺里，它都会把冲刺合同中的测试标准一条条过一遍，用 Playwright 操作真实应用，并把所有偏离预期行为的地方都记成 Bug。

合同本身非常细，比如仅冲刺 3，就定义了关卡编辑器的 27 条标准。评估器给出的发现也足够具体，生成器几乎不用额外调查就能直接修复。

下面是评估器找到的一些问题示例：

合同标准	评估器发现
矩形填充工具允许点击拖动以填充选定瓷砖的矩形区域	失败 — 工具只在拖动的起点和终点放置瓷砖，没有真正填满整个区域。`fillRectangle` 函数虽然存在，但在 mouseUp 时没有被正确触发。
用户可以选择并删除已放置的实体生成点	失败 — `LevelEditor.tsx:892` 的删除键处理逻辑要求 `selection` 和 `selectedEntityId` 同时存在，但用户点击实体时实际上只会设置 `selectedEntityId`。条件判断应改为 `selection
用户可以通过 API 重新排序动画帧	失败 — `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 美元。

大部分时间都花在构建阶段。生成器在没有 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 帮助打磨这篇文章。