介紹 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 處理。