エージェント・スウォームと新しいモデル経済学 · Cursor

今年初め、Cursorチームはエージェントの大規模な群れが協力して目標を達成する能力をテストする一連の実験を実施しました。彼らの仮説は、この協調によってタスクの規模と複雑さの新たな段階が開かれるというものでした。旗艦プロジェクトは、ウェブブラウザをゼロから構築する長期実行スウォームでした。概念実証としては成功しましたが、洗練されたソフトウェアにはほど遠いものでした。

この作業は意図的に経験的でした。白紙のキャンバスから始め、安定した効果的なシステムに向けて山登りを続けました。それ以来、私たちの目標はエージェントスウォームを十分に理解し、意図的に設計できるようにすることでした。その進捗をテストするために、古いスウォームが苦戦したタスクであるSQLiteを、Rustで、ドキュメントだけを頼りにゼロから構築することに戻りました。

初期の結果は有望です。同じタスク、同じモデル、同じ時間予算で新旧のスウォームを実行し、それぞれが保持されたSQLテストスイートのどれだけをパスできるかを測定しました。新しいスウォームはすべてのモデル構成で優れていました。Grok 4.5を使用した場合、4時間で80%に達したのに対し、古いスウォームはスパイラルに陥り、2時間目に入る前に一時停止せざるを得ませんでした。

また、どのモデルがどの仕事をするかも変えました。一部の実行では1つのモデルがすべてを処理し、他の実行ではフロンティアモデルが計画を立て、高速で安価なモデルが作業を実行しました。すべての組み合わせで同様の品質が得られましたが、コストは大きく異なりました。

大規模タスクの記述は自然と木の形を取り、根にある目標が再帰的に基本的な作業単位に分割されます。私たちのスウォームには2つの役割があり、どちらも同じ木構造の分解を中心に組織されています。プランナーエージェントは最もスマートなモデルによって駆動され、目標を分割して委任します。ワーカーエージェントは一般に高速で安価なモデルによって駆動され、それらの断片を実行します。

この設計は、より rigid なオーケストレーションシステムのスーパーセットです。問題に固定トポロジを課すのではなく、スウォームの形状は問題の輪郭をカバーするように成長し、コンピューティングとコンテキストはタスクの複雑さに比例して拡大します。

これが、ブラウザの構築、数学問題の解決、GPUカーネルの最適化など、多様なタスクに設計が一般化する理由だと考えています。また、内部ではオープンソースソフトウェアの脆弱性の発見と修正、自社コードベースのテストカバレッジの向上、および合成トレーニングデータの数十億トークンの生成にも使用しています。

単一エージェントが完全なタスクを引き受ける場合、エージェントは木全体を自分で歩かなければならず、祖先、現在位置、および広範な目標をコンテキストに保持しながら各葉に降りていきます。これが、長期実行の単一エージェントがドリフトする理由を説明していると考えています。目の前の作業に集中して大局を見失うか、大局を保持してその部分でより悪い仕事をするかのどちらかです。

スウォームでは、プランナーは決して実装しないため、そのコンテキストが低レベルの詳細で満たされることはなく、ワーカーは決して計画しないため、そのコンテキストすべてを1つの狭い作業に費やすことができます。

エージェントスウォームをスケールできる能力は、並列性そのものよりも、このコンテキスト効率から来ていると考えています。この効率はあらゆる規模のスウォームに存在するため、この分解は中程度のサイズのタスクでもエージェントのパフォーマンスを向上させます。

この構造の類似物は経済学者ロナルド・コースの企業理論に見られます。彼は、調整コストが作業自体よりも速く成長するため、組織は全員が全員と話すのではなく、境界のあるユニットの階層に落ち着くと論じました。

スウォームの高いコミットレート（旧スウォームは最大約1,000 commits/hour、新システムは約1,000 commits/秒）に対応するため、チームはカスタムバージョン管理システム（VCS）をゼロから構築しました。スループットだけが理由ではなく、すべての変更がVCSを通過するため、衝突が最初に可視化され、次のセクションのいくつかの調整メカニズムがVCS内で直接実装されています。

人間のエンジニアリングチームでは、コードレビュー、所有権、スタンドアップ、マージキューが標準的な調整メカニズムです。しかし、スウォームのコミットレートでは、人間のチームが日常的に遭遇しない障害モードが発生します。例えば、スプリットブレイン設計：互いに気づかない2つのプランナーが、コードベースの異なる部分で同じ概念を異なる方法で実装します。チームはプロンプトを通じてこれを修正しました。プランナーは自分で設計決定を行い、委任されたサブツリーが同じ問題を決定しないようにします。

プランナー間の競合はより困難な形態です。2つのプランナーが互いの存在を知り、同じファイルに対する変更の応酬を繰り返します。チームは、エージェントが共有設計ドキュメントに決定を記録することで解決しました。決定に依存するコードは、そのドキュメントへのコンパイル時チェック付き参照を保持します。プランナーが無意識に矛盾した場合、調整者がドキュメントをマージし、参照が解決を下流に伝播します。

