多 Agent 架构

Anthropic 这篇文章讨论的是两个相互关联的问题：如何让 Claude 产出更高质量的前端设计，以及如何让它在没有人工干预的情况下构建完整应用。

前一代 frontend design skill 和 long-running coding agent harness 已经通过 prompt engineering 和 Harness 设计，把 Claude 的表现推到高于基线的位置，但两者最终都遇到天花板。为突破这个天花板，作者借鉴了 GAN 的思路：把负责生成的 Agent 和负责评估的 Agent 分开。

最后形成的是一个三 Agent 架构：planner、generator、evaluator。它能在数小时自主编码会话中产出更完整的全栈应用。

为什么朴素实现不够

早期长程 Agent 方案使用 initializer agent 把产品规格拆成任务列表，再由 coding agent 一次实现一个功能，并通过结构化产物在会话之间交接上下文。这解决了多会话连续性问题，但复杂任务仍然会让 Agent 随时间逐渐偏离轨道。

Anthropic 观察到两个持续存在的问题。

第一，模型在长任务中会随着上下文窗口填满而失去连贯性。有些模型还会出现 context anxiety：当它感觉自己接近上下文限制时，会过早开始收尾。Context reset 可以缓解这个问题：完全清空上下文窗口，启动一个新的 Agent，并通过结构化交接产物传递上一轮状态和下一步任务。

这和 compaction 不同。Compaction 会把早期对话压缩后让同一个 Agent 继续工作，它保留连续性，但没有给 Agent 一个干净的新窗口，因此 context anxiety 仍可能存在。Reset 给了模型 clean slate，但代价是交接产物必须足够完整，否则下一位 Agent 接不上。

第二，是自我评估问题。要求 Agent 评估自己刚刚产出的工作时，它往往会自信地赞美平庸输出。这个问题在设计这类主观任务中尤其明显，因为没有类似软件测试那样的二元检查。一个布局是精致还是模板化，本质上是判断题，而 Agent 给自己打分时会稳定偏乐观。

即使在有可验证结果的任务中，Agent 也会表现出影响任务完成的判断力问题。把“做事的 Agent”和“评判的 Agent”分开，是解决这个问题的强杠杆。分离本身不会立刻消除宽松评估，因为 evaluator 仍然是 LLM，也会倾向于宽容；但把一个独立 evaluator 调得更怀疑，远比让 generator 对自己保持批判容易。

前端设计：把主观质量变成可评分标准

作者先从前端设计开始实验，因为自我评估问题在这里最明显。没有干预时，Claude 通常会走向安全、可预测、技术上能用但视觉上平庸的布局。

这个实验基于两个洞察：

审美不能完全还原成分数，个人偏好也永远会不同；但可以用评分标准编码设计原则和偏好。
把前端生成和前端评分分开，可以形成反馈循环，推动 generator 产出更强的结果。

作者为 generator 和 evaluator 都提供了四个评分标准：

标准	关注点
设计质量	设计是否像一个协调的整体，而不是零散部件的集合？颜色、字体、布局、图片和细节是否形成明确的氛围和身份？
原创性	是否能看到定制化决策，而不是模板布局、库默认样式和常见 AI 生成痕迹？
工艺	技术执行是否扎实：字体层级、间距一致性、色彩和谐、对比度等。
功能性	独立于审美的可用性：用户是否能理解界面、找到主要操作并完成任务？

其中，设计质量和原创性的权重更高。Claude 默认在工艺和功能性上已经不错，但在设计质量和原创性上容易产出平淡结果。评分标准明确惩罚高度模板化的 “AI slop” 模式，例如紫色渐变加白色卡片，并推动模型承担更多审美风险。

Evaluator 还需要校准。作者用 few-shot 示例和详细分数拆解，让 evaluator 的判断对齐自己的偏好，并减少迭代过程中的分数漂移。

这个循环基于 Claude Agent SDK：generator 根据用户 prompt 创建 HTML/CSS/JS 前端；evaluator 配备 Playwright MCP，可以直接和页面交互，在评分前自主浏览、截图、研究实现。然后 evaluator 的反馈会回流给 generator，进入下一轮迭代。

每次生成通常运行 5 到 15 轮。由于 evaluator 不是只看静态截图，而是实际操作页面，每轮都需要真实时间，完整运行可能持续数小时。Generator 在每次评估后还要做一个策略判断：如果分数趋势好，就沿当前方向打磨；如果方向不行，就切换到完全不同的审美路线。

