智東西
作者｜江宇
編輯｜漠影

智東西3月26日報道，前日，Anthropic發(fā)布了最新工程博客《Harness Design for Long-Running Application Development》。這篇博客由Anthropic Labs團(tuán)隊成員Prithvi Rajasekaran撰寫，討論的話題是：當(dāng)AI開始連續(xù)數(shù)小時地做設(shè)計、寫代碼、搭應(yīng)用時，光靠模型本身已經(jīng)不夠了，還需要一套圍繞模型運(yùn)轉(zhuǎn)的“harness（執(zhí)行框架/調(diào)度框架）”。

這里的harness，不是傳統(tǒng)意義上的“工具鏈”三個字就能概括的東西。按Prithvi Rajasekaran的分享，它是一套專門為長程任務(wù)搭出來的運(yùn)行機(jī)制：什么時候拆任務(wù)，什么時候交接上下文，什么時候引入新的Agent，生成結(jié)果后由誰來檢查，檢查不過如何打回重做，長上下文撐不住時是壓縮歷史還是直接重置會話，這些都屬于harness設(shè)計的一部分。

換句話說，模型負(fù)責(zé)“做事”，而harness負(fù)責(zé)讓它在一段很長、很復(fù)雜、還容易跑偏的工作流程里，盡量一直做對事。

Prithvi Rajasekaran這次分享的重點(diǎn)，就是他過去幾個月圍繞兩個相互關(guān)聯(lián)的問題所做的一輪工程探索：一是怎么讓Claude做出更高質(zhì)量的前端設(shè)計，二是怎么讓Claude在幾乎沒有人工介入的情況下，持續(xù)數(shù)小時構(gòu)建出完整應(yīng)用。

為了把這兩個問題繼續(xù)推進(jìn)，他借鑒了生成對抗網(wǎng)絡(luò)（Generative Adversarial Networks，GAN）的思路，把“生成”和“評估”拆開，先在前端設(shè)計上驗證，再把這套思路擴(kuò)展到長程自動編程里，最后形成了一個由planner（規(guī)劃者）、generator（生成者）和evaluator（評估者）組成的三層Agent架構(gòu)。

整篇內(nèi)容分享了為什么簡單的Agent方案容易失靈，以及他如何一步步搭出這套harness、如何測試、如何迭代、又如何在新模型發(fā)布后繼續(xù)把框架進(jìn)行優(yōu)化。

一、先把AI“管住”，長程開發(fā)真正難的是“別跑偏”

Prithvi Rajasekaran一開始回顧說，過去幾個月里，他主要在做兩件事：讓Claude產(chǎn)出高質(zhì)量前端設(shè)計，以及讓Claude在沒有人類干預(yù)的情況下構(gòu)建完整應(yīng)用。

這項工作承接了團(tuán)隊更早之前在前端設(shè)計能力和長程編碼Agent harness上的嘗試。那時他和同事已經(jīng)通過提示工程（prompt engineering）與harness設(shè)計，把Claude的表現(xiàn)拉到了明顯高于基線的水平，但這兩條路最后都碰到了天花板。

為了繼續(xù)推進(jìn)，他開始尋找一種能跨越兩類問題的AI工程方法：一類是前端設(shè)計這種帶有明顯主觀審美色彩的任務(wù)，另一類是軟件開發(fā)這種可以驗證正確性與可用性的任務(wù)。

他最后從生成對抗網(wǎng)絡(luò)中獲得啟發(fā)，設(shè)計了一種多Agent結(jié)構(gòu)，把負(fù)責(zé)生成結(jié)果的generator和負(fù)責(zé)判斷結(jié)果好壞的evaluator分離開來。

在他看來，最難的其實不是多加一個Agent，而是先把“評價標(biāo)準(zhǔn)”做出來。因為像“這個設(shè)計好不好看”這種判斷，原本非常主觀，如果不能被拆成更具體、可評分的標(biāo)準(zhǔn)，評估就無從談起。也正是從這里出發(fā)，他逐步把一套能把主觀判斷變成可評分項的思路，先用于設(shè)計，再搬到長程自動編程中。

之后，他把這套方法擴(kuò)展到長時間自主編碼任務(wù)里，同時沿用了此前做harness時得到的兩個經(jīng)驗：其一，是把構(gòu)建過程拆成可處理的小塊；其二，是通過結(jié)構(gòu)化產(chǎn)物（structured artifacts）在不同會話之間完成上下文交接。

最后形成的結(jié)果，是一個由planner、generator和evaluator組成的三層Agent架構(gòu)，它可以在持續(xù)數(shù)小時的自動編碼會話中，產(chǎn)出內(nèi)容比較豐富的全棧應(yīng)用。

二、上下文一長就慌，自己打分又總偏高，簡單Agent為什么總失靈

