AI Agent 的持續學習：Replit 的框架

每個人都在談論持續學習，好像它只代表一件事：更新模型權重。但關於 Agent 生態系統，有一個不容忽視的事實——目前生產環境中絕大多數的 Agent 都依賴封閉的尖端模型。當你沒有模型權限時，當然無法對其進行微調。對於大多數 Agent 開發者來說，權重層級的持續學習是行不通的，尤其是在處理最先進的能力時（例如 Fable 5 或 GPT 5.6）。

這並不代表 Agent 無法學習。Agent 系統可以在三個層面上改進——模型、框架和上下文 [0]——而後兩者完全在你的掌控之中。這正是巨大（但經常被忽略）的機會所在：框架層級的學習讓你能夠挖掘生產軌跡，系統性地改進驅動每個 Agent 實例的程式碼、工具和指令；而上下文層級的學習則讓你能夠在 Agent、用戶和組織層級進行個人化，使你的產品在每次互動中變得更好。做到以上所有，你就能累積改進，並每天部署這些改進。

在本文的其餘部分，我將介紹我們在過去一年中如何將持續學習應用於 Replit Agent，並分享我們一路走來學到的所有經驗教訓。

大規模評估與改進 Replit Agent

大多數 Replit Agent 用戶都是從一個想法開始的。他們用自然語言描述目標——沒有儲存庫、測試套件或選定的框架——並期望 Agent 將其變成一個可運行的應用程式。結果可能是一個網站、投影片簡報、行動應用程式、幾個相關聯的成品，或其他完全不同的東西。

氛圍編碼者通常不會檢查差異或測試輸出。Replit Agent 的成功定義其實很簡單：當用戶點擊時，應用程式應該能夠正常運作。

這改變了評估的工作。單一分數可以幫助做出特定的發布決策，但它無法告訴我們，每週 Replit Agent 是否為用戶變得更好。要回答這個問題，評估必須成為改進循環的一部分。

NASA 路易斯研究中心，引擎研究大樓中央控制室，1968 年——當測量結果能改變發布內容時，測量才有意義。

評估現在必須做得更多

過去的 Agent 評估看起來像是一個單向過程：執行評估，產生分數，然後做出發布決定。當發布速度緩慢且被測量的事物很少改變時，這種方法有效。但當模型、提示詞、工具和產品界面都在快速變化時，它就失效了。

舊的循環讓評估感覺是有限的。但 Replit Agent 變化太快，單一分數無法承載整個決策。一個分數可以在單一任務集上比較兩個候選方案。它無法解釋用戶關心什麼、生產環境在哪裡出問題，或者下一步該改進什麼。

評估必須從發布檢查轉變為改進循環。

舊的評估工作在人類做出發布決策時結束；新的評估工作則為一個持續學習的系統提供資訊，該系統從生產環境中學習並部署改進後的 Agent。

該系統有兩個衡量支柱和一個優化循環。離線基準測試告訴我們，在發布之前，候選變更是否能完成模擬的應用程式建置任務。線上 A/B 測試和生產軌跡則顯示，在變更發布後，真實用戶受到怎樣的影響。這些信號隨後會回饋到評估和發布決策中。

沒有任何一個層級是單獨足夠的。基準測試在發布前捕捉回歸問題。A/B 測試顯示生產行為是否發生變化。軌跡聚類解釋了總體指標下的失敗原因。人類判斷則確保改進循環始終指向正確的產品和工程成果。其結構類似於安全工程中的瑞士起司模型：每個層級都有漏洞，但結合在一起，它們能捕捉到比任何單一層級更多的問題。

現有基準測試未能觸及用戶

像 SWE-bench [1] 和 Terminal-Bench [2] 這樣的 Agent 編碼基準測試，在受限且可重複的環境中對程式碼進行評分。這些基準測試很有價值且被廣泛採用，但它們錯過了氛圍編碼者關心的信號。

Replit Agent 通常從頭開始建立程式碼庫。用戶不會帶來固定的路由、函數簽名、選擇器或測試；他們帶來的是產品需求。Agent 會選擇技術棧、資料庫結構、路由、元件和互動流程。

這就產生了一個功能正確性的差距。Agent 可以滿足編碼基準測試的局部限制，但仍然無法滿足用戶所看到的：完成的應用程式是否做了用戶要求的事情。對於氛圍編碼來說，評估目標是成品本身：它是否能載入、核心工作流程是否正常運作、結果是否符合需求。

介紹 ViBench

正是因為需要這種端到端的評估方式，我們才建立了 ViBench [3]，這是我們針對氛圍編碼的公開基準測試，衡量一個簡單但重要的信號：Agent 建立的應用程式是否符合規格？

ViBench 從一份從匿名化的 Replit 生產軌跡中提取的、以純英文撰寫的產品需求文件（PRD）開始。接著，Agent 收到這份 PRD，並從頭開始建立一個可運行的應用程式，不受傳統編碼基準測試所需的支架、路由或參考資料的限制。

然而，使 ViBench 更貼近現實的這種靈活性，也需要一個同樣靈活的評估 Agent，一個始終以 PRD 為基礎的 Agent。在 SWE-bench 風格的基準測試中，專案已經存在，因此評估範圍是固定的。在氛圍編碼中，Agent 選擇技術棧、路由、元件和流程。評估必須探索它創造的任何東西。

為此，每個 ViBench 任務都將 PRD 與一組自然語言測試計畫配對，這些測試計畫描述了成品應用程式必須滿足的功能層級互動和斷言。評估 Agent 使用 Playwright 作為靈活的基礎，使其能夠執行複雜的功能，例如離線模擬、檔案操作和多租戶。由於它事先不知道應用程式的定位器或結構，因此它在筆記本環境中工作，逐步探索應用程式的建構方式並與之互動，這種方法源自 Replit 早期關於自動化自我測試的研究 [4]。

