代理群體與新模式經濟學 · Cursor

今年早些時候，Cursor團隊進行了一系列實驗，旨在測試大規模代理群體協同完成目標的極限。他們的核心假設是，這種協同能夠解鎖更高層級和複雜度的任務。旗艦專案是一個長期執行的代理群體，從零開始構建一個網頁瀏覽器。雖然這個概念驗證取得了成功，但最終成品遠未達到精緻軟體的標準。

這項工作是實驗性的，團隊從一張白紙出發，逐步最佳化出一個穩定有效的系統。此後，他們的目標轉變為深入理解代理群體，以便能夠有意地設計它。為了驗證進展，他們選擇了一箇舊群體曾經掙扎的任務：僅憑文件，用Rust語言從零構建SQLite。

初步結果令人鼓舞。他們在相同任務、相同模型和時間預算下執行了新舊兩種群體，並衡量了每個版本透過獨立SQL測試套件的比例。新群體在所有模型配置下都表現更好。使用Grok 4.5時，新群體在四小時內達到了80%的透過率，而舊群體在第二小時前就陷入螺旋式下降，不得不暫停。

他們還變化了不同模型承擔的角色。在某些執行中，一個模型處理所有工作，而在其他執行中，由前沿模型規劃，快速廉價模型執行。每種混合方式都產生了相似的質量，但成本差異巨大。

團隊將大型任務的描述自然視為樹狀結構，目標為根，遞迴分解為基本工作單元。他們的群體有兩種角色，都圍繞這種樹狀分解組織：規劃者代理由最智慧的模型驅動，將目標分解並委派工作；工作者代理通常由更快更便宜的模型驅動，執行具體任務。這種設計是更嚴格編排系統的超集。群體的形狀會隨著問題輪廓增長，計算和上下文按任務複雜度成比例擴充套件。

團隊認為，這就是設計能夠泛化到構建瀏覽器、解決數學問題和最佳化GPU核心等多樣任務的原因。他們內部也用它來發現和修復開源軟體中的漏洞、提高自己程式碼庫的測試覆蓋率，以及生成數十億令牌的合成訓練資料。

在單個代理處理完整任務時，它必須自行遍歷整棵樹，同時保持祖先、當前位置和全域性目標在上下文中。團隊認為這解釋了長期執行的單一代理為什麼會漂移——它們要麼專注於眼前工作而失去全域性，要麼堅持大局而影響區域性工作。在群體中，規劃者從不實施，因此上下文不會被低層細節填滿；工作者從不規劃，因此可以將所有上下文用於單個狹窄工作。

團隊懷疑，代理群體規模化能力來自這種上下文效率，而不僅僅是並行性本身。即使在中等規模任務上，這種分解也有助於代理效能。

類似的機構在經濟學家羅納德·科斯的公司理論中也有體現：協調成本增長快於工作本身，因此組織形成有限單元層級，而不是讓每個人與每個人對話。

為了適應群體極高的提交率（舊群體峰值約每小時1000次提交，新系統約為每秒1000次），團隊從頭構建了全新的版本控制系統（VCS）。高吞吐量並非唯一原因，每個變更都經過VCS，使得衝突首先在這裡變得可見，且多種協調機制直接在VCS中實現。

在人工程式設計師團隊中，程式碼審查、所有權、站會和合並佇列是標準協調機制。但在群體的提交速率下，出現了人類團隊通常不會遇到的故障模式。例如，分裂大腦設計：兩個規劃者互不知情，在程式碼庫的不同部分以不同方式實現同一概念。團隊透過提示修復：規劃者自己做設計決策，並確保沒有兩個委派的子樹決定同一問題。

規劃者之間的衝突是更棘手的形式，兩個規劃者互相知道對方的存在，並透過來回修改同一檔案而爭鬥。團隊透過讓代理在共享設計文件中記錄決策來解決。依賴某個決策的程式碼攜帶對該文件的編譯時引用。當規劃者無意中相互矛盾時，協調者合併文件，引用將決議傳播到下游。

