Anthropic 长时运行 Agent 编排设计深度解读：GAN 启发的多 Agent 协作架构分析

发布于：2026-03-26 · #AI #Agent #Claude Code #LLM

Anthropic 在 2026 年 3 月 24 日发布的这篇工程博客，揭示了一个核心洞察：让 AI 自主构建完整应用的瓶颈不在模型能力，而在于编排架构（harness）设计。 作者 Prithvi Rajasekaran 来自 Anthropic Labs 团队，通过借鉴 GAN（生成对抗网络）的对抗思想，设计出一套 Planner-Generator-Evaluator 三 Agent 协作架构，使 Claude 能在数小时的自主编码中构建出功能完整、可实际使用的全栈应用。文章同时展示了一条重要规律——随着模型能力提升（Sonnet 4.5 → Opus 4.5 → Opus 4.6），编排复杂度应逐步递减，但编排设计的探索空间不会缩小，只是向更前沿的方向迁移。

一、为什么 Anthropic 要写这篇文章

这篇文章是 Anthropic 此前（2025 年 11 月）发布的《Effective harnesses for long-running agents》的续篇和升级版。前作由 Justin Young 撰写，提出了 Initializer Agent + Coding Agent 的双 Agent 编排，利用 feature_list.json、claude-progress.txt、git 提交等结构化产出物来解决跨上下文窗口的状态传递问题。那套方案虽然有效，但遇到了两个天花板：

第一，模型在长上下文中会”失去连贯性”。 随着上下文窗口填满，模型会出现所谓的”上下文焦虑”（context anxiety）——即模型错误地认为自己即将耗尽上下文容量，开始提前收尾、草率完成任务。Claude Sonnet 4.5 对此尤为敏感，即使使用了 compaction（上下文压缩）也不能消除这一问题。

第二，模型对自身输出的自评估严重偏高。 当要求 Agent 评价自己生成的代码或设计时，它几乎总是给出正面评价——即使人类一眼就能看出质量平庸。这个问题在设计类等主观任务上尤为突出，因为没有类似”测试通过/失败”的二元判据。

Anthropic 写这篇文章的动机，就是展示如何通过更高级的编排设计突破这两个天花板。

二、技术方案的完整架构

2.1 GAN 启发的核心思想：生成与评估分离

文章最大的技术创新是将 GAN 的对抗式思想引入 Agent 编排。其核心逻辑是：

  • 生成器（Generator） 负责产出代码和应用
  • 评估器（Evaluator） 独立于生成器，负责像真实用户一样测试和打分
  • 两者形成反馈闭环，评估器的批评驱动生成器不断改进

作者的关键发现是：让一个独立的评估器变得严苛，远比让生成器自我批评容易得多。 评估器默认也倾向宽容，但通过 few-shot 校准（提供带详细评分的示例）和提示词调优，可以逐步使其评判标准对齐人类偏好。

2.2 前端设计领域的双 Agent 实验

作者首先在前端设计领域验证这一方案。具体架构如下：

生成器 Agent： 基于用户 prompt 生成 HTML/CSS/JS 前端页面。

评估器 Agent： 配备 Playwright MCP（基于浏览器自动化的 Model Context Protocol 工具），能够自主浏览生成的页面、截屏、交互，然后按四项评分标准打分并撰写详细评语。

四项评分标准（核心设计）：

  • 设计质量（Design Quality）：设计是否形成连贯整体？色彩、排版、布局、意象是否共同营造出独特的氛围和身份感？
  • 原创性（Originality）：是否有自主设计决策的痕迹？还是模板布局、组件库默认值、AI 生成模式（如紫色渐变+白色卡片）？
  • 工艺水平（Craft）：排版层级、间距一致性、色彩和谐度、对比度等技术执行
  • 功能性（Functionality）：用户能否理解界面功能、找到主操作、无障碍完成任务？

作者有意加大了设计质量和原创性的权重——因为 Claude 在工艺和功能上默认就表现不错，但在设计和原创性上倾向于生成平庸的”AI 泡沫”。评分标准中明确惩罚高度通用的 AI 风格模式。

迭代流程： 每次生成运行 5-15 轮迭代。每轮中，评估器导航页面→截屏→评分→撰写批评→反馈给生成器。生成器根据反馈做出策略决策：如果分数趋势向好则继续精炼，如果方向不对则大幅转向新的美学方案。完整运行耗时可达 4 小时。

