AutoGen Core の基本概念から App スタックです。AutoGen core は広範囲なマルチエージェント・アプリケーションを構築するために使用できる柔軟なフレームワークとして設計されています。エージェントランタイムはエージェントの ID とライフサイクルを管理します。

AutoGen Core : 基本概念 : App スタック / エージェント ID とライフサイクル

作成 : クラスキャット・セールスインフォメーション
作成日時 : 04/09/2025

* 本記事は github microsoft/autogen の以下のページを独自に翻訳した上でまとめ直し、補足説明を加えています :

• AutoGen Core : Core Concept : Application Stack
• AutoGen Core : Core Concept : Agent Identity and Lifecycle

* サンプルコードの動作確認はしておりますが、必要な場合には適宜、追加改変しています。
* ご自由にリンクを張って頂いてかまいませんが、sales-info@classcat.com までご一報いただけると嬉しいです。

 

 

 

AutoGen Core : 基本概念 : App スタック

AutoGen core は、広範囲なマルチエージェント・アプリケーションを構築するために使用できる、特定のやり方にこだわらない (unopinionated) フレームワークとして設計されています。特定のエージェント抽象化やマルチエージェント・パターンに縛られません。

次の図はアプリケーション・スタックを示します。

スタックの一番下には、エージェントが相互に通信することを可能にする基本的なメッセージングとルーティング装置 (facilities) があります。これらはエージェント・ランタイムにより管理され、殆どのアプリケーションについて、開発者はランタイムにより提供される高位 API を操作する必要があるだけです (Agent and Agent Runtime 参照)。

スタックの最上部では、開発者はエージェントが交換するメッセージのタイプを定義する必要があります。このメッセージタイプのセットはエージェントが従う必要がある動作契約を形成し、契約の実装はエージェントがメッセージを処理する方法を決定します。動作契約はまたメッセージプロトコルと呼ばれることもあります。動作契約を実装するのは開発者の責任です。マルチエージェント・パターンはこれらの動作契約から出現します (Multi-Agent Design Patterns 参照)。

 

アプリケーションの例

コード生成用のマルチエージェント・アプリケーションの具体的な例を考えましょう。アプリケーションは 3 つのエージェントから構成されます : Coder エージェント、Executor エージェントと Reviewer エージェントです。次の図はエージェント間のデータフローとそれらの間で交換されるメッセージタイプを示しています。

この例では、動作契約は以下から構成されます :

• アプリケーションから Coder エージェントへの CodingTaskMsg メッセージ
  

• Coder エージェントから Executor エージェントへの CodeGenMsg
  

• Executer エージェントから Reviewer エージェントへの ExecutionResultMsg
  

• Reviewer エージェントから Coder エージェントへの ReviewMsg
  

• Reviewer エージェントからアプリケーションへの CodingResultMsg

動作契約はこれらのメッセージのエージェントの処理で実装されます。例えば、Reviewer エージェントは ExecutionResultMsg を listen し、コード実行の結果を評価して承認するか拒否するかを決定し、承認される場合は、アプリケーションに CodingResultMsg を送信し、そうでない場合は、コード生成のもう一つのラウンドのために Coder エージェントに ReviewMsg を送信します。

動作契約は reflection と呼ばれるマルチエージェント・パターンのケースで、そこでは生成結果は生成のもう一つのラウンドによりレビューされ、全体的な品質を向上させます。

 

AutoGen Core : 基本概念 : エージェント ID とライフサイクル

エージェントランタイムはエージェントの ID とライフサイクルを管理します。アプリケーションはエージェントを直接には作成するのではなく、エージェント・インスタンスのファクトリー関数を使用してエージェントタイプを登録します。このセクションでは、ランタイムによりエージェントが識別され作成される方法を説明します。

 

エージェント ID

エージェント ID は、分散ランタイムを含むエージェントランタイム内のエージェントインスタンスを一意に識別します。それはメッセージを受信するためのエージェントインスタンスの「アドレス」です。それは 2 つのコンポーネントを持ちます : エージェントタイプとエージェントキーです。

Note : Agent ID = (Agent Type, Agent Key)

 
エージェントタイプはエージェントクラスではありません。それはエージェントを、同じエージェントタイプのエージェントのインスタンスを生成する、特定のファクトリ関数と関連付けます。例えば、異なるファクトリ関数は異なるコンストラクタ・パラメータを持つ同じエージェントクラスを生成することができます。エージェントキーは特定のエージェントタイプのインスタンス識別子です。エージェント ID は文字列に変換したり、文字列から変換できます。この文字列の形式は :

Note : Agent_Type/Agent_Key

 
タイプとキーは、英数字 (a-z) と (0-9)、またはアンダースコア (_) だけを含む場合、有効とみなされます。有効な識別子は数字で始めたり、空白を含むことはできません。

マルチエージェント・アプリケーションでは、エージェントタイプは通常はアプリケーションにより直接定義されます、つまり、それらはアプリケーションのコード内で定義されます。一方、エージェントキーは通常はエージェントに配信される特定のメッセージが与えられたときに生成されます、つまり、それらはアプリケーションのデータにより定義されます。

例えば、ランタイムが、コードレビューを実行するエージェントインスタンスを生成するファクトリ関数を使用してエージェントタイプ “code_reviewer” を登録したとします。各コードレビューのリクエストは専用のセッションを指し示すために一意な ID review_request_id を持ちます。この場合、各リクエストはエージェント ID (“code_reviewer”, review_request_id) を持つ新しいインスタンスにより処理できます。

 

エージェント・ライフサイクル

ランタイムが ID が指定されたエージェントインスタンスにメッセージを配信する場合、それはインスタンスを取得するか、存在しなければ作成します。

ランタイムはリソースを節約し複数のマシンに渡りロードバランスを取るために、エージェントインスタンスの “paging in” や “out” も担います。これはまだ実装されていません。

以上