Prithvi Rajasekaran接著解釋，團(tuán)隊此前已經(jīng)證明，harness設(shè)計會顯著影響長程Agent編碼的有效性。

更早的一次實驗里，他們用initializer agent（初始化Agent）把產(chǎn)品規(guī)格拆成任務(wù)列表，再讓coding agent（編碼Agent）一次實現(xiàn)一個功能點(diǎn)，并通過交接產(chǎn)物在不同會話之間傳遞上下文。開發(fā)者社區(qū)也逐漸形成了類似共識，比如“Ralph Wiggum”方法，就會借助hooks或腳本，讓Agent維持持續(xù)迭代循環(huán)。

但即便如此，一些問題仍然非常頑固。任務(wù)一復(fù)雜，Agent時間一拉長，還是容易逐漸跑偏。Prithvi Rajasekaran觀察到兩種很常見的失效模式。

第一種，是模型在長任務(wù)里會隨著上下文窗口（context window）逐漸填滿而失去連貫性。他還提到，有些模型會表現(xiàn)出所謂“context anxiety（上下文焦慮）”，也就是當(dāng)模型覺得自己快接近上下文極限時，會開始提前收尾，沒做完也想結(jié)束。

為了解決這兩個問題，他們采用了context resets（上下文重置）：把上下文窗口完全清空，啟動一個新的Agent，再通過結(jié)構(gòu)化交接，把前一個Agent的狀態(tài)與下一步計劃傳給后一個Agent。

他特別區(qū)分了這種“重置”做法和compaction（壓縮）。壓縮是把前面對話原地總結(jié)，讓同一個Agent在縮短后的歷史上繼續(xù)工作。壓縮能保留連續(xù)性，但不能給Agent一個真正的“干凈起點(diǎn)”，所以context anxiety仍可能持續(xù)存在。重置則能提供一個徹底清空后的新起點(diǎn)，代價是交接文件必須帶足夠多的狀態(tài)信息，保證下一個Agent能無縫接上。

Prithvi Rajasekaran提到，在更早的測試?yán)铮?strong>Claude Sonnet 4.5的context anxiety已經(jīng)強(qiáng)到只靠壓縮根本不夠，因此context reset成了那一代harness設(shè)計中的必要組件。它確實解決了核心問題，但也會帶來編排復(fù)雜度、token額外開銷和更高延遲。

第二種問題，是他們此前沒有系統(tǒng)處理過的self-evaluation（自我評估）。當(dāng)Agent被要求評價自己剛做出的成果時，它往往會很自信地夸自己的工作，哪怕在人類看來質(zhì)量只是平平。

這在設(shè)計這類主觀任務(wù)上尤其明顯，因為它不像軟件測試那樣存在明確的二元驗證標(biāo)準(zhǔn)。一個布局到底精致還是普通，本身就是判斷題，而模型在給自己的作品打分時，幾乎總是傾向于偏樂觀。

Prithvi Rajasekaran進(jìn)一步指出，即便是那些結(jié)果可驗證的任務(wù)，Agent在執(zhí)行過程中仍會出現(xiàn)判斷失真，進(jìn)而影響最終表現(xiàn)。把“干活的Agent”和“評判它的Agent”分開，是解決這個問題的一個強(qiáng)有力手段。

當(dāng)然，這種分離并不會立刻消除寬松傾向，因為evaluator本身仍然是LLM，依舊會對LLM生成內(nèi)容天然偏慷慨。但相比之下，把一個獨(dú)立的evaluator調(diào)成“懷疑主義者”，明顯比逼generator嚴(yán)厲地批評自己要容易得多。一旦外部反饋存在，generator也就有了可以針對性迭代的依據(jù)。

三、先讓審美變得可評分，Claude怎么從“安全牌”走向更有設(shè)計感

Prithvi Rajasekaran最先在前端設(shè)計上做實驗，因為在那里，自我評估失真最明顯。沒有特別干預(yù)時，Claude通常會傾向于生成那種安全、可預(yù)測、技術(shù)上能用但視覺上很平的布局。

圍繞前端設(shè)計這件事，他搭建的harness主要建立在兩個判斷上。

第一，審美當(dāng)然不可能被徹底化約成一個分?jǐn)?shù)，個人偏好也始終會存在差異，但如果把設(shè)計原則和偏好寫進(jìn)評分標(biāo)準(zhǔn)里，結(jié)果還是能被往更好的方向走。換句話說，“這個設(shè)計美不美”很難穩(wěn)定回答，但“它有沒有遵循我們定義的好設(shè)計原則”就變成了模型能抓住的具體問題。

第二，把前端生成和前端評分拆開后，就能形成一個反饋循環(huán)，持續(xù)把generator往更強(qiáng)的輸出上推進(jìn)。

基于這個思路，他為generator和evaluator都寫進(jìn)了同樣四個評分維度。

