如何设计 Harness 工程，实现长时间自动开发应用

最近，Anthropic 工程团队发了一篇技术博客《长时间运行应用开发的 Harness 设计》^[1]，分享了他们在 AI 自主编程方面的最新探索。简单来说，他们设计了一套让多个 AI 协同工作的架构，用来解决一个很现实的问题：怎么让 AI 持续工作好几个小时，独立完成一个完整的应用程序。

这个探索来自 Anthropic Labs 团队成员 Prithvi Rajasekaran 在两个方向上的实践：一个是让 Claude 做出更好看的前端设计，另一个是让 Claude 在没有人类干预的情况下独立完成完整的应用开发。两个方向之前都取得了一些进展，但也都碰到了天花板。

为了突破瓶颈，他从生成对抗网络（GAN）中借来了一个 核心思路 ：让一个 AI 负责生成，另一个 AI 负责评估。最终形成了一套包含 三个 AI 的架构，让它们在连续数小时的自主编程中，协同完成功能丰富的全栈应用。

这背后的思路和发现，对我们理解 AI 的能力边界和协作方式，都有不少启发。

单干的 AI，有两个绕不过去的软肋

在聊多 AI 协作之前，得先说说为什么让一个 AI 单独干活，效果总是差一点。

Anthropic 团队在之前的实验中就做过类似的尝试。他们用一个初始化 AI 把产品说明书分解成任务列表，再用一个编程 AI 逐个实现功能，做完一个再做下一个，中间通过结构化的文档来传递上下文。社区里也有人用类似的思路，比如用脚本和 hook 让 AI 持续迭代。但即便如此，面对比较复杂的任务，AI 还是会随着时间推移逐渐跑偏。

他们把问题拆解之后，发现了两个反复出现的失败模式。

第一个叫 「上下文焦虑」（context anxiety） 。当 AI 处理一个比较长的任务时，它的上下文窗口会逐渐被占满。随着对话越来越长，AI 的表现开始下降（关于这一点，他们在上下文工程那篇博客里有更详细的讨论）。更麻烦的是，有些模型还会出现一种奇怪的行为：它觉得自己的上下文快用完了，就开始匆匆忙忙地收尾，草率地结束任务。

这有点像一个学生在考试快结束时，看了看表，发现时间不多了，赶紧把后面的题目潦草写几笔交上去。明明还有时间，但心理上的压力让他提前放弃了认真作答。

他们尝试过用「压缩」（compaction）的方式来解决，就是把前面的对话做个摘要，让 AI 在缩短后的历史上继续工作。但这种方式只是缩短了对话长度，AI 心理上的那种焦虑感并没有消失。在他们的测试中，Claude Sonnet 4.5 的上下文焦虑表现得尤为明显，单靠压缩根本不够用。

真正有效的做法是直接 「重置」（context reset） ：清空上下文，启动一个全新的 AI，然后通过一份结构化的交接文档，把之前的工作状态和下一步计划传递过去。相当于换了一个精力充沛的新人接班，同时给他一份详细的工作交接清单。这个方法解决了核心问题，但也带来了额外的编排复杂度、token 开销和延迟。

第二个问题更有意思：AI 的 自我评价严重失真 。当你让一个 AI 评价自己刚做完的工作时，它几乎总是往好里说。即使在人类看来输出质量明显平庸，AI 还是会自信满满地给自己打高分。

这个问题在设计类任务上尤其严重，因为设计好坏很主观，没有像软件测试那样的客观标准可以直接验证。一个布局到底是精致还是平庸，本身就是一个见仁见智的判断，而 AI 在这种判断上会系统性地偏向乐观。

想想看，这在人类世界里也很常见。让一个人评价自己的作品，多多少少都会有些滤镜。区别在于，人类还能偶尔意识到自己的偏见，AI 的这种自我表扬倾向就更加系统化了。

不过，即使是在有客观验证标准的任务上，AI 在执行过程中也经常表现出糟糕的判断力。解决思路其实很直觉：既然自己评价自己不靠谱，那就 让另一个 AI 来评价 。把做事和判断分开，本身就是一个 强有力的杠杆 。更关键的是，调教一个独立的评估者让它变得更严格，比让创作者学会自我批评要容易得多。一旦外部反馈存在了，创作者就有了明确的改进方向。

