介紹 LiteLLM Agent Platform：基於 Kubernetes 的自託管基礎設施層，用於生產環境中的隔離代理沙箱和持久會話管理

在本地腳本中運行 AI 代理非常簡單。但在生產環境中跨團隊、跨重啓、為每個上下文提供隔離環境來可靠地運行它們則完全是另一個問題。BerriAI，作為 LiteLLM AI Gateway 背後的公司，現正開源一個針對此問題的專門解決方案：LiteLLM Agent Platform。該平台被描述為一個簡單、自託管的基礎設施平台，用於在生產環境中運行多個代理。

該平台解決了規模化代理時遇到的關鍵問題。代理是有狀態的：它們攜帶會話歷史、工具調用結果和跨輪次的中間推理。如果運行代理的容器崩潰、重啓或在部署期間被替換，除非有明確的管理機制，否則會話狀態將丟失。同時，不同團隊通常需要不同的運行時環境、工具、秘密和訪問權限，因此不能將所有代理放入一個共享容器中。該平台管理兩個核心能力：每個團隊和每個上下文的沙箱，以及跨 Pod 重啓和升級的會話連續性。

從架構上看，該平台是一個獨立的 Next.js 儀表板，用於管理 LiteLLM v2 託管代理，涵蓋會話聊天、代理 CRUD 和實時狀態。代碼庫主要使用 TypeScript（92.8%），幷包含 Shell 腳本用於配置、Dockerfile 用於容器化以及 CSS 用於儀表板 UI。架構清晰分離了關注點：一個 Web 進程運行在端口 3000，提供 Next.js 儀表板；一個工作進程處理異步代理任務；Postgres 作為持久化存儲；一個模式遷移作為初始化容器在啓動時運行，確保在應用程序啓動前數據庫處於正確狀態。

對於沙箱層——即代理實際執行的隔離運行時環境——沙箱通過 Kubernetes 上的 kubernetes-sigs/agent-sandbox CRD 運行。本地開發使用 kind（Kubernetes in Docker），允許在本地使用 Docker 容器作為節點啓動完整的 Kubernetes 集羣，無需雲提供商。agent-sandbox CRD 是一個來自 kubernetes-sigs 的 Kubernetes 擴展，平台安裝它來管理各個沙箱環境的生命週期。

該平台還包含一個位於 harnesses/opencode 下的 harness 系統，其中包含運行編碼代理（如 Claude Code 或 OpenAI Codex）的配置，這些代理在隔離沙箱中運行，並帶有用於憑據管理的 vault 代理。BerriAI 團隊還維護一個單獨的 litellm-agent-runtime 倉庫，描述為在每個會話虛擬機中運行的編碼代理運行時，這些 VM 由 LiteLLM 代理提供，設計為通用的，通過 harness 配置或啓動載荷進行定製。

一個值得注意的實用細節是如何處理沙箱容器中的環境變量。.env 中任何以 CONTAINER_ENV_ 為前綴的變量都會自動注入到每個沙箱容器中，並去除前綴。例如，CONTAINER_ENV_GITHUB_TOKEN=ghp_... 意味着容器看到 GITHUB_TOKEN=ghp_... 這為團隊提供了一種乾淨的方式，無需修改容器鏡像即可將秘密傳遞到沙箱代理會話中。

對於本地開發，先決條件包括 Docker Desktop、kind、kubectl、helm 和一個 LiteLLM 網關。無需雲憑據即可在本地開始。快速啓動只需兩個命令：bin/kind-up.sh（冪等，配置 kind 集羣並安裝 agent-sandbox 控制器）和 docker compose up（啓動 Postgres、運行模式遷移、啓動 Web 進程和工作進程）。生產部署推薦使用 AWS EKS 作為沙箱集羣，Render 用於 Web 和工作進程。

LiteLLM Agent Platform 是現有 LiteLLM 生態系統之上的一個層，而不是替代品。LiteLLM 的核心是一個 Python SDK 和代理服務器——一個 AI 網關——以 OpenAI 格式調用 100 多個 LLM API，並提供成本跟蹤、護欄、負載均衡和日誌記錄。Agent Platform 依賴一個運行的 LiteLLM 網關，並在其上構建代理編排和會話管理基礎設施。模型路由、成本跟蹤和速率限制仍保留在網關層，而沙箱隔離、會話連續性和管理儀表板由 Agent Platform 處理。