hero

Cursor 今年初做了一件事：讓幾百個 AI agent 同時寫程式，看會發生什麼。結果不是災難，而是千次 commit 每秒的新常態，以及一篇洋洋灑灑的技術報告，從自製版本控制系統講到螞蟻的群體智慧，最後用 compiler 類比收尾。這篇文章值得讀，不是因為它證明了 agent swarm 的可用性——它沒能證明這點——而是因為它誠實地告訴你，要讓一群機率性模型協作不崩潰，需要疊多少層同樣機率性的補丁。每一層補丁都是一個工程師發明的機制，而這些機制本身能不能收斂，沒有人知道。

Swarm 架構圖

原文摘要

今年稍早，Cursor 團隊進行了一系列實驗，測試讓多個 AI agent 協同工作以達成共同目標的極限。他們的假設是，這種方式能解鎖全新層級的任務規模與複雜度。旗艦專案是一個長期運行的 swarm，從零開始打造一個網頁瀏覽器。它作為概念驗證成功了，但離可用的軟體成品還有很大一段距離。

那項工作是刻意走經驗主義路線的。團隊從空白畫布出發，靠逐步改進來逼近一個穩定、有效的系統。在那之後，Cursor 的目標變成深入理解 agent swarm，直到能用工程方法精確地駕馭它。為了檢驗這個進展，他們回到一個舊 swarm 曾經掙扎的任務：從零開始，只用 SQLite 的官方文件，用 Rust 實作整個 SQLite。

初步結果相當正面。團隊用相同的任務、相同的模型、相同的時間預算，跑了新舊兩個版本的 swarm，並測量各自能通過多少比例的保留測試集（held-out SQL test suite）。新版 swarm 在所有模型配置中都表現更好。使用 Grok 4.5 時，新版 swarm 在四小時內達到 80% 的正確率，而舊版 swarm 在跑到兩小時之前就陷入混亂，必須暫停。

團隊還改變了哪些模型負責哪些工作的配置。在某些 run 中，單一模型包辦所有事情；在其他 run 中，一個 frontier 模型負責規劃，一個快速、便宜的模型負責執行。每種混搭都產出相近的品質，但成本差距極為懸殊。

Trees and leaves：樹狀結構與任務分解

對大型任務的描述，自然會形成樹狀結構：根節點是一個目標，遞迴地往下分解成基本的工作單元。Cursor 的 swarm 有兩種角色，都圍繞著同樣的樹狀分解來組織：

  • Planner agent，由最聰明的模型驅動，負責將目標拆解成多個子任務並委派出去。
  • Worker agent，通常由更快、更便宜的模型驅動，負責執行那些子任務。

這個設計是更剛性協調系統（rigid orchestration）的超集。與其把固定的拓撲結構強加在問題上，swarm 的形狀會隨著問題的輪廓生長，運算力和 context 也會與任務複雜度成比例地擴展。團隊認為，這就是為什麼這個設計能泛化到像打造瀏覽器、解數學題、優化 GPU kernel 這麼多樣的任務上。他們也在內部用它來找出並修復開源軟體中的漏洞、提升自家程式碼的測試覆蓋率，以及生成數十億 token 的合成訓練資料。

樹狀結構如何解放記憶體（context）

當單一 agent 承接整個任務時，它必須自己走完整棵樹：下降到每個葉節點時，必須同時在 context 中握著祖先節點、目前位置、以及整體目標。團隊認為，這解釋了為什麼長時間運行的單一 agent 會逐漸偏離——它們要嘛專注眼前的工作但失去大局，要嘛握住大局但在細節上做得更差。

在 swarm 中，planner 永遠不需要親自實作，所以它的 context 不會被低階細節塞滿；worker 永遠不需要規劃，所以可以將全部的 context 花在一個狹窄的工作單元上。Cursor 團隊懷疑，agent swarm 的可擴展性來自這種 context 效率，而非單純的平行化。這種效率在 swarm 的各種規模中都存在，這也是為什麼這種分解方式即使在中等規模的任務上也能提升 agent 表現。

團隊指出，經濟學家 Ronald Coase 在探討「為什麼公司會存在」時，也論證了協調成本的成長速度比工作本身更快，因此組織會沉澱成由有限單元組成的層級結構，而不是讓每個人都跟每個人溝通。這個結構在 swarm 中有類似迴響。

為 agent 打造的版本控制系統

在先前關於 swarm 的文章中，Cursor 團隊曾指出，像 Git 和 Cargo 這樣的工具依賴粗粒度的鎖來做並行控制。這對單一開發者來說沒問題，但對數百個並行 agent 產出的工作量來說完全不可行。