关键案例： 为一家荷兰艺术博物馆生成网站时，前 9 轮迭代产出了一个精致的深色主题着陆页。第 10 轮，生成器突然抛弃原方案，将网站重新构想为 3D 空间体验——CSS 透视渲染的棋盘格地板、墙上自由悬挂的艺术品、用门廊导航而非滚动或点击。这种创造性跳跃是单次生成从未出现过的。

2.3 全栈开发的三 Agent 架构

将设计领域的经验推广到全栈开发后，作者构建了三 Agent 系统：

Planner Agent（规划器）： 接收 1-4 句简短 prompt，扩展为完整产品规格说明。关键设计决策：

  • 规划器被要求关注产品上下文和高层技术设计，而非细粒度技术实现——因为如果规划阶段的技术细节出错，会级联到下游实现
  • 被要求尽量雄心勃勃地设定范围
  • 被要求主动在产品规格中融入 AI 功能
  • 可以读取 Anthropic 的 frontend-design skill 来创建视觉设计语言

Generator Agent（生成器）： 按 Sprint 逐个功能实现。技术栈为 React + Vite + FastAPI + SQLite（后为 PostgreSQL）。每个 Sprint 结束后自评，然后交给评估器。使用 git 进行版本控制。

Evaluator Agent（评估器）： 使用 Playwright MCP 像真实用户一样点击、浏览正在运行的应用，测试 UI 功能、API 端点和数据库状态。按产品深度、功能性、视觉设计、代码质量等维度打分，每项有硬性阈值——任何一项低于阈值则该 Sprint 失败，附详细反馈给生成器修复。

2.4 Sprint 合约机制

这是文章中一个独特的设计模式。在每个 Sprint 开始之前，生成器和评估器会协商一份”Sprint 合约”——就”完成”的定义达成一致。流程如下：

  1. 生成器提出本 Sprint 要构建的内容及验证方式
  2. 评估器审查提案，确保生成器在做正确的事
  3. 双方迭代直到达成共识
  4. 生成器按合约开发，完成后交给评估器验收

合约粒度很高。 文章展示了 Sprint 3（关卡编辑器）有 27 项验收标准。评估器的发现高度具体，例如：

合约标准评估器发现
矩形填充工具允许拖拽填充选定 tile失败 —— 工具仅在拖拽起止点放置 tile，fillRectangle 函数存在但未在 mouseUp 时正确触发
用户可选择并删除已放置的实体生成点失败 —— Delete 键处理器要求 selection 和 selectedEntityId 同时设置，但点击实体只设置了后者
用户可通过 API 重排动画帧失败 —— PUT /frames/reorder 路由定义在 /{frame_id} 之后，FastAPI 将 “reorder” 匹配为 frame_id 整数参数并返回 422

这些是代码级别的精确 bug 定位，远超一般的”功能不工作”描述。

2.5 Agent 间通信机制

文章采用了一种极简的通信方式：基于文件的读写。一个 Agent 写文件，另一个 Agent 读取并回应（在同一文件中或新建文件）。这避免了消息传递框架的复杂性，同时利用了文件系统作为天然的持久化层。

2.6 实验结果对比

实验一：2D 复古游戏制作工具（Opus 4.5）

Prompt：“Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode.”

编排方式耗时成本
单 Agent20 分钟$9
三 Agent 完整编排6 小时$200

单 Agent 产出的应用：布局浪费空间、工作流僵硬、游戏核心功能完全不能运行（实体出现在屏幕上但不响应输入）。三 Agent 编排的产出：画布全视口、面板合理、视觉一致性强、精灵编辑器更丰富、游戏实际可玩，且内置了 Claude AI 集成，用户可以通过自然语言生成游戏关卡。

实验二：浏览器 DAW 数字音频工作站（Opus 4.6，简化编排）

Prompt：“Build a fully featured DAW in the browser using the Web Audio API.”

Agent 与阶段耗时成本
规划器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
合计3 小时 50 分$124.70

最终产出了一个功能齐全的浏览器 DAW：编曲视图、混音台、传输控制、内置 AI Agent 可通过 prompt 自主编曲（设定 tempo/调性→铺旋律→加鼓轨→调混音→添加混响）。

三、编排迭代的关键发现

3.1 模型升级如何改变编排需求

这是文章最具实践指导意义的部分。作者展示了编排设计如何随模型进化而简化：

