エージェントのデモは動く。しかし、実務では動かない。
ほとんどのエージェント・アーキテクチャは、実務では機能しません。
デモでは、単一のタスクに対して素早いレスポンスを返せば、それらしく見えます。しかし、実際の業務には保険の請求、セールス・シーケンス、あるいはデータの照合などが含まれます。これらのタスクには時間と多くのステップが必要です。
問題はステートレス性です。ほとんどのエージェントは、やり取りのたびにコンテキストをゼロから再構築します。その結果、推論の連鎖やそれまでの進捗が失われてしまいます。最終的には、状況を把握しているふりをするだけの「礼儀正しいAI」になってしまうのです。
Google CloudのエキスパートであるAddy Osmani氏とShubham Saboo氏は、これを解決するための5つのパターンを共有しました。その内容は以下の通りです。
Checkpoint-and-Resume エージェントをサーバーのように扱ってください。数ステップの作業ごとに進捗を保存します。もし1,000個のタスクのうち201個目でエージェントが失敗した場合、201個目から再開できるようにします。ゼロからやり直してはいけません。
Delegated Approval 人間による承認にSlackやメールを使うのはやめましょう。これらのツールはコンテキストを断絶させてしまいます。エージェントはその場で一時停止させます。人間が応答したときに即座に再開できるよう、完全な状態（ステート）を保持したままにします。リクエストやエラーの管理には、構造化されたインボックスを使用してください。
Memory-Layered Context 長期メモリとワーキングメモリを分離します。長期メモリはセッションをまたいだ知識を保存し、ワーキングメモリは現在のタスクを処理します。エージェントがエッジケースから悪い習慣を学んでしまう「メモリ・ドリフト（記憶の漂流）」を防がなければなりません。アイデンティティ管理とガバナンス・レイヤーを使用して、不正なデータをブロックしてください。
Ambient Processing サポートチケットやデータベースの変更といったデータストリームを監視するエージェントを構築します。ルールをエージェントにハードコードしてはいけません。ルールは外部のガバナンス・レイヤーに配置します。これにより、一箇所でルールを更新するだけで、エージェント群全体に適用させることができます。
Fleet Orchestration コーディネーター・エージェントを使用して、スペシャリスト・エージェントを管理します。各スペシャリストは独自のツールとアイデンティティを持ちます。これは分散システムで使用されるワーカー・パターンに従ったものです。これにより、システム全体を壊すことなく、特定のスペシャリストだけを更新できます。
最大のリスクはメモリ・ドリフトです。
人々はプロンプトに集中しがちですが、エージェントの振る舞いが時間の経過とともにどのように変化するかを無視しています。もしエージェントが悪かったり奇妙なやり取りから学習してしまうと、あなたが書いたコード通りの動きをしなくなってしまいます。
エージェントはマイクロサービスのように扱う必要があります。アイデンティティ、レジストリ、そして厳格なポリシー適用が必要です。
自問してみてください。「私のエージェントが停止することなく実行しなければならない、最も長いタスクは何だろうか？」と。もしその答えが数時間や数日であるなら、これらのパターンが必要になります。
Source: https://dev.to/archit_aggarwal_5310522d5/your-agent-demo-works-your-agent-doesnt-88l
Optional learning community: https://t.me/GyaanSetuAi