Ejecutar agentes de IA en un script local es sencillo. Ejecutarlos de manera confiable en producción en todos los equipos, en todos los reinicios y con entornos aislados por contexto es un problema completamente diferente. BerriAI, la empresa detrás de LiteLLM AI Gateway, ahora ofrece una respuesta abierta a ese problema: LiteLLM Agent Platform. La plataforma se describe como una plataforma de infraestructura simple y autohospedada para ejecutar múltiples agentes en producción.
¿Qué problema resuelve?
Es útil comprender qué sucede cuando se intenta ampliar los agentes más allá de un solo proceso. Los agentes tienen estado: llevan el historial de sesiones, los resultados de las llamadas de herramientas y el razonamiento intermedio a lo largo de los turnos. Si el contenedor que ejecuta su agente falla, se reinicia o se reemplaza durante una implementación, el estado de la sesión desaparece a menos que algo lo administre explícitamente. Al mismo tiempo, diferentes equipos a menudo necesitan diferentes entornos de ejecución, diferentes herramientas, diferentes secretos, diferentes alcances de acceso, lo que significa que no se pueden colocar todos los agentes en un contenedor compartido.
La plataforma gestiona dos cosas: entornos sandbox por equipo y por contexto, y la continuidad de la sesión entre reinicios y actualizaciones de pods. Estas dos capacidades son las primitivas de infraestructura central que proporciona la plataforma.
Arquitectura y pila técnica
La plataforma es un panel Next.js independiente para agentes administrados LiteLLM v2, que cubre sesiones de chat, CRUD de agente y estado en vivo. La base de código es principalmente TypeScript (92,8%), con scripts de Shell para el aprovisionamiento, un Dockerfile para la contenedorización y CSS para la interfaz de usuario del panel.
La arquitectura separa claramente las preocupaciones. Un proceso web se ejecuta en el puerto 3000 y sirve al panel de Next.js. Un proceso de trabajo maneja tareas de agente asíncrono. Postgres se utiliza como almacén de respaldo persistente y una migración de esquema se ejecuta como un contenedor de inicio al inicio, por lo que la base de datos siempre está en el estado correcto antes de que se inicie la aplicación.
Para la capa de sandbox (el entorno de ejecución aislado donde los agentes realmente se ejecutan), los sandboxes se ejecutan en Kubernetes a través del CRD kubernetes-sigs/agent-sandbox. El desarrollo local utiliza tipos. Si aún no está familiarizado con él: kind (Kubernetes en Docker) le permite activar un clúster de Kubernetes completo localmente utilizando contenedores Docker como nodos, sin necesidad de un proveedor de nube. Agent-sandbox CRD (Definición de recursos personalizados) es una extensión de Kubernetes de kubernetes-sigs que la plataforma instala para gestionar el ciclo de vida de entornos sandbox individuales.
La plataforma también incluye un sistema de arnés bajo arneses/código abierto, que contiene la configuración para ejecutar agentes de codificación, como Claude Code u OpenAI Codex, dentro de entornos aislados con un proxy de bóveda para la gestión de credenciales. El equipo de BerriAI también mantiene un repositorio separado de litellm-agent-runtime, descrito como un tiempo de ejecución de agente de codificación que se ejecuta dentro de máquinas virtuales por sesión aprovisionadas por un proxy LiteLLM, genérico por diseño, con personalización que se realiza mediante la configuración del arnés o una carga útil de hidrato.
Un detalle práctico que vale la pena destacar es cómo se manejan las variables de entorno en los contenedores sandbox. Cualquier elemento en .env con el prefijo CONTAINER_ENV_ se inyecta en cada contenedor de espacio aislado con el prefijo eliminado; por ejemplo, CONTAINER_ENV_GITHUB_TOKEN=ghp_… significa que el contenedor ve GITHUB_TOKEN=ghp_… Esto brinda a los equipos una forma limpia de pasar secretos a sesiones de agente en espacio aislado sin modificar las imágenes del contenedor.
https://github.com/BerriAI/litellm-agent-platform
Empezando
Los requisitos previos para el desarrollo local son Docker Desktop, kind, kubectl, helm y una puerta de enlace LiteLLM. No se requieren credenciales en la nube para comenzar localmente. El inicio rápido consta de dos comandos:
bin/kind-up.sh ventana acoplable componer
bin/kind-up.sh es idempotente: aprovisiona un clúster de tipo llamado agent-sbx, instala el controlador agent-sandbox y carga la imagen del arnés. Docker Compose inicia Postgres, ejecuta la migración del esquema e inicia el proceso web en el puerto 3000 junto con el trabajador.
Para la implementación en producción, la ruta recomendada es AWS EKS para el clúster de espacio aislado y Render para los procesos web y de trabajo. bin/eks-up.sh aprovisiona el clúster EKS y un Render Blueprint proporciona una opción de implementación con un solo clic.
Relación con la puerta de enlace LiteLLM
La plataforma de agentes es una capa adicional al ecosistema LiteLLM existente, no un reemplazo del mismo. El núcleo de LiteLLM es un SDK de Python y un servidor proxy (una puerta de enlace de IA) que llama a más de 100 API de LLM en formato OpenAI, con seguimiento de costos, barreras de seguridad, equilibrio de carga y registro, y admite proveedores como Bedrock, Azure, OpenAI, VertexAI, Cohere, Anthropic, SageMaker, HuggingFace, vLLM y NVIDIA NIM. La plataforma de agentes consume una puerta de enlace LiteLLM en ejecución como una dependencia y construye una infraestructura de orquestación de agentes y administración de sesiones sobre ella. El enrutamiento del modelo, el seguimiento de costos y la limitación de tarifas permanecen en la capa de puerta de enlace. El aislamiento de la zona de pruebas, la continuidad de la sesión y el panel de administración están a cargo de la plataforma del agente.
Explicador visual de Marktechpost
Descripción general
Conceptos
Arquitectura
Requisitos previos
Inicio rápido
Producción
01 / 06
¿Qué es la plataforma de agentes LiteLLM?
BerriAI abrió esta plataforma el 8 de mayo de 2026. Es una capa de infraestructura autohospedada para ejecutar múltiples agentes de IA en producción, construida sobre LiteLLM AI Gateway.
🧱
Autohospedado
Se ejecuta completamente en su propia infraestructura. Ningún dato sale de su entorno. Adecuado para industrias reguladas y equipos con requisitos de residencia de datos.
🤖
Multiagente
Diseñado para ejecutar varios agentes en paralelo, con aislamiento total entre equipos y contextos mediante entornos aislados por sesión.
🔁
Continuidad de la sesión
Las sesiones del agente persisten durante los reinicios y las actualizaciones del pod, por lo que el trabajo con estado no se pierde cuando se reemplazan los contenedores.
⚡
Código abierto (MIT)
Código totalmente abierto bajo licencia MIT. Repositorio: github.com/BerriAI/litellm-agent-platform. Archivar problemas y contribuir directamente.
Conocimiento previo
Esta guía asume familiaridad con Docker, uso básico de la línea de comandos y una comprensión general de qué es un agente de IA (un modelo que llama a herramientas y ejecuta tareas de varios pasos). La experiencia de Kubernetes ayuda, pero no es obligatoria.
02 / 06
Conceptos clave que debe conocer primero
Antes de ejecutar la plataforma, comprenda estos cuatro componentes básicos. Aparecen a lo largo de la instalación y configuración.
A
Puerta de enlace LiteLLM
La puerta de enlace AI subyacente de la que depende la plataforma del agente. Enruta solicitudes a más de 100 proveedores de LLM (OpenAI, Anthropic, Bedrock, VertexAI, etc.) utilizando una API unificada de formato OpenAI. La plataforma del agente no incluye la puerta de enlace, debe tener una ejecutándose por separado y apuntar la plataforma hacia ella.
B
Salvadera
Un entorno de contenedor aislado donde se ejecuta una sesión de un único agente. Cada sandbox es independiente, lo que significa que un agente no puede acceder al sistema de archivos, los secretos o el estado de otro. Los entornos sandbox se aprovisionan y se eliminan por sesión mediante el CRD (definición de recursos personalizados) de kubernetes-sigs/agent-sandbox .
do
Aprovechar
Una capa de configuración que define cómo se ejecuta un tipo específico de agente de codificación (como Claude Code u OpenAI Codex) dentro de un sandbox. La plataforma se envía con un arnés de código abierto en arneses/opencode/ . La imagen del arnés se carga en el grupo de tipos durante la configuración.
D
CRD (Definición de recursos personalizados)
Una extensión de Kubernetes que le permite definir nuevos tipos de recursos. La plataforma utiliza el CRD kubernetes-sigs/agent-sandbox para enseñarle a su clúster de Kubernetes cómo administrar los entornos aislados de agentes como recursos de primera clase, de la misma manera que administra pods o implementaciones.
03 / 06
Cómo está estructurada la plataforma
La plataforma tiene cuatro componentes principales. Comprender cómo se conectan ayuda a la hora de depurar o implementar en producción.
Componente Qué hace Tech web (:3000) Panel de control Next.js. Proporciona la interfaz de usuario para sesiones de chat, operaciones CRUD de agentes y monitoreo de estado en vivo. Next.js, trabajador de TypeScript Proceso en segundo plano que maneja tareas del agente asíncrono, desacoplado del servidor web. TypeScript postgres Almacén de respaldo persistente para el estado de la sesión, configuraciones del agente y metadatos. La migración de esquemas se ejecuta automáticamente como un contenedor de inicio al inicio. Clúster de zona de pruebas de PostgreSQL Clúster de Kubernetes donde se ejecutan zonas de pruebas de agentes individuales, administrado a través del controlador CRD de zona de pruebas del agente. Localmente: amable. En producción: AWS EKS. Kubernetes (tipo/EKS)
Separación de preocupaciones
La puerta de enlace LiteLLM maneja el enrutamiento de modelos, el seguimiento de costos, la limitación de tasas y las barreras de seguridad. La plataforma de agentes maneja el ciclo de vida de la zona de pruebas, la administración de sesiones y el panel de administración. Se ejecutan como servicios independientes y la plataforma del agente consume la puerta de enlace como una dependencia.
04 / 06
Requisitos previos antes de comenzar
Instale y verifique estas herramientas antes de ejecutar cualquier comando de configuración. El inicio rápido no funcionará sin los cinco.
1
Escritorio acoplable
Se requiere para construir y ejecutar contenedores y para alimentar el tipo (que ejecuta nodos de Kubernetes como contenedores Docker). Descárguelo desde docker.com/products/docker-desktop. Verificar con:
ventana acoplable –versión
2
tipo (Kubernetes en Docker)
Se utiliza para aprovisionar un clúster de Kubernetes local para ejecutar entornos sandbox. Instale a través de Homebrew en macOS ( tipo de instalación de cerveza ) o desde kind.sigs.k8s.io. Verificar con:
tipo –versión
3
kubectl
La herramienta de línea de comandos de Kubernetes. Utilizado por los scripts de configuración para interactuar con el clúster tipo. Instale desde kubernetes.io/docs/tasks/tools. Verificar con:
versión kubectl –cliente
4
timón
El administrador de paquetes de Kubernetes. Se utiliza para instalar el controlador de agente-sandbox en el clúster tipo. Instale desde helm.sh/docs/intro/install. Verificar con:
versión del timón
5
Una puerta de enlace LiteLLM en funcionamiento
La plataforma del agente requiere una URL de puerta de enlace LiteLLM para enrutar las llamadas del modelo. Si no tiene uno en ejecución, comience con el inicio rápido oficial de LiteLLM en docs.litellm.ai. Apuntará la plataforma del agente a esta URL durante la configuración.
05 / 06
Inicio rápido local
Clona el repositorio y ejecuta dos comandos para que la plataforma completa se ejecute localmente. No se necesitan credenciales de nube para el desarrollo local.
1
Clonar el repositorio
Extraiga el repositorio de GitHub:
clon de git https://github.com/BerriAI/litellm-agent-platform cd litellm-agent-platform
2
Configure su archivo .env
Copie el archivo env de ejemplo y complete la URL de su puerta de enlace LiteLLM y cualquier secreto:
cp .env.example .env # Edite .env y configure su LITELLM_GATEWAY_URL y otros valores requeridos
3
Aprovisionar el clúster de tipo local
Este script es idempotente, lo que significa que es seguro ejecutarlo varias veces. Aprovisiona un tipo de clúster llamado agent-sbx , instala el controlador de la zona de pruebas del agente a través de helm y carga la imagen del arnés:
bin/kind-up.sh
4
Iniciar todos los servicios
Arranca Postgres, ejecuta la migración del esquema como un contenedor de inicio e inicia el servidor web en el puerto 3000 y el proceso de trabajo:
ventana acoplable componer
5
Abre el tablero
Navegue hasta http://localhost:3000 en su navegador. Debería ver el panel de la plataforma de agentes LiteLLM con opciones para crear agentes, abrir sesiones y monitorear el estado en vivo.
Pasar secretos a sandboxes
Cualquier variable en .env con el prefijo CONTAINER_ENV_ se inyecta automáticamente en cada contenedor sandbox con el prefijo eliminado. Ejemplo: CONTAINER_ENV_GITHUB_TOKEN=ghp_… significa que el sandbox ve GITHUB_TOKEN=ghp_… Esta es la forma correcta de pasar credenciales a las sesiones del agente.
06 / 06
Despliegue de producción
La configuración de producción recomendada separa el clúster de espacio aislado (AWS EKS) de los procesos web y de trabajo (Render). El repositorio incluye scripts y un plano para ambos.
1
Aprovisionar el clúster de espacio aislado de EKS
El script bin/eks-up.sh aprovisiona un clúster de AWS EKS configurado para ejecutar entornos sandbox de agentes. Esto reemplaza a tipo como el backend sandbox. Requiere credenciales de AWS en su entorno:
bin/eks-up.sh
2
Implementar web y trabajador para renderizar
El repositorio incluye un Render Blueprint en implementar/render/ que implementa los servicios web y de trabajo en Render con un solo clic. Consulte implementar/render/README.md para conocer la URL del modelo y las variables de entorno requeridas.
3
Utilice la API de desarrollador directamente (opcional)
Puede interactuar con la plataforma mediante programación a través de su API REST usando curl o cualquier cliente HTTP. La referencia completa de la API que cubre cómo crear un agente, abrir una sesión, enviar un mensaje y leer la respuesta se encuentra en src/server/DEVELOPER.md en el repositorio.
# Ejemplo: crear una sesión de agente mediante curl curl -X POST http://localhost:3000/api/sessions -H "Content-Type: application/json" -d '{"agent_id": "your-agent-id"}'
Resumen de arquitectura para producción
AWS EKS ejecuta el clúster de espacio aislado donde las sesiones del agente se ejecutan de forma aislada. Render aloja el panel web de Next.js y el trabajador asíncrono. Postgres (administrado o autohospedado) persiste el estado de la sesión. La puerta de enlace LiteLLM se ejecuta por separado y maneja todos los modelos de enrutamiento API. Estos cuatro componentes se comunican a través de la red y se pueden escalar de forma independiente.
La plataforma se encuentra actualmente en versión preliminar pública alfa. Presente los problemas en github.com/BerriAI/litellm-agent-platform. Detalles de la arquitectura en docs/k8s-backend.md en el repositorio.
← Anterior 1 / 6 Siguiente →
Publicado por Marktechpost | Noticias e investigaciones sobre IA/ML para desarrolladores e ingenieros
Conclusiones clave
Plataforma de agentes LiteLLM de código abierto de BerriAI, una capa de infraestructura autohospedada para ejecutar múltiples agentes de IA en producción con aislamiento de espacio aislado por equipo y continuidad de sesión entre reinicios de pod. Los sandboxes se ejecutan en Kubernetes a través del CRD kubernetes-sigs/agent-sandbox (localmente con kind, en producción con AWS EKS) y no se necesitan credenciales de nube para comenzar. La plataforma se encuentra encima del LiteLLM Gateway existente, que maneja el enrutamiento de modelos, el seguimiento de costos y la limitación de tarifas en más de 100 proveedores de LLM en formato OpenAI. El inicio rápido consta de dos comandos: bin/kind-up.sh aprovisiona el clúster kind e instala el controlador sandbox; Docker compone botas Postgres, web (:3000) y trabajador. Publicado bajo licencia del MIT y actualmente en versión preliminar pública alfa.
Consulte el repositorio de GitHub. Además, no dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 150.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.
¿Necesita asociarse con nosotros para promocionar su repositorio de GitHub O su página principal de Hugging O su lanzamiento de producto O seminario web, etc.? Conéctate con nosotros