Sonnet 4.5 → 需要上下文重置： 上下文焦虑严重，compaction 不够用，必须清空上下文并用结构化产出物传递状态。增加了编排复杂度、token 开销和延迟。

Opus 4.5 → 可以去掉上下文重置： 模型自身基本消除了上下文焦虑行为，可以在连续会话中运行，由 Claude Agent SDK 的自动 compaction 处理上下文增长。

Opus 4.6 → 可以去掉 Sprint 结构： 模型”规划更谨慎、维持 Agent 任务更持久、在大型代码库中更可靠运行、有更好的代码审查和调试能力”。生成器可以连续两小时以上保持连贯编码，不再需要按 Sprint 分解任务。评估器也从 Sprint 级别移到了运行结束后的单次评估。

关键原则： 编排中的每个组件都编码了一个关于”模型无法独立完成什么”的假设。这些假设值得持续压力测试——既因为假设可能本身就是错的，也因为模型进步会让假设过时。

3.2 评估器的边际效用取决于任务难度

评估器不是一个固定的”要/不要”决策。它的价值取决于当前任务是否处于模型能力的边界：

  • 任务在模型舒适区内 → 评估器是不必要的开销
  • 任务在模型能力边界上 → 评估器提供实质性提升

Opus 4.6 将这条边界向外推移，更多任务落入模型舒适区。但对于那些仍在边界上的任务（如复杂交互、深层嵌套功能），评估器仍然不可或缺。

3.3 让评估器变严格需要大量调优

开箱即用的 Claude 是一个糟糕的 QA Agent。在早期运行中，评估器会识别出真实问题，然后说服自己”这不是什么大问题”并批准通过。它还倾向于浅层测试，不会深入探索边缘情况。

作者的调优循环是：阅读评估器日志 → 找到其判断与人类判断偏离的地方 → 更新 QA 提示词来解决这些偏差。经过数轮迭代后，评估器的评分才趋于合理。

四、对 AI 开发者的实际指导意义

4.1 设计模式清单

本文为 AI 工程师提供了以下可直接采用的设计模式：

  • 生成-评估分离模式：不要让同一个 Agent 既生成又自评。创建独立的评估 Agent，用 few-shot 校准对齐人类偏好，并通过提示词调优使其保持严苛。
  • Sprint 合约模式：在 Agent 开始工作前，让生成器和评估器先就”完成标准”达成协议。这在产品规格（高层）和可测试实现（底层）之间架起桥梁。
  • 规划器解耦模式：不要让实现 Agent 自己决定要做什么。用专门的规划 Agent 从简短 prompt 扩展完整规格，但保持高层——避免规划器指定细粒度技术细节，以防错误级联。
  • 渐进式编排简化：每当底层模型升级，系统性地逐个移除编排组件，观察对输出质量的影响。保留真正”承重”的组件，丢弃已被模型能力覆盖的组件。
  • 文件系统作为通信总线：Agent 间通信不必使用复杂的消息传递框架，直接读写文件即可。简洁、可审计、天然持久化。

4.2 技术栈与工具选择

  • 编排框架：Claude Agent SDK（支持 Python 和 TypeScript）
  • 浏览器自动化：Playwright MCP（基于无障碍树而非截图，结构化、确定性）
  • 应用技术栈：React + Vite（前端）+ FastAPI（后端）+ SQLite/PostgreSQL（数据库）
  • 版本控制：git（Agent 用描述性 commit message 提交，可回滚到工作状态）
  • 前端设计提升：引入 frontend-design skill 插件，注入设计原则防止”AI 泡沫”输出

4.3 成本与时间预期

文章给出了非常透明的成本数据。构建一个功能完整的全栈应用，预期成本在 $125-200 之间，耗时 4-6 小时。 这比单 Agent 贵 15-20 倍，但产出质量差距巨大——核心功能从”完全不工作”到”可实际使用”。

五、优缺点与局限性分析

优点

原创性高。 GAN 启发的生成-评估对抗模式在 Agent 编码领域是真正的创新应用，尤其是将其扩展到主观质量评估（设计美学）而非仅限于可验证正确性。Sprint 合约机制也是业界首创。

工程实践导向。 文章不是理论论述，而是基于大量实际运行的日志、截图和成本数据。评估器发现的 bug 示例（如 FastAPI 路由优先级导致的 422 错误）展示了系统真实的精确度。

