最近 Anthropic 工程团队发了一篇博文，标题叫《Harness design for long-running application development》。这篇文章表面上是在讲他们怎么让 Claude 自主构建完整的应用程序，但读完之后我觉得它触碰到的其实是一个更根本的问题：AI 编程的上限到底是模型能力决定的，还是围绕模型的"工具架"（harness）设计决定的？
他们的实验给出了一个很明确的信号——一个设计良好的三 Agent 系统（规划器 + 生成器 + 评估器），能让 Claude 在 6 小时内自主构建出一个功能完整的 2D 复古游戏编辑器；同样的模型，没有这套工具架，20 分钟就草草收工，核心功能还是坏的。
这不是"prompt 写得好不好"的问题。这是一整套工程方法论的问题。
先说一个你一定遇到过的现象
如果你用 Claude Code、Cursor、或者任何 AI 编程工具做过稍微复杂一点的项目，你大概率观察到过这两个问题：
第一个：Agent 试图一口吃个胖子。 你给它一个像"构建一个类似 claude.ai 的聊天应用"这样的高层级提示，它会尝试把整个应用一次性写完——从路由到数据库到前端到认证全部塞进一个大动作里。结果就是代码量巨大但质量堪忧，各个模块之间的连接漏洞百出。
第二个：Agent 对自己的工作过度自信。 你让它检查一下自己刚写的代码有没有问题，它会信心满满地说"一切看起来很好"——即使一个人类一眼就能看出布局是歪的、按钮点不动、核心功能根本没接通。这个现象在主观性任务（比如前端设计）上尤其严重，因为没有一个像单元测试那样的二元判断标准来打脸。
Anthropic 的团队用了一个很精确的词来描述第一个问题：上下文焦虑（context anxiety） 。模型在上下文窗口快要填满时，会开始急着收工——不是因为任务完成了，而是因为它"感觉到"自己快没空间了。这种焦虑导致它跳过细节、省略功能、匆忙结束。
这两个问题加在一起，就是为什么单个 Agent 做简单任务没问题，但在长时间、多步骤的复杂项目上会"翻车"的根本原因。
Anthropic 的解法：GAN 启发的三 Agent 架构
Anthropic 的 Prithvi Rajasekaran（Labs 团队）提出的解决方案灵感来源出人意料——生成对抗网络（GAN） 。
GAN 的核心思想是：一个生成器和一个判别器互相对抗，生成器试图生成越来越好的输出，判别器试图越来越准确地挑毛病。两者的对抗推动双方同时进步。
把这个思想映射到软件开发上：代码审查和 QA 在软件开发生命周期中本来就扮演着"判别器"的角色。只不过，如果生成代码和评估代码是同一个 Agent，它就会"自己给自己打高分"——就像让一个学生自己批改自己的试卷一样。
所以最终的架构是三个独立的 Agent：
规划器（Planner）
用户只需要给一个 1-4 句话的简短提示（比如"构建一个 2D 复古游戏编辑器"），规划器负责把它展开成一份完整的产品规格说明。
这里有一个关键的设计决策：规划器只关注产品层面和高层技术设计，故意不写详细的技术实现方案。 原因是如果规划器在早期就规定了具体的实现细节，而某些细节是错的，这些错误会级联传递到后续的所有实现中。更聪明的做法是约束"交付物是什么"，让后面的 Agent 自己去想"怎么实现"。
规划器还会主动寻找在产品规格中融入 AI 功能的机会——比如在一个游戏编辑器中加入"用自然语言生成精灵图"或"AI 辅助关卡设计"的功能。
生成器（Generator）
生成器负责实际的编码工作。在较早的版本中，它按照 sprint（冲刺）的方式工作——一次只实现一个功能，完成后自我评估，再进入下一个 sprint。使用的技术栈是 React + Vite + FastAPI + SQLite（后来换成 PostgreSQL），并且使用 git 做版本控制。
在每个 sprint 开始之前，生成器和评估器会协商一份 sprint 合约——双方就"这个 sprint 做什么"和"怎么验证完成"达成一致。这一步存在的原因是产品规格故意写得很高层，sprint 合约用来弥合用户故事和可测试实现之间的鸿沟。
评估器（Evaluator）
评估器是整个系统的灵魂。它拿到 Playwright MCP，像一个真实用户一样操作正在运行的应用——点击按钮、提交表单、测试 API 端点、检查数据库状态。然后按照预定义的评分标准给每个 sprint 打分，任何一项低于阈值就判定 sprint 失败，并生成详细的反馈告诉生成器哪里出了问题。
让评估器靠谱不是一件容易的事。Anthropic 团队明确说了：开箱即用的 Claude 是一个很差的 QA Agent。 在早期的测试中，评估器会发现真实的问题，然后说服自己"这不是什么大事"然后放行。它还倾向于做浅层测试，不深入探查边界情况。
调教评估器的过程是迭代的：读评估器的日志 → 找到它的判断和你的判断不一致的地方 → 更新评估器的 prompt 来修正这些偏差 → 重复。几轮之后，评估器的判断才开始变得合理。
从前端设计开始验证：让主观质量变得可评分
在把这套架构应用到全栈开发之前，团队先在前端设计这个"主观质量"最强的领域做了验证。
核心思路是：虽然美学不能被完全量化，但可以用设计原则把"好不好看"转化为"符不符合标准"。"这个设计漂亮吗？"很难一致地回答，但"这个设计是否遵循了我们的设计原则？"给了模型一个具体的评分依据。
他们定义了四个评分维度：
设计质量：设计是否感觉像一个连贯的整体？颜色、排版、布局、图像是否组合出了独特的氛围和身份？
原创性：有没有自定义的设计决策？还是只是模板布局、组件库默认样式、AI 生成的典型模式？一个人类设计师应该能看出刻意的创意选择。紫色渐变配白色卡片这种典型的"AI slop"在这一项会被直接扣分。
工艺：技术执行的质量——排版层级、间距一致性、颜色协调、对比度。这是能力检查而非创意检查，大多数合理的实现默认就能及格。
功能性：独立于美学的可用性。用户能不能理解界面做什么、找到主要操作、完成任务？
他们故意把设计质量和原创性的权重设得比工艺和功能性高——因为 Claude 在工艺和功能性上默认就能过关，但在设计和原创性上经常产出平淡到乏味的东西。
然后他们跑了 5-15 轮迭代。每轮中，生成器生成一个 HTML/CSS/JS 的前端；评估器用 Playwright MCP 实际浏览页面、截图、评分、写详细评语；反馈回传给生成器作为下一轮的输入。整个过程可以跑到四小时。
有一个例子让人印象深刻：他们让模型为一个荷兰艺术博物馆做网站。到第九轮时，模型产出了一个干净的暗色主题着陆页——看起来不错但符合预期。然后在第十轮，它完全推翻了之前的方案，重新把网站构想为一个空间体验：一个用 CSS perspective 渲染的 3D 房间，棋盘格地板，艺术品以自由形式的位置挂在墙上，用"门"替代滚动或点击来在画廊之间导航。这种创造性跳跃是他们在单次生成中从未见过的。
全栈实战：游戏编辑器的 Solo vs Harness 对比
验证了前端设计之后，团队把这套 GAN 式的架构应用到了全栈开发上。
测试提示只有一句话："创建一个 2D 复古游戏编辑器，包括关卡编辑器、精灵编辑器、实体行为和可游玩的测试模式。"
Solo 模式（单 Agent，无工具架）：跑了 20 分钟，花了 $9。打开应用后初看还行——有关卡编辑器、精灵编辑器。但一点击就出问题了：布局浪费空间，工作流僵硬（没有引导你应该先创建精灵再填充关卡），最致命的是核心游戏功能完全不能用——实体出现在屏幕上但不响应任何输入。翻代码发现实体定义和游戏运行时之间的接线是断的。
三 Agent 工具架模式：跑了 6 小时，花了 $200。规划器把一句话提示展开成了 16 个功能、10 个 sprint 的完整产品规格——除了核心编辑器和播放模式，还规划了精灵动画系统、行为模板、音效音乐、AI 辅助精灵生成和关卡设计、游戏导出和分享链接。
结果差距很明显。工具架版的应用有一致的视觉身份、合理的面板布局、更丰富的精灵编辑器、内置的 Claude AI 功能（可以通过自然语言生成游戏的各个部分），最关键的是——核心游戏功能是可以工作的。可以移动角色、跳上平台（虽然物理还有一些粗糙的边缘）、实际地玩关卡。
评估器在过程中捕获了大量具体的 bug。举几个例子：
- "矩形填充工具应该允许拖拽填充区域——但实际只在拖拽的起点和终点放置了瓷砖，fillRectangle 函数存在但 mouseUp 时没有正确触发"
- "DELETE 键处理器要求同时设置 selection 和 selectedEntityId，但点击实体只设置了 selectedEntityId。条件应该是 selection || (selectedEntityId && activeLayer === 'entity')"
- "PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 把 'reorder' 当作 frame_id 的整数解析，返回 422"
这种细粒度的 bug 报告，不是"感觉有些地方不对"，而是精确到代码行号和修复建议。
工具架的进化：随模型能力提升而简化
这是原文中我觉得最有洞察力的部分。
三 Agent 工具架虽然效果好，但它又贵又慢——$200、6 小时。而且工具架的每一个组件都隐含了一个假设："模型自己做不好这件事"。这些假设值得不断被挑战，因为随着模型能力的提升，某些假设会变得过时。
当 Opus 4.6 发布时，它在长上下文保持、自主任务持续性、代码审查和调试能力上都有显著提升。团队决定重新审视工具架的每一个组件，看哪些还在"承重"，哪些已经可以拆掉了。
最大的简化是去掉了 sprint 结构。sprint 原本存在是因为 Sonnet 4.5 和 Opus 4.5 无法在一个长时间的连续会话中保持连贯——需要把工作拆成小块，每块之间做上下文重置。但 Opus 4.6 原生就能在长时间会话中保持连贯，Claude Agent SDK 的自动 compaction 处理上下文增长。所以 sprint 构造、上下文重置、sprint 合约协商——这些都可以去掉了。
评估器从"每个 sprint 结束时评估"变成了"整个构建结束后做一轮评估"。但它仍然在承重——在模型能力边界上的任务，评估器继续捕获生成器漏掉的功能缺口和 bug。
简化后的工具架用来构建了一个浏览器内的数字音频工作站（DAW）。提示只有一句话："用 Web Audio API 在浏览器中构建一个功能完整的 DAW。"跑了约 4 小时，花了 $124——其中生成器第一轮跑了 2 小时 7 分钟，连续编码，没有 sprint 分解。
评估器仍然捕获了真实的缺陷：
"虽然应用看起来很棒、AI Agent 集成也很好，主要的失败点在功能完整性——虽然应用看起来令人印象深刻，但几个核心 DAW 功能只是展示而没有交互深度：片段不能在时间线上拖拽/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），没有可视化效果编辑器（EQ 曲线、压缩器表）。这些不是边缘情况——它们是让 DAW 可用的核心交互。"
最终产出是一个可以工作的音乐制作程序：可以用自然语言让内置 AI Agent 设置节奏和调性、铺旋律、做鼓轨、调混音器电平、加混响。虽然离专业级还很远（Claude 不能真的"听"音乐，所以 QA 在音乐品味上的反馈循环效果有限），但核心的作曲原语都在了。
几个可以带走的工程原则
读完这篇博文和相关材料之后，我总结了几个我认为对日常 AI 工程实践有直接价值的原则。
原则一：把"做"和"评"分给不同的 Agent
这是全文最核心的一个结论。让同一个 Agent 评价自己的工作，它几乎一定会过于宽容。分离之后，调教一个独立的评估器让它变得严格，比让一个生成器对自己的工作变得批判性，要容易得多。
而且一旦有了外部反馈，生成器就有了一个具体的东西来迭代改进。这跟人类的代码审查是同一个道理——写代码的人和审代码的人最好不是同一个人。
原则二：工具架的每一个组件都应该标注"假设"
sprint 结构假设"模型不能在长会话中保持连贯"。上下文重置假设"compaction 不足以解决上下文焦虑"。sprint 合约假设"模型不能直接从高层规格推导出可测试的实现"。
当模型从 Sonnet 4.5 → Opus 4.5 → Opus 4.6 升级时，这些假设中的一些变得不再成立。如果你不主动去检验这些假设，你的工具架就会积累不再承重但仍然增加复杂度和成本的"遗留组件"。
Anthropic 在他们之前的《Building Effective Agents》文章中说过一句很好的话："找到最简单的可行方案，只在需要时才增加复杂度。"反过来说同样重要：定期审视已有的复杂度，去掉不再需要的部分。
原则三：规划器应该约束交付物而不是实现路径
规划器故意不写详细的技术实现方案，只定义"要交付什么"。这个决策的理由是：如果规划器在早期就锁定了技术细节，而某些细节是错的，这些错误会级联传播到后续所有实现。
换一种方式理解：规划器是产品经理，不是技术 lead。它定义需求和验收标准，让下游的 Agent 自己决定怎么实现。这种关注点分离在人类软件团队中也是最佳实践。
原则四：评估器的校准是一个持续的过程
开箱即用的 LLM 不是好的 QA。它需要被调教——通过几轮反馈循环：看评估器的日志 → 找到它判断失误的地方 → 更新 prompt → 重复。
这不是一次性的事情。随着生成器的输出质量提升，评估器的标准也需要相应提高。否则评估器就变成了一个只会说"都挺好"的橡皮图章。
原则五：模型越强，工具架的"有趣组合空间"不是缩小而是移动
这是原文最后一句话，也是我认为最深刻的一个洞察：
"有趣的工具架组合空间不会随模型改进而缩小。它会移动。AI 工程师有趣的工作是不断发现下一个新的组合。"
随着模型变强，一些简单任务不再需要复杂的工具架。但同时，模型变强也让更复杂的任务变得可能——这些更复杂的任务又需要新的工具架设计。简单说就是：天花板在往上抬，但不是没有天花板。
这跟你的日常开发有什么关系
你可能不需要构建一个 6 小时运行的三 Agent 系统来写一个游戏编辑器。但这篇文章背后的工程思维对任何使用 AI 编程工具的人都有直接价值。
如果你在用 Claude Code / Cursor 做复杂项目： 不要指望一句 prompt 搞定一切。把任务拆解（规划器的角色），一次只做一个功能（sprint 的思想），做完之后让 AI 或你自己从用户视角检查一遍（评估器的角色）。这种人工版的三 Agent 流程，在日常开发中已经能带来很大的提升。
如果你在构建自己的 AI Agent： 考虑引入"生成-评估"的分离。不一定要两个独立的 Agent——一个简单的做法是在 Agent 的工作流末尾加一个"自检步骤"，用不同的 prompt（明确要求批判性而非赞美）来评估自己的输出。即使是这样轻量的分离，也比完全没有评估好得多。
如果你在管理使用 AI 工具的团队： 注意模型更新。每次模型升级时，花一点时间检查你们的 AI 工作流——有没有哪些步骤是在补偿旧模型的弱点，而新模型已经不再需要了？这些步骤如果不去掉，就是在浪费时间和 token。
成本的现实
最后聊一个不能回避的话题：成本。
三 Agent 工具架构建游戏编辑器花了 124。这对个人开发者来说不便宜。但换一个角度看——一个人类开发者从零构建一个功能等价的游戏编辑器或 DAW，需要多少个工时？即使按 200-300。而且这是完全自主、无人干预的。
更重要的是趋势。随着模型能力提升，工具架可以变得更简单（sprint 结构被去掉就是例子），成本会下降。从 v1 到 v2 已经从 124/4h，而且输出质量在提升。
现在看来成本还偏高的场景，可能在一两代模型之后就变得完全经济可行了。而工具架的设计模式——三 Agent 分离、规划-生成-评估循环、假设标注和定期简化——这些工程思维不会因为模型更新而过时。
本文基于 Anthropic 工程博客 2026 年 3 月 24 日发布的《Harness design for long-running application development》（作者 Prithvi Rajasekaran）进行扩展分析。原文链接：anthropic.com/engineering/harness-design-long-running-apps。建议结合原文阅读，其中包含完整的代码示例、实验日志截图和 Appendix 中的规划器输出示例。
