生成オーケストレーションはまた、1つのエージェントが別のエージェントを呼び出すマルチエージェントシステムもサポートしています。 問題を複数の専門エージェントに分割することで、モジュール性、スケーラビリティ、管理性が向上します。
インラインエージェント
インラインエージェントは、子エージェントとも呼ばれ、同じエージェント内で小規模で再利用可能なワークフローです。 それらは多くの場合、メインエージェントがサブルーチンとして使う単なるトピックです。 例えば、メインエージェントは「テキスト翻訳」トピックを大きな計画の一歩として呼び出すことができます。 インラインエージェントはメインエージェントとコンテキストを共有するため、データのやり取りは簡単です。
ベストプラクティス:インラインエージェントを単一の責任に集中させ、十分にテストを行わせること。
接続されているエージェント
コネクテッドエージェントは、それぞれ独自のオーケストレーション、ツール、知識を持つ別個のエージェントです。 メインエージェントは、リクエストの一部を子供エージェントに委任します。 例えば、IT担当者がセールス担当者に価格を問い合わせる場合などです。 接続エージェントはモジュール性、ドメイン分離、プラン制限の回避を可能にします。 それぞれ異なる権限や知識を持っている場合があるため、ガバナンスや監査管理を適用してください。
しかし、接続エージェントを使用するには慎重なガバナンスが必要です:
オーケストレーション:親オーケストレーターは、接続されたエージェントにいつ引き継ぐかの明確な基準を持つべきです。 このハンドオフは通常、ユーザーの意図が接続されたエージェントのドメインと一致したときに行われます。 このプロセスを助けるために、接続されたエージェントの目的を親の設定で明確に説明してください。 親の視点から、接続されたエージェント全体を「ツール」として扱い、説明が記されています。
データハンドオフ:データハンドオフを管理しなければなりません。 親から接続されたエージェントに渡すコンテキストを決めます。 Copilot Studioは、あるエージェントが別のエージェントに電話をかけた際にデフォルトで通話履歴を渡すため、接続されたエージェントはすでに何が話されたかを把握できます。 ただし、特定のパラメータも通過する必要があるかもしれません。 例えば、メインエージェントが以前にユーザーの名前を知っている場合、再度尋ねないように接続されたエージェントにその名前を送信することがあります。
セキュリティ:接続されたエージェントは親エージェントがアクセスできないものにアクセスできる場合があります。 接続されたエージェントに電話することで、誤って制限を回避しないようにしましょう。 例えば、親エージェントが記録を削除できないのに接続エージェントが削除できる場合、適切な承認なしに削除が行われる状況で親エージェントは接続エージェントに連絡すべきではありません。 接続されたエージェントの通話は、他の強力なアクションと同じように扱いましょう。 機密性の高い動作をしている場合は、必要なチェックやユーザーの同意を受けてください。
監査と監視:接続されたエージェントがいつ呼び出しられ、何をしたかを記録します。 別のエージェントなので、別の成績証明書が必要です。 デバッグでは親セッションと接続されたセッションを相関させることが重要です。 通常、テレメトリ内の識別子は両者を結びつけます。
エージェントを分離するタイミング
すべてのサブタスクごとに別々のエージェントを作成しないでください。 サブタスクの場合は別々のエージェントを使用しましょう:
- 独自のツールや知識(専門分野が異なる)を持つほど複雑です。
- メインエージェントとは異なるガバナンスルールやアクセス制御が必要です
- その機能を多くの異なるメインエージェントで再利用する予定です(つまりサービスエージェントのようなものです)。
これらの条件が当てはまらない場合は、完全な接続エージェントの代わりに単純なトピック(インライン)で十分かもしれません。 別々のエージェントはオーバーヘッドを生じさせます。コンテキスト切り替えによる実行時間がやや長くなり、複数のボットの保守が複雑になります。 だから賢明に使いましょう。 実用的なアプローチとしては、まず1人のエージェントから始め、モジュール性や単一のエージェントが越えてはいけない境界が明確に必要だと感じたときだけ複数のエージェントに分割することです。