智东西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。这么作念的刚正，九游jiuyou是既能尽量忠于起初的家具规格，又幸免在一出手就把达成旅途形色得过细、过死。
五、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工程师来说，真确挑升想的责任，就是束缚去找到下一组新的、灵验的组合形势。
买球投注平台app官网
备案号: