最近実験的なツールとしてリリースされたSwarmは、開発者がルーチンとハンドオフを使用してタスクを実行するために、複数のエージェントを互いに協調させる方法を調査できるようにすることを目的としている。
マルチエージェントシステムは、より複雑なAIシステムを構築するためのアプローチであり、タスクはサブタスクに分割される。各タスクは、それを解決するためにもっとも適切な戦略を選択できる専門エージェントに分割される。例えば、2つのサブエージェント（1つは払い戻し管理、もう1つは販売管理）を持つショッパーエージェントを構築し、第3のエージェントであるトリアージエージェントが、どのサブエージェントが新しいリクエストを処理すべきかを決定できる。
Swarmは、軽量でスケーラブル、そしてデザインによって高度にカスタマイズ可能なパターンを探求している。Swarmに似たアプローチは、単一のプロンプトにエンコードすることが困難な、多数の独立した能力や命令を扱う状況に最適である。
述べたように、Swarmはルーチンとハンドオフの概念に基づいている。この文脈では、ルーチンは、ステップとそれを実行するツールのセットであり、ハンドオフは、エージェントが他のエージェントに会話を引き渡すアクションを表す。これは、対応するルーチンをロードし、前の会話で蓄積されたすべてのコンテキストを提供することを意味する。例えば、次のスニペットは、販売と返金エージェントを定義する方法を示している。
def execute_refund(item_name): return "success"refund_agent = Agent( name="Refund Agent", instructions="You are a refund agent. Help the user with refunds.", tools=[execute_refund],)def place_order(item_name): return "success"sales_assistant = Agent( name="Sales Assistant", instructions="You are a sales assistant. Sell the user a product.", tools=[place_order],)ハンドオフを管理するために、transfer_to_sales_agent とtransfer_to_refund_agentという2つの関数を含む以下のスニペットのようなトリアージエージェントを定義できる。また、transfer_to_triage_agentツールをrefund_agentとsales_assistant の定義に追加する必要がある。
triage_agent = Agent( name="Triage Agent", instructions=( "Gather information to direct the customer to the right department." ), tools=[transfer_to_sales_agent, transfer_to_refund_agent],)...refund_agent = Agent(... tools=[execute_refund, transfer_to_triage_agent],)...sales_assistant = Agent(... tools=[place_order, transfer_to_triage_agent],)トリアージ・エージェントを使用する上述のパターンは、ハンドオフを管理するための1つの方法に過ぎず、Swarmは異なるソリューションの使用をサポートしている。
マルチエージェントシステムを構築するための代替フレームワークの例としては、マイクロソフトのAutoGen、CrewAI、AgentKitがある。それぞれ、エージェントをどのようにオーケストレーションするか、どの側面が不可欠かについて、異なるスタンスを取っている。
マルチエージェントシステムは、単一ターンでの応答、長期的メモリの欠如、推論の深さなど、LLMのいくつかの制限を回避することで、より複雑なシステムの作成を可能にすることを目指している。
しかし、複雑なエージェントをマルチエージェントシステムに分解することは、必ずしも簡単な作業ではないことを理解することが重要だ。Hacker Newsのコメント欄でValentinA23氏が指摘するように、このプロセスは、1つのタスクをサブタスクに分割し、各タスクの出力を解析・サニタイズし、エージェントグラフの残りの部分に差し戻すコードを書くことを含め、1つのタスクをサブタスクに分割する最適な方法を決定するために実験する必要があるため、非常に時間がかかる」。
別のHacker Newsコメント投稿者であるLASR氏は、異なるエージェントが時間と共に分岐していくことを懸念している。
エージェントの問題は発散だ。エージェントのアンサンブルは非常に速く、それぞれのことをやり始め、望む状態に一貫して到達することは不可能になる。
最後に、Hacker Newsユーザーのdimitri-vs氏は、現在のLLM、例えばGPT o1やSonnet 3.5の進化の速さについて言及している特に、「複雑なエージェント的アプローチを作り直すよりも、1つのAPIコールに入れ替え、1つか2つのプロンプトを変更する方がはるかに簡単です。特に、異なるモデル間で同じプロンプトを確実に再利用できないことがはっきりしている場合は」。