第一個是Design quality（設(shè)計質(zhì)量），看整體設(shè)計是否是一個統(tǒng)一的整體，而不是零散部件的拼裝；優(yōu)秀的結(jié)果應(yīng)該讓顏色、字體、布局、圖像和細(xì)節(jié)共同營造出清晰的氛圍與身份感。

第二個是Originality（原創(chuàng)性），看里面有沒有定制化的設(shè)計選擇，而不是模板布局、組件庫默認(rèn)值或典型的AI生成套路；如果一個人類設(shè)計師看不出其中有刻意做過的創(chuàng)意決策，那就說明不夠好。像未經(jīng)修改的現(xiàn)成組件，或者白底卡片配紫色漸變這種明顯“AI味”很重的模式，在他這里都會被判定失敗。

第三個是Craft（工藝），也就是技術(shù)執(zhí)行層面，包括字號層級、間距一致性、色彩和諧性、對比度等，這更像是在檢查基本功而不是創(chuàng)意；大多數(shù)正常實現(xiàn)默認(rèn)都能過這一關(guān)，過不了通常說明基礎(chǔ)就出問題了。

第四個是Functionality（功能性），它和審美無關(guān)，更關(guān)注可用性：用戶能否理解界面在做什么，能否找到主要操作，能否不靠猜測完成任務(wù)。

他特別強(qiáng)調(diào)了Design quality和Originality，而不是Craft和Functionality。原因是Claude本來就在工藝和功能性上得分不低，模型通常天然就能表現(xiàn)出一定技術(shù)能力；真正的問題是設(shè)計質(zhì)量和原創(chuàng)性，經(jīng)常只停留在“不難看，但很平”的程度。

因此，這套標(biāo)準(zhǔn)會明確懲罰高度泛化的“AI slop（AI流水線式糊弄設(shè)計）”模式，并通過提高設(shè)計質(zhì)量與原創(chuàng)性的權(quán)重，逼模型在審美上承擔(dān)更多風(fēng)險。

為了讓evaluator的判斷更接近他的偏好，Prithvi Rajasekaran又用帶有詳細(xì)拆分分?jǐn)?shù)的few-shot examples（少樣本示例）做了校準(zhǔn)。這樣做的結(jié)果，是讓evaluator在多輪迭代中更穩(wěn)定，也減少了評分漂移。

整個循環(huán)建立在Claude Agent SDK之上，編排相對直接。先由generator根據(jù)用戶提示生成一個HTML/CSS/JS前端，再給evaluator接入Playwright MCP，讓它在打分前可以直接與運(yùn)行中的頁面交互。

實際運(yùn)行時，evaluator會自己瀏覽頁面、截圖、仔細(xì)檢查實現(xiàn)情況，再對每一項標(biāo)準(zhǔn)打分并寫出詳細(xì)批評，這些反饋再回流給generator，成為下一輪迭代的輸入。

他通常會讓一次生成跑5到15輪迭代。隨著evaluator不斷提出批評，generator往往會被推向更有個性的方向。因為evaluator不是只看靜態(tài)截圖，而是在主動瀏覽頁面，所以每一輪都要花真實時間，完整一次運(yùn)行甚至?xí)系?小時。Prithvi Rajasekaran還會要求generator在每輪評估后做一次策略判斷：如果評分走勢不錯，就繼續(xù)細(xì)化當(dāng)前方向；如果路線不對，就直接轉(zhuǎn)向完全不同的審美方案。

從整體上看，evaluator的評分會隨著迭代先提升，再逐漸平臺化，說明還有進(jìn)一步優(yōu)化空間。

有些案例是逐步細(xì)修上去的，也有些會在某一輪突然大轉(zhuǎn)彎。Prithvi Rajasekaran還發(fā)現(xiàn)，評分標(biāo)準(zhǔn)里的措辭本身，也會以他原先沒完全預(yù)料到的方式影響輸出。比如他在標(biāo)準(zhǔn)里加入“the best designs are museum quality（最好的設(shè)計應(yīng)達(dá)到博物館級別）”這樣的表述后，結(jié)果會把設(shè)計往特定視覺收斂方向上推進(jìn)，這說明和標(biāo)準(zhǔn)綁定在一起的提示語言，會直接塑造最終產(chǎn)物的氣質(zhì)。

雖然分?jǐn)?shù)通常會隨輪次上升，但過程并不總是線性。后期實現(xiàn)整體上往往更強(qiáng)，但他也經(jīng)常更喜歡中間某一輪，而不是最后一輪。

與此同時，隨著輪次推進(jìn)，實現(xiàn)復(fù)雜度也會不斷提高，generator會在evaluator反饋驅(qū)動下嘗試更野心勃勃的方案。值得一提的是，即便在第一輪，沒有任何evaluator反饋時，只要加入了這套標(biāo)準(zhǔn)和相關(guān)語言，輸出質(zhì)量也已經(jīng)明顯優(yōu)于完全不做提示的基線版本。這說明光是標(biāo)準(zhǔn)本身，就已經(jīng)先把模型從那些泛化默認(rèn)值里往外拉了一步。