从 GAN 借来的灵感：把主观审美变成可以打分的标准

解决了「谁来评价」的问题之后，紧接着就是另一个难题：像「这个设计好不好看」这种主观判断，怎么才能让 AI 评得靠谱？

Anthropic 团队从两个洞察出发构建了前端设计的实验架构。第一个洞察：虽然审美没法完全量化成一个分数，个人口味也各不相同，但我们可以用一组编码了设计原则和偏好的评分标准来改善它。「这个设计美不美？」很难一致回答，但「这个设计有没有遵循我们定义的好设计原则？」就给了 AI 一个具体的评判依据。

第二个洞察：把前端生成和前端评分分开，可以形成一个持续驱动生成器走向更好输出的反馈循环。

基于这两个洞察，他们写了四个评分标准，同时放在生成器和评估器的提示词里：

设计质量： 设计整体有没有统一的风格和氛围。颜色、排版、布局、图像和其他细节是否组合在一起创造了一种独特的情绪和辨识度，还是像七拼八凑出来的。

原创性： 设计中有没有体现出自主的创意决策，还是用的都是模板布局、库默认值和 AI 生成的套路。一个人类设计师应该能认出刻意的创意选择。那些未经修改的库组件，或者一眼就能认出的 AI 风格（比如紫色渐变配白色卡片），在这个维度上直接不及格。

工艺水平： 技术层面的检查，包括字体层级、间距一致性、颜色和谐度、对比度等。这是能力检查，多数合理的实现默认就能过关，不及格意味着基本功有问题。

功能性： 独立于美观之外的可用性。用户能不能看懂界面要干什么，能不能找到主要操作按钮，能不能不靠猜就完成任务。

他们有意把设计质量和原创性的权重调得比工艺和功能更高。因为 Claude 天然就擅长做出功能正确、技术规范的东西，工艺和功能上的基本功本来就不错。但在美感和创意上经常表现平庸。通过明确惩罚那些 「AI 味十足」 的通用模式，推着模型在审美上冒一些险。

这个思路其实可以迁移到很多场景。当我们面对一个模糊的目标时，与其纠结于「到底什么算好」，不如先把 「好」拆成几个可以观察、可以衡量的维度 ，然后有针对性地去提升。

他们用少样本示例（带详细打分解析）来校准评估器，确保评估器的判断和团队的偏好一致，同时减少多轮迭代中的评分漂移。

在实际运行中，整个架构搭建在 Claude Agent SDK 上。生成器先根据用户提示词创建一个 HTML/CSS/JS 前端页面。评估器配备了 Playwright MCP，可以直接操控活页面进行交互，在打分之前自己浏览、截图、仔细研究实现效果，然后对每个维度打分并写出详细评语。这些反馈再流回给生成器，作为下一轮迭代的输入。

每一轮生成要进行 5 到 15 次迭代，每次迭代都会把生成器推向一个更有特色的方向。因为评估器是真的在操控页面，每个循环都需要真实的时间。完整的运行可能持续四个小时。

他们还指示生成器在每次评估后做一个策略决策：如果分数趋势向好，就继续在当前方向上精打细磨；如果当前方向不行，就大胆转向一种完全不同的美学风格。

跑下来的结果显示，评估器的评分在前几轮迭代中稳步提升，然后趋于平稳，但仍有改进空间。有些生成过程是渐进式的微调，有些则在不同迭代之间出现了剧烈的美学转向。

一个有趣的发现是：评分标准的措辞本身就会塑造生成器的输出方向。比如标准里有一句 「最好的设计是博物馆级别的」 ，结果就让设计朝着某种特定的视觉方向收敛了。这说明评分标准本身就在引导生成，即使在评估器反馈之前。

虽然分数总体上随着迭代提升，但这个过程并不总是线性的。后面的版本整体上更好，但团队也经常发现中间某一轮的设计比最后一轮更打动人。实现的复杂度也在不断增加，生成器为了回应评估器的反馈，会尝试越来越大胆的方案。有意思的是，即使是第一轮迭代，输出就已经比完全没有提示词的基线版本好了不少，说明评分标准和相关的提示词语言本身，就已经把模型从通用默认值的泥沼里拉了出来。

