サンドボックスを超えて：耐久性のあるAIエージェントの構築
本番環境のAIエージェントにとって、サンドボックスだけでは不十分です。
ほとんどの開発者は、エージェントをメモリ内の単純なループとして構築します。LLMが観察し、決定し、実行し、そして繰り返す。これはラボ内では機能しますが、現実世界では失敗します。
なぜメモリ内のループは失敗するのでしょうか？
- 長期タスク：エージェントの完了に数日かかる場合や、人間の承認を待つ必要がある場合、プロセスを走らせ続けることはCPUとメモリの無駄になります。
- クラッシュからの復旧ができない：システムがクラッシュしたりネットワークが切断されたりすると、状態（ステート）がすべて失われます。中断した場所から再開することができません。
- 複雑性：膨大な追加コードを書かない限り、複数のエージェント同士の連携は困難です。
OrkesのCTOであるVirein Baraiya氏は、より良い方法を提案しています。それは「関心の分離（Separate your concerns）」です。
アクションにはサンドボックスのみを使用してください。リスクのあるツールコードを安全に実行するためにサンドボックスを利用します。
推論には耐久性のあるランタイムを使用してください。LLMはプランを提供し、ランタイムシステムが実行と状態を管理します。
彼はこれを解決するために2つのツールを紹介しています。
- Netflix Conductor これはワークフローエンジンです。台帳（レジャー）として機能し、すべてのLLM呼び出しとツールの使用をデータベースに記録します。
- オンデマンドの停止をサポートしています。エージェントが人間を待機する場合、システムはワークフローを一時停止し、すべてのメモリを解放します。
- 数ヶ月後に起動してタスクを完了させることも可能です。
- Agent Span これはConductorの上に構築されたランタイムです。翻訳機として機能します。
- LangGraphやOpenAI SDKなどの既存のツールを使用できます。
- Agent Spanは、ビジネスロジックを書き換えることなく、エージェントのコードを耐久性のあるワークフローに変換します。
このアーキテクチャには、3つの大きな利点があります。
- ガードレール：LLMではなく、フレームワークがルールを制御します。これにより、ハルシネーション（幻覚）による被害を防ぎます。
- 完全な監査：数ヶ月後でも、エージェントがなぜその決定を下したのかを正確に確認できます。プロセスをリプレイすることも可能です。
- テストの向上：一つのLLMの出力を変更し、システムの他の部分がどのように反応するかを確認できます。
開発者への最後のアドバイス：ビジネスコンテキストに集中してください。モデルは変わります。フレームワークも変わります。しかし、あなたのビジネスがタスクを実行する独自の方法こそが、真の「堀（moat）」となります。
出典: https://dev.to/cognitalk/chao-yue-sha-xiang-wei-ai-agent-gou-jian-chi-jiu-hua-yun-xing-shi-2i9i
オプションの学習コミュニティ: https://t.me/GyaanSetuAi