在讓 Agent 自主編寫複雜前端介面和全端應用等長時間複雜任務上，僅靠提示詞工程（Prompt Engineering）很快就會觸及天花板。現在最流行或最先進的術語是：

Harness（駕馭/調控）

「Harness」這個詞，字面意思是「馬具」，就是套在馬身上、讓人能控制馬匹方向和力量的那套裝備。在 AI 領域，它關注的是構建什麼樣的環境讓 AI 工作，以及這個環境如何保證它的產出是可靠的。

Anthropic 剛剛發表了一篇工程部落格，公開了他們在前端設計和長時間自主軟體工程領域的最新突破。為了讓 Claude 擺脫平庸的審美並能干擾地構建完整應用，工程師們從生成對抗網絡（GAN）中汲取靈感，設計出了一套多智能體（Multi-Agent）協同的腳手架架構。

原始出處：https://www.anthropic.com/engineering/harness-design-long-running-apps

這套架構的演進，揭示了在模型能力不斷迭代的當下，AI 工程師應該如何動態調整開發策略。

這背後，是一套全新的多智能體架構，我們來看看 Anthropic 內部是如何實踐 Harness 的。

兩個問題，一個思路

Anthropic 研究人員過去幾個月一直在攻克兩個方向：讓 Claude 生成高品質的前端設計，以及讓它在無人介入的情況下完整構建應用程式。

這兩件事看起來截然不同——前者考驗的是審美判斷，後者考驗的是邏輯正確性——但它們碰到了同一堵牆。

純靠提示詞工程，兩個方向的性能都到了瓶頸。

突破口來自一個經典的 AI 思路：生成對抗網絡（GAN）。研究人員從中提取了核心結構——一個生成器加一個評估器——並將其移植到智能體系統中。

AI 自我評估，是個坑

在此之前，有兩個持續存在的失敗模式。

第一個是「上下文焦慮」（Context Anxiety）。隨著對話視窗被填滿，模型會逐漸失去連貫性。更糟的是，部分模型會在接近它認為的上下文上限時提前收尾，把任務草草了結。

解法是「上下文重置」：徹底清空上下文視窗，啟動一個新的智能體，同時通過結構化的交接文件，把前一個智能體的狀態和下一步任務傳遞下去。這與壓縮不同——壓縮是在原有對話基礎上做摘要，智能體仍保持連續，上下文焦慮依然存在。重置給的是一塊乾淨的白板，代價是交接文件必須足夠完整。

在測試中，Claude Sonnet 4.5 的上下文焦慮明顯到僅靠壓縮無法解決，上下文重置因此成了架構的核心設計。這解決了根本問題，但也引入了額外的編排複雜度、Token 開銷和延遲。

第二個問題更隱蔽：AI 的自我評估，不可信。

讓智能體評估自己產出的工作，它幾乎總是給出充滿信心的好評——即便人類觀察者一眼就能看出品質平平。這個問題在主觀任務上尤為突出，比如設計，因為沒有可驗證的二元判斷標準。佈局是否精緻，是否有原創感，全靠主觀感受，而智能體在為自己的產出打分時，可靠地偏向正面。

即便是有可驗證結果的任務，智能體有時也會展現出糟糕的判斷力。

解法是拆分：把做事的智能體和評判的智能體分開。

單獨調校一個評估器，讓它保持懷疑態度，遠比讓生成器批判自己的工作更容易實現。一旦外部反饋存在，生成器就有了具體的迭代目標。

前端設計：讓主觀變得可打分

研究人員先在前端設計領域驗證這個思路。

在沒有任何干預的情況下，Claude 傾向於生成安全、可預測的佈局——技術上功能完整，視覺上毫無驚喜。

核心洞察有兩點。第一，審美雖然無法完全量化，但可以用編碼了設計原則的評分標準來改善。問題不是「這個設計美嗎」，而是「這個設計是否符合我們的設計原則」——後者給了模型可以具體打分的依據。第二，把生成和評分分離，可以構建一個驅動生成器向更強輸出迭代的反饋閉環。

研究人員為生成器和評估器設計了四個評分維度：

設計品質：整體是否有內聚感，顏色、排版、佈局、圖像等元素能否融合出獨特的視覺氛圍和身份感。