效果最惊艳的一个例子是荷兰艺术博物馆网站。他们让 AI 为一个虚构的荷兰艺术博物馆做网站。前九轮迭代下来，做出了一个深色主题的着陆页，干净漂亮，但基本在预期之内。到了第十轮，AI 突然推翻了之前所有的方案，重新构想了一个空间体验式的设计：用 CSS 透视渲染了一个带棋盘格地板的 3D 房间，画作自由悬挂在墙上，用户通过「门洞」在不同展厅之间导航，取代了传统的滚动或点击操作。这种创意跳跃，是单次生成从来没有出现过的。

下面是这个博物馆网站的演示视频：

很多时候我们做事情，前几轮的尝试看起来都还行，但如果就此满足，可能会错过后面那个 真正惊艳的方案 。给自己留出足够的迭代空间，有时候比一上来就追求完美更重要。

三个 AI 组队：规划、执行、质检

在前端设计上验证了思路之后，他们把这套方法扩展到了全栈开发领域。生成器加评估器的循环，天然就映射到了软件开发生命周期中的代码审查和 QA 环节。

他们在之前长任务架构的基础上，构建了一个 三 AI 系统 ，每个 AI 针对他们在之前的运行中观察到的特定短板：

规划者（Planner）： 之前的方案要求用户提供一份详细的产品说明书，这本身就是个门槛。于是他们做了一个专门的规划 AI，用户只需要给一到四句话的描述，规划者就会自动展开成一份完整的产品规格说明。规划者被要求尽量把功能想得丰富一些，同时专注于产品上下文和高层技术设计，不去纠结具体的实现细节。

背后的考量是：如果规划者在一开始就把技术细节写得太具体，万一哪个地方想错了，错误就会像多米诺骨牌一样传递到后面整个实现过程。把交付物约束好就行，让执行的 AI 自己摸索路径。他们还让规划者主动寻找在产品中融入 AI 功能的机会。

这个策略值得细想。在管理和协作中，过度详细的前期规划 有时候反而是个陷阱。方向对了，执行者有足够能力的话，留出灵活空间 往往比事无巨细地规定每一步要好。

生成器（Generator）： 实际写代码的 AI。沿用了之前每次只做一个功能的方式，按照功能点逐个推进。每一轮实现都使用 React + Vite + FastAPI + SQLite（后来换成 PostgreSQL）的技术栈，做完后先自我检查一遍，再交给评估器。它还配了 git 做版本控制。

评估器（Evaluator）： 相当于 QA 工程师。之前的架构产出的应用看起来很酷，但真正用起来总有各种 bug。为了抓住这些问题，评估器配备了 Playwright MCP，像真实用户一样点击运行中的应用，测试界面功能、API 接口和数据库状态。它按照一套评分标准给每一轮开发打分，涵盖产品深度、功能完整性、视觉设计和代码质量四个维度。每个维度都设了硬性阈值，任何一项低于阈值，这一轮就算没通过，生成器会收到详细的反馈去修复。

一个很巧妙的设计是 「开发协议」（sprint contract） ：在每一轮开始之前，生成器和评估器会先「谈判」一份协议，明确这一轮要做什么、怎么验证算完成。这个环节存在的原因是，产品规格说明故意写得比较高层，需要一个步骤来衔接用户故事和可测试的实现。生成器提出它要做什么以及怎么验证成功，评估器审查这个提案，确保生成器在做正确的事情。双方反复协商直到达成一致。

沟通方式是通过文件：一个 AI 写文件，另一个 AI 读文件并回复，或者写一个新文件让对方来读。生成器按照协商好的协议开发，完成后交给 QA。这种方式让工作始终忠于产品规格，同时又不会过早地把实现细节卡死。

先达成共识再动手，听起来简单，但无论是 AI 协作还是人类团队协作，很多项目出问题恰恰就是因为 一开始就没把完成标准说清楚 。

9 美元 vs 200 美元：差距到底有多大

为了检验这套架构的实际效果，他们做了一个对比实验。

