在本地运行 AI Agent 脚本并不复杂，但要在生产环境中跨团队、跨重启、且为每个上下文提供隔离环境来稳定运行，则完全是另一回事。为此，LiteLLM AI 网关的开发团队 BerriAI 正式开源了 LiteLLM Agent Platform。这是一个专为生产环境设计的、简单且自托管的基础设施平台，旨在运行和管理多个 AI Agent。
解决的核心痛点
当尝试将 Agent 扩展到单个进程之外时，会遇到许多棘手问题。Agent 具有状态：它们跨轮次携带会话历史、工具调用结果和中间推理过程。如果运行 Agent 的容器在部署期间崩溃、重启或被替换，除非有明确的管理机制，否则这些会话状态就会丢失。此外，不同的团队通常需要不同的运行环境、不同的工具、不同的密钥和不同的访问范围，这意味着不能将所有 Agent 放入同一个共享容器中。
LiteLLM Agent Platform 主要管理两件事：团队专属与上下文专属的沙箱（Sandboxes），以及跨 Pod 重启和升级的会话持续性。这两个功能构成了该平台提供的核心基础设施基础。
架构与技术栈
该平台是一个独立的 Next.js 控制面板，用于管理 LiteLLM v2 托管的 Agent，涵盖会话聊天、Agent 增删改查（CRUD）和实时状态监控。其代码库主要由 TypeScript（占 92.8%）编写，配有用于初始化的 Shell 脚本、用于容器化的 Dockerfile，以及用于控制面板 UI 的 CSS。
其架构实现了清晰的关注点分离：一个运行在 3000 端口的 Web 进程负责提供 Next.js 控制面板服务；一个 Worker 进程负责处理异步 Agent 任务。Postgres 被用作持久化后端存储，并且在启动时会运行一个 init 容器来进行数据库 Schema 迁移，确保应用在启动前数据库始终处于正确状态。
沙箱隔离与运行机制
对于沙箱层（即 Agent 实际执行的隔离运行环境），沙箱通过 kubernetes-sigs/agent-sandbox CRD 运行在 Kubernetes 上。本地开发则使用 kind（Kubernetes in Docker），允许开发者使用 Docker 容器作为节点在本地启动完整的 Kubernetes 集群。agent-sandbox CRD 是来自 Kubernetes 社区的自定义资源定义，平台通过安装它来管理各个沙箱环境的生命周期。
此外，该平台还包含一个位于 harnesses/opencode 路径下的 Harness（安全套件）系统，其中包含了在隔离沙箱中运行 Claude Code 或 OpenAI Codex 等编码 Agent 的配置，并使用 Vault 代理进行凭据管理。BerriAI 团队还维护了一个独立的 litellm-agent-runtime 仓库，这是一个运行在由 LiteLLM 代理配置的每会话虚拟机（VM）内部的编码 Agent 运行时。该运行时设计通用，支持通过 Harness 配置进行定制。
【AgentUpdate 深度解析】LiteLLM Agent Platform 的推出，标志着 AI Agent 基础设施正在加速走向工业级成熟。传统的 Agent 框架（如 LangChain、AutoGPT）多侧重于应用层逻辑和多 Agent 协同，但在生产环境落地时，往往在多租户隔离、状态持久化和高并发执行上面临巨大的工程壁垒。LiteLLM 创新性地借助 Kubernetes 的云原生生态（特别是 agent-sandbox CRD），将 AI 安全沙箱与会话持久化抽象为底层基础设施标准，这与 Fly.io 或 E2B 等沙箱云服务的思路不谋而合。对于企业而言，自托管的 K8s 方案极大降低了数据合规风险。长远来看，这种“网关 + 运行时 + 安全隔离”的组合拳，不仅巩固了 LiteLLM 作为企业级大模型入口的地位，更为未来分布式 Agent 的并发调度与工程落地奠定了坚实的基石。