今年稍早的瀏覽器 swarm 峰值大約是每小時 1,000 次 commit。新版系統的峰值則是大約每秒 1,000 次 commit。為了支撐這樣的活動速率，Cursor 從零打造了一套新的版本控制系統（VCS）。吞吐量並不是自建這一層的唯一理由。系統中的每次變更都會經過 VCS，因此它也是碰撞最先被看見的地方——下一節中的好幾個協調機制，就是直接實作在 VCS 裡面的。

每秒千次 commit 下的五種失敗模式

人類工程團隊有標準的協調機制：code review、ownership、standup 會議、merge queue。這些機制在人類的節奏下運作良好，但在 swarm 的 commit 速率下，出現了人類團隊不常遇到的失敗模式。

一、Split-brain design（分裂腦設計）

兩個 planner，彼此不知道對方的存在，在程式碼的不同角落用不同方式實作了同一個概念。

Cursor 的修正是透過 prompting：planner 必須自己做設計決策，不能將決策委派出去；同時要求他們確保沒有任何兩個被委派的子樹會對同一個問題做決定。

二、Contention between planners（planner 之間的爭奪）

比 split-brain 更難處理的，是兩個 planner 知道彼此的存在，卻透過同一批檔案上的來回修改互相較勁。

問題在於兩套不同的現實圖景，而 merge 工具無法解決意見分歧。Cursor 的解法是讓 agent 將設計決策記錄在共享的設計文件中。依賴某個決策的程式碼會攜帶一個 compile-checked 的參照，指向那篇文件。當 planner 不知不覺地互相矛盾時，一個 reconciler（調解 agent）會合併這些文件，而參照會將解析結果向下游傳播。

三、Merge conflicts（合併衝突）

在 swarm 內部，agent 不斷在同一批檔案上碰撞。要解決衝突，他們必須停下來、吸收另一個 agent 的 context，然後繞過衝突進行合併。Worker agent 非常不擅長這件事——實務上，不是複寫掉對方的修改，就是放棄自己的修改。

為了解決這個問題，Cursor 建立了一個系統，讓一個中立的第三方 agent 介入 merge conflict，替所有當事方解決衝突。它的唯一目標是保持公正與效率，類似於工程團隊中 merge queue 的工作方式。

四、Megafiles（巨型檔案）

某些檔案是 agent 特別喜歡工作的地方。每個 agent 可能只加了一小段程式碼，但沒有任何單一 agent 負責保持檔案小巧。

這些「巨型檔案」會阻塞一切。它們的傳輸、diff、合併都很昂貴，而且成為不斷碰撞的地點。

Cursor 的解法是讓 worker agent 有辦法標記膨脹的檔案。一旦標記，系統會阻擋新的 commit，並由一個外部 agent 將過大的檔案分解成較小的模組。

五、Ossification（僵化）

Agent 在有人類參與的既有程式碼庫中工作時，學會了不要碰核心程式碼——即使它需要改。

為了解決這個問題，Cursor 採取了「許可故意破壞」（license intentional breakage）的策略。一個判斷核心修改值得做的 agent，可以在自己的範圍外做一個聚焦的 patch，並留下一段註解解釋為什麼這樣做。編譯器會將這個變更帶到系統的其他部分，所有依賴舊設計的程式碼都會編譯失敗。每個遇到這些錯誤的 agent 會找到那段註解，讀取理由，並將自己的工作更新以匹配新設計。

Review lenses：多層審查透鏡

在一個既長時間運行又多 agent 的系統中，錯誤會累積，swarm 需要一種方式在微小錯誤變成基礎性的問題之前自我修正。

Cursor 實驗了多種 review lens：例如給審查 agent 看 worker 的完整對話紀錄、或只看輸出結果、或只看程式碼庫。他們也嘗試讓審查 agent 跑在不同的模型上，具有不同的訓練和不同的「個性」。

沒有任何單一 lens 能捕捉所有問題，但 decorrelated（去相關的）lens 會疊加效果，就像自駕車系統透過疊加多個不完美的組件來達到超越人類的可靠性，而不依賴任何單一完美組件。花在審查上的運算力是回報率很高的投資，因為審查遠比它審計的工作本身便宜。團隊懷疑，這種疊加式審查系統是新版 swarm 能維持品質的主要貢獻者之一。

讓 agent 塑造環境：Field Guide 與 Stigmergy

Stigmergy（激勵性痕跡溝通）是像螞蟻和白蟻這類群體生物無需直接溝通就能協調的機制：它們塑造環境，而環境接著塑造下一個個體的行為。

