题记：本文编译自 Anthropic 工程博客《Harness design for long-running application development》，由 Anthropic Labs 团队的 Prithvi Rajasekaran 撰写。
让 AI 写一个页面或一个简单的函数，如今的大多数编程 AI Agent 都能胜任。但如果你只给它一句话的需求，要求它自己规划产品、拆分任务、写代码、测试、迭代修 Bug，连续运行好几个小时，最后交付一个完整的全栈应用呢？
Anthropic 的工程师一直在攻克这个难题。他们之前发表过一篇关于长时间运行 Agent 的 Harness 设计的文章，解决了在多轮对话中传递上下文的问题。但两个更深层次的问题始终悬而未决：Agent 在长时间运行后开始“划水”，并且它对自己的产出质量过于乐观。
这次，Anthropic Labs 的工程师 Prithvi 换了个思路，从生成对抗网络（GAN）借来了核心理念：将“生成”和“评估”的任务拆分给不同的 Agent。结果如何？仅凭一句话的需求，6 小时后，他们得到了一个可以实际游玩的复古游戏编辑器，还自带 AI 辅助功能。
单 Agent 的两个死穴
在探讨多 Agent 架构之前，有必要先弄清楚为什么单个 Agent 难以胜任长时间的复杂开发任务。
第一个问题是“上下文焦虑”。
在 Claude 3.5 Sonnet 上观察到一个现象：随着上下文窗口逐渐被填满，模型会开始“赶工”，提前结束当前任务。然而，这并不是因为任务完成了，而是因为它感觉“剩余空间”不多了。
这个问题有两种主流解法。一种是“压缩”，在上下文窗口内就地压缩早期对话历史。另一种是“上下文重置”，彻底清空上下文，启动一个新 Agent 接手工作，并通过结构化的交接文档传递状态。Anthropic 的测试表明，“压缩”无法解决模型的焦虑感，因为它仍在同一个对话会话中，仍会感知到空间不足。“上下文重置”更彻底，但代价是交接文档必须写得极其出色，否则新 Agent 会丢失关键信息。
第二个问题更为致命：自我评估偏差。
让一个 Agent 评估自己的产出，它会非常自信地给出高分评价，即使从人类视角看质量平平。这在像前端设计这类主观性较强的任务上尤其明显，由于缺乏非黑即白的对错标准，模型的打分倾向于虚高。
Anthropic 尝试过让生成 Agent 自己进行代码审查，效果并不理想。但当评估职责被剥离，交给一个独立的评估 Agent 后，情况变得可控了。正如原文所说，调教一个独立的评估 Agent 让它变得严格，远比让一个生成 Agent 学会自我批判要容易得多。
这个观察其实并不令人意外。人类也是如此，让开发者自己审查自己的代码，效果通常不如另一位同事来审查。
前端设计：如何让 AI 产出摆脱“AI 味”？
在挑战全栈开发之前，Prithvi 先用前端设计任务进行了实验。这个方向有个优点：虽然设计质量主观，但可以通过制定明确的评分标准来量化评估。
他设定了四个评分维度：
- 设计质量：颜色、排版、布局是否具有统一的美学风格，还是看起来东拼西凑。
- 原创性：是否存在主动的创意决策，还是在套用模板默认值。例如，紫色渐变配白色卡片这种“AI 标配”设计会直接扣分。
- 工艺：字体层级、间距、对比度等基础设计规范的掌握程度。
- 功能性：用户是否能直观理解界面、轻松找到操作入口。
前两个维度的权重更高。因为 Claude 的基础设计能力本就不错，“工艺”和“功能性”通常能过关，但在“设计质量”和“原创性”上，它经常输出平庸的方案。
评估 Agent 配备了 Playwright MCP，它并非简单地看截图打分，而是实际在浏览器中操作页面：点击按钮、滚动页面、截图分析，然后撰写详细的批评意见反馈给生成 Agent。每轮迭代 5-15 次，整个过程可能持续四个小时。
有一个案例很有意思。Prithvi 让模型设计一个荷兰美术馆的网站，前九轮迭代都在渐进式改进，产出了一个深色调的着陆页，视觉上已经相当不错。但在第十轮，模型突然推翻了整个方案，创作了一个 3D 空间体验：使用 CSS 透视渲染了一个带有格子地板的房间，画作“挂”在墙上，房间之间通过“门”来导航，而非传统的滚动或点击。
这种创意上的跳跃，在单次生成中几乎不可能出现。是评估反馈的累积压力，迫使生成 Agent 走出“安全区”去冒险尝试。
不过，这里也有一个有趣的副作用：评分标准中的措辞会直接影响生成方向。Prithvi 在标准中写了一句“最好的设计应该是博物馆级别的”，结果模型的审美开始向某种特定的、更严肃、更艺术化的方向收敛。这说明，评估标准本身不仅是评分工具，也是一种强有力的风格引导。
三个 Agent，协同打造一个完整应用
前端设计的实验验证了“生成器-评估器”模式的可行性。Prithvi 随后将这一模式扩展到了全栈开发领域，架构演变为三个独立的 Agent。
Planner：从一句话需求到完整的产品规格
早期的 Harness 需要用户提供详细的产品规格文档。现在，这个任务由 Planner Agent 接手：给它一句话需求，它输出完整的产品规格文档，包括功能列表、设计语言、Sprint 划分，甚至会主动在产品中嵌入 AI 功能。
Prithvi 特意让 Planner 只做高层设计，不涉及具体实现细节。背后的逻辑是：如果 Planner 在规格文档中写死了技术方案但写错了，这个错误会一路传导至下游开发阶段。不如只约束“要做什么”，把“具体怎么做”的决策权留给生成 Agent。
Generator：按 Sprint 规划逐步推进实现
Generator 接过产品规格文档，按 Sprint 划分逐步实现功能。技术栈选用 React + Vite + FastAPI + SQLite，并引入了 Git 进行版本控制。每完成一个 Sprint，在提交给评估器之前，Generator 会先进行一轮自评。
这里有一个关键的设计细节：在每个 Sprint 开始前，Generator 和 Evaluator 会先“谈判”并签订一份“Sprint Contract”，明确约定该 Sprint 要交付的具体内容以及验收标准。这一步弥补了高层产品规格与具体实现之间的鸿沟。
Agent 之间如何通信？答案很简单：通过文件系统。一个 Agent 将输出写入文件，另一个 Agent 读取文件并回复，没有使用复杂的消息队列或 API 调用。虽然简单，但足够有效。
Evaluator：用 Playwright 模拟真实用户进行验收
Evaluator 并非对着代码打分，而是使用 Playwright 像真实用户一样操作应用：点击按钮、填写表单、测试 API、检查数据库状态。然后，它会根据“Sprint Contract”中的验收标准逐条核对，不达标就打回重做。
调教这个 Evaluator 并不容易。Prithvi 提到，Claude 开箱即用地作为一个 QA Agent 其实表现欠佳：在早期运行中，他观察到 Evaluator 发现了真实的问题，但随后会说服自己这些问题“不是大问题”，最终批准通过。此外，它倾向于只测试表面功能，不愿深入探究边界情况。
调教的方法是反复查看 Evaluator 的日志，找出其判断与人类判断不一致的地方，然后有针对性地修改 Prompt。经过好几轮的迭代，才让它的评分标准达到一个合理且严格的水准。
9 美元 vs 200 美元：产出质量的巨大鸿沟
Prithvi 使用同一个需求测试了单 Agent 架构和三 Agent Harness 架构。需求很简单：开发一个 2D 复古游戏编辑器，需要包含关卡编辑、精灵编辑、实体行为定义以及可运行的游戏测试模式。
| 方案 |
耗时 |
成本 |
| 单 Agent |
20 分钟 |
$9 |
| 三 Agent Harness |
6 小时 |
$200 |
三 Agent 方案的成本高出 20 倍，但产出质量完全不在一个级别。
单 Agent 版本乍看还行，但深入使用就暴露了问题。界面布局浪费空间，面板采用固定高度导致大片空白。操作流程缺乏引导，用户需要自己摸索“先创建精灵和实体，再布置关卡”的顺序。最致命的是，游戏本身无法正常运行：实体出现在画面上但不响应任何输入，代码中实体定义与游戏运行时逻辑的连接是断裂的，从表面难以察觉。
单 Agent 版本的主界面
单 Agent 版本的精灵编辑器
单 Agent 版本的游戏模式——实体不响应输入
三 Agent 版本从同一句话需求出发，Planner 将其扩展为包含 10 个 Sprint、16 项功能的完整规格文档。除了基础的编辑器和测试模式，还规划了精灵动画系统、行为模板、音效/音乐系统、AI 辅助的精灵与关卡生成，甚至包括游戏导出和分享链接功能。Planner 还参考了 Anthropic 的前端设计技能，为整个应用制定了统一的视觉设计语言。
实际体验下来，画布充分利用了视窗空间，面板大小合理，界面拥有统一的视觉风格。精灵编辑器工具更丰富，颜色选择器更好用，缩放控制也更便捷。由于 Planner 主动嵌入了 AI 功能，应用内置了 Claude 集成，可以直接用自然语言生成精灵或设计关卡。
三 Agent 版本的主界面（项目创建）
三 Agent 版本的精灵编辑器
用内置 AI 生成关卡
AI 辅助关卡设计的结果
最关键的区别在于，三 Agent 版本的游戏模式是真正“可玩”的。角色可以移动、跳跃，虽然物理引擎有些粗糙（例如角色跳到平台上有时会出现重叠），但核心游戏循环是通的。
三 Agent 版本的游戏模式——核心功能可以运行
Evaluator 在这个过程中发现了许多具体问题。例如，矩形填充工具只在拖拽的起点和终点放置了瓦片，而不是填满整个区域；删除实体生成点的快捷键判断条件写错了；FastAPI 的路由顺序有问题， reorder 参数被错误地当作 frame_id 去解析。这些都是单 Agent 版本中根本不会被发现的 Bug。
Opus 4.6 时代：Harness 架构的“减肥”与简化
上述的三 Agent 架构是基于 Claude 3.5 Opus 运行的。当更强大的 Claude 3.7 Opus 发布后，Prithvi 做了一件所有复杂系统维护者都应该做的事：重新审视架构中的每一个组件，看哪些在模型能力提升后已经不再必要。
例如，Harness 中的每个组件都编码了一个关于“模型不能做什么”的假设，而这些假设值得用新模型反复检验。
Opus 4.6 在规划能力、长上下文检索和自我纠错方面都有显著提升。于是，Prithvi 去掉了整个 Sprint 机制，不再将工作拆分成小块，而是让 Generator 一次性、连续地编写代码。
Planner 被保留了下来，因为如果没有它，Generator 会低估项目范围，直接开始编码，导致最终产品功能严重缺失。Evaluator 也被保留，但它的工作模式从“每个 Sprint 后评分”调整为“全部开发完成后进行一轮完整的 QA”。
这一简化改变了 Evaluator 的角色定位。在 Opus 4.5 时代，开发任务本身就处于模型能力的边界上，Evaluator 几乎每轮都能发现有意义的问题。到了 Opus 4.6，模型的基础能力边界向外扩展了，许多以前需要 Evaluator 严格把关的部分，现在 Generator 自己就能做得很好。Evaluator 的价值更加集中于那些仍然超出 Generator 当前能力范围的复杂验证和深度测试。
简化后的 Harness 被用来测试一个更大的需求——使用 Web Audio API 在浏览器中开发一个 DAW（数字音频工作站）。
| Agent 阶段 |
耗时 |
成本 |
| Planner |
4.7 分钟 |
$0.46 |
| Build 第一轮 |
2 小时 7 分 |
$71.08 |
| QA 第一轮 |
8.8 分钟 |
$3.24 |
| Build 第二轮 |
1 小时 2 分 |
$36.89 |
| QA 第二轮 |
6.8 分钟 |
$3.09 |
| Build 第三轮 |
10.9 分钟 |
$5.88 |
| QA 第三轮 |
9.6 分钟 |
$4.06 |
| 合计 |
3 小时 50 分 |
$124.70 |
Generator 连续编写了两个多小时的代码，没有 Sprint 分割也没有跑偏，这在 Opus 4.5 上是难以实现的。
QA 环节仍然捕捉到了关键问题。第一轮反馈指出：“应用设计很好，AI Agent 集成也不错，但好几个核心 DAW 功能只是展示用的，时间轴上的音频片段不能拖动，没有乐器 UI 面板，没有可视化的效果器编辑器。这些不是边缘功能，而是让一个 DAW 真正可用的核心交互。” 第二轮继续跟进：“录音功能还是空壳，片段裁剪和分割没实现，效果器可视化只有数字滑块没有图形界面。”
最终产出的 DAW 距离专业软件自然还很遥远，但核心组件一应俱全：编排视图、混音器、音频传输控制。Prithvi 甚至通过内置的 AI Agent，完全用自然语言完成了编曲：设定节拍和调性、铺设旋律、添加鼓点、调整混音、添加混响效果。
写在最后
这篇文章给我最大的启发并非三 Agent 架构本身，而是 Prithvi 对 Harness 简化过程的记录与思考。他一开始尝试激进地砍掉组件，发现行不通，随后改为一次只移除一个组件来观察影响。这种“假设驱动”的工程方法论比任何具体架构都更有迁移价值。无论你是在构建 AI Agent 系统还是传统软件系统，理解每个组件为何存在、其底层假设是否依然成立，都是一个至关重要的工程习惯。
另一个让我印象深刻的点是 Evaluator 的调教过程。它不是一个写几行 Prompt 就能工作的黑箱，而是需要反复查看日志、寻找判断偏差、修改 Prompt、再次验证的持续迭代产物。这与我在构建 AI 评估系统时的体验完全一致——评估系统本身就是一个需要精心设计和持续打磨的产品。
模型在变强，Harness 在变简单，但“找到下一个有效的 Agent 组合”这件事永远不会消失。用 Prithvi 的话来说：“有趣的 Harness 组合空间并不会随着模型的进步而缩小，它只是在不断地移动和演化。”
探索 AI 驱动的复杂应用开发是一个充满挑战与乐趣的领域。如果你对此也有兴趣，欢迎到 云栈社区 与其他开发者交流讨论，分享实践中踩过的坑和收获的洞见。
引用链接
[1] Harness design for long-running application development: https://www.anthropic.com/engineering/harness-design-long-running-apps
[2] Effective harnesses for long-running agents: https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
发表于 2 小时前
|
查看: 1|
回复: 0
