dispatching-parallel-agents

並列エージェントへのタスク割り当て

目的

独立性が十分に見込め、並行実行によるメリットが調整コストを上回る場合に限り、2 つ以上のアドホックで範囲が限定されたタスクに並列の子エージェントを使います。 並列化によって短縮できるのは所要時間です。証拠、オーナーシップ、完了要件が緩和されるわけではありません。

割り当ての判断基準

以下の条件をすべて満たす場合にのみ割り当てます。

• 個別のタスクまたは調査すべき事項が 2+ 件ある。
• あるタスクの結果が別のタスクの定義や開始に必要ない。
• タスク間で書き込みが重複せず、同じ可変リソースも必要としない。
• 現時点の証拠から、共通の根本原因がある可能性は低い。
• 各タスクについて、証拠と未解決の不明点を限定した形で報告できる。
• 利用可能な並列実行数と予想される作業量が、調整コストに見合う。

作業の分割がまだ探索段階の場合、複数の失敗が共通の根本原因を持つ可能性がある場合、システム全体のコンテキストが必要な場合、または引き継ぎに見合うほどの作業量がない場合は、並列化せずに進めます。文書化された実装計画に基づく場合は、このアドホックなワークフローではなく、 aegis:subagent-driven-development に割り当てます。

コンテキストとオーナーシップ

実行中のホストにおけるコンテキスト継承モードを意図的に選択します。各子エージェントには、必要十分な指示と証拠のみを渡します。意図せずコンテキストが継承されることを当てにしたり、コンテキストを決して継承すべきでないと決めつけたりしないでください。

各タスクの指示には、以下を含めます。

• 解決すべき目標と問い。
• 使用を許可されたファイル、システム、副作用。
• 判明している事実と証拠の場所。
• 制約、対象外の事項、停止条件。
• 未解決の不明点と検証用参照を含む、期待する結果の形式。

モデルのコンテキストが分離されていても、ファイルシステム、プロセス、Git リポジトリ、認証情報、レート制限、外部サービスが分離されているとは限りません。読み取り専用の調査を優先します。子エージェントが編集する可能性がある場合は、書き込みの担当範囲を明確に分けます。ステージング、コミット、ブランチ、ワークツリー、その他の Git ライフサイクル上の変更は、コーディネーターが担当します。

実行

1. タスクを分割するために必要な最小限の共通ベースラインを確立し、証拠を記録します。
2. ホストの並列実行数の上限内で、独立した領域ごとに範囲を限定したタスクを 1 件ずつ割り当てます。
3. 子エージェントの読み取りや書き込みと競合しない作業は、コーディネーターが任意で続行できます。
4. 結果が返されたら、証拠の鮮度、未解決の不明点、前提の重複、ワークスペースに見られる変更を確認します。
5. 行動する前に、見解の相違を整理します。結果から相互依存が判明した場合は、並列での変更を中止し、作業を単一の担当者に戻します。
6. 編集の場合は、変更を取り込んだ後に統合検証を実行します。読み取り専用の作業の場合は、引用された情報源に照らして、統合した内容を検証します。

並列実行数の管理はコーディネーターが担当します。タスクの指示で明示的に許可されていない限り、子エージェントは再帰的にタスクを委譲しません。子エージェントが失敗、キャンセル、またはタイムアウトした場合は、利用できる部分的な証拠があればその内容を反映します。利用可能な証拠がない場合は、結果なしとして記録し、未解決の不明点も記載します。再試行する場合は、タスクの指示を実質的に変更するか、タスクを直列化します。

子エージェントの出力は証拠または提案であり、GateDecision や完了を決定する権限ではなく、外部アクションの許可でもありません。

よくある失敗

• ファイルが別々であることを、根本原因も別である証拠として扱う。
• 範囲を限定したコンテキストではなく、広範な会話履歴を子エージェントに渡す。
• 複数の子エージェントが同じ担当領域を編集したり、共有サービスを同時に変更したりする。
• 証拠や現行のファイルを確認せず、子エージェントの報告を受け入れる。
• 文書化された計画のために並列作業を使い、そのレビュー段階を回避する。
• コーディネーターが個々の結果だけを検証し、統合後の状態を一度も確認しない。

これらのいずれかが見られた場合は、タスクの指示を絞り、共有部分を直列化するか、担当するデバッグまたは計画のワークフローに戻します。