他舉了一個比較典型的例子：自己曾提示模型為一家荷蘭藝術(shù)博物館做官網(wǎng)。到第九輪時，Claude已經(jīng)做出一個干凈、暗色調(diào)的虛構(gòu)博物館首頁，視覺上挺完整，但整體仍在他的預(yù)期范圍內(nèi)。

到了第十輪，模型卻把此前方案整個推翻，改成了一種空間化體驗：用CSS透視渲染了一個帶棋盤格地面的3D房間，畫作以自由位置掛在墻上，頁面導(dǎo)航也不再依賴滾動或點(diǎn)擊，而是通過房間之間的門洞完成切換。Prithvi Rajasekaran直言，這種創(chuàng)造性跳躍，是他以前在單次生成里沒見過的。

四、從前端評分器到全棧開發(fā)流水線，三層Agent開始接管完整應(yīng)用構(gòu)建

在前端設(shè)計實驗得出這些結(jié)論后，Prithvi Rajasekaran把這套受GAN啟發(fā)的模式擴(kuò)展到了全棧開發(fā)中。在他看來，generator-evaluator的循環(huán)和軟件開發(fā)生命周期是天然對應(yīng)的，因為代碼評審和QA，本質(zhì)上就承擔(dān)著和設(shè)計評估器類似的結(jié)構(gòu)性角色。

先看架構(gòu)。更早的長程harness里，他們已經(jīng)通過initializer agent、一次只做一個功能點(diǎn)的coding agent，以及跨會話的context reset，解決了多會話編碼的連貫性問題。context reset之所以關(guān)鍵，正是因為當(dāng)時用的是Sonnet 4.5，它會表現(xiàn)出前文提到的“context anxiety”。能在context reset來回切換時仍保持任務(wù)推進(jìn)，是那一版harness能跑起來的關(guān)鍵。

但到了這次新實驗里，Prithvi Rajasekaran發(fā)現(xiàn)Opus 4.5已經(jīng)在很大程度上消除了這種問題，因此這套新harness里他干脆把context reset整個拿掉了，改為讓所有Agent在一次連續(xù)會話中跑完整個構(gòu)建流程，把上下文增長交給Claude Agent SDK的自動compaction去處理。

在這個基礎(chǔ)上，他搭建了一個新的三層Agent系統(tǒng)，每個角色都對準(zhǔn)了他在此前運(yùn)行中觀察到的一個缺口。

其中，planner負(fù)責(zé)把用戶那種只有1到4句話的簡單提示，擴(kuò)展成一份完整的產(chǎn)品規(guī)格。之所以要加planner，是因為舊版長程harness要求用戶一開始就自己提供詳細(xì)規(guī)格，他想把這個步驟自動化。為了避免planner一上來就把技術(shù)實現(xiàn)細(xì)節(jié)寫得過死、寫錯后一路污染后續(xù)實現(xiàn)，他在提示里要求planner要大膽擴(kuò)展產(chǎn)品范圍，但聚焦在產(chǎn)品語境和高層技術(shù)設(shè)計上，而不是過細(xì)的技術(shù)落地細(xì)節(jié)。

Prithvi Rajasekaran的考慮是，與其提前把實現(xiàn)路徑寫死，不如先約束最終要交付什么，再讓后續(xù)Agent邊做邊找思路。他還要求planner主動在產(chǎn)品規(guī)格里尋找可以嵌入AI能力的地方。

generator則沿用了舊版harness里“一次做一個功能”的思路，把工作拆成一個個sprint（沖刺階段），每輪從規(guī)格中拿起一個功能點(diǎn)來實現(xiàn)。

每個sprint都用React、Vite、FastAPI和SQLite，后來又換成了PostgreSQL這一套技術(shù)棧來搭建應(yīng)用。generator在每輪結(jié)束后需要先做自我評估，再把成果交給QA。此外，它還接入了git用于版本控制。

evaluator要解決的，則是此前一些應(yīng)用“看上去很厲害，真正用起來還是有bug”的問題。它會通過Playwright MCP，像真實用戶一樣點(diǎn)擊運(yùn)行中的應(yīng)用，測試UI功能、API端點(diǎn)和數(shù)據(jù)庫狀態(tài)。之后再根據(jù)自己找到的bug，以及一套從前端實驗改造而來的評分標(biāo)準(zhǔn)打分，范圍覆蓋product depth（產(chǎn)品深度）、functionality（功能性）、visual design（視覺設(shè)計）和code quality（代碼質(zhì)量）。每個標(biāo)準(zhǔn)都有硬閾值，只要有一項低于閾值，這輪sprint就算失敗，generator必須接收詳細(xì)反饋并返工。

