BerriAI —— LiteLLM gateway 背后的团队 —— 在 5 月 8 日开源了 LiteLLM Agent Platform,一层自托管的基础设施,用来在 Kubernetes 上跑生产级 agent。技术栈:Next.js dashboard 做 agent 的 CRUD 和 session chat,一个 worker process 处理异步任务,PostgreSQL 持久化 session 状态,以及一个 Kubernetes 沙盒集群,每个agent 通过 `kubernetes-sigs/agent-sandbox` CRD 跑在一个隔离的 pod 里。MIT 协议、alpha public preview,代码仓库:github.com/BerriAI/litellm-agent-platform。平台需要一个正在运行的 LiteLLM gateway,以路由到 100+ LLM provider。
架构层面有意思的细节是这个 Kubernetes 原语。`kubernetes-sigs/agent-sandbox` 是 Kubernetes SIG 出的一个 CRD,把"agent 执行的隔离环境"标准化为 K8s 的一级资源类型。如果这个 CRD 被广泛采用,agent 沙盒就跟任何其他 K8s workload 一样可移植。BerriAI 选择在这个 CRD 上面盖,而不是自己造隔离原语,是在押 SIG 的方向。Marktechpost 的写法里没说底层沙盒到底用的是 gVisor、Firecracker、还是只是 namespace 隔离 —— 这取决于 CRD 的实现,跟平台层无关。环境变量通过 `CONTAINER_ENV_` 前缀约定注入(`CONTAINER_ENV_GITHUB_TOKEN=ghp_...` 在沙盒里就是 `GITHUB_TOKEN=ghp_...`),session 持久化到 Postgres,schema 迁移作为 init container 在启动时跑。
对照 Anthropic 这周早些时候发布的 Routines:Routines 跑在 Anthropic 自家云上、绑定 repo 事件和 HTTP 触发、未公开定价。LiteLLM Agent Platform 跑在你自己的 K8s 集群上、MIT 协议、通过 LiteLLM gateway 的 100+ provider 路由器做 provider 中立。同一个问题陈述 —— 你的生产 agent 跑哪 —— 哲学相反。对于有监管或 data-locality 约束的团队(healthcare、金融、EU 居留),自托管加多 provider 是唯一可行的形态。对于没这些约束的团队,Routines 的"Anthropic 替你跑"是低运维形态。这个分裂比双方营销暗示的更宽:LiteLLM Agent Platform 不号称在 first-party Claude tooling 集成上跟 Routines 平齐,Routines 也不号称在 provider 中立上跟 LiteLLM 平齐。
周一上手:如果你这季度在选生产 agent 跑哪,矩阵是云端单一 provider(Anthropic Routines、OpenAI Assistants、AWS Bedrock Agents)vs. 自托管多 provider(LiteLLM Agent Platform、自建在 Modal 或 E2B 上)。LiteLLM Agent Platform 还在 alpha —— 别把承重的 workload 押在 alpha 上 —— 但它的架构选择(K8s SIG CRD、Postgres 状态、环境变量注入约定)告诉你 beta 时它会是什么样。如果你已经在跑 LiteLLM gateway 做 provider 路由,Agent Platform 是一个增量部署,不是迁移。盯紧 `kubernetes-sigs/agent-sandbox` 的上游成熟度 —— 那才是 lock-in 的问题,而不是 BerriAI 自家的 dashboard。