AutoGen Core ランタイムがメッセージを配信するには 2 つの方法があります、直接メッセージ送信とブロードキャストです。このセクションはブロードキャストの中核概念: トピックとサブスクリプションにフォーカスします。

AutoGen Core : 基本概念 : トピックとサブスクリプション

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

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

• AutoGen Core : Core Concept : Topic and Subscription

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

 

 

 

AutoGen Core : 基本概念 : トピックとサブスクリプション

ランタイムがメッセージを配信するには 2 つの方法があります、ダイレクト・メッセージング (直接メッセージ送信) とブロードキャストです。ダイレクト・メッセージングは 1対1 です : 送信者は受信者のエージェント ID を提供する必要があります。一方、ブロードキャストは 1対多 で、送信者は受信者のエージェント ID を提供しません。

多くのシナリオがブロードキャストに適しています。例えば、イベント駆動型ワークフローでは、エージェントは誰がメッセージを処理するか必ずしも知りません、そしてワークフローは相互依存がないエージェントで構成できます。このセクションはブロードキャストの中核概念: トピックとサブスクリプションにフォーカスします。

 

トピック

トピックはブロードキャスト・メッセージのスコープを定義します。本質的には、エージェント・ランタイムはブロードキャスト API を通して Pub/Sub モデルを実装しています : メッセージを発行するとき、トピックが指定される必要があります。それはエージェント ID に対する間接参照です。

トピックは 2 つのコンポーネントで構成されます : トピックタイプとトピックソースです。

Note : Topic = (Topic Type, Topic Source)

 
エージェント ID (これも 2 つのコンポーネントを持ちます) と同様に、トピックタイプは通常は (トピックが対象とする) メッセージタイプを示すためにアプリケーションコードで定義されます。例えば、GitHub エージェントは、新しい issues に関するメッセージを発行する場合、トピックタイプとして “GitHub_Issues” を使用するかもしれません。

トピックソースはトピックタイプ内のトピック用の一意な識別子です。通常はアプリケーションデータにより定義されます。例えば、GitHub エージェントはトピックを一意に識別するためにトピックソースとして “github.com/{repo_name}/issues/{issue_number}” を使用しても良いです。トピックソースは発行者 (publisher) がメッセージのスコープを制限してサイロを作成することを可能にします。

トピック ID は文字列に変換、文字列から変換することができます。この文字列の形式は :

Note : Topic_Type/Topic_Source

 
タイプはそれらが UTF8 で英数字 (a-z) と (0-9) やアンダースコア (_) だけを含む場合、有効とみなされます。有効な識別子は数字で始めたり空白を含むことはできません。ソースはそれらが UTF8 で ascii 32 (空白) と 126 (~) の間の文字だけを含む場合に有効とみなされます。

 

サブスクリプション

サブスクリプションはトピックをエージェント ID にマップします。

上の図はトピックとサブスクリプション間の関係性を示しています。エージェント・ランタイムはサブスクリプションを追跡し続けて、それらを使用してメッセージをエージェントに配信します。

トピックがサブスクリプションを持たない場合、このトピックに発行されたメッセージはどのエージェントにも配信されません。トピックが多くのサブスクリプションを持つ場合、メッセージはすべてのサブスクリプションに従ってすべての受信エージェントに一度だけ配信されます。アプリケーションはエージェントランタイムの API を使用してサブスクリプションを追加または削除できます。

 

型ベース・サブスクリプション

型ベースのサブスクリプションはトピックタイプをエージェントタイプ (agent ID 参照) にマップします。正確なトピックソースとエージェントキーを知ることなしに、トピックからエージェント ID への制限のない (unbounded) マッピングを宣言します。そのメカニズムは単純です : 型ベースのサブスクリプションのトピックタイプに一致するトピックは、サブスクリプションのエージェントタイプと、トピックソースの値に割り当てられたエージェントキーを持つエージェント ID にマップされます。Python API については、TypeSubscription を使用します。

Note : Type-Based Subscription = Topic Type –> Agent Type

 
一般的に、型ベースのサブスクリプションはサブスクリプションを宣言する推奨される方法です。それは可搬性がありデータ独立です : 開発者は、特定のエージェント ID に依存するアプリケーション・コードを書く必要がありません。

 

型ベース・サブスクリプションのシナリオ

型ベース・サブスクリプションは、正確なトピックやエージェント ID がデータ依存な場合、多くのシナリオに適用できます。シナリオは 2 つの考慮事項に分解できます : (1) シングルテナントか、マルチテナントか、そして (2) テナント毎にシングルトピックかマルチトピックか。テナントは通常は特定のユーザセッションか特定のリクエストを処理するエージェントのセットを指します。

 