在每輪sprint開始之前，generator和evaluator還會先協(xié)商一份sprint contract（沖刺契約）：在一行代碼都沒寫之前，先把這塊任務(wù)什么算“完成”談清楚。因為planner輸出的產(chǎn)品規(guī)格本來就刻意保持在高層抽象，不會細(xì)到可直接測試的程度，所以他需要這個步驟，把用戶故事和具體、可驗證的實現(xiàn)之間接起來。

具體流程是，generator先提出自己準(zhǔn)備做什么、怎么驗證完成，evaluator再審這份提案，確認(rèn)它做的是不是對的東西，雙方來回迭代，直到達(dá)成一致。

整個系統(tǒng)中的溝通也盡量簡單，主要通過文件來完成：一個Agent寫文件，另一個Agent讀文件，然后在同一個文件里回復(fù)，或?qū)懸粋€新文件給上一個Agent繼續(xù)讀。等sprint contract敲定后，generator就按照這份契約開始構(gòu)建，再把結(jié)果交給QA。這樣做的好處，是既能盡量忠于最初的產(chǎn)品規(guī)格，又避免在一開始就把實現(xiàn)路徑描述得過細(xì)、過死。

五、20分鐘和6小時的差距，完整Harness為什么能把一個游戲制作器拉開一大截

在這套harness的第一版實驗里，Prithvi Rajasekaran使用的是Claude Opus 4.5，并把完整harness和單Agent系統(tǒng)放在同一個用戶提示下做對比。當(dāng)時他選擇Opus 4.5，原因也很簡單：那是他開始做這些實驗時手頭最強(qiáng)的編碼模型。

測試提示詞是這樣一句話：創(chuàng)建一個2D復(fù)古游戲制作器，要求包括關(guān)卡編輯器（level editor）、精靈編輯器（sprite editor）、實體行為（entity behaviors）以及可試玩的測試模式（playable test mode）。

結(jié)果顯而易見。單Agent版本只跑了20分鐘，花費(fèi)9美元；完整harness跑了6小時，花費(fèi)200美元，成本高出20多倍。但Prithvi Rajasekaran強(qiáng)調(diào)，輸出質(zhì)量的差異幾乎是一眼就能看出來的。

按照這句提示，他原本期待看到的是一個可以搭建關(guān)卡及其組成部分——比如精靈、實體、瓦片布局，然后點(diǎn)一下“play”就能真正游玩的界面。最開始打開單Agent版本時，表面上看，這個應(yīng)用似乎也差不多朝著這個方向去了。

但他一邊點(diǎn)擊一邊試，很快問題就開始冒出來了。首先是布局浪費(fèi)空間，固定高度面板讓大部分視口都空著。

其次是工作流僵硬，當(dāng)他想往關(guān)卡里填內(nèi)容時，系統(tǒng)先要求去創(chuàng)建精靈和實體，但界面里沒有任何地方提示你應(yīng)該按這個順序來操作。

更關(guān)鍵的是，真正的游戲根本跑不起來。實體雖然出現(xiàn)在屏幕上，但完全不響應(yīng)輸入。繼續(xù)往代碼里翻，才發(fā)現(xiàn)實體定義和游戲運(yùn)行時（runtime）之間的連接本身就斷掉了，而且界面上沒有任何明顯線索告訴用戶問題出在哪。

評估完單Agent版本后，他再去看完整harness跑出來的版本。

同樣是一句提示，但經(jīng)過planner這一步擴(kuò)寫后，原始需求被擴(kuò)展成了一個包含16個功能點(diǎn)、拆成10個sprint推進(jìn)的產(chǎn)品規(guī)格，范圍遠(yuǎn)遠(yuǎn)超過單Agent版本。

除了核心編輯器和試玩模式，規(guī)格里還加上了精靈動畫系統(tǒng)、行為模板、音效與音樂、AI輔助精靈生成器、AI輔助關(guān)卡設(shè)計器，以及可以通過鏈接分享的游戲?qū)С龉δ堋?/p>

▲AI輔助關(guān)卡設(shè)計器

▲AI輔助關(guān)卡設(shè)計器

Prithvi Rajasekaran還給planner開放了前端設(shè)計能力，讓它先閱讀這部分內(nèi)容，再為整個應(yīng)用制定一套視覺設(shè)計語言，納入產(chǎn)品規(guī)格之中。之后的每個sprint里，generator和evaluator都會先談妥一份contract，明確這輪具體要實現(xiàn)什么，以及用哪些可測試行為來驗證是否完成。

從打開應(yīng)用的第一眼看，完整harness版本就比單Agent版本更精致、更順滑。畫布占滿了整個視口，面板尺寸更合理，界面也形成了貫穿規(guī)格中設(shè)計方向的一致視覺身份。

