エージェントは問題ない。問題は、その間のハンドオフだ。
ほとんどのマルチエージェントのデモは、一つのエージェントが仮装しているだけのようなものです。エージェントAがタスクを行い、次にエージェントBが別のタスクを行う。しかし、エージェントAがエージェントBに必要な情報を渡せなかったときに何が起こるかは、デモでは示されません。
今年、私は3つのマルチエージェント・システムを本番環境にデプロイしました。難しかったのはエージェントそのものではありません。ハンドオフ（受け渡し）でした。
ハンドオフとは、単にテキストを渡すこと以上の意味を持ちます。以下の管理が必要です：
- スキーマの整合性 (Schema alignment): エージェントBは、毎回エージェントAの出力をパースしなければなりません。
- 失敗の伝播 (Failure propagation): システムは、どのエージェントが失敗したかを把握できなければなりません。
- コンテキストの衛生管理 (Context hygiene): ハンドオフのたびに、コンテキストウィンドウにノイズが追加されます。
最大の間違いは、エージェントを「紐でつながれたブラックボックス」として扱うことです。エージェントAにプロンプトを送り、結果を受け取り、それをエージェントBに放り込む。これは壊れるまでは機能しますが、壊れたときに、なぜ壊れたのかが分からなくなります。
次の3つの一般的な失敗パターンを避けてください：
サイレントな切り捨て (Silent truncation): エージェントAが大量のデータを生成し、エージェントBが末尾を切り捨ててしまう。その結果、エージェントBは不完全なデータを処理し、デタラメな結果を返します。各ステップでトークン数を計測してください。
スキーマのドリフト (Schema drift): エージェントAのプロンプトを変更したことで、返却されるフォーマットが変わってしまう。エージェントBは以前のフォーマットを期待しているため、動作が停止します。プロンプトに頼るのではなく、Pydanticのような構造化出力を使用してください。
レースコンディション (Race conditions): 5つのワーカーを同時に実行する。3つは終了したが、2つはまだ実行中である。アグリゲーターが不完全なデータで早期に処理を開始してしまう。これはテストでは機能しますが、本番環境では失敗します。すべてのタスクが完了するのを待つために、バリア（barrier）を使用してください。
私の最初のシステムは巧妙でしたが、乱雑でした。動的なルーティングと暗黙的なハンドオフを使用していました。それは実際のトラフィックにさらされるまで機能していましたが、ある時、サイレントに失敗しました。
私の2番目のシステムは、見た目は美しくありませんでしたが、正しいものでした。すべてのハンドオフに型定義されたコントラクト（typed contract）を使用し、すべての失敗を明示的に扱い、すべてのエージェントを隔離しました。
現在のシステムはその両方を組み合わせています。2番目のバージョンの規律（discipline）を用いつつ、退屈なコードはフレームワークの背後に隠しています。
マルチエージェント・システムを構築するなら、まずは「見た目は美しくないが正しいバージョン」から始めてください。最初から巧妙になろうとしてはいけません。まずは本番環境で正しく動作させること、それからエレガントに仕上げるのです。
ハンドオフの問題が簡単になることはありません。しかし、それに驚かされることはなくなります。
Source: https://dev.to/mrclaw207/your-agents-are-fine-the-handoff-between-them-isnt-2dij
Optional learning community: https://t.me/GyaanSetuAi