シングルテナント、シングルトピック

このシナリオでは、アプリケーション全体で 1 つのテナントと 1 つのトピックだけがあります。それは最も単純なシナリオで、コマンドラインツールや単一ユーザアプリケーションのような多くのケースで使用できます。

このシナリオに対して型ベース・サブスクリプションを適用するには、各エージェントタイプに 1 つの型ベース・サブスクリプションを作成して、すべての型ベース・サブスクリプションに同じトピックタイプを使用します。発行するとき、常に同じトピック、つまり同じトピックタイプとトピックソースを使用します。

例えば、3 つのエージェントタイプ: “triage_agent”, “coder_agent” と “reviewer_agent” があり、トピックタイプが “default” であると仮定すると、以下の型ベース・サブスクリプションを作成します :

# Type-based Subscriptions for single-tenant, single topic scenario
TypeSubscription(topic_type="default", agent_type="triage_agent")
TypeSubscription(topic_type="default", agent_type="coder_agent")
TypeSubscription(topic_type="default", agent_type="reviewer_agent")

上記の型ベース・サブスクリプションでは、すべてのメッセージに対して同じトピックソース “default” を使用します。従って、トピックは常に (“default”, “default”) です。このトピックに発行されるメッセージは上記のすべての型のすべてのエージェントに対して配信されます。具体的には、メッセージは以下のエージェント ID に送信されます :

# The agent IDs created based on the topic source
AgentID("triage_agent", "default")
AgentID("coder_agent", "default")
AgentID("reviewer_agent", "default")

以下の図はこの例で型ベース・サブスクリプションがどのように動作するかを示しています。

ID を持つエージェントが存在しない場合、ランタイムはそれを作成します。

 

シングルテナント、マルチトピック

このシナリオでは、1 つのテナントだけ存在しますが、どのエージェントがどのトピックを処理するか制御したい場合です。これはサイロを作成して、異なるトピックを処理するのに特化された異なるエージェントを持ちたい場合に役立ちます。

このシナリオに型ベース・サブスクリプションを適用するには、各エージェントタイプに異なるトピックタイプを持つ型ベース・サブスクリプションを 1 つ作成します。これらのエージェントタイプに同じトピックを望む場合は、同じトピックタイプに複数のエージェントタイプをマップできます。トピックソースについては、依然として、発行するときすべてのメッセージに対して同じ値を使用してください。

同じエージェントタイプで上記の例を続けて、以下の型ベース・サブスクリプションを作成します :

# Type-based Subscriptions for single-tenant, multiple topics scenario
TypeSubscription(topic_type="triage", agent_type="triage_agent")
TypeSubscription(topic_type="coding", agent_type="coder_agent")
TypeSubscription(topic_type="coding", agent_type="reviewer_agent")

上記の型ベース・サブスクリプションでは、トピック (“triage”, “default”) に発行される任意のメッセージはタイプ “triage_agent” のエージェントに配信され、トピック (“coding”, “default”) に発行されるメッセージはタイプ “coder_agent” と “reviewer_agent” のエージェントに配信されます。

次の図はこの例で、型ベース・サブスクリプションがどのように動作するかを示します。

 

マルチテナント・シナリオ

シングルテナントのシナリオでは、トピックソースは常に同じ (e.g., “default”) です – それはアプリケーションコードにハードコードされます。マルチテナント・シナリオに移行すると、トピックソースはデータ依存になります。

上記の例を続けると、特定の GitHub issue を処理する専用のエージェントのインスタンスを持ちたい場合、トピックソースをその issue 用の一意な識別子として設定する必要があります。

例えば、エージェントタイプ “triage_agent” 用の型ベース・サブスクリプションが 1 つあるとします :

TypeSubscription(topic_type="github_issues", agent_type="triage_agent")

メッセージがトピック (“github_issues”, “github.com/microsoft/autogen/issues/1”) に発行されると、ランタイムは ID (“triage_agent”, “github.com/microsoft/autogen/issues/1”) を持つエージェントにメッセージを配信します。メッセージがトピック (“github_issues”, “github.com/microsoft/autogen/issues/9”) に発行されると、ランタイムは ID (“triage_agent”, “github.com/microsoft/autogen/issues/9”) を持つエージェントにメッセージを配信します。

次の図はこの例で、型ベース・サブスクリプションがどのように動作するかを示しています。

エージェント ID はデータ依存で、ランタイムはエージェントが存在しない場合にはその新しいインスタンスを作成することに注意してください。

テナント毎に複数のトピックをサポートするためには、シングルテナント、複数のトピックのシナリオのように、異なるトピックタイプを使用できます。

以上