用 GAN 的思路设计 AI 编程 Harness：Anthropic 的多智能体实践

发布： 2026-03-25 分类： AI Engineering 阅读：

背景

Anthropic 工程师 Prithvi Rajasekaran 在官方博客发表了一篇 harness 设计指南，介绍他们如何用多智能体架构突破单 agent 编程的天花板。

这篇文章的核心洞察来自 GAN（生成对抗网络）：把生成和评估分离成两个独立的 agent，通过反复迭代驱动质量提升。这个思路先在前端设计任务上验证，再扩展到完整的全栈应用开发。

单 Agent 的两个根本问题

在介绍多 agent 方案之前，文章先诊断了单 agent 的失败模式。

问题一：Context 焦虑

随着对话上下文增长，模型会逐渐失去连贯性。更严重的是，某些模型（比如 Sonnet 4.5）会在接近它认为的上下文上限时提前收工——功能还没做完，就开始”总结”和”交付”。

压缩（compaction）可以缓解上下文增长，但无法消除焦虑，因为模型知道自己是在一个漫长的对话里继续跑。Context reset 才是根治方案：清空上下文，启动全新 agent，通过结构化的交接文件传递状态。代价是更高的 token 开销和延迟，但换来了干净的起点。

问题二：自我评估偏差

让 agent 评估自己刚写完的代码，它几乎总是给好评——即便结果明显有问题。这在主观任务（比如设计）上尤为严重，因为没有二进制的对错可以验证。

把生成和评估分给两个独立的 agent，并且专门调教评估 agent 保持怀疑态度，比让生成 agent 自我批评要容易得多。

前端设计：让主观质量可量化

第一个实验在前端设计任务上展开。

核心问题是：「这个设计好不好？」无法直接回答，但「这个设计是否符合以下四条标准？」可以。Prithvi 定义了四个评分维度：

维度	说明
设计质量	颜色、排版、布局是否形成统一的视觉语言，而不是零件的堆砌
原创性	是否有明显的定制决策，还是模板布局 + 库默认值 + AI 生成模式（比如白卡片上的紫色渐变）
工艺	排版层级、间距一致性、色彩对比度等基础技术执行
功能性	用户能否理解界面、找到主要操作、完成任务

前两个维度权重更高，因为 Claude 在工艺和功能性上默认就表现不错，而设计质量和原创性才是薄弱环节。评估 agent 拿到 Playwright MCP，可以直接与运行中的页面交互，而不是对着静态截图打分。

循环跑 5-15 次迭代。每次迭代，评估 agent 给出详细批评，生成 agent 决策：沿当前方向细化，还是换一个完全不同的美学风格重来。

一个典型案例：荷兰艺术博物馆网站。前九次迭代生成的是精致但常规的深色主题页面。第十次，模型推翻了整个方案，改成了 CSS 3D 透视渲染的空间体验——棋盘格地板、画作挂在墙上、通过门洞在展览室之间导航。这种创意跳跃在单次生成中从未出现过。

全栈编程：三 Agent 架构

把生成-评估循环移植到全栈开发，形成了三个 agent 的分工：

用户提示（1-4句话）
    ↓
[Planner] → 完整产品规格（功能列表 + 技术设计 + 视觉风格）
    ↓
[Generator] → 按 sprint 逐功能实现，每个 sprint 前与 Evaluator 签约
    ↓
[Evaluator] → 用 Playwright 点击运行中的应用，按合约逐条验证
    ↓
不通过 → 反馈给 Generator，继续迭代
通过 → 下一个 sprint

Planner 的作用是把模糊需求扩展成有野心的产品规格，同时避免过度规定实现细节（防止错误的技术细节向下游传播）。它还会主动寻找机会把 AI 功能编织进产品。

Generator 按 sprint 工作，每个 sprint 只做一个功能。实现前先和 Evaluator 签「sprint 合约」，明确定义「完成」的标准和可测试的验收条件，再开始写代码。

Evaluator 是整个架构里调教成本最高的部分。开箱即用的 Claude 是个糟糕的 QA agent——它会发现问题，然后说服自己「这不是大问题」然后放行。调教过程是：读 evaluator 的日志，找它的判断和人类判断的偏差，更新 prompt 修正。经过几轮迭代，evaluator 才能可靠地发现真实 bug。

一个具体的 bug 发现示例：

合约标准：用户可以通过 API 重新排序动画帧
Evaluator 发现：PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 把 reorder 当成 frame_id 整数解析，返回 422 错误：”unable to parse string as an integer”

这类 bug 在人工测试中很容易被漏掉，但 evaluator 的系统化覆盖能稳定发现。

对比实验：单 Agent vs 完整 Harness

用「2D 复古游戏制作工具」作为测试 prompt：

	单 Agent	完整 Harness
时长	20 分钟	6 小时
成本	$9	$200
核心功能	游戏逻辑接线断裂，实际无法玩	可以移动角色，游戏基本可玩
功能范围	基础编辑器	16 个功能：动画系统、音效、AI 辅助生成、游戏导出

成本高 20 倍，但核心功能从「不可用」到「可用」。

随模型升级简化 Harness

Opus 4.6 发布后，文章做了一轮 harness 简化实验。

移除 sprint 分解：Sonnet 4.5 需要 sprint 结构来保持连贯性，Opus 4.6 可以连续工作 2 小时以上不需要人工分解。sprint 构件被移除，evaluator 改为在整个 build 结束后做一次总验收。

移除 context reset：Opus 4.6 的 context 焦虑行为大幅减弱，自动 compaction 足够应对上下文增长。

保留 Planner 和 Evaluator：没有 planner，generator 会欠缺规划，做出功能更少的应用。evaluator 在 build 边界附近仍然能发现真实 bug。

简化后的 harness 用「浏览器 DAW 音乐制作工具」做验证：

阶段	时长	成本
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
合计	3 小时 50 分钟	$124.70

最终产出：一个在浏览器里运行的 DAW，包含编排视图、混音台、音轨传输，内置 Claude agent 可以通过自然语言完成编曲——设定节拍和调性、生成旋律、构建鼓轨、调整混音电平、添加混响。

几条可复用的原则

文章最后提炼了几条普适原则，值得记住：

1. Harness 的每个组件都编码了一个假设

假设是「模型在这件事上做不好，需要外部脚手架」。随着模型升级，这些假设会失效。定期重新审视 harness，移除不再承重的部分。

2. 评估分离比自我评估有效得多

把生成和评估分给两个 agent，专门调教评估 agent 保持怀疑，比让生成 agent 自我批评要可靠得多。

3. 主观质量可以通过标准化变得可评分

「这个设计好不好？」→「这个设计是否符合设计质量、原创性、工艺、功能性四条标准？」。把模糊判断转化成可量化的标准，是让 evaluator 工作的前提。

4. 模型越强，有趣的 harness 组合越多，不是越少

模型能力提升会让某些脚手架变得不必要，但同时打开了新的可能性空间。有趣的工程工作是持续找到下一个有价值的组合。

原文：Harness design for long-running apps
作者：Prithvi Rajasekaran，Anthropic Labs