演化思维突出。 文章清晰展示了编排如何随模型进步而简化，提出了”每个编排组件都是关于模型局限性的假设”这一深刻洞察，为开发者提供了动态调整编排的方法论。

局限性

缺乏量化评估指标。 文章大量使用定性描述（“明显更好”、“质量差距一目了然”），但没有给出标准化的评估分数。缺少如 SWE-bench 等基准测试的对比数据，难以与竞品做严格比较。

成本高且适用场景窄。 $125-200 的单次运行成本加上 4-6 小时的等待时间，对于大多数日常开发任务来说并不实用。文章展示的都是从零构建完整应用的绿地场景，未涉及存量代码维护、迁移等更常见的工程任务。

评估器本身的天花板。 作者坦承即便经过多轮调优，评估器仍然存在遗漏：小布局问题、不直觉的交互、深层嵌套功能中未被发现的 bug。Claude 无法”听到”音频这个限制也使 DAW 项目的 QA 反馈环在音乐品味维度上失效。

样本量不足。 文章仅展示了 2-3 个案例（游戏制作器、DAW）。编排方案的稳健性、跨领域泛化能力缺乏足够证据支撑。

模型锁定。 整套方案深度绑定 Claude 生态系统（Claude Agent SDK、MCP、特定模型版本行为）。其他模型可能有完全不同的上下文焦虑特征和自评估偏差模式，编排设计未必可迁移。

六、与业界其他方案的对比

与 Devin（Cognition AI）对比

Devin 同样采用多 Agent 架构（Planner → Coder → Critic → Debugger），但定位为”自主初级工程师”，聚焦在 4-8 小时可完成的明确任务（迁移、写测试、修 bug）。Anthropic 的方案更偏向研究探索，目标是从零构建完整应用。Devin 有评审 Agent 但没有 GAN 式对抗动态和 Sprint 合约机制；Anthropic 的方案虽在产出质量上可能更高，但在任务范围和实用性上不如 Devin 成熟。

与 OpenAI Codex 对比

Codex 依赖单一强模型（通过 RL 训练内化了规划-实现-验证-修复循环），而非多 Agent 编排。GPT-5.3-Codex 已展示过 25 小时以上的连续运行。Anthropic 用外部编排解决的问题，OpenAI 选择通过模型训练内化。 这代表了两种截然不同的技术路线——编排工程 vs 模型训练。文章本身也暗示了这一张力：模型越强，编排越该简化。

与 Cursor/Windsurf 等 IDE 工具对比

这些工具面向实时协作编程，开发者全程在场。它们使用单 Agent 循环，没有独立评估器，也不从简短 prompt 扩展完整规格。两者解决的是完全不同的问题：IDE 工具优化的是人机协作效率，Anthropic 编排优化的是无人干预下的自主构建质量。

与”Ralph Wiggum”方法对比

Ralph Wiggum 是社区驱动的简单 while true 循环方案，最适合机械性任务。Anthropic 的博文明确引用了这一方法，但指出它对复杂任务仍然力不从心。三 Agent 编排可以视为 Ralph Wiggum 的”高阶版”——用结构化的多 Agent 协作替代简单的循环重启。

与 MetaGPT 等开源框架对比

MetaGPT 模拟完整软件公司（产品经理、架构师、工程师、QA），角色更多基于组织结构。Anthropic 的三个 Agent 则是功能性分工（规划 vs 生成 vs 评估），核心差异在于 GAN 式对抗动态。MetaGPT 模拟的是人类组织的分工协作，Anthropic 模拟的是对抗训练的质量提升机制。

结论：编排设计是一个移动的前沿

这篇文章最深层的价值不在于某一个具体的编排方案——因为随着模型进步，今天最优的编排明天就可能需要简化。真正的价值在于它建立的方法论框架：将编排中的每个组件视为可独立测试的假设，用消融实验（逐一移除组件观察影响）来发现哪些是真正承重的。

对于中国 AI 开发者而言，三个即可落地的启发是：第一，将”生成”和”评估”解耦到不同 Agent 是提升自主编码质量的最直接杠杆；第二，不要让规划 Agent 指定太细的技术细节，保持高层让实现 Agent 自己摸索路径；第三，每次模型升级都应该重新审视编排架构，主动去掉不再需要的脚手架。

作者 Prithvi Rajasekaran 的一句话精准概括了这个领域的本质——“有趣的编排组合空间不会因为模型进步而缩小。它只是在移动，而 AI 工程师的工作就是持续找到下一个新组合。”