导读：本文来自 Anthropic Labs 工程师 Prithvi Rajasekaran。过去数月，他聚焦两个关联目标：让 Claude 产出更优秀的前端设计，并在无人干预下，端到端自行构建完整应用。

基于此前在前端设计与长时编程编排（Agent Harness）上的积累，他将“生成器 + 评估器”的对抗式思路引入到多智能体设计，最终打磨出由规划器（Planner）、生成器（Generator）、评估器（Evaluator）组成的三智能体架构，能够在数小时的自主编程 session 中产出功能完备的全栈应用。

为什么朴素实现会“翻车”

早期实践表明，编排框架对长时运行的 Agent 编程效果影响极大：通过将产品说明书拆成任务、逐功能实现，并用 artifact 跨 session 传递上下文，能够显著提升完成度。社区也有类似做法（如“Ralph Wiggum”持续迭代法）。但在复杂任务下，系统仍会跑偏，主要有两类失败模式：

• 失败模式一：上下文窗口拖垮连贯性。上下文逐渐填满后，模型易失去全局一致性，甚至出现“上下文焦虑”：临近长度上限就提前收尾。有效手段是上下文重置（context reset）——清空上下文、拉起全新 Agent，并通过结构化交接文件完整传递状态与下一步计划。这与上下文压缩（compaction）不同，压缩保留对话连续性但无法给予 Agent “白纸”，焦虑仍可能存在。实测中，Claude Sonnet 4.5 对此尤为敏感，仅靠压缩难以支撑长任务，因而重置成为 harness 关键一环。
• 失败模式二：自评“自嗨”。让 Agent 评价自身产出时，常过度乐观，尤其在缺乏二元对错的主观领域（如设计）。拆分“执行”与“评判”被证明是有效杠杆：独立评估器可以被“调教”得更挑剔，从而对生成器形成明确的外部反馈闭环。

前端设计实验：把“好不好看”转化为可衡量标准

在前端设计场景中，Claude“默认安全”的风格常显平庸。Prithvi 据此构建了一个由生成器与评估器协作的设计 harness，基于两点洞察：

1. 美感不可完全量化，但可以用清晰的设计原则与偏好作为评分依据。
2. 将“生成”与“评分”分离，形成推动生成器演进的反馈循环。

系统使用四个评分维度，并提高“设计品质”和“原创性”的权重（显式惩罚“千篇一律的 AI 味”）：

• 设计品质：是否形成有辨识度的整体风格（色彩/字体/排版/图像的协同）。
• 原创性：是否体现定制化的设计选择，避免模板化与组件库默认风格堆砌。
• 工艺：排版层级、间距一致性、配色和对比度等实现质量（作为及格线）。
• 功能性：可用性与任务完成效率（独立于审美）。

技术上，系统基于 Claude Agent SDK 搭建：生成器输出 HTML/CSS/JS；评估器通过 Playwright MCP 在真实页面里浏览、截图、细查实现，依据四维标准评分并输出详细批评；这些反馈作为下一轮迭代输入回流生成器。每次生成跑 5–15 轮，因评估器要在真实页面中交互，每轮耗时不菲，整轮最长达4 小时。

有趣的是，评分标准的措辞本身会塑造风格。例如“达到博物馆级品质”的描述会引导视觉收敛至某些风格。总体评分随迭代上升但非线性：后期通常更好，却不乏中期版本优于最终版的情况。生成器也会在反馈推动下尝试更大胆的方案。

案例：为一家荷兰艺术博物馆生成网站。第 9 轮出现了干净的深色主题落地页；第 10 轮则“跳跃”到全新概念：用 CSS 透视打造 3D 房间，棋盘格地面、画作悬挂墙面，用户通过门廊在展厅间切换，取代传统滚动或点击。这种创意跨越在单轮生成中并不常见。

扩展至全栈：引入三智能体架构

“生成—评估”的对抗式循环与软件工程中的代码评审和 QA 天然映射。Prithvi 将其扩展到全栈开发，并在模型能力演进下优化了上下文策略：

• 上下文策略演进：早期（Sonnet 4.5）依赖上下文重置；至 Opus 4.5，上下文焦虑基本消失，改用 Claude Agent SDK 的自动压缩，移除了上下文重置。

三角色分工：

• 规划器（Planner）：将 1–4 句简短 prompt 拓展成完整产品说明书。刻意聚焦产品上下文与高层技术设计，避免在早期陷入细节（因为细节误差会级联）。规划器还会主动纳入 AI 功能。
• 生成器（Generator）：以“一次一个功能”的 sprint 模式推进，使用 React + Vite + FastAPI + SQLite（后改为 PostgreSQL）实现；每个功能完成后自评，再交由 QA。
• 评估器（Evaluator）：通过 Playwright MCP 以“真实用户”方式点击使用应用，测试 UI、API 与数据库状态；按一组标准评分，任一分项低于阈值则判定该 sprint 失败。

