前言¶
2026 年 7 月下旬，Cursor 在官方博客公佈了升級版 Agent Swarm 架構的設計思路與基準測試結果。這套多 Agent 編排系統隨 Cursor 3 的 Agent 運行時一同演進：前沿模型負責「拆任務、定方案」，廉價 Worker 模型負責「寫代碼、跑實現」。在「僅憑 SQLite 手冊、從零用 Rust 重寫數據庫」的封閉實驗中，新架構各配置最終均達到 sqllogictest 100% 通過率，Opus 4.8 規劃 + Composer 2.5 執行的組合總成本約 \(1,339**，而全程使用 GPT-5.5 的單模型方案約 **\)10,565——差距接近 15 倍。
這組數據出自 Cursor 自研基準，並非生產環境實測；但它清晰指向一個正在被更多團隊討論的方向：多模型協作可能比「全程上最強模型」更划算。本文基於 Cursor 官方博客與公開報道，梳理架構要點、實驗數據與落地時的注意點。
背景：從瀏覽器 Swarm 到 SQLite 復刻¶
Cursor 早在 2026 年初就用 Agent Swarm 做過「從零寫瀏覽器」的概念驗證：能跑通，但離可交付產品還有距離。團隊隨後把重點放在理解並工程化 Swarm 本身，並回到舊版 Swarm 曾卡住的難題——僅憑 835 頁 SQLite 官方手冊，在 Rust 中實現完整數據庫引擎。
實驗條件刻意收緊：
- 不提供 SQLite 源碼、二進制、測試套件；
- 禁止聯網；
- 評測使用 Swarm 事先不知道的 sqllogictest（數百萬條 SQL 查詢及標準答案）。
舊版 Swarm 在此任務上表現不佳：Grok 4.5 單模型配置在不到兩小時內因協調失敗被暫停；四小時後各舊配置通過率僅在 11%～77% 之間。新版 Swarm 在同樣時間預算下，四小時後通過率落在 73%～85%，且所有新配置最終都達到 100%。
核心架構：Planner 與 Worker 的樹形分工¶
Cursor 將大型任務自然建模爲一棵任務樹：根節點是總目標，遞歸分解爲可執行的葉子節點。Swarm 中兩類 Agent 各司其職：
- Planner（規劃者）：運行前沿大模型，負責把目標拆成子任務、做架構與關鍵設計決策，不寫實現代碼。
- Worker（執行者）：運行更快、更便宜的模型（基準中多爲 Composer 2.5），在葉子節點執行具體編碼，不做規劃。
這種分工針對的是長程 Agent 的上下文問題。單個 Agent 若既要「記住全局目標」又要「處理當前文件細節」，容易在任務樹上漂移——要麼盯細節丟大局，要麼守大局做不好局部。Planner 上下文不被實現細節佔滿，Worker 則把全部上下文留給單一窄任務，Cursor 認爲這比單純堆並行度更能擴展 Swarm 能力。
Cursor 在博客中還類比了 Ronald Coase 關於企業層級的論述：協調成本增長快於工作量本身，因此係統會自然形成有邊界的分工單元，而不是讓所有人兩兩對話。
協調層：每秒千次提交與失敗模式治理¶
高併發 Agent 寫代碼時，Git 等常規工具很快成爲瓶頸。早期瀏覽器 Swarm 在 Git 上峯值約 1,000 commits/小時；新版自研 VCS 峯值約 1,000 commits/秒。所有變更經 VCS 流轉，衝突在此層最先暴露，多種協調機制也內嵌其中。
Cursor 文檔化了若干在「人類 tempo」下少見的失敗模式及對策：
| 失敗模式 | 簡要說明 | 應對思路 |
|---|---|---|
| Split-brain | 多個 Planner 各自實現同一概念 | 規劃者自己做設計決策，禁止子樹重複決定同一問題 |
| Planner 爭用 | 兩個 Planner 在同一文件上反覆拉鋸 | 共享設計文檔 + 編譯期引用，Reconciler 合併衝突決策 |
| Merge 衝突 | Worker 不擅長合併，易覆蓋或放棄 | 中立第三方 Agent 專門處理合併 |
| Megafiles | 熱門文件膨脹導致 diff/merge 成本飆升 | Worker 可標記臃腫文件，外部 Agent 拆模塊 |
| 僵化（Ossification） | Agent 不敢改核心代碼 | 允許「有意破壞」並留註釋，編譯錯誤驅動下游同步 |
此外還有多層 Review Lenses（不同模型、不同輸入範圍的審查 Agent 疊加），以及 Agent 自維護的 Field Guide——帶行數上限的知識文檔，每次新 Agent 啓動時自動注入，用於沉澱「意外發現」、縮短後續軌跡。
SQLite 基準：準確率、代碼量與衝突對比¶
官方博客對比了四種模型組合（新舊 Harness 各跑一遍）：
- GPT-5.5 同時擔任 Planner 與 Worker
- Grok 4.5 同時擔任 Planner 與 Worker
- Opus 4.8 規劃 + Composer 2.5 執行
- Fable 5 規劃 + Composer 2.5 執行
新版 Harness 在每種組合下均優於舊版。 以 Grok 4.5 爲例：舊版兩小時內產生約 68,000 次提交（約爲新版的 70 倍），但累積 70,000+ 次 merge 衝突後被暫停；新版全程衝突 不足 1,000 次。舊版 Rust 工程拆成 54 個 crate（含 3 套 SQL 包），新版穩定在 9 個 crate。
代碼量差異同樣顯著（均爲引擎代碼行數）：
- Fable 5 組合：舊版 64,305 行 vs 新版 9,908 行（均最終 100% 通過）
- Opus 組合：舊版 19,013 行、97% vs 新版 4,645 行、100%——代碼量減少約 85%，準確率反而更高
Opus 單跑產出的代碼庫已開源：github.com/cursor/minisqlite，讀者可自行審閱質量。
模型經濟學：Worker 佔 Token，Planner 佔賬單¶
四種配置最終質量相近，總成本卻從 \(1,339**（Opus + Composer 2.5）到 **\)10,565（GPT-5.5 單模型）不等，約 15 倍 差距。
Token 結構上，Worker 在各次運行中至少佔 69%，多數超過 90%——執行階段是 Token 大頭。但美元分佈不同：Planner 用的前沿模型單價高。以 Opus + Composer 2.5 爲例，Opus 規劃僅佔少量 Token，卻約佔 總成本的三分之二；Composer Worker 處理絕大多數 Token，只佔約 三分之一。
更直觀的對比來自 GPT-5.5 單模型 run：Worker 側 alone 約 $9,373；換用 Opus 規劃 + Composer 2.5 執行時，整個 Worker 艦隊約 $411，質量相當。這說明「規劃階段用貴模型、執行階段用便宜模型」在 Cursor 的封閉實驗裏具備巨大降本空間。
Composer 2.5 是 Worker 側的主力：基於 Moonshot Kimi K2.5 開源 checkpoint，經 Cursor 繼續預訓練與 RL；標準檔定價 \(0.50/M 輸入、\)2.50/M 輸出（另有 Fast 檔 \(3/\)15，交互默認）。Cursor 稱其智能水平可比肩 Opus 4.7、GPT-5.5，該說法尚未經第三方公開基準獨立驗證。
需注意：Fable 5 規劃雖比 Opus 少消耗規劃 Token，但其 Worker 總 Token 數倍於 Opus 組合，整次 run 反而更貴——說明 Planner 質量會傳導到 Worker 效率，不能只看規劃單價。
與 Cursor 3 的關係¶
Cursor 3 於 2026 年 4 月 2 日發佈，核心是 Agent 優先的統一工作區：Agents Window、本地/雲端/SSH 多 Agent 並行、多倉庫佈局等。Agent Swarm 的 Planner/Worker 編排是這一 runtime 上的架構升級，而非單獨售賣的模型產品；TPS 等媒體報道將其描述爲 Cursor 3 多 Agent 能力的一部分。
對用戶而言，界面層已支持並行管理 Agent 艦隊；Swarm 論文級改進（自研 VCS、Field Guide、Review 棧）則主要體現於 Cursor 內部長跑任務與 Cloud Agent 場景。
對工程團隊的啓示與侷限¶
可借鑑的思路：
- 任務路由：分解、架構、關鍵 trade-off 用強模型；明確子任務交給 Composer 2.5 等低成本模型——與業界「用最小夠用模型完成任務」的趨勢一致。
- Spec 即 Prompt：Swarm 把工程抽象層級從「文件/功能」抬到「規格說明」；835 頁手冊進、數據庫出，稀缺資源是意圖描述的質量。
- 協調與 VCS 同等重要：70,000 次衝突 vs 不足 1,000 次，說明多 Agent 的瓶頸往往在編排與合併，而非單點模型智商。
必須保留的審慎：
- 基準是合成、閉卷、Cursor 自評，公司有展示產品優勢的商業動機。
- Cursor 博客亦引用研究：約 68% 的生產 AI Agent 在 10 步以內停滯——今日的成本紅利多適用於可控實驗，尚不能等同日常業務代碼庫。
- Composer 2.5 與前沿模型的對等說法、Fable 5 等部分模型細節，應以 Cursor 披露爲準，待社區復現。
小結¶
Cursor 新版 Agent Swarm 用 Planner/Worker 樹形分工、自研高吞吐 VCS 與多層審查，在 SQLite-to-Rust 基準上同時改善了準確率、代碼體量與 merge 衝突。模型組合層面，Opus 4.8 + Composer 2.5 相對 GPT-5.5 單模型方案總成本降低約 15 倍，Worker 側 alone 可從約 \(9,373** 壓到約 **\)411。
這對正在評估 AI 編碼 Agent 採購與架構的團隊是一記清晰的信號：多模型編排可能和「換更強模型」同樣重要。下一步 worth 關注的，是同類 Planner/Worker 策略在真實遺留代碼庫、合規與審計要求下的可複製性——以及 minisqlite 等開源產物能否經受社區獨立審查。