实验中的几个观察很重要：

Evaluator 的评分会随迭代改善，然后进入平台期。
评分标准中的词会以意想不到的方式塑造输出，例如类似 “museum quality” 的措辞会把设计推向某种视觉趋同。
改善不是线性的，有时中间版本比最后版本更好。
随着 evaluator 反馈推进，generator 会尝试更复杂、更有野心的实现。
即使第一轮，也明显好过没有评分标准的基线，说明标准本身就能把模型从通用默认值中拉出来。

一个典型例子是荷兰艺术博物馆网站。第九轮时，模型已经生成了一个干净、深色主题、视觉上符合预期的 landing page。第十轮，它完全推翻原方案，把网站重构成一个空间体验：CSS 透视渲染的 3D 房间、棋盘地面、自由挂在墙上的艺术品，以及通过门洞在画廊房间之间导航。这种跃迁很难从单轮生成中得到。

扩展到全栈编码

有了前端实验结果后，作者把这个 GAN-inspired 模式应用到全栈开发。Generator-evaluator 循环自然映射到软件开发生命周期：代码审查和 QA 在结构上承担 evaluator 的角色。

架构

早期 long-running harness 已经用 initializer agent、逐功能 coding agent 和 context reset 解决了多会话编码连贯性问题。Context reset 当时很关键，因为 Sonnet 4.5 会表现出明显的 context anxiety。

到了 Opus 4.5，这种行为基本被模型能力本身缓解，所以这个新 Harness 去掉了 context reset。Agents 在整个构建过程中作为一个连续会话运行，由 Claude Agent SDK 的自动 compaction 处理上下文增长。

新系统保留了三类 Agent persona：

Planner

之前的长程 Harness 需要用户一开始提供详细规格。Planner 的作用是把 1 到 4 句简单用户 prompt 扩展成完整产品规格。

Planner 被要求：

对范围保持雄心。
聚焦产品上下文和高层技术设计。
避免过早指定细粒度技术实现。
寻找把 AI 功能融入产品规格的机会。

避免细粒度实现细节是有意的：如果 planner 在早期指定了错误的技术细节，这些错误会级联到下游实现。更好的做法是约束要交付什么，让后续 Agent 在工作中决定具体路径。

Generator

Generator 继承了早期 Harness 的“一次一个功能”思路，用 sprint 管理范围。它每个 sprint 从 spec 中选择一个功能来实现。

当时的实现栈是 React、Vite、FastAPI 和 SQLite，后来换成 PostgreSQL。Generator 在每个 sprint 结束时要先自评，再交给 QA，同时使用 git 做版本控制。

Evaluator

早期 Harness 生成的应用常常看起来不错，但实际使用时仍有真实 bug。Evaluator 的任务就是抓这些问题。它通过 Playwright MCP 像真实用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态。

然后 evaluator 会根据一组标准评分。这组标准借鉴了前端实验，但扩展到产品深度、功能性、视觉设计和代码质量。每个标准都有硬阈值：任一标准低于阈值，sprint 就失败，generator 会收到具体反馈并继续修复。

Sprint 合约

每个 sprint 开始前，generator 和 evaluator 会协商一个 sprint contract，也就是先就这轮“完成”的定义达成一致，再写代码。

这个环节存在的原因是：产品规格故意保持高层，必须有一步把用户故事转成可测试实现。Generator 提出要构建什么，以及如何验证成功；evaluator 审查这个提议，确认它是否在构建正确的东西。双方通过文件来通信：一个 Agent 写文件，另一个读取并在文件中或新文件中回应。

这样既能保持对 spec 的忠实，又不会在早期过度指定实现。

运行 Harness：复古游戏制作器

第一版 Harness 使用 Claude Opus 4.5。作者用同一个 prompt 分别跑完整 Harness 和单 Agent 系统做对比：

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

Harness	耗时	成本
Solo	20 分钟	$9
Full harness	6 小时	$200

完整 Harness 成本超过 20 倍，但输出质量差异很明显。

