Orchestrator

OrchestratorとSub-agentの責任境界をどのように定義すべきですか？普遍的な原則はありますか？

Orchestrator-Sub-agentの境界設計に唯一の正解はありませんが、広く適用できるいくつかの原則があります。第一に、Orchestratorは「タスクの分解と統合の方法」を担当し、Sub-agentは「特定のタスクタイプの最適な実行」を担当します。第二に、オンチェーン実行操作はOrchestratorまたは専用の「実行Sub-agent」に集中させます。分析系Sub-agentはオンチェーン署名認可を持つべきではありません——外部データを読み取るSub-agent（Prompt Injectionに汚染される可能性がある）と資金操作を実行する認可は、設計上分離されます。第三に、情報交換は自然言語ではなく構造化フォーマットを使用します。第四に、Sub-agentは他のSub-agentの存在を知るべきではありません——「最小知識の原則」です。

OrchestratorはLangChain（LangGraph）でどのように実装されますか？最もシンプルな入門例はありますか？

LangGraphはLangChainのマルチエージェントワークフローフレームワークで、有向非巡回グラフ（DAG）を使用してOrchestrator-Sub-agentのコラボレーションを記述します。LangGraphでは、いくつかのノード（各ノードはAgentまたは処理ステップに対応）とノード間のエッジを定義するStateGraphを作成します。Orchestratorノードは初期タスクを読み取り、最初にどのSub-agentノードを呼び出すかを決定し、すべてのSub-agentが完了した後に結果を統合します。最もシンプルな入門構造：orchestratorノードがユーザー入力を受け取りルーティングを決定；data_analystノードが市場データを照会；risk_assessorノードがリスクを評価；synthesizerノードがすべての結果を統合します。LangGraphの重要な概念：Stateはワークフロー全体で共有される状態辞書です。

OrchestratorパターンとAutoGenのGroupChatメカニズムの違いは何ですか？どちらをいつ選びますか？

両者は「複数のAgentが協力してタスクを完了する」という問題を解決しますが、設計哲学がまったく異なります。

LangGraph Orchestratorパターン：実行パスは事前定義されたDAGによって決定され、Orchestratorは明確な責任を持つ調整ノードです。フローは決定論的です——設計時に「データ分析の後は必ずリスク評価に行き、リスク評価の後に戦略生成に行く」とわかります。これによりフローが監査可能でテスト可能になり、財務的な結果を伴うシナリオに適しています。

AutoGen GroupChatメカニズム：複数のAgentが仮想の「会話グループ」で順番に発言・議論・互いに疑問を呈し、GroupChat ManagerがAgent間の次の発言者を決定します。コラボレーションはより「Agentが自由に議論して最良の答えを見つける」ことに近いです。フローは動的で、毎回異なるパスになる可能性があります。

選択の原則：タスクに明確な実行パスがある場合（データ取得 → 分析 → 決定）はLangGraph Orchestratorを使用します——確定論的・監査可能・Prompt Injectionへの防御が優れています（自然言語通信が少ない）。タスクが意思決定の質を高めるために複数の視点の「議論」を必要とする場合（例：テクニカル分析Agentとファンダメンタルズ分析Agentが互いの結論に疑問を呈する）はAutoGen GroupChatを使用します——動的・多角度ですがテストと監査が難しいです。クリプトシナリオでは：実行レイヤー（資金操作あり）にはLangGraph；純粋な分析レイヤー（資金操作なし）にはAutoGenで多視点の議論ができます。

クリプトシナリオでは、オンチェーン認可を保持するOrchestratorにはどのような具体的なセキュリティ設計要件がありますか？

オンチェーンの主要な操作認可を保持するOrchestratorは、マルチエージェントシステム全体で最もセキュリティ保護が必要なノードになります。具体的なセキュリティ設計要件：

第一に、Orchestratorの入力検証。Orchestratorは2つのソースからの入力を受け取ります：ユーザーの初期タスク（比較的信頼できる）とSub-agentの返答（検証が必要）。Sub-agentの返答にはスキーマ検証を行う必要があります——フォーマットが期待通りか確認し（{"protocol": str, "apy": float, "risk_score": int}）、予期しない長いテキストフィールド（インジェクション指示の可能性）を拒否します。スキーマに適合しないSub-agentの返答は、LLMコンテキストに入れることなく切り捨ててアラートをトリガーします。

第二に、オンチェーン操作の決定には独立した確認レイヤーが必要です。OrchestratorがオンチェーンLLMを実行する決定を下した後、直接実行することはできません。Orchestratorの推論フローとは完全に独立した確認メカニズム（人工確認チャネル、またはハードな規則エンジン検証）を通過する必要があります。これにより、Orchestratorの推論が汚染されても、攻撃者は資金操作を直接トリガーできません。

第三に、Sub-agentはOrchestratorにオンチェーン操作を積極的に要求できません。情報フローは一方向である必要があります：OrchestratorがSub-agentにタスクを割り当て、Sub-agentがOrchestratorに分析結果を返し、OrchestratorがオンチェーンLLM操作を実行するかどうかを自律的に決定します。Sub-agentの返答には積極的な指令（「今すぐX操作を実行することを推奨」）を含めるべきではありません。

第四に、完全な決定チェーンの監査ログ。すべてのオンチェーン操作は、どのSub-agentがどのデータを提供したか → Orchestratorが何に基づいて決定したか → どの確認レイヤーを通過したか → 最終的なオンチェーン実行の詳細まで追跡できなければなりません。