當(dāng)然，單Agent版本里一些笨拙之處并沒有徹底消失，比如它仍然沒有明確告訴用戶，填充關(guān)卡前最好先創(chuàng)建精靈和實體，Prithvi Rajasekaran還是得自己摸索一下才能搞清楚。

這在他看來，更像是基礎(chǔ)模型產(chǎn)品直覺上的短板，而不是harness原本要解決的問題，不過也提示了一個后續(xù)可以在harness內(nèi)部繼續(xù)定向迭代的方向。

繼續(xù)往編輯器里深入，新版本相對于單Agent的優(yōu)勢就更明顯了。比如精靈編輯器本身更豐富、功能更完整，工具面板更清爽，顏色選擇器更好用，縮放控制也更順手。因為他在planner階段就要求把AI能力織進(jìn)產(chǎn)品規(guī)格里，這個應(yīng)用里還自帶了Claude集成，可以通過提示詞直接生成游戲的不同部分，整個制作流程因此明顯提速。

最大的差別還是出現(xiàn)在play mode（試玩模式）里。這一次，他真的可以控制自己的實體在游戲里移動起來并玩下去。雖然物理效果仍有一些粗糙邊緣，比如角色跳到平臺上后會和平臺發(fā)生重疊，這種感覺從直覺上就不太對，但至少最核心的東西已經(jīng)工作起來了，而這一點(diǎn)恰恰是單Agent版本沒有做到的。

又玩了一會兒后，他也發(fā)現(xiàn)AI生成關(guān)卡本身仍有局限，比如前面出現(xiàn)一堵很高的墻，角色根本跳不過去，整局就被卡住了。這說明harness后續(xù)還可以繼續(xù)處理一些常識性優(yōu)化與邊角情況，把應(yīng)用再往前打磨。

從日志里回看，Prithvi Rajasekaran認(rèn)為evaluator在讓實現(xiàn)不偏離規(guī)格這件事上起了很大作用。每個sprint里，它都會逐條對照sprint contract中的測試標(biāo)準(zhǔn)，通過Playwright操作運(yùn)行中的應(yīng)用，把任何偏離預(yù)期行為的地方都記錄成bug。契約本身也非常細(xì)，光是第3個sprint，圍繞關(guān)卡編輯器就列了27條標(biāo)準(zhǔn)，而evaluator的反饋具體到不需要額外調(diào)查就能直接動手修。

不過，要把evaluator調(diào)到這個水平，也不是一上來就能做到。Prithvi Rajasekaran坦言，默認(rèn)狀態(tài)下Claude并不是一個好的QA Agent。

在早期運(yùn)行里，他經(jīng)常看到模型已經(jīng)識別出真實問題，結(jié)果又自己把自己說服，覺得“問題也沒那么大”，最后仍然給通過。它還經(jīng)常只做表層測試，不愿深挖邊界情況，很多更隱蔽的bug就這樣漏過去了。

因此，他的調(diào)優(yōu)方法基本就是反復(fù)讀evaluator日志，找到那些它的判斷和自己判斷不一致的案例，再回頭修改QA提示詞，專門去糾偏。經(jīng)過好幾輪這樣的開發(fā)循環(huán)后，evaluator才終于開始以一種他認(rèn)為“比較合理”的方式打分。

即便如此，Prithvi Rajasekaran也沒有認(rèn)為這套harness毫無問題。在他看來，輸出結(jié)果仍然暴露了模型QA能力的邊界：有些小的布局問題還在，一些交互在局部仍顯得不夠直觀，更深層嵌套功能里的bug，也有不少是evaluator沒有充分觸達(dá)的。

他明確提到，這里面仍然存在大量可以通過進(jìn)一步調(diào)優(yōu)挖出來的驗證空間。但即便如此，和單Agent版本相比，那種提升已經(jīng)非常明顯，因為后者最核心的應(yīng)用功能壓根就沒有跑起來。

六、模型變強(qiáng)了，框架也得瘦身，哪些部件還“承重”得重新審一遍

第一版harness的結(jié)果讓Prithvi Rajasekaran看到了希望，但問題也很明顯：它太重、太慢、太貴了。接下來的合理動作，自然就是看能不能在不明顯損傷表現(xiàn)的前提下，把這套框架做輕一點(diǎn)。

他在這里提出了一個很重要的判斷：harness里的每一個組件，其實都隱含著一個假設(shè)，那就是“模型自己還做不到這件事”。而這種假設(shè)需要不斷做壓力測試，因為它可能一開始就不對，也可能隨著模型升級很快過時。

他提到團(tuán)隊此前那篇《Building Effective Agents》博客里有一個原則，叫“先找盡可能簡單的方案，只有在必要時才增加復(fù)雜度”，這其實也是所有維護(hù)Agent harness的人都會不斷碰到的模式。