原創性：是否存在定制化決策，還是套用模板、使用庫預設值、重複 AI 生成模式。人類設計師應該能識別出刻意的創意選擇。未修改的現成組件，或者 AI 生成的典型特徵——比如白色卡片上的紫色漸變——在這裡直接失分。

工藝：技術執行層面，包括排版層級、間距一致性、色彩和諧度、對比度。這是能力檢驗，不是創意檢驗。大多數合理實現預設都能過關，失分意味著基礎已經失靈。

功能性：獨立於美學的可用性。用戶能否理解介面功能，找到主要操作入口，在不需要猜測的情況下完成任務。

設計品質和原創性的權重高於工藝和功能性——因為 Claude 在工藝和功能上本來表現就不差，但在設計感和原創性上經常產出平庸之作。評分標準明確懲罰了高度通用的「AI 濫貨」模式，通過加權把模型推向更大膽的審美冒險。

整個循環構建在 Claude Agent SDK 之上。生成器先基於用戶提示創建 HTML/CSS/JS 前端，評估器拿到 Playwright MCP 工具，可以直接與運行中的頁面交互，而不只是給靜態截圖打分。評估器會在頁面上自主導航、截圖、仔細研究實現細節，然後對每個維度打分並寫出詳細批評。反饋流回生成器，作為下一輪迭代的輸入。

每次生成運行 5 到 15 輪迭代，每個迭代通常推動生成器向更有辨識度的方向走。完整運行耗時最長可達四小時。

研究人員還指示生成器在每次評估後做一個策略判斷：如果分數趨勢良好，繼續在當前方向上精煉；如果這條路走不通，徹底轉向另一種審美。

結果是：評估器的評分在迭代中持續提升，直到趨於平穩，仍有提升空間。部分生成過程是漸進式優化，另一些則在迭代間發生了銳利的審美轉向。

一個典型案例：研究人員讓模型創建荷蘭藝術博物館網站。到第九輪，它產出了一個簡潔的深色主題落地頁，視覺精緻，但基本在預期範圍內。第十輪，它徹底推翻了這套方案，把網站重新構想成一個空間體驗：用 CSS 透視渲染出棋盤格地板，畫作自由懸掛在牆上，用穿越門洞的方式在不同展廳間導航，而不是普通的滾動或點擊。這是單次生成從未有過的創意跳躍。

擴展到全端編程

驗證了前端設計的效果後，研究人員把這套模式遷移到全端開發。

生成器 - 評估器的循環天然對應軟體開發生命週期中的程式碼審查和 QA 環節。

在早期的長時運行架構中，Sonnet 4.5 的上下文焦慮是核心限制。到了 Opus 4.5，這個行為基本自行消失，上下文重置因此可以從架構中去掉。整個構建過程作為一個連續會話運行，Claude Agent SDK 的自動壓縮處理上下文增長。

最終架構是三個智能體：

規劃器（Planner）：之前的架構需要用戶事先提供詳細規範。研究人員想把這一步自動化，讓規劃器接受一段 1 到 4 句話的提示，將其擴展為完整的產品規範。規劃器被要求在範圍上保持雄心，專注於產品背景和高層技術設計，而不是具體的技術實現細節——因為如果規劃器在顆粒度細節上出錯，錯誤會級聯傳播到下游實現中。研究人員還要求規劃器主動在產品規範裡織入 AI 功能。

生成器（Generator）：沿用了早期架構中一次實現一個功能的思路，以 sprint 為單位推進，每個 sprint 結束時先自我評估再交給 QA。技術棧是 React、Vite、FastAPI 和 SQLite（後升級為 PostgreSQL），並配備 git 進行版本控制。

評估器（Evaluator）：早期架構的應用看起來不錯，但實際使用時存在真實 bug。評估器拿到 Playwright MCP，像真實用戶一樣點擊應用，測試 UI 功能、API 端點和資料庫狀態，然後對照 sprint 契約和一套評分標準進行打分——包括產品深度、功能性、視覺設計和程式碼品質。每個維度設有硬性門檻，任何一個低於閾值，sprint 即判定失敗，生成器獲得關於問題所在的詳細反饋。

