この記事では、基本原則、設計目標、戦略的目標など、Agent Framework のアーキテクチャにおける主要な概念について説明します。
目標
Agent Framework
は、次の重要な優先順位を念頭に置いて開発されました。
- セマンティック カーネル エージェント フレームワークは、エージェント機能を実装するためのコア基盤として機能します。
- 異なる種類の複数のエージェントが 1 つの会話内で共同作業を行い、それぞれが独自の機能を提供しながら、人間の入力を統合できます。
- エージェントは、複数の同時会話に同時に参加して管理できます。
エージェント
抽象 Agent
クラスは、すべての種類のエージェントのコア抽象化として機能し、より特殊なエージェントを作成するために拡張できる基本的な構造を提供します。 この基底クラスは、より具体的なエージェント実装の基礎を形成し、そのすべてがカーネルの機能を利用してそれぞれの関数を実行します。 [エージェントの種類] セクションで、使用可能なすべての エージェントの種類を確認 します。
基礎となるセマンティック カーネル Agent
抽象化については、 こちらをご覧ください。
基礎となるセマンティック カーネル Agent
抽象化については、 こちらをご覧ください。
エージェントは、タスクを実行するために直接呼び出すか、異なるパターンで調整できます。 この柔軟な構造により、エージェントはさまざまな会話型またはタスク駆動型のシナリオに適応でき、インテリジェントなマルチエージェント システムを構築するための堅牢なツールを開発者に提供できます。
セマンティック カーネルのエージェントの種類
エージェント スレッド
抽象 AgentThread
クラスは、スレッドまたは会話状態のコア抽象化として機能します。 さまざまなエージェントに対して会話状態を管理するさまざまな方法を抽象化します。
ステートフル エージェント サービスは、多くの場合、会話状態をサービスに格納し、ID を使用して操作できます。他のエージェントでは、各呼び出しでチャット履歴全体をエージェントに渡す必要がある場合があります。この場合、会話状態はアプリケーションでローカルで管理されます。
ステートフル エージェントは通常、一致する AgentThread
実装でのみ機能しますが、他の種類のエージェントは複数の AgentThread
の種類で動作します。 たとえば、 AzureAIAgent
には一致する AzureAIAgentThread
が必要です。 これは、Azure AI エージェント サービスがサービスに会話を格納し、スレッドを作成して更新するために特定のサービス呼び出しを必要とするためです。
AzureAIAgent
で別のエージェント スレッドの種類が使用されている場合、予期しないスレッドの種類が原因で高速に失敗し、呼び出し元に警告する例外が発生します。
エージェント オーケストレーション
重要
エージェント フレームワークのエージェント オーケストレーション機能は、試験段階にあります。 これらはアクティブな開発中であり、プレビューまたはリリース候補ステージに進む前に大幅に変更される可能性があります。
注
AgentGroupChat
オーケストレーション パターンを使用している場合は、維持されなくなったことに注意してください。 開発者は、新しい GroupChatOrchestration
パターンを使用することをお勧めします。 移行ガイドがここに用意 されています。
セマンティック カーネルの エージェント オーケストレーション フレームワークを使用すると、複数のエージェントを連携して複雑なタスクを共同で解決できます。 エージェントが対話し、情報を共有し、責任を委任する方法を定義するための柔軟な構造が提供されます。 主要なコンポーネントと概念は次のとおりです。
- オーケストレーション パターン: コンカレント、シーケンシャル、ハンドオフ、グループ チャット、マゼンティックなどの事前構築済みのパターンを使用すると、開発者はシナリオに最適なコラボレーション モデルを選択できます。 各パターンは、エージェントがタスクを通信および処理するための異なる方法を定義します (詳細については、 オーケストレーション パターン の表を参照してください)。
- データ変換ロジック: 入力変換と出力変換を使用すると、オーケストレーション フローでエージェントと外部システムの間でデータを適応させ、単純なデータ型と複雑なデータ型の両方をサポートできます。
- Human-in-the-loop: 一部のパターンでは、human-in-the-loop がサポートされ、人間のエージェントがオーケストレーション プロセスに参加できるようになります。 これは、人間の判断や専門知識が必要なシナリオに特に役立ちます。
このアーキテクチャにより、開発者は、コラボレーション、特殊化、動的調整を通じて実際の問題に取り組むことができるインテリジェントなマルチエージェント システムを構築できます。
セマンティック カーネル機能を使用したエージェントの配置
Agent Framework
は、多くの開発者がセマンティック カーネル エコシステム内で知るようになった基本的な概念と機能に基づいて構築されています。 これらの基本原則は、Agent Framework の設計の構成要素として機能します。 セマンティック カーネルの使い慣れた構造と機能を活用することで、Agent Framework は、より広範なセマンティック カーネル アーキテクチャとの一貫性を維持しながら、より高度で自律的なエージェント動作を可能にするために機能を拡張します。 これにより、開発者はスムーズに移行でき、既存の知識を適用して、フレームワーク内にインテリジェントで適応可能なエージェントを作成できます。
プラグインと関数呼び出し
プラグイン はセマンティック カーネルの基本的な側面であり、開発者はカスタム機能を統合し、AI アプリケーションの機能を拡張できます。 これらのプラグインは、特殊な機能やビジネス固有のロジックをコア AI ワークフローに柔軟に組み込む方法を提供します。 さらに、フレームワーク内のエージェント機能は、Plugins を利用しFunction Callingを利用することで大幅に強化できます。 これにより、エージェントは外部サービスと動的にやり取りしたり、複雑なタスクを実行したりすることができ、多様なアプリケーション内で AI システムの範囲と汎用性をさらに広げます。
プラグインを使用するようにエージェントを構成する方法については 、こちらをご覧ください。
エージェント メッセージ
入力と応答の両方を含むエージェント メッセージングは、セマンティック カーネルのコア コンテンツ タイプに基づいて構築され、通信のための統一された構造を提供します。 この設計の選択により、従来のチャット完了パターンから、アプリケーション開発におけるより高度なエージェント駆動型パターンへの移行プロセスが簡略化されます。 使い慣れたセマンティック カーネル コンテンツ タイプを活用することで、開発者は既存のシステムを見直す必要なく、エージェント機能をアプリケーションにシームレスに統合できます。 この合理化により、基本的な会話型 AI からより自律的なタスク指向のエージェントに進化するにつれて、基になるフレームワークの一貫性が維持され、開発が迅速かつ効率的になります。
テンプレート
エージェントの役割は、主に受け取る命令によって形成され、その動作とアクションが決まります。
Kernel
promptの呼び出しと同様に、エージェントの命令には、実行中に動的に置換されるテンプレート化されたパラメーター (値と関数の両方) を含めることができます。 これにより、柔軟でコンテキストに対応した応答が可能になり、エージェントはリアルタイム入力に基づいて出力を調整できます。
さらに、プロンプト テンプレート構成を使用してエージェントを直接構成できます。これにより、開発者は構造化された再利用可能な方法で動作を定義できます。 このアプローチは、エージェントの指示を標準化およびカスタマイズするための強力なツールを提供し、動的な適応性を維持しながら、さまざまなユース ケース間で一貫性を確保します。
セマンティック カーネル テンプレートを使用してエージェントを作成する方法の詳細については 、こちらをご覧ください。
宣言型仕様
宣言型仕様の使用に関するドキュメントは近日公開予定です。
重要
この機能は実験段階にあります。 この段階の機能は開発中であり、プレビューまたはリリース候補ステージに進む前に変更される可能性があります。
カスタム エージェントの種類の登録
宣言型 YAML 仕様システムでカスタム エージェントを使用するには、まずエージェント クラスをエージェント レジストリに登録する必要があります。 これは、YAML 仕様のtype:
フィールドを解析するときに、AgentRegistry
がエージェントを認識して構築できるようにするために必要です。
カスタム エージェントの種類を登録するには、 @register_agent_type
デコレーターを使用します。
from semantic_kernel.agents import register_agent_type, Agent, DeclarativeSpecMixin
@register_agent_type("custom_agent")
class CustomAgent(DeclarativeSpecMixin, Agent):
...
デコレーターに提供される文字列 ( "custom_agent"
など) は、YAML 仕様の type: フィールドと一致する必要があります。
登録が完了すると、カスタム エージェントは宣言型パターン (たとえば、 AgentRegistry.create_from_yaml(...)
を使用して) を使用してインスタンス化できます。
DeclarativeSpecMixin
は、from_yaml
、from_dict
、resolve_placeholders
などのメソッドのサポートを追加します。これにより、エージェントを YAML またはディクショナリの仕様から構築できます。
@classmethod
async def from_yaml(cls, yaml_str: str, *, kernel=None, plugins=None, prompt_template_config=None, settings=None, extras=None, **kwargs):
# Resolves placeholders and loads YAML, then delegates to from_dict.
...
@classmethod
async def from_dict(cls, data: dict, *, kernel=None, plugins=None, prompt_template_config=None, settings=None, **kwargs):
# Normalizes and passes spec fields to _from_dict.
...
@classmethod
@abstractmethod
async def _from_dict(cls, data: dict, *, kernel, prompt_template_config=None, **kwargs):
# Subclasses implement this to create the agent from a dict.
...
@classmethod
def resolve_placeholders(cls, yaml_str: str, settings=None, extras=None) -> str:
# Optional: override this to customize how environment or runtime placeholders are resolved in YAML.
return yaml_str
ヒント
カスタム エージェントは、YAML ベースの構築を有効にするために DeclarativeSpecMixin
から継承する必要があり、 @register_agent_type
を使用してレジストリに登録する必要があります。
この機能は使用できません。