Sprint 契约是关键机制：每个 sprint 开始前，生成器与评估器先就“完成的定义”达成一致（生成器提交目标与验收方式，评估器审查并迭代修订）。这既确保忠实于产品说明书，也避免在实现层面过早收紧约束。Agent 之间通过文件通信：一方写入，另一方读取并在文件里回复或新增文档。

实测对比：单 Agent vs 完整 Harness（基于 Opus 4.5）

任务：构建“2D 复古游戏制作器”，包含关卡编辑器、精灵编辑器、实体行为、可玩的测试模式。

单 Agent 的问题：布局浪费、流程僵硬、缺少引导；更致命的是游戏功能损坏——实体虽能出现但不响应输入，追查发现实体定义与运行时未连通。

Harness 的表现：规划器将一句话 prompt 扩展为涵盖 16 个功能、跨 10 个 sprint 的产品说明书，范围远超单 Agent。除核心编辑器与游戏模式，还包含精灵动画系统、行为模板、音效与音乐、AI 辅助精灵/关卡生成、导出与分享等。UI 更精致，画布充分利用视窗、面板比例合理、风格统一；关键是游戏模式下角色可正常移动与游玩。

评估器的打磨十分细腻。例如在 Sprint 3（关卡编辑器）中就有 27 条验收标准，发现的问题包括：

• 矩形填充工具只在拖拽起止点放置瓷砖，而非填满区域。
• 删除实体生成点的快捷键逻辑条件判断错误。
• 帧重排序 API 路由优先级配置不当，导致返回 422 错误。

要达到这个 QA 水准并不轻松：开箱即用的 Claude 并非理想的 QA Agent，早期常“发现问题又自我说服不是问题”。通过多轮阅读日志、定位其与人类判断偏差之处并迭代 prompt，评估器才逐步变得更严格且实用。

随模型进化，简化架构

首版 harness 表现出色，但体量大、速度慢、成本高。下一步自然是“在不损失效果的前提下瘦身”。原则很清晰：每个组件都基于“模型做不到什么”的假设，这些假设需要不断复查，因为它们可能本就有误，且会随着新模型快速过时。Anthropic 在《Building Effective Agents》中同样强调：从最简可行起步，仅在必要时增加复杂度。

随着 Opus 4.6 发布，简化更具合理性。其在规划、长任务持续性、大代码库可靠性、代码评审与调试、长上下文检索方面显著提升——这些正是 harness 以往在“兜底”的能力。

• 移除 sprint 结构：4.6 已能原生把工作分块，外部脚手架可撤。规划器与评估器保留，但评估器从“每个 sprint 都测”改为构建结束后的单次终审。
• 评估器的投入时机：不再是“要或不要”的二元判断，而是在任务逼近或越过模型独立可靠范围时，才值得投入成本。

更新后 harness 实测：浏览器内构建完整 DAW

任务：用 Web Audio API 在浏览器中构建全功能 DAW（数字音频工作站）。总运行 约 4 小时，花费 $124.70。大头在“构建”阶段——生成器连续跑超两小时，无需 4.5 时代的 sprint 分解。

QA 发现的真实问题：首轮指出应用外观成熟、AI 集成正常，但多个 DAW 核心功能仅“展示式”存在，缺乏交互深度——如时间线无法拖动片段、缺少乐器 UI（合成器旋钮、鼓机 pad）、缺少可视化效果编辑（EQ 曲线、压缩表）。第二轮进一步发现：音频录制仍为桩代码、片段裁剪/分割未实现等。

最终作品距离专业级音乐制作尚有差距——Claude 毕竟“听不见”，在音乐品味上 QA 回路先天受限。但核心要素已打通：编排视图、混音台、传输控制都能在浏览器内工作。更重要的是，Prithvi 仅通过 prompt 就完成了一段短曲的制作：Agent 设定了速度与调性、写出旋律、搭建鼓轨、调整混音电平并加上混响。

方法论与经验

• 持续实验与调优：面向特定模型做针对性实验，阅读其在真实问题上的执行轨迹，有目的地修正 prompt 与流程。
• 分解与专业化：在复杂任务中拆分环节，为关键步骤部署专精 Agent，能获得显著的质量提升空间。
• 模型升级即架构复盘：新模型发布时，主动审视已有 harness，剥离不再承重的模块，同时探索新能力组合可能。

核心判断：有趣的 harness 组合空间不会随着模型变强而缩小，它只是不断迁移。对 AI 工程师而言，真正有意思的工作，是持续找到下一种新颖组合。