- Lo que realmente hace un intérprete de código
- Lo que añade un runtime de agente
- Dimensiones clave de decisión
- Dónde encajan mejor los intérpretes de código
- Dónde encajan mejor los runtimes de agente
- Patrones híbridos: usar ambos en una misma aplicación
- Evaluación de la infraestructura de sandbox para cada modelo
- FAQ
- Artículos recomendados
Los intérpretes de código manejan tareas de ejecución aisladas y de corta duración: ejecutar un script, devolver un resultado, descartar todo. Los runtimes de agente manejan flujos de trabajo de varios pasos que requieren estado persistente, acceso a herramientas, control del navegador, E/S de archivos o sesiones de larga duración. La elección correcta depende de tu carga de trabajo, no de la etiqueta que un producto use para describirse a sí mismo.
Lo que realmente hace un intérprete de código
Un intérprete de código le da a un modelo de lenguaje una forma de ejecutar código y ver la salida. El modelo escribe un script de Python, el intérprete lo ejecuta de forma aislada y el resultado vuelve como texto, un archivo o un gráfico renderizado. Cuando la sesión termina — o incluso entre turnos en algunas implementaciones — el entorno se reinicia. Nada persiste.
Ese diseño es intencional. Los intérpretes de código priorizan la seguridad y la simplicidad sobre la continuidad. El límite de aislamiento es estricto porque lo único que debe suceder es: ejecutar este código, devolver este resultado.
El alcance práctico es pequeño: un runtime de Python (o similar) en un entorno aislado, un sistema de archivos limitado a la sesión, suficiente acceso a la red para obtener librerías o datos externos si el caso de uso lo necesita, y un mecanismo para devolver artefactos. La sesión puede durar 30 segundos o 10 minutos, pero la aplicación la trata como fundamentalmente efímera.
Esto se ajusta limpiamente a varias cargas de trabajo de alto valor:
- Ejecución de script único: un usuario pide al modelo que calcule algo, y el resultado vuelve como un número, tabla o archivo.
- Análisis de datos: subir un CSV, generar un resumen, producir un gráfico. El trabajo comienza y termina dentro de una interacción.
- Cálculo rápido: matemáticas, transformaciones de datos, conversiones de formato y tareas similares que caben en un solo bloque de código.
- Entornos educativos: donde cada ejercicio está aislado y no hay expectativa de continuidad de la sesión.
Lo que los intérpretes de código no manejan bien es cualquier cosa que requiera que el entorno recuerde algo, realice una acción fuera del entorno aislado o continúe trabajando después de que el usuario deje de observar.
Lo que añade un runtime de agente
Un runtime de agente es un entorno de ejecución diseñado para trabajo que abarca múltiples pasos, involucra herramientas externas y puede tomar minutos u horas en lugar de segundos. La sesión no se descarta entre pasos: es un espacio de trabajo que el agente utiliza para avanzar hacia un objetivo.
Las adiciones prácticas sobre un intérprete simple son significativas:
Espacio de trabajo persistente: los archivos escritos en un paso siguen ahí en el siguiente. Un agente de codificación puede crear una rama, editar archivos, ejecutar pruebas, corregir fallos y hacer un push de un commit, todo dentro de una sesión, sin empezar de nuevo.
Paquetes instalados y herramientas del sistema: un runtime de agente típicamente soporta instalar dependencias, ejecutar comandos de shell, llamar a CLIs, iniciar procesos en segundo plano y trabajar con un entorno de desarrollo real en lugar de un entorno aislado de Python restringido.
Acceso al navegador y web: los agentes que necesitan leer documentación, interactuar con aplicaciones web, llenar formularios o automatizar flujos de trabajo web necesitan un navegador en el entorno de ejecución. Un intérprete de código no tiene concepto de una sesión de navegador persistente.
Almacenamiento de archivos y persistencia de artefactos: las salidas que deben sobrevivir a una sola ejecución — código generado, datos intermedios, archivos descargados, capturas de pantalla — necesitan un sistema de archivos que persista a través de los pasos y, en algunos casos, a través de las sesiones.
Sesiones de larga duración: algunas tareas de agente toman 20 minutos. Algunas toman más. Un runtime de agente está diseñado para mantenerse vivo durante la duración de un flujo de trabajo, no para iniciar y detener en cada llamada de función.
Orquestación de múltiples herramientas: los flujos de trabajo reales de agentes implican llamar a múltiples herramientas en secuencia — una búsqueda web, seguida de una edición de archivo, seguida de una ejecución de prueba, seguida de un push de git. Un runtime de agente está construido para coordinar esa cadena de manera confiable.
La compensación es real: los runtimes de agente son más complejos de operar, cuestan más por sesión que un intérprete ligero, y exponen una superficie de ataque más grande que requiere una configuración cuidadosa de políticas. Para cargas de trabajo que se ajustan al modelo de intérprete, añadir toda esta complejidad es un desperdicio.
Dimensiones clave de decisión
La tabla a continuación mapea los criterios de decisión prácticos. La mayoría de las aplicaciones caen claramente en un lado; los patrones híbridos se cubren en la siguiente sección para los casos que abarcan ambos.
| Dimensión | Intérprete de código | Runtime de agente |
|---|---|---|
| Duración de la sesión | Segundos a minutos, efímera | Minutos a horas, persistente |
| Estado entre pasos | Descartado o limitado | Preservado |
| Acceso a herramientas | Solo ejecución de código | CLI, navegador, E/S de archivos, APIs, subprocesos |
| Instalación de paquetes | Imagen fija o restringida | Dinámica, con controles de política |
| Interacción con navegador/web | No disponible | Soportada |
| Almacenamiento de archivos | Solo ámbito de sesión | Persistente entre pasos |
| Costo por sesión | Bajo | Más alto |
| Complejidad de infraestructura | Baja | Más alta |
| Puntos de control humano en el ciclo | No es típico | Común — aprobar antes de desplegar, fusionar o acción externa |
| Modelo de concurrencia | Muchas sesiones cortas en paralelo | Menos sesiones más largas |
La duración de la sesión y los requisitos de estado son los filtros más rápidos. Si tu carga de trabajo se reinicia entre turnos, usa un intérprete. Si tu carga de trabajo avanza hacia un objetivo a través de múltiples turnos, usa un runtime.
La amplitud de herramientas es el segundo filtro. El control del navegador, operaciones de git, herramientas CLI y llamadas a API externas requieren un runtime. Si tu única herramienta es la ejecución de código, un intérprete es suficiente.
Los puntos de control humano en el ciclo casi siempre indican un runtime. Pausar una sesión para esperar aprobación y luego continuar requiere estado persistente y una sesión que pueda reanudarse. Los intérpretes no están diseñados para esto.
Dónde encajan mejor los intérpretes de código
Los intérpretes de código son la elección correcta cuando la ejecución es acotada y autónoma. Los casos de uso más sólidos:
Asistentes de análisis de datos: el usuario sube un archivo, hace una pregunta, recibe gráficos y resúmenes. El trabajo termina cuando el modelo devuelve la salida. No hay un siguiente paso que dependa de la memoria del anterior.
Herramientas de matemáticas y cálculo: calculadoras, conversores de unidades, análisis estadístico, simulaciones numéricas. Son de un solo paso: entrada entra, salida sale.
Informes automatizados: trabajos programados que generan un informe desde una fuente de datos y lo envían por correo electrónico o lo guardan. El trabajo se ejecuta, produce un artefacto y termina.
Generación de gráficos y visualizaciones: el modelo escribe código de matplotlib o similar, el intérprete lo ejecuta y el usuario recibe una imagen. No hay necesidad de un entorno persistente.
Uso de herramientas LLM en entorno aislado: cuando un modelo necesita una herramienta code_interpreter para razonar sobre datos, verificar cálculos o formatear la salida — y nada más — un intérprete de código es precisamente para lo que está diseñada la API.
El atractivo de los intérpretes en estos escenarios es práctico: son más baratos por sesión, más fáciles de operar y más simples de asegurar. No hay estado persistente que gestionar, ningún ciclo de vida de sesión que rastrear, y la superficie de ataque es estrecha porque el código se ejecuta una vez y el entorno desaparece.
Dónde encajan mejor los runtimes de agente
Los runtimes de agente son la elección correcta cuando una tarea no puede completarse sin coordinar múltiples herramientas a lo largo del tiempo, mantener el estado a través de los pasos, o tomar acciones fuera del entorno aislado de ejecución de código.
Agentes de codificación: un agente que lee un código base, escribe cambios, ejecuta el conjunto de pruebas, corrige fallos y abre una solicitud de extracción necesita un espacio de trabajo persistente con git, un terminal y un sistema de archivos. Esto es arquitectónicamente incompatible con un intérprete efímero.
Agentes de navegador y automatización web: raspar contenido dinámico, llenar formularios, navegar flujos web de múltiples pasos, extraer datos estructurados de interfaces visuales — todo esto requiere una sesión de navegador real que persista el tiempo suficiente para completar el flujo de trabajo.
Pipelines de investigación y recolección de datos: agentes que recuperan documentos de múltiples fuentes, cruzan información, escriben resultados intermedios en disco y producen una salida final sintetizada necesitan un espacio de trabajo que persista a través de todos esos pasos.
Cargas de trabajo de evaluación y RL: ejecutar muchos episodios de agente en paralelo, cada uno manteniendo su propio estado, rastreando puntuaciones y escribiendo puntos de control, requiere un runtime diseñado para concurrencia y aislamiento de sesiones a escala.
Agentes de infraestructura de larga ejecución: agentes que provisionan recursos, ejecutan despliegues, monitorean salidas y reaccionan a cambios en una ventana de varios minutos u horas necesitan un modelo de sesión que pueda pausar, reanudar y establecer puntos de control.
Herramientas de codificación agénticas como los agentes estilo Codex o agentes conectados a IDE que realizan acciones en un proyecto real necesitan toda la superficie de un entorno de desarrollo — no un intérprete en entorno aislado.
El costo de un runtime se justifica cuando la alternativa es cablear manualmente la gestión del estado, la coordinación de herramientas y la persistencia de la sesión. El runtime proporciona esa infraestructura; tú configuras la política.
Patrones híbridos: usar ambos en una misma aplicación
Muchas aplicaciones reales incorporan ambos patrones. Un asistente de codificación podría usar un runtime de agente para la sesión general — manteniendo el contexto del repositorio, rastreando qué archivos se han cambiado, gestionando una rama — mientras llama a un intérprete de código específicamente para ejecutar pruebas o scripts proporcionados por el usuario en un entorno aislado como suboperación dentro del flujo de trabajo del agente más grande.
Un producto de análisis de datos podría usar un runtime de agente para orquestar el flujo de trabajo completo — descargar datos, limpiarlos, unir múltiples fuentes — mientras usa invocaciones de intérprete aisladas para los pasos de cómputo individuales donde el aislamiento estricto importa y el estado no necesita persistir.
El patrón se ve así en la práctica:
- La capa externa es un runtime de agente: mantiene la sesión, coordina herramientas y gestiona el estado.
- Las operaciones internas que requieren aislamiento estricto usan invocaciones de intérprete de código de corta duración como una herramienta entre muchas.
- El runtime de agente decide cuándo invocar el intérprete, qué entradas pasar y qué hacer con la salida.
Este no es un patrón arquitectónico complejo; es simplemente usar cada capa para lo que está diseñada. El runtime de agente gestiona el flujo de trabajo; el intérprete maneja la ejecución aislada cuando es necesario.
Evaluación de la infraestructura de sandbox para cada modelo
Ya sea que estés evaluando un proveedor de sandbox gestionado o diseñando el tuyo propio, las preguntas que necesitas responder difieren significativamente según el modelo para el que estés construyendo.
Para cargas de trabajo de intérprete de código, los criterios de evaluación son relativamente estrechos:
- ¿Cuál es la latencia de inicio? El inicio en menos de un segundo importa para el uso interactivo.
- ¿Qué lenguajes y paquetes están disponibles en la imagen predeterminada?
- ¿Pueden los usuarios instalar paquetes adicionales, y eso está permitido por tu modelo de seguridad?
- ¿Cuáles son los límites de recursos (CPU, memoria, tiempo de ejecución)?
- ¿Cómo se devuelven los artefactos de la sesión — respuesta síncrona, descarga de archivo o URL prefirmada?
- ¿Hay una opción de sistema de archivos persistente, o todo se descarta al salir?
Para cargas de trabajo de runtime de agente, los criterios se expanden considerablemente:
- ¿El entorno soporta sistemas de archivos persistentes que sobreviven a través de los pasos en una sesión?
- ¿Se puede pausar y reanudar la sesión — para flujos de trabajo con humano en el ciclo o gestión de costos?
- ¿Hay soporte para navegador, y cómo está configurado?
- ¿Qué herramientas de shell y CLIs están disponibles?
- ¿Cómo se controla el acceso a la red — políticas de salida, filtrado de DNS, listas blancas de salida?
- ¿Cuál es el modelo de concurrencia de sesiones y cómo escala?
- ¿Cómo se inyectan y delimitan los secretos?
- ¿Qué observabilidad existe — registros de comandos, seguimiento de cambios de archivos, métricas de recursos?
- ¿Cómo maneja la plataforma las sesiones de larga duración que superan los ciclos típicos de solicitud-respuesta?
Novita Agent Sandbox está diseñado para cargas de trabajo de runtime de agente — agentes de codificación, automatización de navegador, pipelines de análisis de datos y cargas de trabajo de evaluación/RL que necesitan estado persistente, acceso a herramientas y control de sesión. Utiliza aislamiento microVM, soporta Pausa/Reanudación y se integra con la plataforma de API de modelos de Novita, de modo que los equipos que usan Novita para inferencia de LLM pueden ejecutar cargas de trabajo de sandbox en la misma plataforma. Para los equipos que evalúan la infraestructura de sandbox para flujos de trabajo de agentes, la documentación de Novita Agent Sandbox cubre el modelo de aislamiento, la API del ciclo de vida y la configuración de recursos.
Para cargas de trabajo que son genuinamente solo de intérprete — script único, efímero, sin estado — un runtime de agente completo es una sobrecarga que no necesitas. Usa la herramienta más simple.
La prueba práctica: ¿puede tu flujo de trabajo completarse correctamente si el entorno de ejecución se destruye y reconstruye entre cada turno del modelo? Si es así, un intérprete probablemente sea suficiente. Si no — porque el estado, el acceso a herramientas o la continuidad de la sesión importan — necesitas un runtime.
FAQ
¿Cuál es la diferencia principal entre un intérprete de código y un runtime de agente?
Un intérprete de código ejecuta código en un entorno aislado y descarta el entorno cuando la sesión termina. Un runtime de agente mantiene un espacio de trabajo persistente — con archivos, herramientas instaladas, acceso al navegador y estado de sesión — a través de múltiples pasos de un flujo de trabajo. El intérprete responde “ejecuta este código y devuelve el resultado”; el runtime responde “trabaja hacia este objetivo a través de tantos pasos como sea necesario”.
¿Puede un intérprete de código usar herramientas como búsqueda web o acceso a archivos?
Algunas implementaciones de intérpretes de código soportan uso limitado de herramientas — subidas de archivos, llamadas de red dentro del sandbox, o devolución de artefactos. Lo que no soportan es un espacio de trabajo persistente que lleve el estado a través de los turnos o una sesión de navegador que dure más que una sola llamada de función. Si tu aplicación necesita leer una página web, escribir un archivo y luego hacer referencia a ese archivo en un paso posterior, necesitas un runtime.
¿Es un runtime de agente siempre más caro que un intérprete de código?
Por sesión, sí. Los runtimes de agente implican más infraestructura — sistemas de archivos persistentes, procesos de larga duración, acceso a navegador o CLI — y esos componentes cuestan más que un sandbox de intérprete de corta duración. Para cargas de trabajo que genuinamente requieren coordinación de múltiples pasos, el costo del runtime está justificado. Para tareas de un solo paso, es una sobrecarga.
¿Cuándo debería usar ambos en la misma aplicación?
Cuando el flujo de trabajo externo requiere estado persistente pero las suboperaciones individuales se benefician de un aislamiento estricto. Un agente de codificación que ejecuta el conjunto de pruebas en un intérprete en un entorno aislado, o un pipeline de datos que delega pasos de cómputo a intérpretes efímeros mientras la capa de orquestación mantiene el estado general, son ambos patrones híbridos comunes.
¿Soporta Novita Agent Sandbox ambos modelos?
Novita Agent Sandbox está diseñado para cargas de trabajo de runtime de agente — espacios de trabajo persistentes, Pausa/Reanudación, acceso al navegador y control de sesión de múltiples pasos. Para invocaciones de intérprete aisladas y efímeras, una ejecución más ligera puede ser más apropiada dependiendo de tu caso de uso. Consulta la documentación de Novita Agent Sandbox para obtener detalles actuales sobre las capacidades.
¿Cómo sé si mi carga de trabajo necesita un runtime?
La prueba práctica: ¿puede tu flujo de trabajo completarse correctamente si el entorno de ejecución se destruye y reconstruye entre cada turno del modelo? Si es así, un intérprete es suficiente. Si la respuesta es no — porque el estado, el acceso a herramientas, el control del navegador o la continuidad de la sesión importan — necesitas un runtime.
