智东西3月26日报道，前日，Anthropic发布了最新工程博客《Harness Design for Long-Running Application Development》。这篇博客由Anthropic Labs团队成员Prithvi Rajasekaran撰写，讨论的话题是：当AI开始连续数小时地做设计、写代码、搭应用时，光靠模型本身已经不够了，还需要一套围绕模型运转的“harness（执行框架/调度框架）”。
这里的harness，不是传统意义上的“工具链”三个字就能概括的东西。按Prithvi Rajasekaran的分享，它是一套专门为长程任务搭出来的运行机制：什么时候拆任务，什么时候交接上下文，什么时候引入新的Agent，生成结果后由谁来检查，检查不过如何打回重做，长上下文撑不住时是压缩历史还是直接重置会话，这些都属于harness设计的一部分。
换句话说，模型负责“做事”，而harness负责让它在一段很长、很复杂、还容易跑偏的工作流程里，尽量一直做对事。
Prithvi Rajasekaran这次分享的重点，就是他过去几个月围绕两个相互关联的问题所做的一轮工程探索：一是怎么让Claude做出更高质量的前端设计，二是怎么让Claude在几乎没有人工介入的情况下，持续数小时构建出完整应用。
为了把这两个问题继续推进，他借鉴了生成对抗网络（Generative Adversarial Networks，GAN）的思路，把“生成”和“评估”拆开，先在前端设计上验证，再把这套思路扩展到长程自动编程里，最后形成了一个由planner（规划者）、generator（生成者）和evaluator（评估者）组成的三层Agent架构。
整篇内容分享了为什么简单的Agent方案容易失灵，以及他如何一步步搭出这套harness、如何测试、如何迭代、又如何在新模型发布后继续把框架进行优化。
一、先把AI“管住”，长程开发真正难的是“别跑偏”
Prithvi Rajasekaran一开始回顾说，过去几个月里，他主要在做两件事：让Claude产出高质量前端设计，以及让Claude在没有人类干预的情况下构建完整应用。
这项工作承接了团队更早之前在前端设计能力和长程编码Agent harness上的尝试。那时他和同事已经通过提示工程（prompt engineering）与harness设计，把Claude的表现拉到了明显高于基线的水平，但这两条路最后都碰到了天花板。
为了继续推进，他开始寻找一种能跨越两类问题的AI工程方法：一类是前端设计这种带有明显主观审美色彩的任务，另一类是软件开发这种可以验证正确性与可用性的任务。
他最后从生成对抗网络中获得启发，设计了一种多Agent结构，把负责生成结果的generator和负责判断结果好坏的evaluator分离开来。
在他看来，最难的其实不是多加一个Agent，而是先把“评价标准”做出来。因为像“这个设计好不好看”这种判断，原本非常主观，如果不能被拆成更具体、可评分的标准，评估就无从谈起。也正是从这里出发，他逐步把一套能把主观判断变成可评分项的思路，先用于设计，再搬到长程自动编程中。
之后，他把这套方法扩展到长时间自主编码任务里，同时沿用了此前做harness时得到的两个经验：其一，是把构建过程拆成可处理的小块；其二，是通过结构化产物（structured artifacts）在不同会话之间完成上下文交接。
最后形成的结果，是一个由planner、generator和evaluator组成的三层Agent架构，它可以在持续数小时的自动编码会话中，产出内容比较丰富的全栈应用。
二、上下文一长就慌，自己打分又总偏高，简单Agent为什么总失灵
Prithvi Rajasekaran接着解释，团队此前已经证明，harness设计会显著影响长程Agent编码的有效性。
更早的一次实验里，他们用initializer agent（初始化Agent）把产品规格拆成任务列表，再让coding agent（编码Agent）一次实现一个功能点，并通过交接产物在不同会话之间传递上下文。开发者社区也逐渐形成了类似共识，比如“Ralph Wiggum”方法，就会借助hooks或脚本，让Agent维持持续迭代循环。
但即便如此，一些问题仍然非常顽固。任务一复杂，Agent时间一拉长，还是容易逐渐跑偏。Prithvi Rajasekaran观察到两种很常见的失效模式。
第一种，是模型在长任务里会随着上下文窗口（context window）逐渐填满而失去连贯性。他还提到，有些模型会表现出所谓“context anxiety（上下文焦虑）”，也就是当模型觉得自己快接近上下文极限时，会开始提前收尾，没做完也想结束。
为了解决这两个问题，他们采用了context resets（上下文重置）：把上下文窗口完全清空，启动一个新的Agent，再通过结构化交接，把前一个Agent的状态与下一步计划传给后一个Agent。
他特别区分了这种“重置”做法和compaction（压缩）。压缩是把前面对话原地总结，让同一个Agent在缩短后的历史上继续工作。压缩能保留连续性，但不能给Agent一个真正的“干净起点”，所以context anxiety仍可能持续存在。重置则能提供一个彻底清空后的新起点，代价是交接文件必须带足够多的状态信息，保证下一个Agent能无缝接上。
Prithvi Rajasekaran提到，在更早的测试里，Claude Sonnet 4.5的context anxiety已经强到只靠压缩根本不够，因此context reset成了那一代harness设计中的必要组件。它确实解决了核心问题，但也会带来编排复杂度、token额外开销和更高延迟。
第二种问题，是他们此前没有系统处理过的self-evaluation（自我评估）。当Agent被要求评价自己刚做出的成果时，它往往会很自信地夸自己的工作，哪怕在人类看来质量只是平平。
这在设计这类主观任务上尤其明显，因为它不像软件测试那样存在明确的二元验证标准。一个布局到底精致还是普通，本身就是判断题，而模型在给自己的作品打分时，几乎总是倾向于偏乐观。
Prithvi Rajasekaran进一步指出，即便是那些结果可验证的任务，Agent在执行过程中仍会出现判断失真，进而影响最终表现。把“干活的Agent”和“评判它的Agent”分开，是解决这个问题的一个强有力手段。
当然，这种分离并不会立刻消除宽松倾向，因为evaluator本身仍然是LLM，依旧会对LLM生成内容天然偏慷慨。但相比之下，把一个独立的evaluator调成“怀疑主义者”，明显比逼generator严厉地批评自己要容易得多。一旦外部反馈存在，generator也就有了可以针对性迭代的依据。
三、先让审美变得可评分，Claude怎么从“安全牌”走向更有设计感
Prithvi Rajasekaran最先在前端设计上做实验，因为在那里，自我评估失真最明显。没有特别干预时，Claude通常会倾向于生成那种安全、可预测、技术上能用但视觉上很平的布局。
围绕前端设计这件事，他搭建的harness主要建立在两个判断上。
第一，审美当然不可能被彻底化约成一个分数，个人偏好也始终会存在差异，但如果把设计原则和偏好写进评分标准里，结果还是能被往更好的方向走。换句话说，“这个设计美不美”很难稳定回答，但“它有没有遵循我们定义的好设计原则”就变成了模型能抓住的具体问题。
第二，把前端生成和前端评分拆开后，就能形成一个反馈循环，持续把generator往更强的输出上推进。
基于这个思路，他为generator和evaluator都写进了同样四个评分维度。
第一个是Design quality（设计质量），看整体设计是否是一个统一的整体，而不是零散部件的拼装；优秀的结果应该让颜色、字体、布局、图像和细节共同营造出清晰的氛围与身份感。
第二个是Originality（原创性），看里面有没有定制化的设计选择，而不是模板布局、组件库默认值或典型的AI生成套路；如果一个人类设计师看不出其中有刻意做过的创意决策，那就说明不够好。像未经修改的现成组件，或者白底卡片配紫色渐变这种明显“AI味”很重的模式，在他这里都会被判定失败。
第三个是Craft（工艺），也就是技术执行层面，包括字号层级、间距一致性、色彩和谐性、对比度等，这更像是在检查基本功而不是创意；大多数正常实现默认都能过这一关，过不了通常说明基础就出问题了。
第四个是Functionality（功能性），它和审美无关，更关注可用性：用户能否理解界面在做什么，能否找到主要操作，能否不靠猜测完成任务。
他特别强调了Design quality和Originality，而不是Craft和Functionality。原因是Claude本来就在工艺和功能性上得分不低，模型通常天然就能表现出一定技术能力；真正的问题是设计质量和原创性，经常只停留在“不难看，但很平”的程度。
因此，这套标准会明确惩罚高度泛化的“AI slop（AI流水线式糊弄设计）”模式，并通过提高设计质量与原创性的权重，逼模型在审美上承担更多风险。
为了让evaluator的判断更接近他的偏好，Prithvi Rajasekaran又用带有详细拆分分数的few-shot examples（少样本示例）做了校准。这样做的结果，是让evaluator在多轮迭代中更稳定，也减少了评分漂移。
整个循环建立在Claude Agent SDK之上，编排相对直接。先由generator根据用户提示生成一个HTML/CSS/JS前端，再给evaluator接入Playwright MCP，让它在打分前可以直接与运行中的页面交互。
实际运行时，evaluator会自己浏览页面、截图、仔细检查实现情况，再对每一项标准打分并写出详细批评，这些反馈再回流给generator，成为下一轮迭代的输入。
他通常会让一次生成跑5到15轮迭代。随着evaluator不断提出批评，generator往往会被推向更有个性的方向。因为evaluator不是只看静态截图，而是在主动浏览页面，所以每一轮都要花真实时间，完整一次运行甚至会拖到4小时。Prithvi Rajasekaran还会要求generator在每轮评估后做一次策略判断：如果评分走势不错，就继续细化当前方向；如果路线不对，就直接转向完全不同的审美方案。
从整体上看，evaluator的评分会随着迭代先提升，再逐渐平台化，说明还有进一步优化空间。
有些案例是逐步细修上去的，也有些会在某一轮突然大转弯。Prithvi Rajasekaran还发现，评分标准里的措辞本身，也会以他原先没完全预料到的方式影响输出。比如他在标准里加入“the best designs are museum quality（最好的设计应达到博物馆级别）”这样的表述后，结果会把设计往特定视觉收敛方向上推进，这说明和标准绑定在一起的提示语言，会直接塑造最终产物的气质。
虽然分数通常会随轮次上升，但过程并不总是线性。后期实现整体上往往更强，但他也经常更喜欢中间某一轮，而不是最后一轮。
与此同时，随着轮次推进，实现复杂度也会不断提高，generator会在evaluator反馈驱动下尝试更野心勃勃的方案。值得一提的是，即便在第一轮，没有任何evaluator反馈时，只要加入了这套标准和相关语言，输出质量也已经明显优于完全不做提示的基线版本。这说明光是标准本身，就已经先把模型从那些泛化默认值里往外拉了一步。
他举了一个比较典型的例子：自己曾提示模型为一家荷兰艺术博物馆做官网。到第九轮时，Claude已经做出一个干净、暗色调的虚构博物馆首页，视觉上挺完整，但整体仍在他的预期范围内。
到了第十轮，模型却把此前方案整个推翻，改成了一种空间化体验：用CSS透视渲染了一个带棋盘格地面的3D房间，画作以自由位置挂在墙上，页面导航也不再依赖滚动或点击，而是通过房间之间的门洞完成切换。Prithvi Rajasekaran直言，这种创造性跳跃，是他以前在单次生成里没见过的。
四、从前端评分器到全栈开发流水线，三层Agent开始接管完整应用构建
在前端设计实验得出这些结论后，Prithvi Rajasekaran把这套受GAN启发的模式扩展到了全栈开发中。在他看来，generator-evaluator的循环和软件开发生命周期是天然对应的，因为代码评审和QA，本质上就承担着和设计评估器类似的结构性角色。
先看架构。更早的长程harness里，他们已经通过initializer agent、一次只做一个功能点的coding agent，以及跨会话的context reset，解决了多会话编码的连贯性问题。context reset之所以关键，正是因为当时用的是Sonnet 4.5，它会表现出前文提到的“context anxiety”。能在context reset来回切换时仍保持任务推进，是那一版harness能跑起来的关键。
但到了这次新实验里，Prithvi Rajasekaran发现Opus 4.5已经在很大程度上消除了这种问题，因此这套新harness里他干脆把context reset整个拿掉了，改为让所有Agent在一次连续会话中跑完整个构建流程，把上下文增长交给Claude Agent SDK的自动compaction去处理。
在这个基础上，他搭建了一个新的三层Agent系统，每个角色都对准了他在此前运行中观察到的一个缺口。
其中，planner负责把用户那种只有1到4句话的简单提示，扩展成一份完整的产品规格。之所以要加planner，是因为旧版长程harness要求用户一开始就自己提供详细规格，他想把这个步骤自动化。为了避免planner一上来就把技术实现细节写得过死、写错后一路污染后续实现，他在提示里要求planner要大胆扩展产品范围，但聚焦在产品语境和高层技术设计上，而不是过细的技术落地细节。
Prithvi Rajasekaran的考虑是，与其提前把实现路径写死，不如先约束最终要交付什么，再让后续Agent边做边找思路。他还要求planner主动在产品规格里寻找可以嵌入AI能力的地方。
generator则沿用了旧版harness里“一次做一个功能”的思路，把工作拆成一个个sprint（冲刺阶段），每轮从规格中拿起一个功能点来实现。
每个sprint都用React、Vite、FastAPI和SQLite，后来又换成了PostgreSQL这一套技术栈来搭建应用。generator在每轮结束后需要先做自我评估，再把成果交给QA。此外，它还接入了git用于版本控制。
evaluator要解决的，则是此前一些应用“看上去很厉害，真正用起来还是有bug”的问题。它会通过Playwright MCP，像真实用户一样点击运行中的应用，测试UI功能、API端点和数据库状态。之后再根据自己找到的bug，以及一套从前端实验改造而来的评分标准打分，范围覆盖product depth（产品深度）、functionality（功能性）、visual design（视觉设计）和code quality（代码质量）。每个标准都有硬阈值，只要有一项低于阈值，这轮sprint就算失败，generator必须接收详细反馈并返工。
在每轮sprint开始之前，generator和evaluator还会先协商一份sprint contract（冲刺契约）：在一行代码都没写之前，先把这块任务什么算“完成”谈清楚。因为planner输出的产品规格本来就刻意保持在高层抽象，不会细到可直接测试的程度，所以他需要这个步骤，把用户故事和具体、可验证的实现之间接起来。
具体流程是，generator先提出自己准备做什么、怎么验证完成，evaluator再审这份提案，确认它做的是不是对的东西，双方来回迭代，直到达成一致。
整个系统中的沟通也尽量简单，主要通过文件来完成：一个Agent写文件，另一个Agent读文件，然后在同一个文件里回复，或写一个新文件给上一个Agent继续读。等sprint contract敲定后，generator就按照这份契约开始构建，再把结果交给QA。这样做的好处，是既能尽量忠于最初的产品规格，又避免在一开始就把实现路径描述得过细、过死。
五、20分钟和6小时的差距，完整Harness为什么能把一个游戏制作器拉开一大截
在这套harness的第一版实验里，Prithvi Rajasekaran使用的是Claude Opus 4.5，并把完整harness和单Agent系统放在同一个用户提示下做对比。当时他选择Opus 4.5，原因也很简单：那是他开始做这些实验时手头最强的编码模型。
测试提示词是这样一句话：创建一个2D复古游戏制作器，要求包括关卡编辑器（level editor）、精灵编辑器（sprite editor）、实体行为（entity behaviors）以及可试玩的测试模式（playable test mode）。
结果显而易见。单Agent版本只跑了20分钟，花费9美元；完整harness跑了6小时，花费200美元，成本高出20多倍。但Prithvi Rajasekaran强调，输出质量的差异几乎是一眼就能看出来的。
按照这句提示，他原本期待看到的是一个可以搭建关卡及其组成部分——比如精灵、实体、瓦片布局，然后点一下“play”就能真正游玩的界面。最开始打开单Agent版本时，表面上看，这个应用似乎也差不多朝着这个方向去了。
但他一边点击一边试，很快问题就开始冒出来了。首先是布局浪费空间，固定高度面板让大部分视口都空着。
其次是工作流僵硬，当他想往关卡里填内容时，系统先要求去创建精灵和实体，但界面里没有任何地方提示你应该按这个顺序来操作。
更关键的是，真正的游戏根本跑不起来。实体虽然出现在屏幕上，但完全不响应输入。继续往代码里翻，才发现实体定义和游戏运行时（runtime）之间的连接本身就断掉了，而且界面上没有任何明显线索告诉用户问题出在哪。
评估完单Agent版本后，他再去看完整harness跑出来的版本。
同样是一句提示，但经过planner这一步扩写后，原始需求被扩展成了一个包含16个功能点、拆成10个sprint推进的产品规格，范围远远超过单Agent版本。
除了核心编辑器和试玩模式，规格里还加上了精灵动画系统、行为模板、音效与音乐、AI辅助精灵生成器、AI辅助关卡设计器，以及可以通过链接分享的游戏导出功能。
▲AI辅助关卡设计器
▲AI辅助关卡设计器
Prithvi Rajasekaran还给planner开放了前端设计能力，让它先阅读这部分内容，再为整个应用制定一套视觉设计语言，纳入产品规格之中。之后的每个sprint里，generator和evaluator都会先谈妥一份contract，明确这轮具体要实现什么，以及用哪些可测试行为来验证是否完成。
从打开应用的第一眼看，完整harness版本就比单Agent版本更精致、更顺滑。画布占满了整个视口，面板尺寸更合理，界面也形成了贯穿规格中设计方向的一致视觉身份。
当然，单Agent版本里一些笨拙之处并没有彻底消失，比如它仍然没有明确告诉用户，填充关卡前最好先创建精灵和实体，Prithvi Rajasekaran还是得自己摸索一下才能搞清楚。
这在他看来，更像是基础模型产品直觉上的短板，而不是harness原本要解决的问题，不过也提示了一个后续可以在harness内部继续定向迭代的方向。
继续往编辑器里深入，新版本相对于单Agent的优势就更明显了。比如精灵编辑器本身更丰富、功能更完整，工具面板更清爽，颜色选择器更好用，缩放控制也更顺手。因为他在planner阶段就要求把AI能力织进产品规格里，这个应用里还自带了Claude集成，可以通过提示词直接生成游戏的不同部分，整个制作流程因此明显提速。
最大的差别还是出现在play mode（试玩模式）里。这一次，他真的可以控制自己的实体在游戏里移动起来并玩下去。虽然物理效果仍有一些粗糙边缘，比如角色跳到平台上后会和平台发生重叠，这种感觉从直觉上就不太对，但至少最核心的东西已经工作起来了，而这一点恰恰是单Agent版本没有做到的。
又玩了一会儿后，他也发现AI生成关卡本身仍有局限，比如前面出现一堵很高的墙，角色根本跳不过去，整局就被卡住了。这说明harness后续还可以继续处理一些常识性优化与边角情况，把应用再往前打磨。
从日志里回看，Prithvi Rajasekaran认为evaluator在让实现不偏离规格这件事上起了很大作用。每个sprint里，它都会逐条对照sprint contract中的测试标准，通过Playwright操作运行中的应用，把任何偏离预期行为的地方都记录成bug。契约本身也非常细，光是第3个sprint，围绕关卡编辑器就列了27条标准，而evaluator的反馈具体到不需要额外调查就能直接动手修。
不过，要把evaluator调到这个水平，也不是一上来就能做到。Prithvi Rajasekaran坦言，默认状态下Claude并不是一个好的QA Agent。
在早期运行里，他经常看到模型已经识别出真实问题，结果又自己把自己说服，觉得“问题也没那么大”，最后仍然给通过。它还经常只做表层测试，不愿深挖边界情况，很多更隐蔽的bug就这样漏过去了。
因此，他的调优方法基本就是反复读evaluator日志，找到那些它的判断和自己判断不一致的案例，再回头修改QA提示词，专门去纠偏。经过好几轮这样的开发循环后，evaluator才终于开始以一种他认为“比较合理”的方式打分。
即便如此，Prithvi Rajasekaran也没有认为这套harness毫无问题。在他看来，输出结果仍然暴露了模型QA能力的边界：有些小的布局问题还在，一些交互在局部仍显得不够直观，更深层嵌套功能里的bug，也有不少是evaluator没有充分触达的。
他明确提到，这里面仍然存在大量可以通过进一步调优挖出来的验证空间。但即便如此，和单Agent版本相比，那种提升已经非常明显，因为后者最核心的应用功能压根就没有跑起来。
六、模型变强了，框架也得瘦身，哪些部件还“承重”得重新审一遍
第一版harness的结果让Prithvi Rajasekaran看到了希望，但问题也很明显：它太重、太慢、太贵了。接下来的合理动作，自然就是看能不能在不明显损伤表现的前提下，把这套框架做轻一点。
他在这里提出了一个很重要的判断：harness里的每一个组件，其实都隐含着一个假设，那就是“模型自己还做不到这件事”。而这种假设需要不断做压力测试，因为它可能一开始就不对，也可能随着模型升级很快过时。
他提到团队此前那篇《Building Effective Agents》博客里有一个原则，叫“先找尽可能简单的方案，只有在必要时才增加复杂度”，这其实也是所有维护Agent harness的人都会不断碰到的模式。
Prithvi Rajasekaran第一次尝试简化时，直接大刀阔斧砍掉了很多东西，也顺手试了一些新的创意办法，但最后没能复现原始harness的效果。
更麻烦的是，一旦改动太多，反而很难判断哪一块组件才是真正“承重”的，以及它到底承担了什么作用。于是从那以后，他换成了一种更机械、也更靠谱的办法：每次只删一个组件，再回头看最终结果发生了什么变化。
正是在这一轮轮迭代过程中，Anthropic又发布了Opus 4.6，这进一步强化了他简化harness的动机。
因为从新模型的能力描述看，4.6本来就应该比4.5更少依赖外部脚手架（scaffolding）。按照Anthropic的发布博客，Opus 4.6“计划更谨慎、能持续更久地执行Agent任务、能在更大代码库中更可靠地运行，并且具备更好的代码评审和调试能力来发现自身错误”，同时它在长上下文检索（long-context retrieval）上也有明显提升，而这些能力原本正是harness试图额外补齐的部分。
七、去掉Sprint后，Evaluator不再是“必选项”，看任务难度再决定
在具体简化动作里，Prithvi Rajasekaran先下手砍掉的是sprint结构。过去之所以分sprint，是为了把工作拆成更小块，让模型更容易保持一致性。既然Opus 4.6已经明显增强，他就有理由相信，模型也许可以不依赖这种拆解，自己原生完成整段构建。
不过，planner和evaluator他都保留了下来，因为这两个角色的价值仍然很明显。没有planner时，generator会明显低估任务范围：它拿到一条原始提示后就直接开建，不会先做规格设计，最终做出来的应用也往往没有planner扩展出来的版本那么丰富。
而在去掉sprint之后，evaluator的位置也跟着变了。它不再在每个sprint结束后逐轮打分，而是改成在整轮构建结束后做一次单次评估。
Prithvi Rajasekaran认为，这其实反映了一个更有意思的变化：随着模型能力本身增强，evaluator对某些任务到底是不是“承重部件”，已经不再固定，而是取决于任务所处的位置，是否仍然贴着当前模型单独完成能力的边界。
在4.5时代，这条边界离得比较近，很多构建任务正好卡在generator单独完成得不太稳的边缘，因此evaluator在整个构建过程中能持续抓出不少关键问题。到了4.6，模型原始能力抬高了，边界也整体向外推。以前那些必须靠evaluator兜底才能做顺的任务，现在很多已经落进了generator单独也能处理好的范围里。
对这部分任务来说，evaluator就会变成纯粹的额外成本。但如果任务依然处在generator能力边缘之外，那evaluator还是能继续带来真实提升。
所以，Prithvi Rajasekaran给出的结论是，是否使用evaluator，不是一个永远固定的“是或否”判断。只有当任务超过当前模型单独可靠完成的能力边界时，evaluator的成本才真正值得。
在做这些结构简化的同时，他还额外强化了提示词，去改善harness为每个应用加入AI功能的方式。更具体地说，就是让generator不只是嵌一个“看起来像AI”的功能，而是真正能构建出一个可以通过工具驱动应用自身功能的agent。
这部分也经历了不少迭代，因为相关知识还比较新，Claude训练数据对这类模式的覆盖并不算厚。但经过足够多的调试后，generator最终还是能够比较正确地把这类agent搭出来。
八、4小时做出一个网页版数字音频工作站，交付还是得靠QA盯住
为了测试更新后的harness，Prithvi Rajasekaran换了一个新的提示：在浏览器中用Web Audio API构建一个功能完整的Digital Audio Workstation（DAW，数字音频工作站），也就是用来作曲、录音和混音的音乐制作程序。
即便结构已经简化，这次运行依旧不算便宜，大约耗时4小时，token成本124美元左右。时间的大头依然耗在builder上，它在没有sprint拆解的前提下，仍能连贯地跑两小时以上，这一点正是Opus 4.5当时做不到的。
和前一版harness一样，planner先把那句一行提示扩展成了完整规格。从日志上看，generator在应用规划、agent设计、功能接线，以及交给QA前的自测这几步上都做得不错。
但即便这样，QA Agent依旧抓出了实在的缺口。第一轮反馈里，它给出的评价是：这是个很强的应用，设计还原度高，AI agent做得稳，后端也不错，主要失败点在Feature Completeness（功能完整性）上。虽然应用看上去很唬人，AI集成也运转良好，但几个核心DAW功能其实只是“展示出来了”，缺乏足够的交互深度：音频片段不能在时间线上拖动和移动，没有乐器界面面板，比如合成器旋钮（synth knobs）和鼓垫（drum pads），也没有可视化效果编辑器，比如EQ曲线（EQ curves）和压缩器表（compressor meters）。这些不是边角小问题，而是让DAW真正可用的核心交互，而且产品规格里本来就明确要求了这些东西。
到了第二轮反馈，QA又继续指出几项功能缺口，包括录音仍然只是stub-only（只有占位逻辑，按钮能切换但并没有真正采集麦克风输入），音频片段的边缘拖拽改长度与片段切分还没实现，以及效果器可视化仍停留在数值滑杆，并没有真正的图形化表现，比如EQ曲线。
Prithvi Rajasekaran借这个例子强调，哪怕模型本体已经更强，generator单独跑时仍然会漏细节，或者把一些功能做成占位壳子就算完工，因此QA依然有价值，它会把这些尾部缺口揪出来，再交还给generator去补。
按最初提示，他期待的是一个程序：可以写旋律、和声、鼓点，把它们排成一首歌，同时在过程中还能得到一个集成Agent的帮助。从最终结果来看，这个应用离专业级音乐制作软件当然还有很大距离，Agent在作曲上的能力也还明显需要继续提升。
Prithvi Rajasekaran还特别提到，Claude实际上并不能“听见”声音，因此围绕音乐品味进行的QA反馈循环，天然就比视觉或代码验证要弱一些。
不过，他仍然认为最终成品已经具备了一个可用音乐制作程序的核心骨架，这东西当然还没有“音准完美”，但确实已经越来越接近了。
九、模型越强，Harness也值得做
在最后的总结里，Prithvi Rajasekaran谈到，随着模型持续变强，大致可以预期它们会越来越能长时间工作，也能承担更复杂的任务。在某些情况下，这意味着围绕模型搭的那层“haarness”会随着时间推移变得没那么重要，开发者甚至可以直接等下一代模型发布，让一部分问题自己消失。
但另一方面，模型越强，可供harness继续发挥作用的空间也会越大。因为当基础能力抬高后，工程师就可以继续设计新的harness组合，把任务推到模型默认能力之上。
基于这次工作，他认为有几条经验值得留下。
第一，始终要亲自去和你正在构建的模型打交道，读取它在真实问题上的trace（执行轨迹），再围绕你想要的结果去调性能。
第二，在更复杂的任务上，把任务拆开，并让不同Agent各自专职处理问题的不同方面，有时确实能继续挖出额外空间。
第三，当新模型出现后，重新审视已有harness通常是值得的：把那些已经不再“承重”的部件剥掉，同时再加上此前做不到的新部件，把能力往更高处进化。
Prithvi Rajasekaran最后给出的判断：随着模型进步，值得探索的harness组合空间并不会缩小，它只是会移动。对AI工程师来说，真正有意思的工作，就是不断去找到下一组新的、有效的组合方式。
热门跟贴