1つのリポジトリで複数のAIエージェント
書き込みが調停されていれば、複数のエージェントは1つのリポジトリを共有できます。エージェントは触れるパスを宣言し、サーバーはそれを割り当て、解放されるまで他の全員に対して拒否します。この調停がなければ、2番目のエージェントは何の告知もなく最初のエージェントの作業を消してしまいます。
すべてを壊すケース
2つのエージェントが同じファイルに触れる2つのタスクを受け取ります。最初のエージェントがファイル を読み、20秒考え、書き込みます。2番目のエージェントは最初が書き込む前に同じバージョンを読んで おり、それを上書きしてしまいます。何もクラッシュせず、何も警告せず、最初の作業は消えました。
この状況は1つ以上のエージェントがいれば珍しくありません。エージェントは広く読み、速く書くから です。ほとんどのツールが隔離している理由がここにあります。エージェントごとに1台のマシン、エージェ ントごとに1つのブランチです。
他の世界がやっていること: エージェントごとにworktree
この問題への一般的な答えは分割です。各エージェントに独自のgit worktree、独自のインデックスを 持つファイルの完全なコピーを与え、範囲が重ならないように調整します。Windsurf、Conductor、 OpenHandsがやっていることで、ほとんどのガイドが推奨する方法です。
これは機能し、欠点はちょうど1つです。分割は約束であって保証ではありません。範囲が重ならない ことを誰も検証しておらず、重なったときにそれがわかるのはマージのとき、つまり両方のエージェント が終わり、もう誰も理由を覚えていないときです。
確保、3つの段階で
書き込む前に、エージェントは触れるパスを宣言します。ボードは空いていればそれを割り当て、保持 されていれば拒否します。常に1つのファイルにつき所有者は1人だけです。
作業中、監視役はディスクへの実際の書き込みを見張り、それぞれをその作成者に紐づけます。他の 誰かが保持しているパスへの書き込みは反映される前にスナップショットされます。前のバージョンは 保持されるため、ルールが回避されても何も失われません。
最後に、エージェントはパスを解放します。ファイルは次のエージェントのために利用可能になり、 マージは不要です。生きているバージョンが2つ同時に存在したことは一度もないからです。
画面に映るもの
各ウィンドウは作業中のエージェントを映し、ボードは誰が何を持っているかを示します。エージェント が待っていること、そしてその理由が見えます。行き詰まったエージェントは被害が出る前に見えます。 これが見えないキューとの本当の違いです。
人も数に入ります。同じキャンバス上の複数の人が、それぞれ自分のエージェントを操作し、名前付き の他人のカーソルを見ます。
この形が適さないとき
タスクが本当に独立していて長時間かかるなら、マシンごとの隔離は依然として合理的です。調停する ものも待つものもありません。共有が勝るのはタスクが触れ合うときで、同じ機能に取り組んでいれば 必ずそうなります。比較ページではツールごとの選択を詳しく説明しています。
率直な答え
複数のエージェントを動かすにはgit worktreeを使うべきですか?
ほとんどのガイドが出す答えで、実際に機能します。エージェントごとに独自のインデックスとファイルを持つworktreeがあれば、衝突は起こり得ません。ただし常に同じコストがかかります。エージェントの数だけコピーがあり、最後にコピーごとに1回のマージが必要です。ファイル確保付きの単一ディレクトリはその両方をなくし、代わりにエージェントが時々30秒ほど待つだけです。
エージェントごとにブランチを与えないのはなぜですか?
よくある解決策ですが、コストを最後に移すだけです。3つのブランチは3回のマージを生み、競合は3つのエージェントすべてが終わったとき、つまり誰も理由を覚えていない瞬間に現れます。共有ディレクトリは競合が発生した瞬間にそれを解決します。
エージェントが確保を無視したらどうなりますか?
選択の余地はありません。ルールはモデルに提案されるのではなく、サーバーが強制します。監視役が書き込みを見張り、それぞれをその作成者に紐づけます。他の誰かが保持しているパスへの書き込みは、反映される前にスナップショットが取られるため、両方のバージョンがまだ存在します。
同時に何エージェントまでですか?
Proプランで5つのエージェントウィンドウ、それ以上のプランではさらに多くなります。実際の制約はマシンではなく、その瞬間にプロジェクトが抱えている独立した作業の数です。