第一版架构使用的是 Claude Opus 4.5，他们用同样的提示词分别在完整架构和单 AI 系统上运行。提示词只有一句话：

创建一个 2D 复古游戏制作器，包含关卡编辑器、精灵编辑器、实体行为和可玩的测试模式。

下面是两种方式的时间和成本对比：

贵了 20 多倍。 但打开两个版本一用，差距一目了然。

单 AI 的版本乍一看还行，界面各部分都有，编辑器能打开，也能创建精灵和实体。下面是单 AI 版本打开后的初始界面：

但真正用起来就露馅了。布局浪费大量空间，固定高度的面板让大部分视口都空着。操作流程很僵硬，要往关卡里填东西，系统提示你得先创建精灵和实体，但界面上完全没有引导你该按什么顺序来。下面是单 AI 版本的精灵编辑器：

最致命的是 核心功能压根就跑不通 。实体放到了关卡里，但游戏运行起来什么都不响应，角色出现在屏幕上却没有任何输入反馈。深入看代码才发现，实体定义和游戏运行时的连接根本就是断的，而且界面上没有任何线索告诉你问题出在哪儿。下面是尝试在单 AI 版本中运行游戏的画面，可以看到实体完全无法操控：

三 AI 架构的版本就完全不同了。同样的一句话需求，规划者把它展开成了涵盖 16 个功能 、分 10 个开发周期 完成的完整规格说明，远超单 AI 的想象范围。除了基本的编辑器和游戏模式，还加入了精灵动画系统、行为模板、音效和音乐，甚至还有 AI 辅助的精灵生成器和关卡设计器，以及游戏导出和分享链接功能。规划者还读取了 Anthropic 的前端设计技能文档，为这个应用创建了一套视觉设计语言。每一轮开发，生成器和评估器都会先协商一份协议，定义具体的实现细节和验收标准。

打开应用，马上就能感受到比单 AI 版本多出来的精致和流畅。画布用满了整个视口，面板大小合理，界面有一套统一的视觉风格，和规格说明中定义的设计方向一致。下面是三 AI 架构版本的初始界面，正在创建一个新游戏项目：

当然也有一些单 AI 版本中出现的笨拙感依然存在。操作流程没有很好地引导用户应该先做精灵和实体再去填充关卡，需要自己摸索。这更像是基础模型在产品直觉上的短板，而不是架构能解决的问题。不过这也指出了一个方向：在架构内部增加有针对性的迭代，可以进一步提升输出质量。

深入编辑器之后，三 AI 版本的优势更加明显了。精灵编辑器更丰富、更完整，工具面板更清爽，颜色选择器更好用，缩放控制也更顺手。下面是三 AI 架构版本的精灵编辑器，和单 AI 版本对比明显更清爽好用：

因为规划者被要求在规格中主动融入 AI 功能，这个应用还自带了 Claude 集成，让用户可以通过自然语言提示来生成游戏的不同部分，大大加速了工作流程。下面两张图展示了使用内置 AI 功能生成关卡的过程和效果：

最大的差别在游戏模式里。这次，角色可以控制了，游戏是真的能玩的。物理效果还有些粗糙，角色跳到平台上时有些穿模，手感上不太对。但 核心功能是通的 ，这一点单 AI 版本根本没做到。多走几步之后也碰到了一些限制，AI 构建的关卡里有一面大墙跳不过去，被卡住了。这说明常识层面的改进和边角情况的处理，还有进一步优化的空间。下面是三 AI 架构版本的游戏模式，可以看到角色已经能正常操控了：

评估器的工作日志很能说明问题。每一轮开发周期，它都会对照协议里的验收标准，通过 Playwright 操作运行中的应用，把任何偏离预期行为的地方作为 bug 记录下来。协议的颗粒度非常细，光是第三轮的关卡编辑器就有 27 条验收标准。评估器发现的问题也具体到可以直接行动，不需要额外调查。下面是几个例子：

让评估器做到这个水平并不容易。直接用的话，Claude 是一个 很差的 QA 代理 。在早期运行中，Anthropic 团队眼看着评估器发现了真实的问题，然后自说自话地觉得这些问题不算什么，大方地批准了。它还倾向于 只做表面测试 ，不深入探查边角情况，导致更隐蔽的 bug 经常溜过去。

