Harness發威！Claude被榨干的秘訣公開了

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

智東西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工程師來說，真正有意思的工作，就是不斷去找到下一組新的、有效的組合方式。