Cursor 在更早的 run 中就編碼了「保持筆記」和「記錄決策」這類規則，因為它們看起來顯然有益。回過頭來看，這些規則是讓 agent 為未來的自己和隊友將知識制度化。

團隊進一步推動了這個方向，做了一個稱為 Field Guide 的實驗。它是一個完全由 agent 擁有的資料夾，其中的 index.md 會在每個 agent 啟動時自動注入到 context 中。Agent 的工作是策劃哪些內容該進 Field Guide，唯一的限制是行數預算。

Field Guide 的底層邏輯是：模型權重是凍結的，所以正是那些「意料之外的遭遇」（surprise encounters）值得捕捉下來，讓下一個 agent 的軌跡更短。Field Guide 是一個早期實驗，結果有潛力。團隊預期，在 agent 不完全擁有的程式碼庫上，Field Guide 的好處會更大。訓練模型為其後繼者而寫——更好的捕捉會導致更好的獎勵——是一個有趣的後續研究方向。

SQLite 實驗設計

Cursor 指示新版 swarm（配備上述所有改進）用 Rust 實作整本 835 頁的 SQLite 手冊。他們扣留了 SQLite 的原始碼、測試套件、SQLite 二進位檔，以及網際網路存取權。

為了測量進展，他們用 sqllogictest 來評分——這是一套來自 SQLite 專案的測試套件，設計用來檢查不同資料庫引擎對相同查詢是否回傳相同的結果。它包含了數百萬個已知正確答案的查詢，評分就是 swarm 的資料庫答對的比例。進展在 run 的過程中會呈現為一條上升曲線。

Swarm 從未被告知測試套件的存在。每次 run 結束後，團隊手動審查程式碼和 run 本身，檢查是否有作弊或走捷徑的跡象，並確認系統是均勻地建立出來的，而不只是在測試會看的地方。

解讀這些曲線時要注意的是：agent 選擇了自己的策略。有些先建立廣泛的基礎，在前幾個小時分數很低，然後在後期出現急遽飆升；有些則深入一個領域，早期就拿到高分，然後在補齊其他部分時趨於平穩。趨勢比特定時刻的精確分數更重要。

四種模型混搭的實驗結果

Cursor 測試了四種配置，橫跨不同的能力與成本範圍：

  1. GPT-5.5 同時作為 planner 和 worker——全程使用強大的 frontier 模型。
  2. Grok 4.5 同時作為 planner 和 worker——成本效率較高的 frontier 模型。
  3. Opus 4.8 作為 planner，Composer 2.5 作為 worker——frontier 判斷力搭配高效率執行。
  4. Fable 5 作為 planner，Composer 2.5 作為 worker——用來觀察次一級的 planner 是否讓混合配置更划算或更不划算。

新版 harness 在每種混搭中都勝過舊版。Fable 5 的混合配置在第一個小時內就通過了大約三分之二的測試套件。到了四小時的截止點，新版 run 的分數落在 73% 到 85% 之間，而舊版 run 則落在 11% 到 77% 之間。舊版 Grok 4.5 run 在兩小時標記之前就被暫停了。每一種新版配置最終都通過了 100% 的測試套件。

深度檢視 run 的細節

舊版 Grok 4.5 run 在前兩小時產生了 68,000 次 commit，大約是新版 run 速度的 70 倍。一種解讀是它更有生產力。另一種是這些 commit 大部分是空轉的工作（thrash、爭奪、攪動）。

merge conflict 的數據指向後者。舊版 run 在被暫停前累積了超過 70,000 次衝突，並且是在加速而非趨於穩定；新版 run 在完整的四小時中記錄了不到 1,000 次衝突。

衝突集中在檔案長得最大的地方。在舊版 run 中，最大的檔案在整個 run 中持續成長，單一最熱門的檔案收集了 7,771 次衝突，被 1,173 個不同的 agent 碰過。在新版 run 中，整個程式碼庫中競爭最激烈的檔案只看到 47 次衝突。

舊版 swarm 最大的協調失敗——split-brain，也就是 planner 彼此重複做同樣的工作——體現在套件結構上。舊版 run 膨脹到 54 個 crate，包含三個獨立的 SQL 套件。新版 run 在早期就穩定在 9 個 crate，之後再也沒有增加。

這一切最終都反映在產出的程式碼庫上。在 Fable 5 混搭中，新舊 swarm 最終都通過了完整測試套件，但舊版需要 64,305 行引擎程式碼，而新版只用 9,908 行就做到了。Opus 混搭也呈現相同的模式：舊版 harness 的 19,013 行拿到 97% 的分數，新版 harness 的 4,645 行拿到 100%。