调教的过程就是反复阅读评估器的日志，找到它的判断和团队判断不一致的地方，然后更新 QA 提示词来解决这些问题。来回好几轮之后，评估器的评判才达到一个团队觉得合理的水平。即便如此，最终输出仍然暴露了模型 QA 能力的局限：一些细小的布局问题、某些地方不太直觉的交互、以及评估器没有深入测试到的嵌套功能中的未发现 bug。验证层面显然还有进一步提升的空间。但和单 AI 版本相比，连应用的核心功能都跑不通，提升是显而易见的。

模型变强了，脚手架就该拆

有了初步成果之后，下一步自然是思考怎么简化。200 美元和 6 个小时 的成本，还是太重了。

他们总结了一个很有意思的原则：架构中的每个组件，本质上都编码了一个关于模型做不到什么的假设。 而这些假设值得经常检验，因为它们可能本来就不对，也可能随着模型升级而过时。他们之前那篇「构建有效代理」的博客也总结了类似的理念：先找到最简单的可行方案，只在必要时才增加复杂度。

第一次简化尝试比较激进，一下子砍掉了太多东西，还尝试了一些创新想法，结果没能复现原来的性能。而且到了这一步，很难分清架构中的哪些部分是真正承重的，承了什么重。基于这个教训，他们改用更系统的方式：每次只拿掉一个组件，观察它对最终结果的影响。

正好这时 Anthropic 发布了 Claude Opus 4.6。新模型在规划能力、长任务持续性、大代码库操作、代码审查和自我纠错方面都有明显提升，长上下文检索能力也大幅改善。这些能力，恰恰都是之前架构为了弥补模型短板而搭建的。所以有充分的理由期待 4.6 需要的脚手架比 4.5 更少 。

拆掉开发周期。 之前为了让模型在长任务中保持连贯，他们把工作拆成一个个小的开发周期。鉴于 Opus 4.6 的能力提升，有理由相信模型可以原生地处理这种工作分解，不再需要外部拆分。

同时，Opus 4.5 之前表现出的强烈的「上下文焦虑」行为，在 Opus 4.6 上基本消失了。 所以他们可以直接去掉上下文重置机制，让整个 AI 作为一个连续会话运行完全部构建过程，用 Claude Agent SDK 的自动压缩来处理上下文增长。

他们保留了规划者和评估器，因为两者的价值依然明显。没有规划者的话，生成器面对原始提示词会直接开始写代码，不会先做规格说明，最终产出的应用功能远不如有规划者的版本丰富。

评估器则从每轮评估改成了全部完成后评估一次。因为模型能力变强了，评估器的承重作用随着任务的不同而变化。在 Opus 4.5 上，他们的构建任务正好卡在模型能力的边界上，评估器在整个构建过程中都能抓到有意义的问题。到了 Opus 4.6，模型的原始能力提升了，这个边界往外移了。之前需要评估器检查才能正确实现的任务，现在经常在生成器的能力范围之内了，评估器就成了不必要的开销。但对于那些仍然处于生成器能力边界上的构建部分，评估器依然能带来真实的提升。

换句话说，评估器的价值取决于当前任务相对于模型能力的位置。

任务在模型的舒适区内，评估器就是多余的成本；任务在模型的能力边界上，评估器就是不可或缺的。这让评估器变成了一个动态的决策，而非固定的是或否。

在结构简化的同时，他们还优化了提示词，改进了架构在应用中构建 AI 功能的方式，具体来说就是让生成器构建一个能通过工具驱动应用自身功能的代理。这个调教花了不少功夫，因为相关知识足够新，Claude 的训练数据对这部分覆盖很薄。但经过反复调整，生成器确实学会了正确地构建代理。

简化后的架构实战：从零做出一个音乐制作软件

为了测试更新后的架构，他们用了下面这个提示词来生成一个数字音频工作站（DAW），也就是那种用来作曲、录音和混音的音乐制作软件：

在浏览器中使用 Web Audio API 构建一个功能完整的 DAW。