Prithvi Rajasekaran第一次嘗試簡化時，直接大刀闊斧砍掉了很多東西，也順手試了一些新的創(chuàng)意辦法，但最后沒能復(fù)現(xiàn)原始harness的效果。

更麻煩的是，一旦改動太多，反而很難判斷哪一塊組件才是真正“承重”的，以及它到底承擔(dān)了什么作用。于是從那以后，他換成了一種更機(jī)械、也更靠譜的辦法：每次只刪一個組件，再回頭看最終結(jié)果發(fā)生了什么變化。

正是在這一輪輪迭代過程中，Anthropic又發(fā)布了Opus 4.6，這進(jìn)一步強(qiáng)化了他簡化harness的動機(jī)。

因為從新模型的能力描述看，4.6本來就應(yīng)該比4.5更少依賴外部腳手架（scaffolding）。按照Anthropic的發(fā)布博客，Opus 4.6“計劃更謹(jǐn)慎、能持續(xù)更久地執(zhí)行Agent任務(wù)、能在更大代碼庫中更可靠地運(yùn)行，并且具備更好的代碼評審和調(diào)試能力來發(fā)現(xiàn)自身錯誤”，同時它在長上下文檢索（long-context retrieval）上也有明顯提升，而這些能力原本正是harness試圖額外補(bǔ)齊的部分。

七、去掉Sprint后，Evaluator不再是“必選項”，看任務(wù)難度再決定

在具體簡化動作里，Prithvi Rajasekaran先下手砍掉的是sprint結(jié)構(gòu)。過去之所以分sprint，是為了把工作拆成更小塊，讓模型更容易保持一致性。既然Opus 4.6已經(jīng)明顯增強(qiáng)，他就有理由相信，模型也許可以不依賴這種拆解，自己原生完成整段構(gòu)建。

不過，planner和evaluator他都保留了下來，因為這兩個角色的價值仍然很明顯。沒有planner時，generator會明顯低估任務(wù)范圍：它拿到一條原始提示后就直接開建，不會先做規(guī)格設(shè)計，最終做出來的應(yīng)用也往往沒有planner擴(kuò)展出來的版本那么豐富。

而在去掉sprint之后，evaluator的位置也跟著變了。它不再在每個sprint結(jié)束后逐輪打分，而是改成在整輪構(gòu)建結(jié)束后做一次單次評估。

Prithvi Rajasekaran認(rèn)為，這其實反映了一個更有意思的變化：隨著模型能力本身增強(qiáng)，evaluator對某些任務(wù)到底是不是“承重部件”，已經(jīng)不再固定，而是取決于任務(wù)所處的位置，是否仍然貼著當(dāng)前模型單獨(dú)完成能力的邊界。

在4.5時代，這條邊界離得比較近，很多構(gòu)建任務(wù)正好卡在generator單獨(dú)完成得不太穩(wěn)的邊緣，因此evaluator在整個構(gòu)建過程中能持續(xù)抓出不少關(guān)鍵問題。到了4.6，模型原始能力抬高了，邊界也整體向外推。以前那些必須靠evaluator兜底才能做順的任務(wù)，現(xiàn)在很多已經(jīng)落進(jìn)了generator單獨(dú)也能處理好的范圍里。

對這部分任務(wù)來說，evaluator就會變成純粹的額外成本。但如果任務(wù)依然處在generator能力邊緣之外，那evaluator還是能繼續(xù)帶來真實提升。

所以，Prithvi Rajasekaran給出的結(jié)論是，是否使用evaluator，不是一個永遠(yuǎn)固定的“是或否”判斷。只有當(dāng)任務(wù)超過當(dāng)前模型單獨(dú)可靠完成的能力邊界時，evaluator的成本才真正值得。

在做這些結(jié)構(gòu)簡化的同時，他還額外強(qiáng)化了提示詞，去改善harness為每個應(yīng)用加入AI功能的方式。更具體地說，就是讓generator不只是嵌一個“看起來像AI”的功能，而是真正能構(gòu)建出一個可以通過工具驅(qū)動應(yīng)用自身功能的agent。

這部分也經(jīng)歷了不少迭代，因為相關(guān)知識還比較新，Claude訓(xùn)練數(shù)據(jù)對這類模式的覆蓋并不算厚。但經(jīng)過足夠多的調(diào)試后，generator最終還是能夠比較正確地把這類agent搭出來。

八、4小時做出一個網(wǎng)頁版數(shù)字音頻工作站，交付還是得靠QA盯住

為了測試更新后的harness，Prithvi Rajasekaran換了一個新的提示：在瀏覽器中用Web Audio API構(gòu)建一個功能完整的Digital Audio Workstation（DAW，數(shù)字音頻工作站），也就是用來作曲、錄音和混音的音樂制作程序。