模型經濟學

前面提到每種模型配置都產出相近品質，但成本差距極大：從 Opus 4.8 混合配置的 $1,339 到 GPT-5.5 單一配置的 $10,565。Token 數據顯示了這差距的來源。

支出的結構在每次 run 中都是一致的：worker 承擔了至少 69% 的 token，在大多數 run 中甚至超過 90%。

但美元的分佈和 token 不同，因為 planner token 更貴。在 Opus 4.8 加 Composer 2.5 的混搭中，Opus 作為 planner 只產生了一小部分的 token，卻佔了大約三分之二的成本；而 Composer 作為 worker 處理了絕大多數的 token，只佔了剩下的三分之一成本。

在一個大型任務中，真正需要 frontier 智慧的時刻很少：原始的任務分解、設計決策、以及某些取捨。一旦 frontier planner 把模糊性壓縮成了詳細而明確的指令，較便宜的模型只需要照著執行即可。這是巨大的潛在節省空間。在使用 GPT-5.5 同時做 planner 和 worker 的 run 中，光 worker 部分就花了 $9,373。而在 Opus 4.8 做 planning、Composer 2.5 做 work 的 run 中，整個 worker 艦隊只花了 $411。

一個值得注意的細節來自兩個混合 run 的比較。Fable 5 planner 比 Opus 4.8 planner 的帳單略小，儘管其每 token 價格大約是 Opus 的兩倍——因為它用了遠少於 Opus 的 planning token。但 Fable run 的 worker 消耗了好幾倍的 token，整個 run 最終貴了不少。

Specs as prompts：意圖即程式碼

AI 能力的每一次躍升，都提高了工程師可以工作的抽象層級。自動補全（autocomplete）讓工程師一次寫一行程式碼。早期的模型把這提升到一個程式碼區塊（block），而 agent 則提升到一個檔案或一個功能（feature）。

有了 swarm，工作的單元變成了 spec（規格）。

這要能運作，swarm 必須真的按照 spec 執行——這正是這篇文章大部分的內容。團隊給了 swarm 835 頁的散文，它交回來一個資料庫。在這個實驗中，真正稀缺的——也是團隊預期未來軟體工程中會稀缺的——是正確的意圖描述。

從這個角度來看，swarm 開始像一個編譯器。編譯器將原始碼透過一系列中間步驟轉譯成機器碼。Swarm 對意圖做了類似的事情：planner 將目標解析成任務樹，然後逐步降階為可執行的工作。差別在於，編譯器在每一步都保持語義不變，而 swarm 在每一步都是機率性的。這篇文章中描述的每一件事，都是為了關閉那個差距。

團隊邀請讀者探索 swarm 的產出。Opus 4.8 單獨運行的程式碼庫已在 github.com/cursor/minisqlite 公開。

城武觀點

一、編譯器類比是行銷，不是工程

Cursor 在文章最後一段把 swarm 比喻為 compiler：意圖 → 任務樹 → 可執行工作。這個類比聽起來漂亮，但它是願景包裝，不是工程描述。

compiler 的每個 pass 是確定性且可組合的：parser、type checker、optimizer、codegen——每個階段的輸入和輸出有明確的語義契約，你可以單獨測試、逐層證明正確性。但 swarm 的每個協調層——reconciler 的設計文件合併、merge agent 的中立第三方判決、review lens 的多層審查、Field Guide 的共享知識庫——本身全都是機率性機制。Cursor 的整套系統，本質是用機率性機制去修正機率性機制。

收斂性在哪裡？沒人知道。自駕車的 stacked reliability 類比（文章明確引用了）在這裡不成立，因為物理世界有碰撞等於損壞的硬限制——你的車撞上護欄，感測器會立刻告訴你出事了。但程式碼沒有這種硬限制。一個 worker agent 因為 context 偏差而在某個檔案裡留下一個微妙的邏輯錯誤，review lens 完全可能沒抓到——因為 review lens 也是機率性的。下游的 agent 繼續在這個錯誤上疊加工作，merge agent 照常合併，reconciler 的設計文件完全沒有提到這一段。整條鏈上的每一個檢查點都是機率性的，沒有任何一個環節能給你確定性的保證。

Cursor 說「這篇文章中描述的每一件事，都是為了關閉那個差距」。但關閉差距的方式，是不斷往同一個機率性系統上疊加更多機率性補丁。這不是 compiler 的逐層消歧義，而是 whac-a-mole——只是槌子也由地鼠自己拿著。

