エージェントのスワームと新しいモデル経済学

ブログ / リサーチ 今年初め、私たちは目標達成のためにエージェントをスケーリングして協力させる限界をテストする実験を行いました。このアプローチが、新しいレベルのタスクスケールと複雑さを解き放つだろうというのが私たちの仮説でした。フラッグシッププロジェクトは、Webブラウザを一から構築する長期的なスワームでした。概念実証としては成功しましたが、洗練されたソフトウェアには程遠いものでした。その作業は意図的に経験的なものでした。私たちは白紙の状態から始め、安定した効果的なシステムに向かってヒルクライムを行いました。それ以来、私たちの目標は、エージェントスワームを意図的にエンジニアリングできるほど十分に理解することでした。その進捗をテストするために、古いスワームが苦労していたタスク、つまりドキュメントのみを頼りにRustでSQLiteを一から構築するというタスクに戻りました。私たちの初期の結果は有望です。古いスワームと新しいスワームを同じタスク、同じモデル、同じ時間予算で実行し、それぞれがどれだけホールドアウトされたSQLテストスイートをパスできるかを測定しました。新しいスワームは、すべてのモデル構成でより良い結果を出しました。Grok 4.5を使用すると、4時間で80％に達しましたが、古いスワームはスパイラルし、2時間以内に一時停止する必要がありました。また、どのモデルがどのジョブを実行したかも変更しました。一部の実行では1つのモデルがすべてを処理しましたが、他の実行ではフロンティアモデルが計画し、高速で安価なモデルが作業を実行しました。どの組み合わせでも同程度の品質が得られましたが、コストは大きく異なりました。 1 #木と葉 大規模タスクの説明は、自然に木のような形をとります。ルートに目標があり、それが基本的な作業単位に再帰的に細分化されます。私たちのスワームには2つの役割があり、どちらも同じツリー状の分解を中心に組織化されています。プランナーエージェントは、最も賢いモデルによって駆動され、目標を分割して委任します。ワーカーエージェントは、一般的に高速で安価なモデルによって駆動され、それらの部分を実行します。この設計は、より厳格なオーケストレーションシステムのスーパーセットです。問題に固定されたトポロジーを課すのではなく、スワームの形状は問題の輪郭をカバーするように成長し、計算とコンテキストはタスクの複雑さに比例してスケーリングします。これが、この設計がブラウザ構築、数学的問題解決、GPUカーネル最適化など、多様なタスクに一般化する理由だと考えています。内部的には、オープンソースソフトウェアの脆弱性の発見と修正、自社コードベースのテストカバレッジの向上、数十億トークンの合成トレーニングデータの生成にも使用しています。 #木がメモリのためにすること 単一のエージェントが完全なタスクを引き受ける場合、それはツリー全体を自分で歩く必要があり、祖先、現在の位置、そしてより広い目標を常にコンテキストに保持しながら、各リーフに下降します。これが、長期間実行される単一エージェントがドリフトする理由だと考えています。彼らは、目の前の仕事に集中して全体像を見失うか、全体像を保持して目の前の仕事の質を低下させるかのどちらかです。スワームでは、プランナーは決して実装しないため、コンテキストが低レベルの詳細で満たされることはなく、ワーカーは計画しないため、コンテキスト全体を1つの狭い作業部分に費やすことができます。エージェントスワームをスケーリングできる能力は、並列性自体よりも、このコンテキスト効率から来ると推測しています。その効率は、あらゆるスケールでスワームに存在するため、この分解は中程度のサイズのタスクでもエージェントのパフォーマンスに役立ちます。この構造の響きは他の場所にもあります。経済学者のロナルド・コースは、企業がなぜ存在するのかを問い、調整コストは作業自体よりも速く増加するため、組織は全員が全員と話すことを許すのではなく、境界のある単位の階層に落ち着くと主張しました。 #エージェントのためのバージョン管理システム 以前のスワームに関する投稿で、GitやCargoのようなツールは並行制御のために粗いロックに依存していると述べました。これは開発者1人には問題ありませんが、数百のエージェントが生成する作業量には対応できません。今年の初めのブラウザスワームは、Gitで毎時約1,000コミットにピークを迎えました。新しいシステムは、毎秒約1,000コミットにピークを迎えます。このレートの活動を促進するために、私たちはバージョン管理システム（VCS）を一から構築しました。スループットだけがこのレイヤーを所有する理由ではありませんでした。システム内のすべての変更はVCSを通過するため、衝突が最初に可視化される場所であり、次のセクションのいくつかの調整メカニズムは直接そこに実装されています。 #毎秒1,000コミットでの障害モード 人間のエンジニアリングチームには、コードレビュー、オーナーシップ、スタンドアップ、マージキューなどの標準的な調整メカニズムがあります。これらのシステムは人間のテンポで機能しますが、スワームのコミットレートでは、人間のチームが日常的に遭遇しない障害モードが見られます。 #スプリットブレイン設計 互いを認識していない2つのプランナーが、コードベースの異なる部分で異なる方法で同じ概念を実装します。私たちはこれをプロンプトで修正しました。プランナーは委任するのではなく、自分で設計上の決定を行い、委任されたサブツリーのいずれも同じ質問を決定しないことを保証する必要があります。 #プランナー間の競合 より困難な形態の競合は、2つのプランナーがお互いを認識しており、同じファイルに対してバックツーバックの変更を通じて戦う場合です。問題は現実の2つの画像であり、マージツールでは不一致を修正できません。代わりに、エージェントは共有設計ドキュメントに決定を記録させます。決定に依存するコードは、そのドキュメントへのコンパイルチェック済み参照を保持します。プランナーが無意識のうちに互いに矛盾する場合、レコンサイラーがドキュメントをマージし、参照が下流に解決を伝播します。 #マージコンフリクト スワーム内では、エージェントは同じファイルで絶えず衝突します。衝突を解決するために、彼らは停止し、他のエージェントのコンテキストを吸収し、それを回避してマージする必要があります。ワーカーエージェントはこれに弱く、実際には、他の変更を上書きするか、自身の変更を放棄します。これを修正するために、中立的な第三者エージェントがマージコンフリクトに介入し、すべての当事者に代わってそれらを解決するシステムを作成しました。その唯一の目標は、エンジニアリングチームのマージキューのように、公平かつ効率的であることです。 #メガファイル 一部のファイルは、エージェントが作業するのに特に人気のある場所です。各エージェントは少量しかコードを追加しない可能性があり、単一のエージェントがファイルを小さく保つ責任を負うわけではありません。これらの「メガファイル」はすべてを詰まらせます。転送、差分、マージにコストがかかり、絶え間ない衝突の場所になります。これを修正するために、ワーカーエージェントに肥大化したファイルをフラグ付けする方法を与えました。フラグ付けされると、新しいコミットがブロックされ、外部エージェントが肥大化したファイルをより小さなモジュールに分解します。 #骨化 エージェントは、人間が関与する既存のコードベースで作業することから、変更が必要な場合でもコアコードに触れないことを学習しました。これを修正するために、意図的な破壊にライセンスを与えます。コアの変更が価値があると判断したエージェントは、その範囲外に集中したパッチを作成し、その理由を説明するコメントを残すことができます。コンパイラは変更をシステム全体に伝播し、古い設計に依存するすべてがビルドに失敗します。これらのエラーのいずれかに遭遇した各エージェントは、コメントを見つけ、理由を読み、自身の作業部分を一致するように更新します。 #レビューレンズ 長期実行かつマルチエージェントのシステムでは、エラーが蓄積するため、スワームは小さな間違いが基盤となる前に自己修正する方法が必要です。ワーカーの完全なトランスクリプト、またはその出力のみ、あるいはコードベース以外の何もレビューエージェントに与えるなど、多くの種類のレビューレンズを試しました。異なるモデルで実行され、異なるトレーニングと異なるパーソナリティを持つレビューアも試しました。単一のレンズですべてをキャッチできるわけではありませんが、自己運転システムが単一の完璧なコンポーネントなしで人間以上の信頼性に達するのと同じように、相関の少ないレンズはスタックします。レビューに費やされた計算は、レビューが監査する作業よりもはるかに安価であるため、高いリターンがあります。このスタックレビューシステムが、実行の持続的な品質に大きく貢献したと推測しています。 #エージェントに環境を形成させる スティグメルギーは、アリやシロアリのようなスワーム生物が直接的なコミュニケーションなしに調整するメカニズムです。