Solo run 的应用表面上符合预期：可以构建关卡和组件，然后点击 play 测试。但实际点击后，问题开始出现：布局浪费空间，固定高度面板让大部分视口空着；工作流僵硬，界面没有引导用户先创建 sprites 和 entities；更关键的是，游戏本身坏了，实体显示在屏幕上却不响应输入。查看代码后发现，entity definitions 和 game runtime 之间的连接断了，而且界面没有暴露这个问题。

完整 Harness 从同一个一句话 prompt 开始，但 planner 把它扩展成 16 个功能、10 个 sprint。规格不只包含核心编辑器和 play mode，还包括 sprite animation system、behavior templates、音效和音乐、AI-assisted sprite generator、AI level designer，以及带可分享链接的 game export。

Planner 还读取 frontend design skill，并把视觉设计语言写进 spec。每个 sprint 中，generator 和 evaluator 会协商 contract，明确这一轮的实现细节和可测试行为。

完整 Harness 产出的应用明显更精致：canvas 使用完整视口，面板尺寸更合理，界面有一致视觉识别，并延续 spec 中的设计方向。它仍有一些笨拙之处，例如用户仍然需要自己摸索“先做 sprites 和 entities，再填充关卡”的流程。这更像基础模型产品直觉的缺口，而不是 Harness 本身已经解决的问题。

真正大的差异出现在 play mode：作者可以移动实体并实际玩游戏。物理效果还有粗糙边缘，例如角色跳上平台后与平台重叠；AI 生成关卡也会出现无法跳过大墙导致卡住的问题。但核心玩法是可用的，而 solo run 没做到这一点。

从日志看，evaluator 把实现紧紧拉回 spec。每个 sprint 它都会根据 sprint contract 的测试标准，通过 Playwright 操作运行中的应用，并对偏离预期的地方提交 bug。仅 Sprint 3 就有 27 条 criteria，覆盖 level editor；evaluator 的反馈细到无需额外调查即可行动。

几个 evaluator 发现的问题示例：

Contract criterion	Evaluator finding
Rectangle fill tool 允许拖拽填充矩形区域	FAIL：工具只在拖拽起点和终点放置 tile，没有填满区域；`fillRectangle` 函数存在，但没有在 `mouseUp` 正确触发。
用户可以选择并删除 entity spawn points	FAIL：`LevelEditor.tsx` 中 Delete key handler 同时要求 `selection` 和 `selectedEntityId`，但点击 entity 只会设置 `selectedEntityId`。
用户可以通过 API 重排 animation frames	FAIL：`PUT /frames/reorder` 路由定义在 `/{frame_id}` 之后，FastAPI 把 `reorder` 当作 frame id 解析，返回 422。

QA Agent 的调优难点

让 evaluator 达到这个水平并不容易。开箱即用时，Claude 是一个糟糕的 QA agent。

早期运行中，它会识别出真实问题，然后说服自己这些问题不严重，并批准工作。它也倾向于浅层测试，而不是探测边界情况，所以更细微的 bug 会漏掉。

调优循环是：

阅读 evaluator 日志。
找出它和人类判断不一致的例子。
更新 QA prompt 来修正这些偏差。

经过几轮后，evaluator 的评分才达到作者认为合理的程度。即便如此，Harness 输出仍显示出模型 QA 能力边界：小布局问题、不够直觉的交互、深层嵌套功能中 evaluator 没有充分测试到的 bug。

但和 solo run 相比，提升很明显：solo run 的核心功能根本不可用，而完整 Harness 至少让核心体验跑了起来。

迭代 Harness

第一版结果令人鼓舞，但 Harness 也庞大、缓慢、昂贵。下一步自然是：在不降低表现的前提下简化 Harness。

这里有一个通用原则：Harness 中的每个组件，都编码了对“模型自己做不到什么”的假设。这些假设值得被压力测试，因为它们可能是错的，也可能随着模型变强迅速过时。

作者第一次尝试简化时删得太猛，并加入了一些新想法，结果无法复现原 Harness 的表现，也难以判断哪些组件才是真正承重的。于是他改用更有方法的路径：一次移除一个组件，然后观察它对最终结果的影响。

随着 Opus 4.6 发布，简化 Harness 更有必要。Opus 4.6 在长期规划、持续 agentic task、更大代码库可靠性、代码审查、调试、长上下文检索上都有提升，而这些正是原 Harness 用来补足的能力。

移除 Sprint 结构

