前言¶
2026 年 7 月，Cursor 在官方博客「Agent swarms and the new model economics」中公佈了 Cursor 3 升級版 Agent Swarm 的架構與基準結果。這套系統把 AI 編碼工作拆成兩類角色：Planner（規劃者） 用前沿大模型做任務分解與設計決策，Worker（執行者） 用更快、更便宜的模型寫代碼。兩者配合，在「僅憑 SQLite 手冊、從零用 Rust 重寫數據庫引擎」的閉卷測試中，四種正式對比配置最終都達到了 sqllogictest 隱藏測試集的 100% 通過率；最便宜的一組（Opus 4.8 規劃 + Composer 2.5 執行）總賬單約 \(1,339**，而同任務下 GPT-5.5 單模型包辦約 **\)10,565。
媒體常把這一差距概括爲「約 15 倍」——這個數字來自非正式對照跑分（Fable 5 單模型約 $20,057 ÷ $1,339）。Cursor 自己在四組受控對比裏給出的區間是 約 7.9 倍；若只比 Worker 層 token 賬單，GPT-5.5 單跑 Worker 花費 $9,373，Opus + Composer 混合跑 Worker 僅 $411，差距約 22 倍。下文按官方一手信息梳理架構原理、基準細節與成本算術，方便讀者判斷這套分層是否值得在自己的工程裏借鑑。
單 Agent 的上下文困境¶
Cursor 把大型軟件任務自然建模成一棵樹：根節點是總目標，遞歸向下拆成越來越小的子任務。單個 Agent 若獨自完成整棵樹，必須在上下文裏同時記住「全局目標、當前路徑、葉子節點細節」，長程運行中很容易 漂移——要麼只顧眼前實現、丟失架構一致性，要麼死守大圖、局部代碼質量下降。
Agent Swarm 的解法很直接：
- Planner：只負責拆分與委派，不寫實現代碼，上下文不被低層細節佔滿。
- Worker：只執行被派發的窄任務，不做規劃，全部上下文留給當前這一塊工作。
Cursor 認爲，Swarm 的可擴展性主要來自這種 上下文效率，而不只是「多開幾個 Agent 並行」。經濟學家 Coase 關於「企業爲何存在」的論述在這裏有呼應：協調成本增長快於工作量本身，因此係統會自然分層，而不是讓所有人兩兩直接對話。
SQLite 轉 Rust：閉卷基準怎麼測¶
爲驗證新架構，Cursor 讓新舊兩代 Swarm 做同一道題：
只給 835 頁 SQLite 官方手冊，要求用 Rust 實現完整數據庫引擎；不提供 SQLite 源碼、測試套件、二進制和互聯網訪問。
評分使用 SQLite 項目的 sqllogictest——包含數百萬條 SQL 及標準答案，用於跨引擎比對查詢結果。Swarm 事先不知道 這套測試存在；跑完後 Cursor 還會人工審查是否作弊、是否只在測試覆蓋區域堆代碼。
四組受控模型配置如下：
- GPT-5.5 兼任 Planner 與 Worker（強前沿模型單跑）
- Grok 4.5 兼任 Planner 與 Worker（成本較低的前沿模型單跑）
- Opus 4.8 規劃 + Composer 2.5 執行
- Fable 5 規劃 + Composer 2.5 執行
新 harness 在每一組配置下都優於舊版。 四小時後，新系統通過率約在 73%–85%，舊系統僅 11%–77%；舊版 Grok 跑甚至在兩小時內因 merge 衝突失控被暫停。最終，四組新配置全部達到 100%。
代碼體量差距同樣明顯。以 Opus 相關對比爲例：舊 harness 約 19,013 行、準確率 97%；新 harness 4,645 行、準確率 100%，代碼量約減 85%。舊 Grok 跑在 2 小時內產生約 68,000 次 commit（約爲新系統的 70 倍），卻積累 7 萬+ merge 衝突；新系統全程不足 1,000 次衝突。舊版把項目拆成 54 個 Rust crate（含 3 套重複 SQL 包），新版穩定在 9 個 crate。
賬單算術：7.9 倍、15 倍與 22 倍¶
先看 Cursor 正式對比的四組總成本（均達到 100% 通過率）：
| 配置 | 總成本（約） |
|---|---|
| Opus 4.8 + Composer 2.5 | $1,339 |
| Grok 4.5 單模型 | $1,928 |
| Fable 5 + Composer 2.5 | $2,234 |
| GPT-5.5 單模型 | $10,565 |
$10,565 ÷ $1,339 ≈ 7.9 倍——這是官方受控對比裏最直接的「總賬單倍數」。
Worker 層纔是大頭：各次運行中 Worker 產出至少 69% token，多數超過 90%。GPT-5.5 單跑裏 Worker alone 約 \(9,373**；Opus 規劃 + Composer 執行時，整個 Worker 艦隊約 **\)411。$9,373 ÷ $411 ≈ 22.8 倍——這反映的是「執行層換便宜模型」的槓桿，而非整單成本。
媒體報道的 ~15 倍，通常用圖表中帶腳註的 Fable 5 單模型非正式跑（約 $20,057，Cursor 標明 informal run for cost calibration, not part of the controlled comparison）去除以 $1,339 得出。算術成立，但對照組不在官方評分矩陣內，引用時需說明口徑。
Composer 2.5 作爲 Worker 的定價爲：輸入 \(0.50 / 百萬 token**，輸出 **\)2.50 / 百萬 token。Cursor 創始人 Michael Truell 稱其基於 Kimi K2.5，性能宣稱接近 Opus 4.7 / GPT-5.5——該說法尚未經第三方公開基準獨立驗證。在 Opus + Composer 混合跑中，Opus 作爲 Planner 只產出少量 token，卻約佔 總成本的三分之二；Composer 處理絕大多數 token，只佔約 三分之一——說明「少數時刻需要前沿判斷力，大量執行可以下沉到廉價模型」這一分工邏輯。
1000 commits/s：協調工程纔是隱藏主角¶
舊版瀏覽器 Swarm 在 Git 上峯值約 1000 commits/小時；新版自研 VCS 峯值約 1000 commits/秒。所有變更經 VCS 匯聚，衝突在這裏最先暴露，多種協調機制也實現在這一層。
Cursor 文檔化了若干在高併發下才會放大的失敗模式及對策：
- Split-brain（分裂腦）：兩個 Planner 互不知曉，各自實現同一概念。對策：Planner 自己做設計決策，並保證委派子樹不重複決定同一問題；共享設計文檔 + 編譯期引用 綁定決策與代碼。
- Merge 衝突：Worker 不擅長合併，容易覆蓋或放棄。對策：中立第三方 Agent 專門仲裁衝突。
- Megafiles（巨型文件）：多 Agent 往同一文件堆代碼，diff/merge 成本爆炸。對策：Worker 可標記臃腫文件，外部 Agent 將其拆成更小模塊。
- Ossification（僵化）：Agent 學到「不要動核心代碼」。對策：允許有理由的越界修改，編譯錯誤驅動下游 Agent 跟隨調整。
- Field Guide（現場指南）：Agent 自維護、有行數上限的知識文檔，每次會話啓動時注入，類似蟻羣的 Stigmergy（環境痕跡協調）。
此外還有多種 Review Lens 疊加審查——不同模型、不同信息粒度並行審代碼，類似自動駕駛多傳感器融合，用相對便宜的審查算力換整體質量。
從 Vibe Coding 到「Spec 即 Prompt」¶
Cursor 把 Swarm 的工作單元抬升到 Spec（規格說明） 一層：Autocomplete 時代一行一行補全，Agent 時代以文件/功能爲單位，Swarm 時代則以 意圖描述 爲輸入。本次實驗只給了 835 頁手冊 prose，輸出是可運行的數據庫——稀缺資源從「會不會寫循環」變成 「能不能把意圖寫清楚」。
這與 Vibe Coding（氛圍編程） 的流行形成有趣對照：個人開發者用自然語言快速迭代原型；Swarm 則把同一思路推到 工業級並行與賬單優化——前沿模型只在分解與關鍵 trade-off 上出場，其餘交給 Composer 這類「夠用的 Worker」。Swarm 被 Cursor 比作 概率性編譯器：Planner 把目標降到任務樹，再逐步 lower 成可執行工作；與確定性編譯器不同，每一步都有不確定性，上文那些 VCS、Review、Field Guide 機制就是在 縮小語義漂移。
開源倉庫 github.com/cursor/minisqlite 發佈了 Opus 4.8 單跑版本的代碼（非上述最便宜混合跑），供社區自行審查質量。
冷靜看待：基準很亮，落地仍早¶
需要強調的 caveat：
- 這是 Cursor 自研基準上的自研系統，商業上有展示動機；閉卷重寫 SQLite 與日常業務代碼庫差異很大。
- Cursor 在文中引用的外部研究指出：68% 的生產環境 AI Agent 在 10 步以內 就會停滯——今日的成本優勢主要體現在 受控長任務實驗，尚不能自動外推到普通 CRUD 維護。
- Fable 5 作 Planner 雖 planning token 更少，但其 Worker 消耗遠高於 Opus Planner 配置，總成本反而更高——說明「Planner 越強/越省不一定越便宜」，Worker 效率與規劃質量強耦合。
- 混合架構對 Spec 質量 依賴極高：Planner 一旦分解錯誤或設計文檔矛盾，廉價 Worker 只會高效地寫錯代碼。
結語¶
Cursor 3 的 Agent Swarm 用 Planner/Worker 分層回答了一個工程經濟學問題：大任務裏真正需要前沿模型的時刻很少，但 token 產量最大的執行層可以換便宜模型。 在 SQLite→Rust 閉卷測試中，新 harness 在準確率、代碼量、衝突率上全面優於舊版；受控總成本從約 $10,565 降到 $1,339（約 7.9 倍），Worker 層 alone 可從 $9,373 降到 $411（約 22 倍）。「15 倍」作爲傳播口徑存在，但讀者應區分 總賬單、Worker 賬單、非正式對照 三種算法。
對普通開發者，短期更現實的收益可能是 Cursor 3 產品裏的 多 Agent 並行編排 與 Composer 2.5 這類高性價比 Worker；長期則值得思考：你的團隊是否能把需求寫成像 SQLite 手冊那樣足夠明確的 Spec，讓 Planner 分得清、Worker 寫得穩。分層架構節省的不只是 API 賬單，還有 merge 衝突和冗餘 crate 帶來的 認知與協作成本——這或許比 headline 裏的倍數更值得帶入下一次架構評審。
