AI 知識
高活動量，不等於高產能
68,000 次 commit，直覺上像是一支 AI 軟體團隊正在全速開發。
但在 Cursor 公開的 agent swarm 實驗裡，這個數字代表的更可能是另一件事：大量 agent 同時動手，卻沒有足夠清楚的分工與衝突處理機制，於是「高活動量」變成「高速互撞」。
這場實驗的任務很硬。AI Agent 必須只依 835 頁 SQLite 文件，以 Rust 從零建立資料庫引擎。它們拿不到 SQLite 原始碼、官方測試、binary，也不能連上網路。完成後，再用事前保留、agent 不知道存在的 sqllogictest 驗證。
實驗最值得看的，不是某個模型又拿到幾分，而是同一群 AI 如何因協作架構不同，產生完全不同的工作型態。
忙碌不等於進度
舊版蜂群中的 Grok 4.5 run，在前兩小時產生約 68,000 次 commit，約為新版架構的 70 倍。
數字看起來驚人，代價也同樣驚人：舊架構四小時累積超過 70,000 次 merge conflict；新架構則低於 1,000 次。
更具體地看，舊架構最熱門的單一檔案發生 7,771 次衝突，有 1,173 個 agent 曾經介入。新版架構最熱門檔案的衝突數只有 47 次。
這個差距說明了一個常被 AI 自動化掩蓋的問題：當工作邊界不清楚，每個 agent 都可能合理地認為自己應該修改同一個核心檔案。它們確實持續產出，也確實持續抵銷彼此的產出。
所以 commit 數、工具呼叫數、token 數與 agent 數，都不能單獨當成進度指標。
新架構到底改了什麼
Cursor 的新版 harness 沒有放棄多 agent，而是把協作責任重新分層。
1. Planner 先拆出可獨立完成的工作
Planner 不必親自寫完所有程式。它的價值是理解整體依賴、決定模組邊界、安排先後順序，並把工作切成 worker 能明確完成的任務。
這是少數真正需要強推理的地方。如果任務一開始就切錯，後面再多 worker 都只是在錯誤邊界上加速。
2. Worker 專注執行，不反覆重做架構決策
Worker 接到的是具體工作，而不是「大家一起把資料庫做好」這種沒有責任邊界的目標。
當 task scope、輸入、輸出與完成條件清楚，worker 才能平行；否則只是多人同時搶一支筆。
3. 用中立 reconciler 處理衝突
舊架構讓產生衝突的 agent 自己解衝突，容易延續各自版本的假設。新版則把衝突交給中立角色判斷兩邊意圖，再決定如何整合。
衝突處理從「誰覆蓋誰」變成獨立責任。
4. 提早拆分熱門大檔案
如果數百個 agent 都需要修改同一個檔案，問題通常不是大家不夠努力，而是模組邊界失效。
新版架構會辨識高衝突熱點，把過大的檔案拆成更小、責任更單一的模組，降低不同工作共用同一修改面的機率。
5. 共享一份持續更新的 field guide
多 agent 系統不能只靠每個 agent 的局部上下文。它需要一份共同狀態，記錄目前架構、已知陷阱、慣例與決策。
這份 field guide 不是把所有歷史都塞進 prompt，而是讓後續 agent 不必重複探索已經得到的結論。
少寫 75% 程式，結果反而更完整
在 Opus 4.8 配置中，舊架構產生 19,013 行程式碼，保留測試通過率為 97%；新架構只產生 4,645 行，卻達到 100%。
新版少了約四分之三的程式碼，結果反而更好。
這不是在鼓吹程式碼越少越好，而是說明大量程式碼可能只是重複實作、平行版本與架構失控的副產品。當模組邊界與責任清楚，系統不需要用膨脹掩蓋混亂。
舊架構最後擴張到 54 個 Rust crate，甚至同時出現 3 套 SQL package；新版穩定在 9 個 crate。這比 commit 數更能反映架構是否收斂。
最聰明的模型不必坐滿每一個位置
實驗也比較了不同 planner 與 worker 組合。
全部使用 GPT-5.5 的配置成本為 10,565 美元；使用 Opus 4.8 規劃、Composer 2.5 執行的配置為 1,339 美元，差距約 7.9 倍。兩者最終都通過同一套保留測試。
這不代表較低成本模型永遠比較好，也不表示任何任務都能照抄這個比例。
它支持的是一個更務實的配置原則：把高階推理放在少數需要分解、設計與取捨的節點；把已經明確定義的工作交給成本較低的 worker。
Cursor 的數據顯示，worker 至少消耗 69% token，多數配置甚至超過 90%。如果每個 worker 都使用最昂貴模型，規模一放大，成本就會快速失控。
通過測試，不等於成為正式 SQLite
這項實驗需要嚴格保留事實邊界。
SQLite 官方對 sqllogictest 的說明很清楚：它驗證資料庫是否算出正確答案，但不測效能、索引效率、磁碟或記憶體使用、transaction 行為、concurrency 與 locking。
因此，通過保留測試代表這些 AI 建出的引擎在測試涵蓋的查詢正確性上達標；它不代表已具備正式 SQLite 的效能、可靠性、相容性與生產成熟度。
Cursor 也明確表示，尚未對公開輸出做完整的深度人工品質分析。
這個限制不會降低實驗價值，反而讓結論更精確：它測到的是「多 agent 協作架構如何影響完成一個大型軟體任務」，不是「AI 已經取代成熟資料庫工程」。
衡量 AI 團隊，應該看哪些數字
如果 commit 數不夠，實務上可以改看以下指標：
- 有效完成率：通過多少真正獨立、事前保留的驗收。
- 衝突密度：每個完成項目需要處理多少 merge conflict 與重工。
- 架構收斂：模組數、重複實作與熱點檔案是否持續增加。
- 成本效率：每個通過驗收的成果花多少 token、時間與金額。
- 人工介入：需要多少次救援、回滾與重新拆任務。
這些數字比「同時開了幾個 agent」更接近真實產能。
結語
AI Agent 不會因為數量變多，就自動成為一支團隊。
能否規模化，取決於工作是否能被切開、決策是否有層次、衝突是否有明確 owner、共同狀態是否可追蹤，以及驗收是否真正獨立。
當這些條件缺席，更多 agent 只會讓混亂跑得更快；當協作架構成立，較少程式碼、較少衝突與較低成本，反而可能交出更完整的結果。
下一波 AI 開發工具競爭，未必只看誰有更強模型。誰能把一群模型管理成真正協作的系統，才可能拉開差距。
查證摘要
- Cursor 於 2026-07-20 公開新舊 agent swarm harness 與四種模型配置的 SQLite-from-scratch 實驗。
- 舊版 Grok 4.5 run 前兩小時約 68,000 commits；舊架構四小時超過 70,000 conflicts，新架構低於 1,000。
- 新架構以 planner、worker、neutral reconciler、hot-file splitting 與 shared field guide 降低協作成本。
- Opus 4.8 配置由 19,013 LOC／97% 改善為 4,645 LOC／100%。
- GPT-5.5 全配置成本 10,565 美元；Opus 4.8 planner + Composer 2.5 worker 為 1,339 美元。
- SQLite 官方說明
sqllogictest只驗證答案正確性，不涵蓋效能、索引效率、資源使用、transaction、concurrency 或 locking。