合併衝突在群體中頻繁發生。為了解決衝突，代理必須停止工作，吸收另一代理的上下文併合並。工作者代理不擅長此道，在實踐中要麼覆蓋對方更改，要麼放棄自己的更改。為此，團隊建立了由中立第三方代理介入合併衝突的系統，其唯一目標是公正高效，類似於人工程式設計師團隊的合併佇列。

某些檔案成為代理工作的熱門地點。每個代理可能只新增少量程式碼，但沒人負責保持檔案小巧。這些“巨檔案”導致所有操作變慢。團隊讓工作者代理標記臃腫檔案，然後阻止新提交併由外部代理將過大的檔案分解為更小的模組。

另外，代理學會了在有人類參與的現有程式碼庫中不觸及核心程式碼，即使需要更改。團隊允許有意破壞：認為核心更改有價值的代理可以在其範圍之外製作專注補丁，並留下解釋註釋。編譯器將更改傳播到整個系統，依賴舊設計的構建失敗。遇到錯誤的每個代理會找到註釋、閱讀理由並更新自己的工作以匹配。

在長期執行的多代理系統中，錯誤會累積，團隊需要一種機制在微小錯誤成為基礎問題前糾正。他們嘗試了多種審查視角，如給審查者提供工作者的完整記錄、僅輸出或僅程式碼庫。沒有一個單一視角能捕獲所有問題，但去相關視角疊加起來，就像自動駕駛系統無需任何完美元件就能達到超人類可靠性。團隊懷疑這種疊加審查系統是執行質量持續高水平的主要原因。

群體生物如螞蟻和白蟻透過環境塑造來實現無直接通訊的協調，這種機制稱為“stigmergy”。團隊之前就植入“記筆記”和“記錄決策”等規則，因為它們顯然有益。回顧來看，這些規則讓代理為未來的自己和隊友制度化知識。他們進一步透過稱為“現場指南”的實驗推動這一點，這是一個完全由代理擁有的資料夾，其中的index.md自動注入到每個代理啟動時。代理負責策劃指南內容，唯一約束是行預算。指南的基本邏輯是模型權重凍結，因此恰好是那些意外遭遇值得捕捉，以使下一條代理軌跡更短。

現場指南是一個早期實驗，取得了有希望的結果。團隊預計在代理不完全擁有的程式碼庫上益處更大。訓練模型為繼任者寫作，更好的捕獲帶來更好的獎勵，是一個有趣的後續研究領域。

在最終的SQLite實驗中，新版本群體配備了上述所有改進，被指示用Rust實現整個835頁的SQLite手冊。團隊遮蔽了原始碼、測試套件和SQLite二進位制檔案，並禁止訪問網際網路。他們使用sqllogictest（SQLite專案中用於檢查不同資料庫引擎對相同查詢返回相同結果的測試套件）來衡量進展。該套件包含數百萬個已知正確答案的查詢，評分是群體資料庫正確回答的比例。

群體從未被告知該套件的存在。每次執行後，團隊手動審查程式碼和執行過程，檢查作弊和捷徑，並確認系統是均勻構建的，而不是僅僅在測試檢測的地方。

團隊測試了四種配置：GPT-5.5同時作為規劃者和工作者；Grok 4.5同時作為兩者；Opus 4.8作為規劃者搭配Composer 2.5作為工作者；Fable 5作為規劃者搭配Composer 2.5作為工作者。新框架在所有組合中均優於舊框架。Fable 5混合在第一個小時內透過約三分之二的套件。到四小時截止時，新執行介於73%到85%之間，而舊執行範圍從11%到77%。舊Grok 4.5執行在不到兩小時時被暫停。每個新配置最終都透過了套件的100%。

從活動率來看，舊執行在最初兩小時內產生了68,000次提交，約為新執行速率的70倍。但這主要是忙碌工作（抖動、爭用、流失）。舊執行積累了超過70,000個衝突後被迫暫停。新執行則表現出穩定高效的進步。