マージ競合はスウォーム内で頻繁に発生します。競合を解決するには、エージェントが停止し、相手のコンテキストを吸収してマージする必要があります。ワーカーエージェントはこれを苦手とし、実際には相手の変更を上書きするか、自分の変更を放棄します。これを修正するために、チームは中立的な第三者エージェントがマージ競合に介入し、すべての当事者に代わって解決するシステムを作成しました。その唯一の目標は公平で効率的であることで、人間のチームでのマージキューのように機能します。

一部のファイルはエージェントが作業するのに特に人気のある場所です。各エージェントが少量のコードを追加するだけかもしれませんが、誰もファイルを小さく保つ責任を持ちません。これらの「メガファイル」はすべてを窒息させます。転送、差分、マージにコストがかかり、絶え間ない競合の場になります。

これを修正するために、チームはワーカーエージェントに肥大化したファイルをフラグする方法を与えました。フラグが立てられると、新しいコミットをブロックし、外部エージェントが過成長したファイルをより小さなモジュールに分解します。

さらに、エージェントは人間が関与する既存コードベースでの作業から、変更が必要な場合でもコアコードに触れないことを学習していました。チームは意図的な破壊を許可することでこれを修正しました。コア変更が価値があると判断したエージェントは、スコープ外の焦点を絞ったパッチを作成し、理由を説明するコメントを残すことができます。コンパイラが変更をシステム全体に伝播し、古い設計に依存するものはすべてビルドに失敗します。そのエラーのそれぞれに遭遇したエージェントは、コメントを見つけ、理由を読み、自分の作業を一致するように更新します。

長期実行かつマルチエージェントのシステムでは、エラーが蓄積され、小さな間違いが基盤となる前に修正するメカニズムが必要です。チームは、ワーカーの完全なトランスクリプト、出力のみ、またはコードベースのみなど、多くの種類のレビューレンズを試しました。単一のレンズですべてを捉えることはできませんが、非相関のレンズは積み重なり、自動運転システムが単一の完璧なコンポーネントなしで人間を超える信頼性に達するのと同様です。レビューに費やされるコンピューティングは高いリターンをもたらします。レビューは監査する作業よりもはるかに安価だからです。この積み重ねられたレビューシステムが、実行の持続的な品質に大きく貢献したと考えています。

Stigmergyは、アリやシロアリなどの群生生物が直接通信せずに調整するメカニズムです。彼らは環境を形成し、環境が次の生物を形成します。チームは以前の実行で「メモを取る」や「決定を文書化する」などのルールをエンコードしていましたが、それらは明らかに良いと思われたからです。振り返ると、それらはエージェントが将来の自分やチームメイトのために知識を制度化することを可能にしていました。

チームはこれをさらに押し進め、フィールドガイドと呼ぶ自己作成の共有コンテキストの実験を行いました。これはエージェントが完全に所有するフォルダで、そのindex.mdが各エージェントの起動時に自動的に注入されます。ガイドに何を入れるかはエージェントの仕事であり、唯一の制約は行予算です。

ガイドの背後にある論理は、モデルの重みが固定されているため、まさに驚きの遭遇を捉えて次のエージェントの軌跡を短くすることが価値があるということです。

フィールドガイドは有望な結果をもたらした初期の実験です。チームは、エージェントが完全に所有していないコードベースでは、その利益がさらに大きくなると予想しています。後継者のために書くようにモデルを訓練し、より良いキャプチャがより良い報酬につながるようにすることは、興味深いフォローアップ研究領域です。

最終的なSQLite実験では、新しいバージョンのスウォームに上記のすべての改善を装備し、835ページのSQLiteマニュアル全体をRustで実装するよう指示しました。ソースコード、テストスイート、SQLiteバイナリ、インターネットアクセスを遮断しました。進捗を測定するために、sqllogictest（さまざまなデータベースエンジンが同じクエリに対して同じ結果を返すかどうかを確認するためにSQLiteプロジェクトで構築されたテストスイート）に対して評価しました。数百万の既知の正解を持つクエリが含まれており、スコアはスウォームのデータベースが正しく取得した割合です。

スウォームはスイートの存在を知らされませんでした。各実行後、チームは手動でコードと実行自体をレビューし、不正や近道をチェックし、システムがテストが見る場所だけでなく均等に構築されていることを確認しました。

チームは4つの構成をテストしました：GPT-5.5をプランナー兼ワーカーとして、Grok 4.5を両方として、Opus 4.8をプランナー、Composer 2.5をワーカーとして、Fable 5をプランナー、Composer 2.5をワーカーとして。新しいフレームワークはすべての混合で古いものを上回りました。Fable 5の混合は最初の1時間でスイートの約3分の2をパスしました。4時間のカットオフまでに、新しい実行は73%から85%の間にあり、古い実行は11%から77%の範囲でした。古いGrok 4.5の実行は2時間前に一時停止されました。すべての新しい構成は最終的にスイートの100%をパスしました。

活動率の単純な尺度から、古い実行は最初の2時間で68,000コミットを生成し、新しい実行のペースの約70倍でした。しかし、そのほとんどは忙しい作業（スラッシュ、コンテンション、チャーン）でした。古い実行は一時停止前に70,000以上の競合を蓄積していました。新しい実行は安定した効率的な進歩を示しました。