前のページでは、コンテキスト プロバイダーがエージェントにメモリと動的な知識 (呼び出しのたびに事前に挿入される情報) を提供する方法を示しました。 この時点で、ツールの使用、スキルの読み込み、ミドルウェアの実行、豊富なコンテキストでの描画を行うことができる 単一 のエージェントがあります。 これは強力ですが、それでも 1 つのエージェントがすべてを実行しています。
エージェントの責任が、1 セットの命令で適切に処理できる範囲を超えるとどうなりますか? エージェントがツールを蓄積すると、 ツールの選択が低下します 。モデルは、数十を並べ替えるよりも、いくつかの適切に説明されたツールの中から選択する方が優れています。 命令が幅広くなると、フォーカスが低下 します。旅行予約、経費報告、カレンダー管理を網羅しようとするシステムプロンプトでは、モデルに役割が多すぎて対処しきれなくなります。
ツールとしてのエージェント は、エージェントを作成できるようにすることでこれを解決します。1 つのエージェント ( 外側 のエージェント) は、通常の関数ツールであるかのように別のエージェント ( 内部 エージェント) を呼び出すことができます。 各内部エージェントには、独自の命令、独自のツール、独自の専門知識など、厳密な範囲があります。 外部エージェントは、委任するタイミングと何を要求するかを決定します。他のツールを呼び出すタイミングを決定するのとまったく同じ方法です。
使用タイミング
次の場合は、エージェントをツールとして使用します。
- ユーザーがフライトについて質問したときに専用の "旅行予約エージェント" を呼び出す一般的なアシスタントなど、 特殊なサブタスク を対象のエージェントに委任する必要があります。
- 外部エージェントは、会話に基づいて内部エージェントを関与させる タイミングと関係を 決定する必要があります。委任はモデル駆動型であり、ハードコーディングされません。
- エージェント間の 実行順序 を明示的に制御する必要はありません。外側のエージェントは、独自の推論によって物事を調整できます。
ヒント
各エージェントは、その特殊化と要件に応じて異なるモデルを使用することもできます。 より複雑なエージェントでは推論に大きなモデルが使用される場合があります。一方、単純なエージェントでは、より小さく高速なモデルを使用して効率を高める場合があります。
考慮事項
| 考慮事項 | 詳細情報 |
|---|---|
| 簡略 | ツールとしてのエージェントは、最も軽量なマルチエージェント パターンです。 エージェントをツールに変換し、別のエージェントに渡します。 これは、1 つのエージェントで十分でない場合の自然な次のステップです。 |
| Latency | 各委任は完全なエージェント呼び出しです。外部エージェントは内部エージェントを呼び出し、LLM を呼び出します。これは独自のツールを呼び出す可能性があります。 ネストされた呼び出しは積み重なります。 内部エージェントが集中して迅速に解決できるように保ちます。 |
| ルーティングはモデル駆動型 | 外部エージェントの LLM は、ツールを呼び出すタイミングを決定するのと同じように、内部エージェントを呼び出すタイミングを決定します。 つまり、ルーティングは予測できない可能性があります。ツールの説明があいまいな場合、モデルで間違ったエージェントが呼び出されたり、完全にスキップされたりする可能性があります。 明確で具体的な説明が重要です。 |
| 可視性の制限 | 外側のエージェントは、内部エージェントの最終的なテキスト応答を確認します。内部エージェントの中間推論、ツール呼び出し、またはコンテキストは表示されません。 内部エージェントの動作を監視する必要がある場合は、トレースを使用 します。 |
| コンテキストの分離 | 内部エージェントは、独自の命令とツールを使用して実行されます。 外部エージェントの会話履歴またはコンテキストは自動的には継承されません。 他の関数ツールと同様に、ツール呼び出し引数を使用して通信します。 |
どのように機能するのか
ツールとしてのエージェントは、既に知っている ツール呼び出しループ に基づいています。 唯一の違いは、呼び出される "関数" 自体がエージェントであることです。
┌──────────────────────────────────────────────────────────┐
│ User: "Book me a flight to Paris and file the expense" │
└──────────────┬───────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ Outer agent reasons about the request │
│ → decides to call the travel-booking agent first │
└──────────────┬───────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ Inner agent (travel-booking) runs as a tool: │
│ • receives: "Book a flight to Paris" │
│ • uses its own tools (search_flights, book_flight) │
│ • returns: "Booked Flight AF123, $450" │
└──────────────┬───────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ Outer agent receives the tool result │
│ → decides to call the expense-filing agent next │
└──────────────┬───────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ Inner agent (expense-filing) runs as a tool: │
│ • receives: "File expense for Flight AF123, $450" │
│ • uses its own tools (create_expense, attach_receipt) │
│ • returns: "Expense report filed" │
└──────────────┬───────────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────────┐
│ Outer agent synthesizes both results: │
│ "Done! Booked Flight AF123 to Paris for $450 and filed │
│ expense report." │
└──────────────────────────────────────────────────────────┘
重要なポイント:
- 内部エージェントは関数ツールのように見えます。 外部エージェントの観点から見ると、内部エージェントの呼び出しは、
get_weather()またはsearch_database()の呼び出しと同じではありません。 フレームワークは、名前、説明、および入力パラメーターを持つツールへのエージェントの変換を処理します。 - 内部エージェントは独立して実行されます。 独自の命令、ツール、LLM 呼び出しがあります。 外部エージェントの完全な会話は表示されません。ツール呼び出しを通じて渡された入力のみが表示されます。
- 外側のエージェントには最終的な結果のみが表示されます。 内部エージェントの中間ステップ (ツールの呼び出し、推論、再試行) は、外部エージェントからは見えません。 ツールの結果と同様に、テキスト応答を受け取ります。
次のステップ
1 つのプロセス内でエージェントを作成できるようになったので、次の手順は エージェント間 (A2A) です。これにより、エージェントは標準プロトコルを使用してサービスと組織の境界を越えて通信できるようになります。
より深く進む:
- Tools の概要 - 関数ツールとしてのエージェントの使用 - C# と Python のコード例
- 関数ツール — ツールとしてのエージェントが構築するツールの種類
- 可観測性 - 内部エージェントの動作のトレース