运行仍然耗时不短，约 4 小时 ，成本 124 美元 。但和第一版的 200 美元比，已经省了不少。

大部分时间花在了生成器上，它连续工作了两个多小时，不再需要之前 Opus 4.5 那样的开发周期分段。下面是各阶段的详细数据：

和之前的架构一样，规划者把一句话的提示词展开成了完整规格说明。从日志来看，生成器在规划应用和代理设计、连接代理、测试代理后交付 QA 这些环节上都表现得不错。

但 QA 代理仍然 抓到了真实的问题 。第一轮反馈中指出：

这是一个设计精良、AI 集成扎实、后端稳健的应用。主要的失败点在功能完整性上。虽然应用看起来很酷，AI 集成也做得好，但几个核心 DAW 功能只是展示性质的，缺乏交互深度：音频片段不能在时间线上拖动和移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有可视化的效果编辑器（EQ 曲线、压缩器仪表）。这些可不是边角功能，而是让一个 DAW 真正可用的核心交互，规格说明里也明确要求了。

第二轮反馈又抓到了几个功能缺口：

剩余问题：音频录制仍然只是存根（按钮可以切换但没有实际的麦克风采集）；音频片段的边缘拖动调整大小和片段分割未实现；效果可视化是数字滑块，没有图形化呈现（没有 EQ 曲线）。

生成器在自主工作时仍然容易漏掉细节或者把功能做成半成品，QA 在 最后一公里的问题 上依然有实际价值。

下面是最终 DAW 应用的演示视频：

这个应用离专业音乐制作软件还差得远，AI 助手的作曲能力也明显需要大量改进。另外 Claude 实际上听不到声音，这让 QA 反馈循环在音乐品味方面的效果打了折扣。

但最终的应用有了一个功能完整的音乐制作程序的所有核心组件：一个能工作的编曲视图、混音器和播放控制，全都跑在浏览器里。更重要的是，他们能完全通过自然语言提示来拼出一段短曲：AI 助手设置了节奏和调性，铺了一条旋律，建了一个鼓轨，调整了混音器音量，加了混响效果。作曲的核心功能都在了，AI 助手可以自主驱动它们，用工具从头到尾完成一个简单的制作。

能力边界在移动，有趣的工作永远在前方

随着模型持续进步，我们大致可以预期它们能工作更长时间，处理更复杂的任务。在某些情况下，这意味着围绕模型的架构会变得越来越不重要，开发者可以等下一个模型出来，看看哪些问题自然而然就解决了。但另一方面，模型越强，就越有空间去开发能够完成超越基线模型能力的复杂任务的架构。

围绕模型的架构设计空间并不会缩小，它只是在移动。

这有点像工具的进化。当我们有了更锋利的刀，切简单的东西确实不再需要什么特殊技巧了。但也正是因为刀更锋利了，我们才敢去挑战那些之前根本切不动的材料。

从这次实践中，可以提炼出几条值得带走的经验。

第一，多看过程，少只看结果。 他们反复强调要在真实问题上跑模型、读它的运行轨迹，然后有针对性地调优。很多优化的灵感，都藏在过程里。这对我们日常工作也一样，复盘过程往往比只盯着结果更有价值。

第二，分工协作的思路在 AI 时代依然有效。 面对复杂任务时，分解问题、让专门的代理去处理各个环节，有时候能带来显著提升。规划、执行、检验这三个环节的分离，放在人类组织中也是被反复验证过的有效模式。

第三，对任何系统保持「可拆卸」的心态。 当新模型出来的时候，好的做法是重新审视架构，拆掉那些对性能不再有贡献的部分，同时加入新的组件去实现之前可能做不到的更强能力。一个好的架构应该像衣服一样，随着身体的变化而调整。太紧了束缚发挥，太松了起不到作用。今天管用的组合，明天未必还是最优解。

对于所有在 AI 领域探索的人来说，这篇文章传递的核心信息或许是：真正有趣的工作，永远在能力的边界上。 模型在进步，边界在移动，而找到下一个有价值的组合方式，正是这个时代最值得投入的事。

引用链接

[1] 《长时间运行应用开发的 Harness 设计》: https://www.anthropic.com/engineering/harness-design-long-running-apps