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。