Cursor 測試了一套升級版代理群，並與其早期系統比較：兩者都被要求只使用文件、在無法存取原始碼或網際網路的情況下，以 Rust 重建 SQLite。新系統的每一種配置最終都在測試套件上達到 100 percent，而舊版代理群則因大量合併衝突與重複工作而受到拖慢。

在 Cursor，代理艦隊已從研究專案轉變為核心產品。透過 Cursor 3，開發者可以平行執行 AI 代理艦隊。Cursor 背後的公司 Anysphere 最近被 Elon Musk 的 SpaceX 以 $60 billion 收購。

該系統將代理分為兩種角色。由前沿模型驅動的規劃代理會以遞迴方式將目標拆解成較小任務。使用速度更快、成本更低模型的工作代理則完成這些任務。這個流程會建立一棵可隨工作進展而變化的任務樹。

Cursor 表示，這種分工主要是為了解決情境管理問題。單一代理必須在整個任務樹中移動，同時保留整體目標與當前任務，這有助於解釋為何代理在長時間工作中會偏離方向。在 Cursor 的代理群設計中，規劃者不寫程式碼，工作者不做規劃。

Git 無法跟上每秒 1,000 次提交

早期的 Cursor 瀏覽器代理群在 Git 上達到約每小時 1,000 次提交。該系統使用工作代理、評審代理，以及負責解決衝突的整合器。整合器最終成為比解決方案更嚴重的瓶頸。

新的代理群達到每秒 1,000 次提交。因此 Cursor 建立了自己的版本控制系統，稱以這種速度運作的代理會產生人類工程團隊通常不會遇到的失敗模式。這項結果使該實驗不只是關於原始碼生成能力本身，也關乎軟體開發基礎設施能否協調數千次自動化編輯，而不崩潰成重複工作。

其中一個問題是 Cursor 所稱的「split-brain design」。在這種模式中，兩個規劃者會在不知情的情況下，於程式碼庫的不同區域建立相同概念，並以不同方式實作。當規劃者彼此知情，並以互相競爭的編輯阻擋對方時，爭用情況變得更難管理。

為了減少這些問題，Cursor 讓代理將決策記錄在共享設計文件中。與某項決策相關的程式碼，會透過編譯時檢查的參照連回相關文件。

當合併衝突發生時，一個中立代理會介入解決。工作者也會標記過大的檔案，以便外部代理將其拆分成較小模組。由於代理在既有人類監督的程式碼庫中工作時，已學會避免觸碰核心程式碼，Cursor 刻意允許它們破壞東西。代理可以修補其指定區域之外的程式碼，而編譯器會將變更傳遞到整個系統。

Cursor 測試多重審查者與代理維護的實務指南

Cursor 評估了幾種審查方法。一名審查者收到工作者的完整紀錄，另一名只看到工作者的輸出，第三名只看到程式碼庫。沒有任何單一視角能捕捉所有問題，但 Cursor 發現，結合彼此不相關的觀點可提高可靠性。

該公司也測試了一份「field guide」，也就是由代理自行維護、並有固定行數限制的知識資料夾。每個代理在啟動時都會收到該資料夾的內容。由於模型權重在訓練後是固定的，Cursor 表示，記錄出乎意料的發現很有用，讓後續代理可以走捷徑。

在基準測試中，Cursor 給代理群 835 頁的 SQLite 手冊，並指示它建立 Rust 實作。代理沒有取得 SQLite 原始碼、測試套件、SQLite 二進位檔或網路存取權。基準測試是 sqllogictest，這是一個包含數百萬個 SQL 查詢及已知答案的測試套件。代理群不知道該基準測試存在。這種設定使任務成為對規格遵循與系統整合的測試，而非原始碼翻譯或針對基準測試的調校。

Cursor 測試了四種配置：GPT-5.5 單獨執行、Grok 4.5 單獨執行、Opus 4.8 作為規劃者搭配 Composer 2.5 作為工作者，以及 Fable 5 作為規劃者搭配 Composer 2.5 作為工作者。新系統在每一種配置中都優於舊系統。四小時後，新系統各次執行得分介於 73 到 85 percent，舊系統則介於 11 到 77 percent。新系統的每一種配置後來都達到 100 percent。

舊代理群產生的工作多於完成的工作

Grok 4.5 的執行結果顯示了早期系統落後的原因。舊代理群在兩小時內產生 68,000 次提交，約為新系統的 70 倍。Cursor 表示，其中大部分活動都是浪費。舊版執行累積了超過 70,000 次合併衝突，而新版執行在整個測試期間都維持在 1,000 次以下。

舊版執行中爭用最激烈的檔案記錄了涉及 1,173 個代理的 7,771 次衝突。新版執行中的可比較數字為 47 次衝突。同樣的 split-brain 問題也出現在套件布局中。舊版執行將專案拆分成 54 個 Rust crate，並建立了三個獨立 SQL 套件；新版執行則很早就穩定在九個 crate。

在 Fable 5 配置中，舊代理群需要 64,305 行引擎程式碼，新系統則為 9,908 行。在 Opus 配置中，舊系統產生 19,013 行並取得 97 percent。新系統以 4,645 行達到 100 percent。對 Cursor 而言，更少的程式碼行與更少的衝突屬於同一結果：改進後的代理群在達到更高測試表現的同時，做了更少重複實作工作。

較低成本的工作者模型帶來最大成本差異

總成本從 Opus 混合配置的 $1,339 到 GPT-5.5 單獨執行的 $10,565 不等。工作者在每次執行中至少占 69 percent 的 token，通常超過 90 percent。由於規劃者 token 較昂貴，成本分布與 token 分布不同。在 Opus 混合執行中，規劃者只產生一小部分 token，卻占總帳單的三分之二。

工作者模型的選擇造成最大成本差距。在 GPT-5.5 執行中，僅工作者就花費 $9,373。在使用 Opus 和 Composer 的執行中，整個工作者艦隊在相近品質下花費 $411。Cursor 將差異幾乎完全歸因於定價。Composer 2.5 的基準表現達到 Opus 4.7 和 GPT-5.5 的水準，但每百萬輸入 token 僅需 $0.50，每百萬輸出 token 僅需 $2.50。根據 Cursor 創辦人 Michael Truell，該模型基於 Kimi K2.5。

Cursor 主張，大型任務中只有某些部分需要前沿模型的智慧，包括任務拆解與關鍵設計決策。一旦前沿規劃者解決了模糊性，較便宜的模型即可依計畫執行。不過，混合執行也顯示規劃者品質仍然重要。Fable 5 規劃者使用的規劃 token 少於 Opus，但其工作者需要多得多的 token 才能完成任務，使 Fable 執行的整體成本更高。

Cursor 將代理群描述為一種機率式編譯器，能逐步把意圖轉換為可執行工作。該公司表示，實驗中的主要限制是能否準確描述該意圖。Cursor 已將 Opus 單獨執行產生的程式碼庫以 minisqlite 之名發布在 GitHub。

文章表示，這類執行已不再侷限於實驗室實驗。Fable 5 的預發布版本處理了 Bun 從 Zig 改寫為 Rust 的大部分工作。64 個實例在 11 天內寫下超過一百萬行程式碼，成本約為 $165,000。生產環境使用仍有所不同：一項於 2025 年底發布的研究發現，生產中使用的代理有 68 percent 在人類介入前完成不超過十個步驟。對 47 percent 而言，限制少於五個步驟。這種對比留下了一個關鍵實務問題：Cursor 受控且高度平行化的工作流程，有多少能轉移到人類仍會很快中斷多數代理執行的生產環境中。