介绍 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 处理。