在 Replit 的規模下運行 ViBench 以及我們一般的評估，也需要強大的基礎設施支援 [5]。在內部，我們依賴於相同的生產基礎設施，這些基礎設施讓我們能夠為建置應用程式和運行我們的 Agent 啟動隔離且資源充足的沙盒。因為我們可以快速複製這些沙盒 [6]，所以我們可以並行運行大部分評估，而無需冒著交叉評估污染的風險。

除了從頭開始建置應用程式之外，相同的 ViBench 基礎——由自然語言測試計畫評分的自然語言 PRD——也能適應一系列氛圍編碼場景。為了評估 Agent 如何在現有應用程式內部工作，更接近 Replit 的中期軌跡工作負載，我們讓它在現有程式碼庫上啟動，並根據功能 PRD 衡量它完成功能擴展的能力。該程式碼庫可以來自我們自己的參考實作，也可以來自 Agent 自己氛圍編碼的應用程式，我們在論文中稱之為 Vibe-to-ref 和 Vibe-on-Vibe。當我們發布新的產品界面時，相同的基礎讓我們能夠快速衍生出新問題來評估新穎的互動模式，就像我們為 Agent 4 的平行與合併以及子 Agent 分解所做的那樣。

ViBench 保持行為評估器固定，同時改變輸入和建構策略。

早期的 ViBench 結果給了我們兩個有用的教訓。首先，前沿編碼基準測試的分數並不一定能轉移到完整的應用程式建置上，尤其是對於開放權重模型而言。其次，大多數模型在擴展自己的程式碼時會變得更差，因為錯誤往往會疊加。這些教訓共同為我們提供了一個更好的攀登目標：不僅要編寫能通過測試的程式碼，還要建置能夠承受下一個用戶請求的應用程式。

A/B 測試是我們保持誠實的方法

我們非常信任離線評估，但它們並非唯一的評判標準。我們見過太多 Agent 更新在受控環境中表現良好，卻在真實用戶行為上出現倒退，這讓我們知道生產環境需要自己的衡量層。

用戶是無腳本的、始終在線的，並且以離線基準測試無法完全複製的規模運作。他們會放棄專案、改變主意、以令人驚訝的方式組合功能，並發現我們不知道要測試的失敗模式。

因此，我們對大多數影響 Agent 的更新進行 A/B 測試：提示詞、工具、框架修訂、模型更換以及更大的行為變更。多個實驗通常會同時運行——並保持歸因清晰，以避免隱藏交互作用。A/B 測試揭示了用戶行為、情緒和成功：用戶是否繼續使用、成本是否出現異常、情緒是否發生變化、用戶是否發布了某些東西？

A/B 測試為我們提供了對生產行為的受控讀取，但總體指標本身並不能解釋一切。這是勝利嗎？根本的行為變化是什麼？

A/B 測試的一個挑戰是結果難以解釋。如果運行時間增加，是 Agent 做了更多有用的工作，還是它卡住了？如果成本下降，是我們提高了效率，還是 Agent 默默地停止做某些有價值的事情？如果情緒下降，哪些使用案例退步了、哪些新的失敗模式出現了、哪些用戶放棄了？

Telescope：什麼在出問題

A/B 測試告訴我們生產行為何時發生變化。Telescope——我們的軌跡分析和聚類系統——則有助於解釋原因。

在生產規模下，沒有工程師能閱讀每一條軌跡。Telescope 將重複的模式組織成工程師和 Agent 可以處理的問題集群。它總結失敗軌跡、將其嵌入、對相似案例進行聚類，並在分佈變化時對新的會話進行分類。目標不僅是計算失敗次數，更是發現那些隱藏在顯而易見之處的失敗。

GIF

對我們不知道要尋找的內容進行聚類。

Telescope 使用簡短、基於證據的面向，其靈感來自 Clio [7] 相同的自下而上方法。對於軌跡，它從用戶訊息、可見的 Agent 回覆、工具呼叫、錯誤、元數據和其他上下文中重建會話。接著，Telescope 總結出錯的內容，嵌入這些摘要，並使用基於密度的聚類 [8] 形成新出現的問題組。

面向使調查更快，尤其是在僅靠聚類不夠時。當支援報告指向一個廣泛的問題時，例如連接埠失敗，工程師和 Agent 可以先搜索緊湊層，探索相關的面向，然後深入查看具有解釋該問題所需的日誌和可觀測性上下文的代表性會話。

總體而言，相同的結構將零散的失敗轉化為產品問題：哪些工作流程占主導地位、哪些被放棄、哪些反覆出錯、以及緩解措施是否正在縮小預期的集群。

有關此底層架構的更多資訊，請參閱我們合作夥伴 Braintrust [9] 關於 Topics 的深入文章。

循環：從證據到 Agent 改進

一旦有了衡量標準，瓶頸就會轉移。ViBench、A/B 測試和 Telescope 可以告訴我們什麼失敗了、在哪裡失敗、以及發生的頻率。我們仍然需要將這些證據轉化為可行的修復方案。

我們求助於一個自我改進循環來解決這個問題。其運作原則很簡單：如果 Agent 對建置軟體有用，那麼它們也應該對改進 Agent 本身有用。每次迭代都從讀取生產日誌、軌跡集群和最近的失敗開始，以找到一個值得追查的假設。然後，它建立一個候選方案，開啟一個附帶推理說明的草稿 PR，根據 ViBench、A/B 結果、軌跡數據和最近的基準線衡量結果，並建議是發布、迭代還是放棄它。