每個 sprint 開始前，生成器和評估器會先協商一份 sprint 契約：在寫任何程式碼之前，先約定這塊工作「完成」意味著什麼。產品規範是有意保持高層次的，這一步的目的是在用戶故事和可測試實現之間架起橋樑。生成器提出要構建什麼以及如何驗證成功，評估器審查這個提案，二者迭代直到達成共識。智能體之間通過文件通信：一個智能體寫文件，另一個讀取並在文件中或新文件裡回應。

單智能體 vs 完整架構：差距有多大

研究人員用同一個提示詞——創建一個支持關卡編輯器、精靈編輯器、實體行為和可玩測試模式的 2D 復古遊戲製作工具——分別跑了單智能體和完整架構。

單智能體跑了 20 分鐘，花了 9 美元。完整架構跑了 6 小時，花了 200 美元。

架構的成本超過單智能體 20 倍，但輸出品質的差距一目了然。

單智能體版本：打開時介面看起來尚可，但仔細點擊後問題開始浮現。佈局浪費空間，固定高度的面板讓大部分視口空空如也。工作流僵硬，沒有任何引導提示。遊戲本身直接是壞的——實體出現在螢幕上，但對輸入沒有任何響應。程式碼裡，實體定義和遊戲運行時之間的連接就是斷的。

完整架構版本：規劃器把一句話提示擴展成一份 16 個功能、分佈在 10 個 sprint 裡的規範，涵蓋了精靈動畫系統、行為模板、音效和音樂、AI 輔助的精靈生成器和關卡設計器、以及帶分享連結的遊戲導出功能，比單智能體版本嘗試的範圍大得多。

差距最明顯的在遊玩模式：完整架構版本真的可以玩——可以移動物體，遊戲運行。物理有些粗糙，角色跳上平台後會與平台重疊，但核心功能是通的，而這正是單智能體版本根本沒做到的。

評估器在整個過程中發揮了關鍵作用。每個 sprint 裡，它遍歷契約的測試標準，通過 Playwright 操作運行中的應用，把任何偏離預期行為的地方記錄為 bug。Sprint 3 的契約單獨就有 27 條標準，評估器的發現具體到可以直接採取行動。

比如其中幾個例子：矩形填充工具應支持拖曳填充矩形區域——評估器發現工具只在拖曳起點和終點放置了瓦片，fillRectangle 函數存在但 mouseUp 時沒有正確觸發。用戶應能選中並刪除已放置的實體生成點——評估器發現 Delete 鍵處理器要求同時設置 selection 和 selectedEntityId，但點擊實體只設置了 selectedEntityId，條件應改為兩者之一滿足即可。

但把評估器調校到這個水平並不容易。初期運行中，它會發現合理的問題，然後說服自己這些問題沒那麼嚴重，直接放行。它也傾向於淺層測試，而不是探測邊界情況，更隱蔽的 bug 經常漏掉。調優過程是：讀取評估器的日誌，找到它的判斷與研究人員判斷不同的例子，更新 QA 提示來解決這些偏差。經過幾輪開發循環，評估器的打分方式才達到研究人員認為合理的水平。

簡化架構：模型變強了，腳手架該減了

第一版架構效果不錯，但笨重、慢、貴。

下一步是在不降低性能的前提下簡化架構。這也是一個更普遍原則的體現：架構裡的每一個組件都編碼了一個關於模型無法獨立完成某件事的假設，而這些假設值得持續檢驗——不僅因為它們可能本就不對，也因為隨著模型改進，它們會迅速過時。

研究人員一開始激進地削減架構，同時嘗試了一些新思路，但無法復現原版的性能，也難以判斷架構的哪些部分是真正關鍵的。隨後改為更系統的方法：每次只去掉一個組件，觀察對最終結果的影響。

與此同時，Opus 4.6 發布，給了進一步減少架構複雜度的動力。官方說明稱：Opus 4.6 規劃更仔細，能更持久地保持智能體任務，在更大的程式碼庫中運行更可靠，並且有更好的程式碼審查和調試能力來自己捕捉錯誤。長上下文檢索也有大幅提升。這些正是架構原本用來彌補的能力。

