Multi-agent

並列スペシャリストレーン

Status: active

並列の専門レーンを使うと、1 つの Gateway でユーザー体験の速さを維持しながら、チャットやルームごとに異なるエージェントへルーティングできます。並列処理は単なる「エージェントの追加」ではなく、希少なリソースを扱う設計上の問題として捉えてください。

基本原則

専門レーンによってスループットが向上するのは、実際のボトルネックに対する競合が減る場合に限られます。

セッションロック：特定のセッションを同時に変更する実行は 1 つだけにする必要があります。
グローバルなモデル容量：ユーザーに表示されるすべてのチャット実行は、引き続きプロバイダーの制限を共有します。
ツール容量：シェル、ブラウザー、ネットワーク、リポジトリでの作業は、モデルのターン自体よりも遅くなることがあります。
コンテキスト予算：長いトランスクリプトは、以後のすべてのターンを遅くし、焦点をぼやけさせます。
所有権の曖昧さ：複数のエージェントが同じ作業を重複して行うと、容量が無駄になります。

OpenClaw はすでにセッションごとに実行を直列化し、コマンドキューによって全体の並列処理数を制限しています。専門レーンはその上に、どのエージェントがどの作業を担当するか、何をチャット内に残すか、何をバックグラウンド作業にするかというポリシーを追加します。

推奨される導入手順

フェーズ 1：レーンの契約と負荷の高いバックグラウンド作業

各レーンのワークスペースとシステムプロンプトに、次の契約を明記します。

目的：このレーンが担当する作業。
対象外：このレーンでは試みず、引き渡すべき作業。
チャット予算：簡単な回答はチャット内で行います。長いタスクには簡潔に応答してから、バックグラウンドのサブエージェントまたはタスクで実行します。
引き渡しルール：別のレーンが作業を担当する場合は、引き渡し先を示し、簡潔な引き渡し要約を提供します。
ツールリスクのルール：作業を実行できる最小限のツール範囲を優先します。

これは最も低コストなフェーズであり、ほとんどの詰まりを解消します。1 つのコーディング作業によって調査レーンが極端に遅くなることがなくなり、各チャットのコンテキストを整理された状態に保てます。

フェーズ 2：優先度と並行処理の制御

各レーンのビジネス価値に合わせて、キューとモデルの容量を調整します。

json5

{  agents: {    defaults: {      maxConcurrent: 4,      subagents: { maxConcurrent: 8, delegationMode: "prefer" },    },  },  messages: {    queue: {      mode: "collect",      debounceMs: 1000,      cap: 20,      drop: "summarize",    },  },}

ダイレクトチャットや個人チャット、および本番運用エージェントは、優先度の高い作業に使用します。システムが混雑しているときは、調査、下書き、バッチコーディングをバックグラウンドタスクに移します。

フェーズ 3：コーディネーター／トラフィックコントローラー

複数のレーンが稼働するようになったら、小規模なコーディネーターパターンを追加します。

進行中のレーンタスクと担当者を追跡します。
グループ間で重複するリクエストを検出します。
レーン間で引き渡し要約をルーティングします。
ブロッカー、完了した結果、および人間による判断が必要な事項だけを提示します。

ここから始めないでください。レーンの契約がないコーディネーターは、混乱を調整するだけです。

最小限のレーン契約テンプレート

# レーン契約 ## 担当範囲 - <job this lane is responsible for> ## 担当範囲外 - <work to hand off> ## チャット予算 - 簡単な質問には直接回答します。- 複数ステップの作業、時間のかかる作業、またはツールを多用する作業の場合：簡潔に応答し、作業をサブエージェントとして生成するかバックグラウンドで実行して、完了後に結果を返します。 ## 引き渡し 別のレーンがリクエストを担当する場合は、次の内容を返信します。 - 対象レーン- 目的- 関連するコンテキスト- 次に行う具体的なアクション ## ツールの使用方針 タスクを完了できる最小限のツール範囲を使用します。このレーンが明示的に担当している場合を除き、広範なシェル操作やネットワーク作業は避けます。