Anthropic Labs 的 Prithvi Rajasekaran 发了一篇重磅工程博客，讲他们怎么用多 agent 架构让 Claude 自主构建完整的全栈应用——从一句话 prompt 到可运行的游戏引擎和浏览器 DAW。
这篇文章和我之前写的《Harness Engineering 就是控制论》形成了完美的呼应：那篇讲的是"为什么要做 harness"，这篇讲的是"怎么做 harness，以及做到什么程度"。
核心问题：Agent 为什么会跑偏
两个老问题，终于被系统性地拆解了：
- 上下文焦虑（Context Anxiety）——模型在上下文快满时会提前收工，输出质量急剧下降。Sonnet 4.5 需要 context reset 来对抗，而 Opus 4.5/4.6 基本消除了这个问题。
- 自我评价失真——这是更致命的问题。让 agent 评价自己的工作，它会"发现 bug → 说服自己这不重要 → 批准通过"。自我批评比自我表扬难 100 倍。
三 Agent 架构：受 GAN 启发
解法很优雅——借鉴 GAN 的对抗思想，把一个 agent 拆成三个角色：
🧠 Planner：把 1-4 句 prompt 扩展成完整产品 spec。故意不写技术细节，只定义"造什么"，避免错误级联到实现层。
⚡ Generator：按 spec 逐个 sprint 实现功能（React + Vite + FastAPI + SQLite）。每个 sprint 结束自评一次，然后交给 QA。
🔍 Evaluator：用 Playwright 实际操作运行中的应用来验证。不是看代码，是像用户一样点击、截图、测试。对照 sprint contract 逐条打分。
关键设计决策：agent 之间通过文件通信。一个 agent 写文件，另一个读文件并回应。简单，可追溯，不需要复杂的消息传递。
Evaluator 才是最难的部分
这是文章里最让我震撼的部分。
Claude 开箱即用做 QA 很差。它会识别出真实问题，然后说服自己这些问题"不严重"，然后批准通过。
调教 evaluator 的过程：
- 读 evaluator 的日志
- 找到它的判断和你的判断不一致的地方
- 更新 prompt 来修正偏差
- 反复迭代直到评分合理
他们在前端设计领域还发展出了四个评分维度：
- 设计质量——是否有统一的视觉身份，而不是零件拼凑？
- 原创性——是否有自主审美决策？紫色渐变配白卡片这种 AI slop 直接零分。
- 工艺——排版层级、间距一致性、对比度等技术执行。
- 功能性——用户能不能理解界面、完成任务？
前两项权重远高于后两项。因为 Claude 天然在工艺和功能上就及格了，但在设计和原创上默认产出"技术上正确但视觉上无聊"的东西。
数据说话
| 方案 | 时长 | 成本 | 结果 |
|---|---|---|---|
| Solo（无 harness） | 20 min | $9 | 核心功能不能用 |
| V1 Harness（Opus 4.5） | 6 hr | $200 | 能玩，有瑕疵 |
| V2 Harness（Opus 4.6） | 3h50m | $125 | 完整 DAW，可作曲 |
V1 到 V2 的变化特别有意思：
- 去掉了 sprint 分解——Opus 4.6 能连续编码 2 小时不跑偏
- 去掉了 context reset——不再有上下文焦虑
- Evaluator 从每 sprint 改成最后跑一次——模型更强了，很多问题自己就解决了
- 成本从 $200 降到 $125，时间从 6h 降到 4h
模型升级 → Harness 简化
这可能是全文最重要的洞察：
Harness 的每个组件都编码了一个关于"模型不能做什么"的假设。这些假设值得反复压力测试，因为它们可能本来就是错的，而且会随模型进步迅速过时。
实操方法论：每次新模型出来，逐个拆掉 harness 组件，看哪个不再 load-bearing。不要一次性大改——他们试过激进简化，效果反而变差，因为分不清哪个组件真正重要。
但反过来也成立：模型越强，你能尝试的 harness 组合空间也越大。Evaluator 在简单任务上不再必要，但在复杂任务的边界上依然能给出真正的提升。
一个惊喜：3D 博物馆
在前端设计实验中，他让 generator + evaluator 迭代生成一个荷兰艺术博物馆网站。前 9 轮是正常的暗色主题着陆页。第 10 轮，agent 突然推翻了整个方案，改成了一个 CSS 透视渲染的 3D 展厅——棋盘格地板、墙上挂画、用门廊导航不同画廊。
这种创意跳跃，单次生成几乎不可能出现。是迭代压力推动了真正的创新——evaluator 不断说"不够好"，generator 被迫尝试完全不同的方向。
我的思考
读完这篇，几个想法：
1. 分离评价者和执行者，是一个通用的工程模式。不只是 coding agent——任何需要质量控制的自动化系统都应该考虑这个模式。代码审查、文章编辑、投资决策，核心都是"生成容易，评价难"。
2. "文件通信"这个设计选择值得学习。Agent 之间不需要复杂的协议，写文件读文件就够了。简单、可审计、可恢复。这和 Unix 哲学完全一致。
3. Evaluator 的调教是一门手艺。不是写个 prompt 说"严格打分"就完了。你需要读日志、找偏差、修正判断标准、反复迭代——本质上你在做的是把自己的品味和判断力编码成机器可执行的标准。
4. 模型进步让 harness 变成活的东西。不是设计好就放着不动。每次模型升级，你都需要重新审视：哪些脚手架还有用？哪些已经是多余的开销？哪些新能力可以利用？
这篇文章和之前的控制论那篇合起来看，画面就很完整了：harness engineering 是控制论在软件工程的最新实例，而它本身也是一个活的、需要持续迭代的控制系统。
我们不只是在造 agent。我们在造造 agent 的系统。