- Por Qué Importan las Preguntas de Migración de Sandbox
- Compatibilidad de API y SDK
- Compatibilidad del Intérprete de Código
- Ciclo de Vida de la Sesión y Comportamiento de Tiempo de Espera
- Persistencia de Archivos y Estado
- Políticas de Instalación de Paquetes
- Políticas de Red y Salida
- Manejo de Secretos en Sandboxes
- Límites de Concurrencia y Escalado
- Observabilidad y Registro
- Ruta de Migración y Esfuerzo
- Diferencias en el Modelo de Precios
- Ajuste de Novita Agent Sandbox
- Preguntas Frecuentes (FAQ)
- Artículos recomendados
Al evaluar un sandbox compatible con E2B o alternativo a E2B para una aplicación de IA, verifique la superposición de la superficie de API, la compatibilidad de la interfaz del SDK, el comportamiento de la sesión del intérprete de código, el ciclo de vida de archivos y estado, las políticas de instalación de paquetes, los controles de salida de red, los límites de duración y concurrencia de sesiones, y el modelo de precios antes de comprometerse con una migración. Ninguna de estas verificaciones toma más de una tarde de pruebas, pero omitir cualquiera de ellas es la fuente más común de sorpresas posteriores a la migración en producción.
Por Qué Importan las Preguntas de Migración de Sandbox
Los proveedores de sandbox se ven similares a nivel superficial. Todos ofrecen ejecución aislada, algún tipo de soporte para Python y una interfaz REST o SDK. Pero los detalles divergen rápidamente una vez que intentas ejecutar una carga de trabajo real de agente: un agente de codificación que necesita un sistema de archivos persistente entre llamadas de herramientas, un flujo de trabajo de análisis de datos que instala pandas en tiempo de ejecución, o un agente de navegador que necesita HTTPS saliente a una API específica.
Una lista de verificación de migración útil no es una matriz de características. Es un conjunto de preguntas que aplicas a los requisitos reales de tu aplicación antes de decidir si un cambio de proveedor es de baja fricción o una reestructuración completa.
Esta guía recorre cada categoría con las preguntas que vale la pena hacer, qué buscar en la documentación del proveedor, y cómo Novita Agent Sandbox aborda cada dimensión para los equipos que lo evalúan como objetivo de migración.
Compatibilidad de API y SDK
Preguntas a considerar:
- ¿El proveedor objetivo ofrece un SDK oficial para tu lenguaje (Python, TypeScript, Go)?
- ¿El SDK expone las mismas primitivas de alto nivel de las que dependes: creación de sandbox, ejecución de código, operaciones de archivos, gestión de procesos?
- ¿La superficie de la API REST es estable y versionada, o está en cambio rápido?
- ¿Qué flujo de autenticación utiliza el SDK (encabezado de clave de API, OAuth, cuenta de servicio)? ¿Coincide con tu gestión de secretos existente?
Qué buscar: Documentación del SDK que cubra explícitamente los métodos del ciclo de vida del sandbox, los métodos del sistema de archivos y los métodos de proceso. Un proveedor con solo una API REST genérica y sin SDK mantenido requerirá más código de conexión por tu parte.
Dónde surgen las diferencias en la práctica: El SDK de Python de E2B encapsula la creación de sandbox, la ejecución de código con sandbox.run_code() y las operaciones del sistema de archivos. Si tu aplicación llama a nombres de métodos específicos o depende del comportamiento de salida en streaming del SDK, prueba esas rutas en el proveedor objetivo antes de asumir que funcionan.
Compatibilidad del Intérprete de Código
Preguntas a considerar:
- ¿El sandbox admite ejecución interactiva de Python (estilo REPL, no solo ejecución de scripts)?
- ¿Cómo se separan la salida estándar, el error estándar y el resultado de la ejecución?
- ¿Puede el sandbox producir gráficos, figuras o salida binaria (PNG, SVG, HTML) a partir de código Python?
- ¿Cuál es la versión de Python predeterminada y es configurable?
- ¿Puede el intérprete de código ejecutar comandos de shell arbitrarios, o la ejecución está restringida a Python?
Qué buscar: Muchos marcos de aplicaciones de IA asumen un resultado de ejecución en streaming o estructurado que separa stdout, stderr, datos de visualización (salida enriquecida al estilo Jupyter) y errores de ejecución. Si tu agente analiza esa estructura, un proveedor que solo devuelve una respuesta de texto plano te obligará a reescribir la capa de análisis.
Resultados de ejecución en streaming: Algunos proveedores transmiten resultados parciales mientras el código se ejecuta. Otros devuelven un único objeto de respuesta después de que la ejecución se completa. Para fragmentos de código cortos esto rara vez importa, pero para pasos de procesamiento de datos de larga duración, la transmisión de resultados parciales suele ser importante para la experiencia del usuario.
Ciclo de Vida de la Sesión y Comportamiento de Tiempo de Espera
Preguntas a considerar:
- ¿Cuál es el tiempo de espera predeterminado y máximo de la sesión?
- ¿El proveedor admite pausar y reanudar una sesión (estado preservado entre interrupciones)?
- ¿Qué sucede con la ejecución en curso si una sesión expira?
- ¿La creación de sesiones es síncrona o asíncrona desde la perspectiva de tu aplicación?
- ¿Cómo se termina explícitamente una sesión y qué limpieza ocurre automáticamente?
Qué buscar: Los agentes de codificación y los flujos de trabajo de análisis de datos de múltiples pasos a menudo necesitan sesiones que excedan una sola interacción del LLM. Un proveedor con un tiempo de espera predeterminado de 60 segundos y sin soporte de pausa/reanudación obliga a tu agente a serializar todo el estado antes de que termine cada interacción, una limitación arquitectónica significativa.
Sobre pausa/reanudación específicamente: Pausa/reanudación es diferente de crear una nueva sesión con una instantánea. Pausa/reanudación preserva el estado del proceso en memoria, los identificadores de archivos abiertos y las bibliotecas cargadas. Instantánea y restauración restaura una imagen del sistema de archivos pero típicamente no preserva los procesos en ejecución. Conoce qué mecanismo ofrece un proveedor y cuál necesita realmente tu agente.
Latencia de creación de sesión: Si tu agente crea un nuevo sandbox por cada llamada de herramienta, la latencia de inicio se acumula rápidamente. Consulta la documentación del proveedor sobre el comportamiento de arranque en frío frente a grupo caliente y si puedes precalentar sesiones.
Persistencia de Archivos y Estado
Preguntas a considerar:
- ¿El sandbox tiene un sistema de archivos persistente a través de los pasos de ejecución de código dentro de una sesión?
- ¿Se pueden acceder a los archivos creados en una sesión en una sesión posterior, o el sistema de archivos es efímero por sesión?
- ¿Existe una API de carga/descarga de archivos, o los archivos deben pasarse en línea?
- ¿Cuáles son los límites de tamaño del sistema de archivos (cuota de disco por sesión)?
- Si tu agente genera artefactos grandes (modelos, conjuntos de datos), ¿cómo funciona la exportación de archivos?
Qué buscar: La mayoría de los sandboxes ofrecen un sistema de archivos efímero por sesión. Si tu flujo de trabajo requiere persistencia entre sesiones (por ejemplo, un agente de codificación que construye un artefacto a lo largo de múltiples interacciones de usuario), verifica si el proveedor admite volúmenes con nombre, espacios de trabajo persistentes o un patrón documentado de exportación y restauración.
E/S de archivos en modo intérprete de código: Para agentes de análisis de datos, la capacidad de escribir un CSV o PNG dentro del sandbox y luego descargarlo a tu aplicación es una primitiva central. Prueba que el ciclo completo funcione de extremo a extremo: sube un archivo, ejecuta código que lo lea y transforme, descarga el resultado.
Políticas de Instalación de Paquetes
Preguntas a considerar:
- ¿Puede el código en el sandbox ejecutar
pip installen tiempo de ejecución sin restricciones? - ¿El proveedor permite imágenes base personalizadas o entornos de paquetes preinstalados?
- ¿Existe un mecanismo para permitir o denegar paquetes?
- ¿La instalación de paquetes sobrevive a través de las llamadas de herramientas dentro de una sesión, o es por ejecución?
- ¿Qué sucede cuando falla la instalación de un paquete (dependencias del sistema faltantes, conflicto de versiones)?
Qué buscar: La instalación de paquetes en tiempo de ejecución es uno de los puntos de divergencia más comunes entre sandboxes. Algunos proveedores instalan paquetes en una capa de sesión persistente, de modo que pip install pandas en el paso 1 está disponible en el paso 2. Otros restablecen a una imagen base en cada bloque de código. Si tu agente asume que la instalación persiste, esta es una suposición que se rompe.
Nota sobre la cadena de suministro: Permitir pip install arbitrario en tiempo de ejecución tiene implicaciones en la cadena de suministro. Para cargas de trabajo de producción, pregunta si el proveedor permite instalaciones con restricciones de internet (desde un mirror privado de PyPI o una lista de permitidos) en lugar de pip install abierto desde internet público.
Políticas de Red y Salida
Preguntas a considerar:
- ¿El acceso a internet saliente está habilitado por defecto, o el sandbox está aislado de la red?
- ¿Puede el código en el sandbox hacer solicitudes HTTP a APIs externas?
- ¿Existe una lista de permitidos o denegados configurable para destinos de salida?
- ¿Qué sucede con la resolución DNS dentro del sandbox?
- ¿Pueden dos sandboxes comunicarse directamente, o solo a través de tu capa de aplicación?
Qué buscar: Para un agente de análisis de datos que obtiene conjuntos de datos públicos, la salida abierta es conveniente. Para un agente de codificación que se ejecuta en un entorno sensible a la seguridad, la salida controlada o bloqueada es el valor predeterminado correcto. Conoce cuál necesita tu carga de trabajo.
Agentes de navegador vs. agentes de ejecución de código: Los agentes de navegador típicamente necesitan acceso completo a internet (para navegar a URLs que el usuario especifica). Los agentes de ejecución de código a menudo solo necesitan acceso a APIs específicas. Estos son perfiles de salida diferentes que pueden requerir diferentes configuraciones de sandbox.
Manejo de Secretos en Sandboxes
Preguntas a considerar:
- ¿Cómo se inyectan secretos (claves de API, credenciales) en un sandbox al momento de crearlo?
- ¿Los secretos inyectados son accesibles como variables de entorno, archivos montados, o ambos?
- ¿Los secretos son visibles en los registros de ejecución o en el estado serializado?
- ¿El proveedor limpia automáticamente los secretos de la salida de registros?
Qué buscar: El error más común es inyectar un secreto a través de una variable de entorno y luego el sandbox registra todas las variables de entorno al inicio, filtrando el secreto a tu pila de observabilidad. Pregunta si el proveedor tiene algún comportamiento de limpieza, y construye limpieza a nivel de aplicación si no es así.
Diferencia de variables de entorno generales: No todas las variables de entorno son secretos. Los proveedores que tratan las dos de manera intercambiable (sin secretos tipados, sin redacción) requieren más código defensivo por tu parte.
Límites de Concurrencia y Escalado
Preguntas a considerar:
- ¿Cuál es el límite predeterminado y máximo de sandboxes concurrentes por cuenta?
- ¿La aplicación de la concurrencia es dura (las solicitudes fallan por encima del límite) o blanda (las solicitudes se ponen en cola)?
- ¿Existen topes de concurrencia por región o por centro de datos?
- ¿Existe un modelo de aislamiento de sandbox por usuario, o todos los sandboxes comparten límites a nivel de cuenta?
- ¿Cuál es el comportamiento de ráfaga cuando pasas de 0 a 100 sandboxes concurrentes?
Qué buscar: Las cargas de trabajo de evaluación, los entornos de RL y las plataformas de codificación multiinquilino requieren alta concurrencia. Un proveedor con un nivel gratuito limitado a 5 o 10 sandboxes concurrentes es viable para prototipado pero no para ejecuciones de RL en producción con 50–100 ensayos paralelos.
Límites de cuenta vs. organizacionales: Algunos proveedores aplican límites por clave de API y permiten múltiples claves por organización. Otros aplican límites a nivel de organización independientemente del número de claves. Para cargas de trabajo de alta concurrencia, esta distinción afecta cómo estructuras tu cuenta de producción.
Observabilidad y Registro
Preguntas a considerar:
- ¿Qué registros de ejecución expone el proveedor: stdout, stderr, eventos del sistema, tráfico de red?
- ¿Los registros se transmiten en tiempo real o están disponibles solo después de que la ejecución se completa?
- ¿Por cuánto tiempo se retienen los registros?
- ¿Existe una API de registro estructurado (JSON, campos buscables) o solo texto plano?
- ¿Puedes conectar tu propia pila de observabilidad (OpenTelemetry, Datadog, Splunk)?
Qué buscar: Para depurar fallos de agentes en producción, quieres saber qué código se ejecutó, qué imprimió, qué archivos creó y qué llamadas de red realizó. Los proveedores que exponen solo stdout/stderr y nada más hacen que el análisis de causa raíz sea lento.
Requisitos de pista de auditoría: Si tu caso de uso involucra datos regulados o requisitos de cumplimiento, pregunta si el proveedor puede producir un registro de auditoría de todos los eventos de ejecución con marcas de tiempo. El stdout en texto plano no es una pista de auditoría.
Ruta de Migración y Esfuerzo
Antes de comprometerte con una migración, delimita el trabajo real en estas dimensiones:
Capa de SDK: Si el proveedor objetivo tiene un SDK oficial con nombres de métodos similares, los cambios a nivel de aplicación pueden limitarse a la inicialización, autenticación y algunas firmas de métodos. Si el objetivo solo ofrece una API REST, estás escribiendo una capa adaptadora.
Modelo de sesión y estado: Si tu proveedor actual tiene pausa/reanudación y el objetivo no, necesitas rediseñar cómo tu agente maneja el estado en múltiples turnos. Esto rara vez es un cambio pequeño.
Entorno de paquetes: Si tu proveedor actual utiliza una imagen base personalizada con paquetes preinstalados, reconstruir ese entorno en un nuevo proveedor lleva tiempo y pruebas.
Pruebas: Cualquier migración de sandbox debe incluir un conjunto de pruebas de integración que ejecute tus cargas de trabajo reales de agente de extremo a extremo en el proveedor objetivo antes de cambiar el tráfico de producción. Las pruebas unitarias que simulan el sandbox no son suficientes: las diferencias de comportamiento aparecen precisamente en el entorno de ejecución real.
Una señal aproximada de esfuerzo: Si el proveedor objetivo tiene un SDK que encapsula las mismas primitivas (crear, ejecutar código, listar archivos, descargar archivo, terminar), y tu modelo de sesión es sin estado por turno, la migración suele ser un esfuerzo de 1 a 2 días. Si dependes de pausa/reanudación, imágenes base personalizadas o un comportamiento específico de salida en streaming, presupuesta una semana o más para diseño, implementación y pruebas.
Diferencias en el Modelo de Precios
Los modelos de precios de los sandboxes varían significativamente, y el modelo adecuado depende de la forma de tu carga de trabajo.
Dimensiones comunes de precios:
| Dimensión | Lo que afecta |
|---|---|
| Facturación por segundo | Cargas de trabajo donde las sesiones son cortas y el tiempo de inactividad es bajo |
| Facturación por minuto | Cargas de trabajo donde los pequeños incrementos de facturación importan menos |
| Mínimo de suscripción | Costo fijo mensual independientemente del uso |
| Facturación por vCPU + memoria | Asignación de recursos personalizable; pagas por lo que configuras |
| Facturación plana por ejecución | Costo predecible para tamaños de tarea uniformes |
Preguntas a considerar:
- ¿La facturación se basa en el uso (por segundo/minuto de tiempo activo del sandbox) o es basada en suscripción (mínimo mensual)?
- ¿La facturación de vCPU y memoria es independiente, o está vinculada a niveles fijos?
- ¿Qué cuenta como segundo facturable: tiempo de creación de sesión, tiempo de ejecución activa de código, o tiempo total de sesión desde el inicio hasta el final?
- ¿Existe un nivel gratuito y cuáles son sus límites para tu tipo de carga de trabajo?
- ¿Hay una diferencia de costo entre sesiones de arranque en frío y sesiones precalentadas?
Cómo divergen los precios en la práctica: Un proveedor que cobra desde la creación de la sesión hasta su terminación (independientemente de si el código se está ejecutando activamente) será más caro para cargas de trabajo con períodos largos de inactividad entre turnos de agente. Un proveedor que factura solo durante la ejecución activa es más barato para esas cargas de trabajo pero puede no existir en el nivel de recursos que necesitas.
Para cargas de trabajo de RL o evaluación de alta concurrencia, el costo por cada mil ejecuciones a menudo importa más que la tarifa por segundo. Haz los cálculos con un recuento realista de ejecuciones mensuales antes de seleccionar un proveedor.
Ajuste de Novita Agent Sandbox
Novita Agent Sandbox es uno de los principales objetivos de migración para los que se escribió esta lista de verificación. Está dirigido a cargas de trabajo de agente de codificación, agente de navegador, análisis de datos, evaluación y RL. Para los equipos que trabajan con esta lista de verificación, aquí es donde encaja Novita y dónde pueden existir brechas:
SDK y API: Novita proporciona un SDK de Python y una API REST para la creación de sandboxes, ejecución de código, operaciones del sistema de archivos y gestión de procesos. Los equipos que migran desde flujos de trabajo al estilo E2B encontrarán primitivas familiares. Verifica los nombres de métodos específicos en la documentación de Novita Sandbox para la versión de tu SDK objetivo.
Ciclo de vida de la sesión: Novita admite sesiones de hasta 24 horas, Pausa/Reanudación y Pausa automática/Reanudación automática para sesiones inactivas. Para agentes de codificación de múltiples turnos que necesitan preservar el estado dentro de la sesión a través de llamadas al LLM, esta es una diferencia operativa significativa respecto a proveedores con límites de 60 minutos.
Concurrencia: El nivel base de Novita admite 50 sandboxes concurrentes sin tarifa de suscripción. Para cargas de trabajo de evaluación o RL que necesitan mayor concurrencia, contacta a Novita para niveles empresariales.
Modelo de precios: Novita factura por segundo sobre vCPU y memoria reales, sin mínimo de suscripción. Para cargas de trabajo con patrones de uso variables o explosivos, la facturación basada en uso sin un piso suele ser más barata que las alternativas basadas en suscripción. Verifica las tarifas actuales en la página de precios de Novita AI antes de hacer proyecciones de costos.
Implementación BYOC: Novita admite la ejecución de sandboxes dentro de tu propia VPC de AWS o GCP. Para equipos con requisitos estrictos de aislamiento de red, esto evita el modelo de nube pública multiinquilino.
Dónde verificar cuidadosamente: La compatibilidad de API/SDK con E2B, las garantías de reemplazo directo y la paridad de capacidades específicas están sujetas a desarrollo continuo. No asumas compatibilidad completa sin probar tus patrones de carga de trabajo específicos contra el SDK actual de Novita. Se recomienda revisión del producto antes de publicar cualquier afirmación de compatibilidad.
Dónde Novita puede no encajar: Los equipos con una inversión profunda en abstracciones específicas del SDK de E2B, equipos que necesitan soporte de sandbox con GPU, o equipos que requieren implementación local fuera de AWS/GCP deben evaluar cuidadosamente el ajuste antes de migrar.
Preguntas Frecuentes (FAQ)
¿Es Novita Agent Sandbox un reemplazo directo de E2B?
No por suposición. Los nombres de métodos del SDK, el comportamiento del ciclo de vida de la sesión, la estructura de salida en streaming y la persistencia de la instalación de paquetes deben probarse contra tu carga de trabajo específica antes de tratar a cualquier proveedor como un reemplazo directo. Utiliza la lista de verificación de esta guía para verificar cada dimensión explícitamente.
¿Cuál es el esfuerzo mínimo para migrar de E2B a un proveedor de sandbox diferente?
Si el proveedor objetivo tiene un SDK oficial con primitivas similares (crear, ejecutar código, operaciones de archivos, terminar) y tu modelo de sesión es sin estado por turno, la migración suele ser un esfuerzo de 1 a 2 días que cubre la inicialización del SDK, la autenticación y un pequeño número de firmas de métodos. Si dependes de pausa/reanudación, imágenes base personalizadas o un comportamiento específico de salida en streaming, presupuesta una semana o más.
¿Novita Agent Sandbox admite pausa y reanudación?
Sí. Novita admite Pausa/Reanudación y Pausa automática/Reanudación automática para sesiones inactivas, con duraciones de sesión de hasta 24 horas. Esto es relevante para agentes de codificación de múltiples turnos que necesitan preservar el estado dentro de la sesión a través de llamadas al LLM. Verifica el comportamiento actual en la documentación de Novita Sandbox para la versión de tu SDK.
¿Cómo pruebo si un proveedor de sandbox objetivo es compatible con mi aplicación?
Ejecuta tus cargas de trabajo reales de agente de extremo a extremo en el proveedor objetivo en un entorno de prueba antes de cambiar el tráfico de producción. Prueba los métodos específicos del SDK que tu aplicación llama, la estructura de salida en streaming que tu analizador espera, la persistencia de la instalación de paquetes entre llamadas de herramientas y los ciclos de archivos (subir, transformar, descargar). Las pruebas unitarias que simulan el sandbox no son suficientes: las diferencias de compatibilidad aparecen solo en la ejecución real.
¿Novita admite la ejecución de sandboxes dentro de una cuenta de nube privada?
Sí. Novita admite la implementación BYOC (Trae Tu Propia Nube) dentro de tu propia VPC de AWS o GCP. Para equipos con requisitos estrictos de aislamiento de red, residencia de datos o cumplimiento normativo, esto evita el modelo de nube pública multiinquilino. Contacta a Novita para conocer la disponibilidad actual de BYOC y las opciones de configuración.