二、稀缺的不是「意圖描述」，而是「能操作 swarm 的人」

Cursor 的結論是：「在這個實驗中真正稀缺的，是正確的意圖描述。」這句話讀起來像是一個民主化的宣言——你只要寫 spec，不用寫 code。但整篇文章的每一個段落都在打臉這個結論。

split-brain 需要人類工程師設計 prompting 策略來修正。planner contention 需要人類工程師發明 reconciler 機制。merge conflict 需要人類工程師設計第三方中立 agent。megafile 需要人類工程師設計標記與分解流程。ossification 需要人類工程師想出「許可故意破壞」的策略。review lens 需要人類工程師實驗不同審查配置並找到 decorrelated 疊加方式。Field Guide 需要人類工程師設計行數預算、注入時機、agent 策劃規則。

每多一層補丁，系統的複雜度就往上跳一級。能寫 835 頁 SQLite spec 的人或許不多，但能在每秒 1,000 次 commit 的速度下看懂 swarm 的行為，然後發明新的協調機制來解決新出現的 failure mode 的人——這種人 Cursor 以經在文章裡展示了至少七個。他們更稀缺，也更難複製。

這把軟體開發的門檻從「寫程式」移到了「操作 swarm」——表面上是民主化，讓不會寫 code 的人也能透過 spec 開發軟體；實質上是集中化，因為真正能駕駛這台機器的人變得極度稀少，而且這群人的經驗高度綁定在特定 swarm 平台的內部機制上。你不是在學一個通用的技能，你是在學 Cursor 的 swarm 怎麼運作。這不是解放，這是換了一個更難逃脫的生態系。

三、成本省下的錢，去了誰的口袋？

混合模型 swarm（Opus 4.8 + Composer 2.5）花 $1,339，全 frontier（GPT-5.5）花 $10,565——省了將近九成。數字很好看，但這個九成是 Cursor 吃走，還是使用者吃走？

Cursor 的定價模式是訂閱制。你付的月費不會因為 swarm 在後端選了便宜模型就變便宜。真正從模型套利中獲益的，是 Cursor 自己的毛利——貴模型做 planning，便宜模型做 execution，中間的價差變成平台的利潤。

這本身不是問題——平台賺錢天經地義。真正的問題是：Cursor 把 swarm 的複雜度本身當成護城河。你無法自己混搭 Opus 4.8 + Composer 2.5 就拿到跟 Cursor swarm 一樣的效果，因為那些協調機制——reconciler、merge agent、Field Guide、decorrelated review lens——才是讓混合模型能跑出同樣品質的關鍵。而這些機制是閉源的，且深度整合在 Cursor 的自製 VCS 裡面。

但這個護城河沒它宣稱的那麼深。模型套利的前提是：frontier 模型和便宜模型之間存在夠大的價差，而且便宜模型在「照著明確指令執行」這件事上夠可靠。問題是，這扇窗隨時可能被模型廠商自己關閉。想像一下：Anthropic 決定推出 planner mode（貴）和 worker mode（便宜），兩種模式共用同一個模型權重但不同定價——或是 Google 在 Gemini 裡面直接內建 task decomposition 功能，讓你根本不需要 Cursor 的 swarm 層來做規劃。

到那時候，Cursor 的複雜度從護城河變成負擔——你花了好幾年打造的 swarm 協調層，被模型廠商在 API 層直接吃掉。而模型廠商有動機這樣做：因為那九成的價差，從 Cursor 的口袋搬到模型廠商的口袋，對他們來說只是改一個 API 定價策略的事。

Cursor 用這篇文章展示的工程成就——從新打造 VCS、發明五種 failure mode 的修補機制、疊加 decorrelated review lens、設計 Field Guide 做 stigmergy 式知識傳承——都是真正的工程。但工程上的 impressive 不等於願景上的誠實。compiler 的比喻是一個精巧的敘事框架，它讓你相信 swarm 是一個確定性的、可預測的、會被逐步改進到完美的系統。但文章裡的每一個機制都在告訴你相反的現實：這是一個靠大量人類工程師的手工修正，才能勉強在有限場景中收斂的機率性系統。你可以佩服工程師的巧思，但不要買單他們的行銷框架。

城武的未解檔案——compiler 的每個 pass 都知道自己在幹嘛；swarm 的每個 pass 都在賭。Cursor 花了整篇文章告訴你他賭得有多好，但沒告訴你的是：這場賭局裡，平台是莊家，而你連籌碼的面額都看不到。