前言¶
2026 年 7 月，Cursor（Anysphere）發佈了一項名爲 Agent Swarm 的研究實驗：讓多 Agent 蜂羣僅憑 835 頁 SQLite 官方文檔，在 Rust 中從零重建 SQLite 數據庫引擎——不提供源碼、不提供測試套件、不提供 SQLite 二進制、也不允許聯網。最終，新架構下的多種模型組合均通過了 sqllogictest 全部測試；其中 Opus 4.8 負責規劃、Composer 2.5 負責執行 的混合方案，總成本約 1339 美元，而 GPT-5.5 單模型包辦規劃與執行 的方案約 10565 美元。質量相近，成本差了一個數量級。
這不是「模型又變強了」的簡單敘事，而是 Agent 編排經濟學 的一次量化驗證：大任務裏真正需要前沿模型的地方，可能只佔很小一塊；一旦規劃層把歧義消解成明確指令，廉價模型足以承擔絕大部分執行工作。本文基於 Cursor 官方博客、開源倉庫 minisqlite 及 Hacker News 討論，梳理實驗設計與結論，供正在評估多 Agent 方案的開發者參考。
實驗在測什麼¶
Cursor 把這次 SQLite 重建當作 新舊蜂羣 harness 的對照實驗。舊版蜂羣曾在類似任務上陷入合併衝突與重複建設；新版則疊加了自研版本控制系統、衝突仲裁、設計文檔對齊、文件拆分、多層 Review 等機制。
任務約束如下：
- 輸入：835 頁 SQLite 手冊（ prose 規格）。
- 輸出：Rust 實現的完整數據庫引擎。
- 禁止：SQLite 源碼、官方測試套件、sqlite3 二進制、互聯網訪問。
- 評測：實驗方在 Agent 不知情的情況下，用 sqllogictest 打分——這是 SQLite 項目用於跨引擎一致性驗證的套件，包含數百萬條 SQL 及已知正確答案，得分即通過比例。
實驗結束後，Cursor 還人工審查代碼與運行過程，排查作弊、走捷徑、以及「只修測試覆蓋區域」的局部優化。
Planner 與 Worker：樹形分解¶
Cursor 將大任務自然建模爲一棵 任務樹：根節點是總目標，遞歸拆成可執行子任務。蜂羣只有兩個核心角色：
- Planner（規劃者）：通常由前沿模型驅動，負責分解目標、做架構與設計決策、向下委派。
- Worker（執行者）：通常由更快、更便宜的模型驅動，負責在窄範圍內實現具體代碼。
Planner 不寫實現細節，Worker 不做全局規劃。Cursor 認爲，這比固定拓撲的編排系統更靈活——蜂羣形狀隨任務複雜度伸縮，上下文效率 纔是規模化的關鍵，而不只是並行度。
類比經濟學裏的科斯定理：協調成本增長快於工作量本身，所以組織會分層，而不是讓所有人兩兩直接溝通。單 Agent 長時運行容易「漂移」——要麼盯住眼前細節丟全局，要麼抱着大圖做不好局部；分層則讓各層上下文各就其位。
新 harness 解決了哪些「千次提交/秒」的故障¶
早期瀏覽器蜂羣實驗峯值約 1000 commits/小時；新系統峯值約 1000 commits/秒。Git 級別的粗粒度鎖已無法支撐，Cursor 爲此自研 VCS，並在其中實現協調邏輯。
官方博客重點提到幾類人類團隊不常遇見、但高併發 Agent 會放大的故障：
- Split-brain 設計：兩個 Planner 各自實現同一概念。對策：Planner 必須親自做設計決策，並保證委派子樹不重複決策同一問題。
- Planner 爭用：兩個 Planner 在同一文件上來回改。對策：共享設計文檔 + 代碼中 compile-checked 引用；衝突時由 reconciler 合併文檔並向下傳播。
- 合併衝突：Worker 不擅長合併，容易覆蓋或放棄。對策：中立第三方 Agent 專門仲裁衝突。
- Megafiles：熱門文件越寫越大，diff/merge 成本爆炸。對策：Worker 可標記臃腫文件，外部 Agent 負責拆分模塊。
- Ossification（僵化）：Agent 學到「別動核心代碼」。對策：允許有理由的越界修改，編譯錯誤驅動下游 Agent 跟進調整。
此外還有 Review lenses（多種審查視角疊加）和 Field Guide（Agent 自維護的共享上下文索引），用於長時運行中抑制錯誤累積。
SQLite 實驗結果¶
Cursor 測試了四種模型組合（新舊 harness 對照，相同時間預算）：
| 配置 | 角色 |
|---|---|
| GPT-5.5 | Planner + Worker 均爲 GPT-5.5 |
| Grok 4.5 | Planner + Worker 均爲 Grok 4.5 |
| Opus 4.8 + Composer 2.5 | 前沿規劃 + 高效執行 |
| Fable 5 + Composer 2.5 | 次一線規劃 + 高效執行 |
新 harness 在每一種組合下都優於舊 harness。 以 Grok 4.5 爲例：新系統在 4 小時內達到約 80% 通過率，舊系統不到 2 小時就因失控被暫停。4 小時截止時，新系統得分在 73%–85% 區間，舊系統在 11%–77% 區間；新系統的每一種配置最終都達到了 sqllogictest 100% 通過率。
行爲差異往往比分數更說明問題。舊 Grok 運行 2 小時內產生約 68000 次提交，約爲新系統的 70 倍，但伴隨 70000+ 次合併衝突；新系統全程 4 小時衝突不足 1000 次。舊系統最熱單文件被 1173 個 Agent 觸碰、累計 7771 次衝突；新系統最熱文件僅 47 次。包結構上，舊系統膨脹到 54 個 crate（含 3 套 SQL 包），新系統早期穩定在 9 個 crate。
代碼體量同樣懸殊：Fable 5 配置下，舊系統引擎代碼約 64305 行才跑滿測試，新系統約 9908 行；Opus 配置下，舊 harness 約 19013 行得 97%，新 harness 約 4645 行得 100%。
1339 美元 vs 10565 美元：模型經濟學¶
官方給出的總成本區間：Opus 4.8 混合方案約 1339 美元，GPT-5.5 單模型方案約 10565 美元。 各次運行的 token 結構一致——Worker 至少承擔 69% token，多數超過 90%；但 美元分佈與 token 分佈並不重合，因爲 Planner token 單價更高。
在 Opus 4.8 + Composer 2.5 組合中：
- Opus 作爲 Planner：token 佔比很小，卻約佔 總成本的三分之二。
- Composer 作爲 Worker：承擔絕大多數 token，卻只佔約 三分之一成本。
更直觀的對比：
- GPT-5.5 單模型方案中，僅 Worker 部分 就花了 9373 美元。
- Opus 規劃 + Composer 執行的方案中，整個 Worker 艦隊 只花了 411 美元。
Cursor 的結論是：大任務裏只有少數時刻真正需要前沿智能——初始分解、設計決策、關鍵權衡。一旦 Planner 把模糊目標壓成明確指令，廉價模型按 spec 執行即可。兩種混合方案（Fable 5 與 Opus 4.8 各配 Composer 2.5）質量相近，但 Fable 規劃 token 更少、Worker token 卻多幾倍，整體反而更貴——說明 Planner 選型 同樣影響經濟學，不能只看單價。
minisqlite：蜂羣的產物長什麼樣¶
實驗產出的 minisqlite 已開源：github.com/cursor/minisqlite（Anysphere 組織下同名倉庫）。README 描述其爲 SQLite 的 Rust 重實現，覆蓋 SQL 方言、查詢規劃與執行、事務、存儲引擎及官方 on-disk 格式；可讀寫 sqlite3 生成的數據庫文件。
公開 API 刻意極簡：Connection::{open, open_in_memory, execute, query}，約 20 萬行 Rust、14 個 crate、5650 個測試，庫代碼無 unsafe。Cursor 註明尚未做深度人工審計，歡迎社區審閱。
倉庫創建時間爲 2026-07-17，早於博客廣泛傳播，說明代碼與文章是同一實驗鏈條的公開延續。
「規格即 Prompt」：對開發者的啓示¶
Cursor 將能力演進概括爲抽象層級的抬升：補全 → 代碼塊 → 文件/功能 → Agent 蜂羣下的 spec（規格）。這次實驗的稀缺輸入不是算力，而是 835 頁 prose 規格；蜂羣像一臺 概率性編譯器，把意圖逐級 lower 成可執行工作，每一步都可能偏離，於是需要 VCS、Review、設計文檔等工程化約束來收窄 gap。
對日常工程實踐的啓示可以概括爲三點：
- 分層模型是成本槓桿，不是噱頭。 若你的任務可拆成「少量關鍵決策 + 大量確定性實現」，Planner/Worker 混合值得納入成本模型，而非默認全鏈路用最貴模型。
- 編排質量往往大於模型分數。 同一 Grok 4.5，新舊 harness 表現天差地別；合併衝突、crate 膨脹、代碼行數說明 協調機制 纔是規模化瓶頸。
- 規格與測試仍是錨點。 Agent 未被告知 sqllogictest 的存在，卻仍需通過外部一致性驗證；無論蜂羣多複雜，可並行、可判定的驗收標準 仍是信任基礎。
Hacker News 上對此實驗的討論（約 278 points、143 條評論）也呈現兩極：一方認爲這預示「規格驅動 + 廉價 Worker 集羣」的未來；另一方質疑 SQLite 語義已大量存在於模型權重中，「僅憑文檔重建」是否等價於從零構建。這些爭議不影響 成本結構 這一核心數據，但提醒讀者：實驗驗證的是 harness + 模型經濟學，而非「AI 已無需人類數據庫專家」。
結語¶
Cursor Agent Swarm 的 SQLite 實驗，用可復現的基準（sqllogictest）和公開代碼（minisqlite），把 「規劃用強模型、執行用弱模型」 從經驗法則變成了帶美元數字的工程命題。1339 美元與 10565 美元的差距，主要來自 Worker 艦隊該用誰、以及 harness 能否讓廉價模型 穩定執行 而非 無效內卷。
若你正在設計多 Agent 流水線，不妨先問兩個問題：哪些步驟真的需要 frontier 判斷？執行層的驗收標準能否像 sqllogictest 一樣清晰、可並行？答案將比「再換一個更強的單模型」更接近真實的 Agent 經濟學。
參考來源
- Cursor 官方博客：Agent swarms and the new model economics
- 開源倉庫：cursor/minisqlite
- Hacker News 討論：Agent swarms and the new model economics
