Planner-Worker モデルは、多数の AI コーディングエージェントを、協調のない群れとして動かすのではなく、特化した階層的な役割を与えることで一度に協調させるためのパターンである。Planner エージェントはプロジェクトマネージャーのように振る舞い、コードベースを読み、何をする必要があるかを決め、タスクを生成する。サブタスクを再帰的に作成することもある。その後 Worker エージェントが、プロジェクトのより広い全体像を追う必要なしに、それらのタスクを実装する。イテレーションの終わりには、Judge エージェントが全体の目標が達成されたかどうかを評価する。
用法
このパターンは、Cursor のエンジニアリング上の実験（Wilson Lin の功績とされる）に由来するとされている。この実験は、それ以前のよりフラットなアプローチ、すなわち多数のエージェントが共有のファイルロックの仕組みを通じて協調するやり方の後に行われた。そのやり方では、エージェントが互いを待って行き詰まったり、過度にリスクを避けるようになったりした。誰もが好きに動けるシステムでは、作業の難しい部分に責任を感じるエージェントが 1 つもいなかったからである。階層型のバージョンは、Web ブラウザの構築に取り組む数百のエージェントが協働する規模にまでスケールし、1 週間で 1,000 を超えるファイルにわたって 100 万行を超えるコードを生み出したと報告されている。
Cursor 自身の投稿「Scaling long-running autonomous coding」に基づく別の説明は、同じ 3 つの役割から成る形を、単一の実験ではなく明示的な段階的発展の結果として描いている。最初の設計である、対等な立場のエージェントがロックを使って共有ファイルに書き込むフラットな協調モデルは、ボトルネックとなり、エージェントをリスク回避的にした。2 番目の設計ではロックを楽観的並行性制御に置き換えたが、これはボトルネックを取り除いたものの協調の問題は解決しなかった。そして 3 番目の設計が、現在本番で動いているものとして説明されている Planner/Worker/Judge の分割であり、Planner は再帰的にサブプランナーを生成でき、Judge はイテレーションがいつ終わったか、いつ再開すべきかを判断する。その投稿は、ハーネスやモデル以上に「システムの振る舞いの驚くほど多くの部分が、エージェントにどうプロンプトを与えるかにかかっている」と述べていると引用されている。また、長時間にわたる自律的な作業に限っては GPT のモデルが Opus を上回ったと報告しているとも引用されている。Opus には早々に止まって手抜きをする傾向があったためであり、同じタスクでも役割が違えば別のモデルが求められるということである。
適用される場面
このパターンが適用されるのは、同じコードベース上で少数を超えるエージェントを同時に動かす規模へとスケールさせる場面であり、そこでは素朴な並列化が協調上の衝突（2 つのエージェントが同じタスクを取得する、あるエージェントの変更が別のエージェントの作業を壊す）を引き起こす。このパターンは、プランナーが推論できる階層へと実際に分解できるコードベースとタスクの集合を前提としている。出典は、この規模はまだ日常的な開発では一般的ではなく、ほとんどのユーザーにとっては、大規模な群れを管理するよりも、1 つの有能な長時間稼働エージェントをより深く使い込むほうが実用的な場合が多いと述べている。このパターンは Cursor のバックグラウンドのクラウドエージェントと組み合わされる。そこでは各エージェントが Git ワークツリー によって独自の隔離された作業コピーの中で動作し、その結果をプルリクエストによってマージして戻す（Cursor を参照）。