即便結(jié)構(gòu)已經(jīng)簡化，這次運(yùn)行依舊不算便宜，大約耗時4小時，token成本124美元左右。時間的大頭依然耗在builder上，它在沒有sprint拆解的前提下，仍能連貫地跑兩小時以上，這一點(diǎn)正是Opus 4.5當(dāng)時做不到的。

和前一版harness一樣，planner先把那句一行提示擴(kuò)展成了完整規(guī)格。從日志上看，generator在應(yīng)用規(guī)劃、agent設(shè)計、功能接線，以及交給QA前的自測這幾步上都做得不錯。

但即便這樣，QA Agent依舊抓出了實在的缺口。第一輪反饋里，它給出的評價是：這是個很強(qiáng)的應(yīng)用，設(shè)計還原度高，AI agent做得穩(wěn)，后端也不錯，主要失敗點(diǎn)在Feature Completeness（功能完整性）上。雖然應(yīng)用看上去很唬人，AI集成也運(yùn)轉(zhuǎn)良好，但幾個核心DAW功能其實只是“展示出來了”，缺乏足夠的交互深度：音頻片段不能在時間線上拖動和移動，沒有樂器界面面板，比如合成器旋鈕（synth knobs）和鼓墊（drum pads），也沒有可視化效果編輯器，比如EQ曲線（EQ curves）和壓縮器表（compressor meters）。這些不是邊角小問題，而是讓DAW真正可用的核心交互，而且產(chǎn)品規(guī)格里本來就明確要求了這些東西。

到了第二輪反饋，QA又繼續(xù)指出幾項功能缺口，包括錄音仍然只是stub-only（只有占位邏輯，按鈕能切換但并沒有真正采集麥克風(fēng)輸入），音頻片段的邊緣拖拽改長度與片段切分還沒實現(xiàn)，以及效果器可視化仍停留在數(shù)值滑桿，并沒有真正的圖形化表現(xiàn)，比如EQ曲線。

Prithvi Rajasekaran借這個例子強(qiáng)調(diào)，哪怕模型本體已經(jīng)更強(qiáng)，generator單獨(dú)跑時仍然會漏細(xì)節(jié)，或者把一些功能做成占位殼子就算完工，因此QA依然有價值，它會把這些尾部缺口揪出來，再交還給generator去補(bǔ)。

按最初提示，他期待的是一個程序：可以寫旋律、和聲、鼓點(diǎn)，把它們排成一首歌，同時在過程中還能得到一個集成Agent的幫助。從最終結(jié)果來看，這個應(yīng)用離專業(yè)級音樂制作軟件當(dāng)然還有很大距離，Agent在作曲上的能力也還明顯需要繼續(xù)提升。

Prithvi Rajasekaran還特別提到，Claude實際上并不能“聽見”聲音，因此圍繞音樂品味進(jìn)行的QA反饋循環(huán)，天然就比視覺或代碼驗證要弱一些。

不過，他仍然認(rèn)為最終成品已經(jīng)具備了一個可用音樂制作程序的核心骨架，這東西當(dāng)然還沒有“音準(zhǔn)完美”，但確實已經(jīng)越來越接近了。

九、模型越強(qiáng)，Harness也值得做

在最后的總結(jié)里，Prithvi Rajasekaran談到，隨著模型持續(xù)變強(qiáng)，大致可以預(yù)期它們會越來越能長時間工作，也能承擔(dān)更復(fù)雜的任務(wù)。在某些情況下，這意味著圍繞模型搭的那層“haarness”會隨著時間推移變得沒那么重要，開發(fā)者甚至可以直接等下一代模型發(fā)布，讓一部分問題自己消失。

但另一方面，模型越強(qiáng)，可供harness繼續(xù)發(fā)揮作用的空間也會越大。因為當(dāng)基礎(chǔ)能力抬高后，工程師就可以繼續(xù)設(shè)計新的harness組合，把任務(wù)推到模型默認(rèn)能力之上。

基于這次工作，他認(rèn)為有幾條經(jīng)驗值得留下。

第一，始終要親自去和你正在構(gòu)建的模型打交道，讀取它在真實問題上的trace（執(zhí)行軌跡），再圍繞你想要的結(jié)果去調(diào)性能。

第二，在更復(fù)雜的任務(wù)上，把任務(wù)拆開，并讓不同Agent各自專職處理問題的不同方面，有時確實能繼續(xù)挖出額外空間。

第三，當(dāng)新模型出現(xiàn)后，重新審視已有harness通常是值得的：把那些已經(jīng)不再“承重”的部件剝掉，同時再加上此前做不到的新部件，把能力往更高處進(jìn)化。

Prithvi Rajasekaran最后給出的判斷：隨著模型進(jìn)步，值得探索的harness組合空間并不會縮小，它只是會移動。對AI工程師來說，真正有意思的工作，就是不斷去找到下一組新的、有效的組合方式。