作者首先完全移除了 sprint construct。Sprint 结构原本用于把工作拆成模型能连贯处理的块；但 Opus 4.6 已经有理由能原生处理更长任务。

Planner 和 evaluator 被保留下来，因为两者仍有明显价值：

没有 planner，generator 会低估范围，拿到原始 prompt 后直接开工，最终应用不如 planner 规格下丰富。
Evaluator 则从每个 sprint 后评分，变成在运行结束后做单次 QA。

模型能力提升后，evaluator 是否“承重”变成任务相关，而不是固定答案。对于 4.5，很多构建都处在 generator 独立能力边界附近，evaluator 能持续抓到有意义问题。到了 4.6，边界外移，很多过去需要 evaluator 的任务已经能被 generator 独立完成；在这些任务上，evaluator 可能只是额外开销。但对仍然处在 generator 能力边界上的部分，evaluator 继续带来真实提升。

实际含义是：是否使用 evaluator，不是永远 yes/no，而要看任务是否超出当前模型可靠 solo 完成的范围。

同时，作者还加入了 prompt，让 Harness 更好地把 AI 功能构建进每个应用，尤其是让 generator 构建一个能通过工具驱动应用自身功能的 proper agent。这也需要迭代，因为相关知识很新，模型训练数据覆盖较薄。

更新后 Harness：浏览器 DAW

为了测试更新后 Harness，作者给出一个 Digital Audio Workstation prompt：

Build a fully featured DAW in the browser using the Web Audio API.

这次运行仍然漫长且昂贵，总计约 4 小时，token 成本约 $124。多数时间花在 builder 上，它在没有 Opus 4.5 所需 sprint 分解的情况下，连贯运行了两个多小时。

Agent / 阶段	耗时	成本
Planner	4.7 分钟	$0.46
Build Round 1	2 小时 7 分钟	$71.08
QA Round 1	8.8 分钟	$3.24
Build Round 2	1 小时 2 分钟	$36.89
QA Round 2	6.8 分钟	$3.09
Build Round 3	10.9 分钟	$5.88
QA Round 3	9.6 分钟	$4.06
Total V2 Harness	3 小时 50 分钟	$124.70

和前一个 Harness 一样，planner 把一句话 prompt 扩展成完整 spec。日志显示，generator 在规划应用和 agent 设计、把 agent 接入应用、以及交给 QA 前测试方面表现不错。

但 QA agent 仍然抓到了真实缺口。第一轮反馈指出，应用设计 fidelity、AI agent 和后端都不错，但 feature completeness 是主要失败点：若干核心 DAW 功能只是展示，没有交互深度，例如 clip 不能在 timeline 上拖动或移动，没有 instrument UI panels，也没有视觉化 effect editors。

第二轮 QA 又抓到几类功能缺口：录音仍然只是 stub，clip 边缘拖拽 resize 和 clip split 没实现，effect visualization 只是数字滑块而不是 EQ curve 等图形界面。

最终应用还远不是专业音乐制作程序，Agent 的作曲能力也明显需要继续提升。更重要的是，Claude 实际上听不到声音，因此 QA feedback loop 在音乐品味方面不够有效。

但最终应用已经具备浏览器音乐制作程序的核心组件：可用的 arrangement view、mixer、transport。作者还可以完全通过 prompting 做出一段短歌：Agent 设置 tempo 和 key，铺 melody，生成 drum track，调整 mixer levels，并添加 reverb。

接下来

随着模型继续进步，我们大致可以预期它们能工作更久，也能处理更复杂的任务。有些情况下，模型周围的脚手架会随着时间变得不那么重要，开发者可以等下一个模型，让某些问题自然消失。

另一方面，模型越强，就越有空间设计更有野心的 Harness，完成基线模型做不到的复杂任务。

这项工作的经验是：

始终用目标模型做实验。
在真实问题上阅读执行轨迹。
为目标结果调优性能。
复杂任务中，拆解任务并为不同方面使用 specialized agents，可能仍有提升空间。
新模型到来时，要重新审视 Harness，移除不再承重的组件，也加入过去不可能的新能力。

作者最后的判断是：随着模型变强，有趣的 Harness 组合空间不会缩小，而是会移动。AI 工程师的工作，是持续找到下一个有效的新组合。

来源

Harness Design for Long-Running Application Development — Prithvi Rajasekaran, Anthropic, 2026.03。