LiteLLM Agent Platform の紹介:Kubernetes ベースのセルフホスト型インフラストラクチャレイヤー。本番環境での分離されたエージェントサンドボックスと永続セッション管理を実現
BerriAI が LiteLLM Agent Platform をオープンソース化しました。これは、本番環境で AI エージェントを実行するためのセルフホスト型インフラストラクチャであり、チーム/コンテキストごとに分離されたサンドボックスと、再起動後も持続するセッションを提供します。Kubernetes 上に構築され、LiteLLM AI Gateway と統合してステートフルなエージェントワークロードを処理し、Next.js ダッシュボード、非同期ワーカー、シークレットの自動環境変数注入を備えています。
ローカルスクリプトで AI エージェントを実行するのは簡単です。しかし、本番環境でチーム間、再起動をまたいで、コンテキストごとに分離された環境でそれらを確実に実行するのはまったく別の問題です。BerriAI(LiteLLM AI Gateway の背後にある企業)は、この問題に対する専用のソリューションとして LiteLLM Agent Platform をオープンソース化しました。このプラットフォームは、本番環境で複数のエージェントを実行するためのシンプルでセルフホスト型のインフラストラクチャプラットフォームと説明されています。
このプラットフォームは、エージェントをスケーリングする際に発生する重要な問題を解決します。エージェントはステートフルです。セッション履歴、ツール呼び出し結果、複数ターンにわたる中間推論を保持します。エージェントを実行するコンテナがクラッシュしたり、再起動したり、デプロイ中に置き換えられたりすると、明示的に管理されない限り、そのセッション状態は失われます。同時に、異なるチームは異なるランタイム環境、ツール、シークレット、アクセス範囲を必要とすることが多く、すべてのエージェントを1つの共有コンテナに入れることはできません。このプラットフォームは、チームおよびコンテキストごとのサンドボックスと、Pod の再起動やアップグレードをまたいだセッション継続性という2つの中核機能を管理します。
アーキテクチャ的には、このプラットフォームは LiteLLM v2 管理エージェントのためのスタンドアロンの Next.js ダッシュボードであり、セッションチャット、エージェント CRUD、ライブステータスをカバーします。コードベースは主に TypeScript(92.8%)で、プロビジョニング用のシェルスクリプト、コンテナ化用の Dockerfile、ダッシュボード UI 用の CSS が含まれます。アーキテクチャは関心事を明確に分離しています。Web プロセスはポート3000で実行され Next.js ダッシュボードを提供します。ワーカープロセスは非同期エージェントタスクを処理します。Postgres は永続ストアとして使用され、スキーママイグレーションは起動時に init コンテナとして実行され、アプリケーションが起動する前にデータベースが常に正しい状態になります。
サンドボックス層(エージェントが実際に実行される分離されたランタイム環境)では、サンドボックスは Kubernetes 上の kubernetes-sigs/agent-sandbox CRD を介して実行されます。ローカル開発には kind(Kubernetes in Docker)を使用します。kind を使用すると、Docker コンテナをノードとして使用してローカルに完全な Kubernetes クラスターを起動でき、クラウドプロバイダーは不要です。agent-sandbox CRD はkubernetes-sigs からの Kubernetes 拡張機能で、プラットフォームがインストールして個々のサンドボックス環境のライフサイクルを管理します。
プラットフォームには、harnesses/opencode の下にあるハーネスシステムも含まれており、Claude Code や OpenAI Codex などのコーディングエージェントを、クレデンシャル管理用の vault プロキシを使用して分離されたサンドボックス内で実行するための設定が含まれています。BerriAI チームは別の litellm-agent-runtime リポジトリも維持しており、これは LiteLLM プロキシによってプロビジョニングされたセッションごとの VM 内で実行されるコーディングエージェントランタイムとして説明されており、設計は汎用的で、カスタマイズはハーネス設定またはハイドレートペイロードを介して行われます。
注目すべき実用的な詳細の1つは、サンドボックスコンテナ内の環境変数の処理方法です。.env 内の CONTAINER_ENV_ プレフィックスが付いた変数はすべて、プレフィックスが削除されて各サンドボックスコンテナに自動的に注入されます。たとえば、CONTAINER_ENV_GITHUB_TOKEN=ghp_... の場合、コンテナは GITHUB_TOKEN=ghp_... を認識します。これにより、チームはコンテナイメージを変更せずにシークレットをサンドボックスエージェントセッションに渡すクリーンな方法を提供します。
ローカル開発の前提条件は、Docker Desktop、kind、kubectl、helm、および LiteLLM ゲートウェイです。ローカルで開始するためにクラウド認証情報は必要ありません。クイックスタートは2つのコマンドです:bin/kind-up.sh(冪等で、kind クラスターをプロビジョニングし、agent-sandbox コントローラーをインストールし、ハーネスイメージをロードします)と docker compose up(Postgres を起動し、スキーママイグレーションを実行し、ポート3000で Web プロセスとワーカーを起動します)。本番環境へのデプロイには、サンドボックスクラスターに AWS EKS、Web およびワーカープロセスに Render を使用することを推奨します。
LiteLLM Agent Platform は既存の LiteLLM エコシステムの上にあるレイヤーであり、その代替ではありません。LiteLLM のコアは Python SDK とプロキシサーバー(AI ゲートウェイ)であり、OpenAI 形式で100以上の LLM API を呼び出し、コスト追跡、ガードレール、負荷分散、ログ記録を提供します。Agent Platform は実行中の LiteLLM ゲートウェイを依存関係として消費し、その上にエージェントオーケストレーションとセッション管理インフラストラクチャを構築します。モデルルーティング、コスト追跡、レート制限はゲートウェイ層に残り、サンドボックス分離、セッション継続性、管理ダッシュボードは Agent Platform が処理します。