BerriAI опубликовала исходники LiteLLM Agent Platform для изоляции и сохранения сессий stateful‑агентов

BerriAI выложила в открытый доступ LiteLLM Agent Platform — самохостируемый Kubernetes‑слой для запуска множества stateful‑агентов с изолированными рантаймами и сохранением сессий при перезапусках;

BerriAI опубликовала исходный код LiteLLM Agent Platform — самохостируемой инфраструктуры на Kubernetes, предназначенной для продакшен‑запуска множества stateful‑агентов с изоляцией сессий и сохранением состояния через рестарты. Это прямой ответ на трудности масштабирования stateful‑агентов за пределами одиночного скрипта: платформа отделяет управление сессиями и рантаймами от логики самих агентов, что упрощает эксплуатацию и повышает надежность.

В комплект входит веб‑интерфейс на Next.js для управляемых агентами LiteLLM v2: чат‑сессии, CRUD‑операции с агентами и живой статус работы. Кодовая база преимущественно на TypeScript (92.8%), дополнена Shell‑скриптами для provision, Dockerfile для контейнеризации и CSS для интерфейса. Архитектура выделяет отдельный веб‑процесс (порт 3000) и воркер для асинхронных задач; Postgres используется как персистентное хранилище, а миграция схемы выполняется через init‑контейнер при старте.

Слой сандбоксов реализован через Kubernetes‑CRD kubernetes‑sigs/agent‑sandbox; для локальной разработки авторы предлагают kind (Kubernetes in Docker). В репозитории есть каталог harnesses/opencode с конфигурациями для запуска кодинг‑агентов — например, Claude Code или OpenAI Codex — внутри изолированных сандбоксов. Для управления секретами и учётными данными используется vault‑proxy, что помогает безопасно подключать внешние сервисы к изолированным рантаймам. Отдельно поддерживается репозиторий litellm‑agent‑runtime — рантайм кодинг‑агента, работающий внутри per‑session VM, которые провижинятся через LiteLLM‑прокси. Базовая логика рантайма универсальна и настраивается через harness или hydrate‑payload, что позволяет адаптировать поведение агентов и окружения без изменения ядра платформы.

Практические детали включают автоматическую инъекцию переменных окружения: значения из.env с префиксом CONTAINER_ENV_ попадают в контейнеры с удалённым префиксом (пример: CONTAINER_ENV_GITHUB_TOKEN → GITHUB_TOKEN). Для продакшен‑развёртывания авторы рекомендуют держать кластер сандбоксов в AWS EKS, а веб и воркер — на Render. Для локального старта облачные креды не требуются: достаточно Docker Desktop, kind, kubectl, helm и LiteLLM gateway. Быстрый старт сведен к двум командам: bin/kind-up.sh-идемпотентно создаёт кластер agent‑sbx, ставит controller и загружает harness‑image; и docker compose up-поднимает Postgres, запускает миграцию схемы, веб‑сервис на порту 3000 и воркер. Исходники и подробные инструкции опубликованы в репозитории проекта.