研究人員首先去掉了 sprint 結構。sprint 的作用是把工作分解成塊，讓模型保持連貫。Opus 4.6 有理由直接處理這件事，不需要這種分解。規劃器和評估器保留——去掉規劃器，生成器會低估範圍，拿到原始提示後直接開始構建，產出的應用功能比規劃器規劃的少得多。

去掉 sprint 後，評估器改為在整個運行結束後做一次性的掃描，而不是每個 sprint 結束後打分。

這改變了評估器的負載承擔方式，其價值取決於任務落在模型能力邊界的哪一側。在 4.5 上，邊界很近，構建本身處於生成器獨立完成的上限，評估器在整個構建過程中都能發現有意義的問題。在 4.6 上，模型的原始能力增強，邊界向外移動。之前需要評估器干預才能連貫實現的任務，現在往往在生成器的能力範圍之內，評估器對於這些任務變成了多餘的開銷。但對於仍處於生成器能力邊界的部分，評估器依然帶來真實的提升。

評估器不是一個固定的是非判斷，它值不值得用，取決於任務是否超出了當前模型單獨能可靠完成的範圍。

用一句話造了一個 DAW 音樂軟體

為了驗證更新後的架構，研究人員用這個提示詞：

用 Web Audio API 在瀏覽器裡構建一個功能完整的 DAW（Digital Audio Workstation 專業的電腦音樂製作軟體或系統）

整個運行歷時約 4 小時，花費 124 美元。

各階段耗時和成本如下：

階段	時長	成本
規劃器	4.7 分鐘	$0.46
構建（第 1 輪）	2 小時 7 分鐘	$71.08
QA（第 1 輪）	8.8 分鐘	$3.24
構建（第 2 輪）	1 小時 2 分鐘	$36.89
QA（第 2 輪）	6.8 分鐘	$3.09
構建（第 3 輪）	10.9 分鐘	$5.88
QA（第 3 輪）	9.6 分鐘	$4.06
合計	3 小時 50 分鐘	$124.70

構建階段獨立連貫運行了超過兩小時，不需要 4.5 時代用過的 sprint 分解。規劃器把一行提示擴展成完整規範，生成器完成了規劃、連接智能體、並在交給 QA 前進行測試。

QA 還是發現了真實的缺口。第一輪反饋指出：這是一個很強的應用，具備出色的設計還原度、穩固的 AI 智能体和良好的後端。主要失敗點在功能完整性——雖然應用外觀令人印象深刻，AI 集成運轉良好，但幾個核心 DAW 功能僅有展示而沒有交互深度：片段無法在時間線上拖曳移動，沒有樂器 UI 面板，沒有可視化效果編輯器。這些不是邊緣情況，而是 DAW 可用性的核心交互。

第二輪反饋又發現了幾個功能缺口：錄音功能仍然只是佔位實現，片段邊緣拖曳和片段分割未實現，效果可視化是數字滑塊而非圖形化介面。

最終應用包含了一個功能性音樂製作程式的所有核心組件：可運行的編曲視圖、混音器和傳輸控件。研究人員通過純提示詞拼出了一小段歌曲片段：智能體設置了速度和調性，編排了旋律，構建了鼓軌，調整了混音器電平，加了混響。核心原語已經存在，智能體可以自主驅動它們，用工具端到端創建一個簡單的製作作品。

這距離專業音樂製作軟體還有距離，Claude 本身也無法真正聽到聲音，這讓 QA 反饋在音樂品味層面的有效性打了折扣。但方向是清晰的。

架構設計的規律

隨著模型持續改進，腳手架的有效性會隨之變化。

有些問題會隨著下一個模型的到來自行解決，開發者可以選擇等待。但另一方面，模型越強，用架構實現超出模型基礎能力的複雜任務的空間就越大。

幾條值得帶走的原則：始終針對正在構建的模型做實驗，閱讀它在真實問題上的運行日誌，調優性能以達到想要的結果。對於複雜任務，有時分解任務並對每個子問題應用專項智能體會帶來提升空間。每當新模型發布時，值得重新審視已有的架構——剝離不再關鍵的組件，加入新能力帶來的可能性。

有趣的架構組合不會隨著模型改進而減少，只會移動。對 AI 工程師而言，持續尋找下一個新穎組合，才是核心工作。