Wooldridge マルチエージェントシステム は何をしますか？
このスキルは、「複数のモデルをどう会話させるか」ではなく、「この環境がどんな種類の自律システムを構築することを強制するのか」という問いがある場合に使用します。
使用すべき場合
- リアクティブ、熟考的、またはハイブリッドエージェントアーキテクチャのいずれかを選択する必要がある。
- 誰も完全な情報や議論の余地のない制御を持っていないために、調整が失敗し続けている。
- エージェントが不確実性の下で交渉、割り当て、またはコミットメント戦略を必要とする。
- 設計が、エージェントが何を知っているか、全員が何を知っているか、あるいは共通知識がそもそも達成可能かどうかに依存している。
- 「マルチエージェント」設計が実際には単なる非同期オブジェクトオーケストレーションであるかどうかを診断する必要がある。
使用すべきでない場合
- 調整要件のない単一エージェント計画や最適化問題。
- 単一のコントローラがすでにグローバルな意思決定権を所有している集中スケジューラ。
- 個別の目標、信念、または制御境界を持たない、プロンプトのみのロールプレイスウォーム。
- エージェントの自律性と知識の非対称性が無関係である、一般的な分散システム設計。
主要なメンタルモデル
環境特性がアーキテクチャを決定する
観測可能性、決定論性、動的変化、時間的制約から始める。アーキテクチャの選択は、環境の形状によって決まるのであって、流行りのエージェントパターンに対する個人的な好みではない。
自律性は制御の逆転である
エージェントは単なる非同期オブジェクトではない。エージェントは従うかどうか、いつ従うかを決定する。つまり、リクエストには、暗黙の従順ではなく、意味論、拒否、および調整ロジックが必要である。
調整は制約から生まれる
部分観測可能性、リソース競合、相互依存する目標が調整圧力を生み出す。優れたプロトコル設計は、協調が常に望ましいと仮定するのではなく、その圧力を特定することから始まる。
コミットメント戦略は変動性に合わせる必要がある
大胆なエージェントは急速に変化する環境で過剰コミットし、慎重なエージェントは安定した環境で消耗する。再検討頻度は、普遍的なベストプラクティスではなく、環境ダイナミクスに結びついた設計パラメータである。
知識レベルが重要である
個別知識、全員知識、共通知識、分散知識は互換性がない。間違ったレベルを要求すると、プロトコルが不可能になるか、無駄に高コストになる可能性がある。
決定ポイント
flowchart TD
A[エージェントアーキテクチャが必要] --> B{環境は完全に観測可能で安定しているか？}
B -->|はい| C[単純なリアクティブまたはプランナー重視の設計で十分かもしれない]
B -->|いいえ| D{不確実性の下でリアルタイムな反応が必要か？}
D -->|はい| E[ハイブリッドアーキテクチャ]
D -->|いいえ| F[熟考的アーキテクチャ]
E --> G{エージェントが協調する必要がある理由は？}
F --> G
G -->|部分情報| H[情報共有プロトコル]
G -->|リソース競合| I[交渉または割り当てメカニズム]
G -->|タスク依存性| J[コミットメントまたは委任プロトコル]
G -->|真の自律性なし| K[より単純な集中設計を使用する]
- エージェントアーキテクチャを選択する前に、環境を特徴づける。
- エージェントがリクエストを拒否、延期、または再解釈できないのであれば、エージェントの自律性があるふりをしてはいけない。
- 知識要件を意図的に選択する。多くのシステムは共通知識ではなく、分散知識を必要とする。
- コミットメントの大胆さを、環境の変化率と再検討のコストに合わせる。
失敗モード
アーキテクチャ優先設計
兆候：誰も環境を説明できる前に、チームがBDI、ディベート、または派手なエージェントフレームワークを望む。
修正：まず環境の特徴づけを強制する。
擬人化的自律性
兆候：設計が信念や欲望について語るが、それらをローカル状態、観測、またはプロトコル義務にマッピングできない。
修正：精神的な言語を具体的な計算状態に基づかせる。
調整自体のための調整
兆候：通信トラフィックが増加するが、どの環境圧力がそれを必要としているかを説明できる者はいない。
修正：実際の強制関数を特定し、それに対処する最小限のプロトコルを設計する。
隠された中央コントローラ
兆候：1つの「エージェント」が黙って全ての重要な選択を行い、他のエージェントは単に実行するだけである。
修正：アーキテクチャが集中型であることを認めるか、真の意思決定権を再分配する。
不可能な知識の仮定
兆候：プロトコルの正確性が、すべてのエージェントが他のすべてのエージェントが事実を知っていることを知っていることに依存しているが、ネットワークが信頼できない。
修正：環境が許す限り、分散知識、確認応答、または結果整合性に緩和する。
実践例
専門家LLMレビュースウォーム
コーディングシステムがセキュリティ、パフォーマンス、スタイルのエージェントを使用する。セキュリティレビューはスタイルレビューとは異なる証拠に依存し、単一のレビューアは全体像を把握できない。ハイブリッドコーディネータと対象を絞った情報共有を、すべてのレビューアがコンテキスト全体を見るべきだと仮定する代わりに使用する。
分散車両監視
センサーエージェントが重複しているが不完全な領域をカバーする。単一のエージェントがエンドツーエンドのトラック連続性を維持できないため、調整が必要である。一般的な「協調」ではなく、部分観測可能性を中心にプロトコルを設計する。
品質ゲート
- 環境はアーキテクチャ選択の前に明示的に特徴づけられている。
- 設計は調整圧力の真の原因を特定している。
- 知識要件は適切なレベルで述べられている。
- コミットメント戦略は変動性と再検討コストに結びついている。
- 主張されている自律性には、リクエストの拒否、遅延、またはローカルな解釈が含まれている。
指標
- 誰かがシステムをマルチエージェントと呼ぶが、すべての重要な決定が依然として1つのコントローラを経由する場合、彼らは分散実行の名前を変えているのであって、自律性を設計しているわけではない。
- 「共通知識」が通信モデルなしで軽率に使用されている場合、プロトコルはおそらく仕様不足である。
- チームがなぜエージェントが協調しなければならないのかを言えない場合、その設計はおそらくエージェントをまったく必要としていない。
参考文献ルーティング
references/environment-characterization-drives-architecture.md: アーキテクチャの選択が主な問題である場合にロードする。references/coordination-as-necessity-not-luxury.md: 調整を正当化または最小化する必要がある場合にロードする。references/commitment-strategies-and-environment-dynamics.md: 大胆さや再計画の頻度が主な調整問題である場合にロードする。references/grounded-epistemic-logic-for-distributed-agents.md: 知識の主張が安全性や正確性を左右する場合にロードする。references/negotiation-and-resource-allocation-mechanisms.md: 自律性が希少リソースと衝突する場合にロードする。