Cursor Agent Swarms and Model Economics

Hierarchical Swarms Reduce Cost and Increase Accuracy

Cursorの研究によると、エージェント・スウォーム（群れ）の階層的なタスク分解、つまり高レベルの計画と低レベルの実行を分離することで、計算コストを削減しながらソフトウェアエンジニアリングの成果を大幅に向上させることが可能です。ドキュメントのみを使用してRustでSQLiteを再構築するというベンチマーク・タスクにおいて、新しい「planner-worker」スウォーム・アーキテクチャは、すべてのモデル構成において以前のイテレーションを上回り、一部の設定ではsqllogictestスイートで100%の合格率を達成しました。

The Planner-Worker Architecture

大規模な技術的タスクは、ルートとなる目標が基本的な作業単位へと再帰的に細分化されるツリー構造として構成されます。スウォームは、この構造を管理するために2つの異なる役割を利用します：

• Planner Agents: Frontier modelsによって駆動されるこれらのエージェントは、目標を断片化し、自身で実装を行うことなくそれらを委譲します。
• Worker Agents: より高速で安価なモデルによって駆動されるこれらのエージェントは、委譲された特定のタスクを実行します。

この分離により、詳細に集中するあまりグローバルな目標を見失う、あるいは全体像を維持しようとして実装が不十分になるという、単一エージェント・システムにおける一般的な失敗モードである「context drift（コンテキスト・ドリフト）」を防ぐことができます。役割を分離することで、plannerはコンテキストを低レベルのノイズから解放し、workerはコンテキスト・ウィンドウ全体を狭い作業範囲に充てることができます。

Solving Coordination at Scale

数百の同時実行エージェントへのスケーリングは、人間のエンジニアリング・チームでは通常見られない失敗モードをもたらします。毎秒1,000コミットのピークスループットを処理するために、Cursorは特定の調整メカニズムを実装するためにカスタムのバージョン管理システム（VCS）を開発しました：

Managing Design and Conflict

• Split-Brain Design: 2つのplannerが同じコンセプトを異なる方法で実装することを防ぐため、plannerは設計決定を中央集権的に行い、委譲されたサブツリーが同じ問題に対処しないように促されます。
• Planner Contention: Planner同士が意見を異にする場合、決定事項を共有の設計ドキュメントに記録します。コードはコンパイルチェックされた参照を介してこれらのドキュメントに依存します。reconcilerがドキュメントをマージして、解決策を下流へ伝播させます。
• Merge Conflicts: 中立的な第三者エージェントが、マージ・キューと同様に、workerエージェント間の衝突を解決するための公平な調停役として機能します。
• Megafiles: ファイルが肥大化してシステムを圧迫するのを防ぐため、workerエージェントは肥大化したファイルをフラグ立てし、外部エージェントがそのファイルをより小さなモジュールへと分解するようトリガーします。
• Ossification: エージェントがコア・コードの変更を避けるようになるのを防ぐため、システムは「意図的な破壊をライセンス化」します。エージェントはコア・コードをパッチし、推論論理をコメントとして残すことができます。その後、コンパイラがすべての依存するエージェントに対し、新しい設計に合わせるよう作業の更新を強制します。

Model Economics: Frontier Planning vs. Efficient Execution

実験データは、frontier-levelの知能は、コーディングそのものよりも、高レベルの調整、設計決定、および曖昧さの解消に主に必要とされることを示しています。これにより、ハイブリッド・モデル・ミックスを使用することで、大幅なコスト削減が可能になります。

Cost Comparison of Model Mixes

In the SQLite experimentにおいて、異なる構成が同等の品質の結果をもたらしましたが、コストは大きく異なりました：

| Model Mix | Role Distribution | Relative Cost | | :--- | :--- | :--- | :--- | | GPT-5.5 | Planner & Worker | Highest ($10,565) | | Opus 4.8 / Composer 2.5 | Planner / Worker | Lowest ($1,339) |

Workerはトークンの大部分（しばしば90%以上）を占めますが、コストはplannerによって駆動されます。Opus 4.8/Composer 2.5のハイブリッド構成では、plannerは少数のトークンを生成しましたが、コストの3分の2を占め、一方でworkerフリートは、総支出の3分の1のみで作業の大部分を処理しました。

Results of the SQLite Experiment

スウォームを検証するため、Cursorは、元のソースコードやインターネットにアクセスせずに、835ページのSQLite manualをRustで実装するようスウォームに指示しました。

Performance Gains

旧来のスウォーム・ハーネスを使用してGrok 4.5を用いた新しい構成と比較すると、効率性に顕著な差が現れました：

• Commit Volume: 旧来のスウォームは2時間で68,000コミットを生成しましたが（主に「busywork」またはchurn）、新しいスウォームは大幅にターゲットを絞っていました。

• Merge Conflicts: 旧来の実行では70,000件以上の衝突が発生しましたが、新しい実行では4時間で1,000件未満に抑えられました。

• Code Efficiency: Fable 5 mixにおいて、新しいスウォームは、旧来のスウォームが同じ結果を得るために使用した64,305行のエンジン・コードに対し、9,908行のエンジン・コードを使用してタスクを完了しました。

Community Perspectives and Critiques

技術的な同僚たちの間での議論は、この手法の潜在能力と限界の両方を浮き彫りにしています：

"I think the concept of integrating is the real challenge. Re-writing code in new languages based on decent docs is a difficult but less useful measure of how AI can help replace engineers."

批判的な意見として、SQLiteのソースコードや様々なRust rewrites（Tursoのものなど）がモデルの学習データに存在している可能性があり、実験が純粋な推論ではなく記憶に基づいている可能性があることが指摘されています。また、調整メカニズム（coordination harness）は素晴らしいものの、エージェント・スウォームが既存のソフトウェアを再構築することではなく、完全にユニークなものを作り上げる能力は、依然として主要な課題として残っています。