Del modelo al agente: equipar la API de respuestas con un entorno de computadora

Actualmente estamos en una transición de usar modelos, que se destacan en tareas específicas, a usar agentes capaces de gestionar flujos de trabajo complejos. Al usar prompts con los modelos, solo puedes acceder a la inteligencia entrenada. Sin embargo, al dotar al modelo de un entorno de computadora, es posible cubrir un rango mucho más amplio de casos de uso, como ejecutar servicios, solicitar datos de las API o generar artefactos más útiles, como hojas de cálculo o informes.

Surgen algunos problemas prácticos al intentar construir agentes: dónde almacenar archivos intermedios, cómo evitar pegar tablas grandes en un prompt, cómo otorgar acceso a la red del flujo de trabajo sin generar problemas de seguridad y cómo manejar tiempos de espera o reintentos sin tener que construir tu propio sistema de flujo de trabajo.

En lugar de que los desarrolladores tengan que crear sus propios entornos de ejecución, creamos los componentes necesarios para equipar la API de respuestas⁠(se abre en una nueva ventana) con un entorno de computadora que permita ejecutar de manera confiable tareas del mundo real.

La API de respuestas de OpenAI, junto con la herramienta shell y un espacio de trabajo en contenedor alojado, está diseñada para resolver estos problemas prácticos. El modelo propone pasos y comandos; la plataforma los ejecuta en un entorno aislado con un sistema de archivos para entradas y salidas, almacenamiento estructurado opcional (como SQLite) y acceso restringido a la red. 

En esta publicación, explicaremos cómo construimos un entorno de computadora para agentes y compartiremos algunas lecciones iniciales sobre cómo usarlo para flujos de trabajo de producción más rápidos, repetibles y seguros.

Un buen flujo de trabajo con agentes comienza con un ciclo de ejecución ajustado: el modelo propone una acción como leer archivos u obtener datos con la API, la plataforma la ejecuta y el resultado alimenta el siguiente paso. Comenzaremos con la herramienta shell, la forma más sencilla de ver este ciclo en acción, y luego cubriremos el espacio de trabajo en el contenedor, las redes, las skills reutilizables y la compactación de contexto.

Para entender la herramienta shell, primero es útil entender cómo un modelo de lenguaje usa herramientas en general: para hacer cosas como llamar a una función o interactuar con una computadora. Durante el entrenamiento, a un modelo se le muestran ejemplos de cómo se usan las herramientas y los efectos resultantes, paso a paso. Esto ayuda al modelo a aprender cuándo y cómo usar una herramienta. Cuando decimos “usar una herramienta”, nos referimos a que el modelo solo propone la llamada; no puede ejecutarla por sí solo.

La herramienta shell hace que el modelo sea mucho más potente: interactúa con una computadora mediante la línea de comandos para llevar a cabo una amplia gama de tareas, desde buscar texto hasta enviar solicitudes de API en tu computadora. Basada en herramientas Unix conocidas, nuestra herramienta shell puede hacer todo lo que esperarías, con utilidades como grep, curl y awk listas para usar.

En comparación con nuestro intérprete de código actual, que solo ejecuta Python, la herramienta shell permite un rango mucho más amplio de casos de uso, como ejecutar programas de Go o Java o iniciar un servidor NodeJS. Esta flexibilidad permite que el modelo realice tareas de agente complejas.

Por sí solo, un modelo solo puede proponer comandos shell, pero ¿cómo se ejecutan estos comandos? Necesitamos un orquestador que reciba la salida del modelo, invoque las herramientas y devuelva la respuesta al modelo en un ciclo, hasta que la tarea se complete.

La API de respuestas es la forma en que los desarrolladores interactúan con los modelos de OpenAI. Cuando se usa con herramientas personalizadas, la API de respuestas devuelve el control al cliente, y este requiere su propio marco de ejecución de las herramientas. Sin embargo, esta API también puede orquestar de manera inmediata la interacción entre el modelo y las herramientas alojadas. 

Cuando la API de respuestas recibe un prompt, ensambla el contexto del modelo: prompt del usuario, estado previo de la conversación e instrucciones de herramientas. Para que la ejecución en el shell funcione, el prompt debe mencionar el uso de la herramienta shell y el modelo seleccionado debe estar entrenado para proponer comandos de shell, (los modelos GPT‑5.2 y posteriores están entrenados para esto. Con todo este contexto, el modelo decide la siguiente acción. Si elige la ejecución en el shell, devuelve uno o más comandos de shell al servicio de la API de respuestas. El servicio de la API reenvía esos comandos al entorno de ejecución del contenedor, transmite la salida del shell y la proporciona al modelo en el contexto de la siguiente solicitud. Luego, el modelo puede inspeccionar los resultados, emitir comandos de seguimiento o producir una respuesta final. La API de respuestas repite este ciclo hasta que el modelo devuelve una finalización sin comandos shell adicionales.

Cuando la API de respuestas ejecuta un comando de shell, mantiene una conexión de streaming con el servicio de contenedores. A medida que se genera la salida, la API la envía al modelo casi en tiempo real, de modo que el modelo puede decidir si esperar más salida, ejecutar otro comando o pasar a una respuesta final.

El modelo puede proponer varios comandos de shell en un solo paso, y la API de respuestas puede ejecutarlos de forma concurrente usando sesiones de contenedor separadas. Cada sesión transmite la salida de forma independiente, y la API multiplexa esos flujos de vuelta en salidas estructuradas de las herramientas como contexto. En otras palabras, el ciclo del agente puede paralelizar tareas, como buscar archivos, obtener datos y validar resultados intermedios.

Cuando el comando implica operaciones con archivos o procesamiento de datos, la salida del shell puede volverse muy grande y consumir el presupuesto de contexto sin aportar señales útiles. Para controlar esto, el modelo especifica un límite de salida por comando. La API de respuestas aplica ese límite y devuelve un resultado acotado que conserva tanto el inicio como el final de la salida, mientras marca el contenido omitido. Por ejemplo, podrías limitar la salida a 1000 caracteres, con el inicio y el final preservados:

texto al principio ... 1000 caracteres truncados ... texto al final

En conjunto, la ejecución concurrente y la salida acotada hacen que el ciclo del agente sea rápido y eficiente en contexto, de modo que el modelo pueda seguir razonando sobre los resultados relevantes en lugar de saturarse por registros sin procesar de la terminal.

Un posible problema con los ciclos del agente es que las tareas pueden ejecutarse durante mucho tiempo. Las tareas de larga ejecución llenan la ventana de contexto, lo cual es importante para proporcionar contexto entre turnos y entre agentes. Imagina un agente llamando a una skill, recibiendo una respuesta, agregando llamadas a herramientas y resúmenes de razonamiento: la ventana de contexto limitada se llena rápidamente. Para evitar perder el contexto importante a medida que el agente sigue ejecutándose, necesitamos una forma de conservar los detalles clave y eliminar cualquier cosa superflua. En lugar de exigir a los desarrolladores que diseñen y mantengan sistemas personalizados de resumen o de conservación de estado, incorporamos compactación nativa en la API de respuestas, diseñada para alinearse con el comportamiento del modelo y con la forma en que ha sido entrenado.

Nuestros modelos más recientes están entrenados para analizar el estado previo de la conversación y generar un elemento de compactación que conserva la información clave en una representación cifrada y eficiente en tokens. Después de la compactación, la siguiente ventana de contexto incluye este elemento de compactación junto con las porciones más relevantes de la ventana anterior. Esto permite que los flujos de trabajo continúen de forma coherente a través de los límites de las ventanas, incluso en sesiones extendidas de varios pasos y dirigidas por herramientas. Codex se basa en este mecanismo para sostener tareas de codificación de larga ejecución y la ejecución iterativa de herramientas sin degradar la calidad.

La compactación está disponible ya sea integrada en el servidor o a través de un punto de acceso independiente `/compact`. La compactación del lado del servidor permite configurar un umbral, y el sistema gestiona automáticamente el momento de la compactación, eliminando la necesidad de una lógica compleja del lado del cliente. Permite una ventana de contexto de entrada efectiva un poco mayor para tolerar pequeños excesos justo antes de la compactación, de modo que las solicitudes cercanas al límite puedan procesarse y compactarse en lugar de rechazarse. A medida que evoluciona el entrenamiento de los modelos, la solución de compactación nativa también evoluciona con cada nueva versión de modelo de OpenAI.

Codex nos ayudó a crear el sistema de compactación mientras actuaba como uno de sus primeros usuarios. Cuando una instancia de Codex presentaba un error de compactación, iniciábamos una segunda instancia para investigar. Como resultado, Codex obtuvo un sistema de compactación nativo y eficaz simplemente trabajando en el problema. Esta capacidad de Codex para inspeccionarse y perfeccionarse se ha convertido en un aspecto especialmente interesante de trabajar en OpenAI. La mayoría de las herramientas solo requieren que el usuario aprenda a usarlas; Codex aprende junto a nosotros.

Ahora, cubramos el estado y los recursos. El contenedor no solo es un lugar para ejecutar comandos, sino también el contexto de trabajo para el modelo. Dentro del contenedor, el modelo puede leer archivos, consultar bases de datos y acceder a sistemas externos bajo controles de políticas de red.

La primera parte del contexto del contenedor es el sistema de archivos para cargar, organizar y gestionar recursos. Creamos las API de contenedores y archivos⁠(se abre en una nueva ventana) para darle al modelo un mapa de los datos disponibles y ayudarlo a elegir operaciones de archivos específicas en lugar de realizar escaneos amplios y ruidosos.

Un antipatrón común es incluir todas las entradas directamente en el contexto del prompt. A medida que crecen las entradas, sobrecargar el prompt se vuelve costoso y difícil de navegar para el modelo. Un patrón más adecuado es preparar los recursos en el sistema de archivos del contenedor y dejar que el modelo decida qué abrir, analizar o transformar mediante comandos de shell. Al igual que los humanos, los modelos funcionan mejor con información organizada.

La segunda parte del contexto del contenedor son las bases de datos. En muchos casos, sugerimos a los desarrolladores almacenar datos estructurados en bases de datos como SQLite y consultarlos. En lugar de copiar, por ejemplo, una hoja de cálculo completa en el prompt, puedes darle al modelo una descripción de las tablas, especificar qué columnas existen y qué significan, y permitir que extraiga las filas que necesita.

Por ejemplo, si preguntas: “¿Qué productos tuvieron una disminución en las ventas este trimestre?”, el modelo puede consultar solo las filas relevantes en lugar de revisar toda la hoja de cálculo. Esto es más rápido, económico y escalable para conjuntos de datos más grandes.

La tercera parte del contexto del contenedor es el acceso a la red, una parte esencial de las cargas de trabajo del agente. Es posible que el flujo de trabajo del agente necesite obtener datos en tiempo real, llamar a APIs externas o instalar paquetes. Al mismo tiempo, otorgar acceso ilimitado a internet a los contenedores puede ser riesgoso: puede exponer información a sitios web externos, interactuar involuntariamente con sistemas internos sensibles o de terceros, o dificultar la protección contra filtraciones de credenciales y la exfiltración de datos.

Para abordar estas preocupaciones sin limitar la utilidad de los agentes, construimos contenedores alojados para usar un proxy de salida sidecar. Todas las solicitudes de red salientes fluyen a través de una capa de políticas centralizada que aplica listas de permitidos y controles de acceso, a la vez que mantiene el tráfico observable. Para las credenciales, usamos inyección de secretos con alcance de dominio en el egreso. El modelo y el contenedor solo ven marcadores de posición, mientras que los valores secretos sin procesar permanecen fuera del contexto visible para el modelo y solo se aplican a destinos aprobados. Esto reduce el riesgo de filtración mientras sigue permitiendo llamadas externas autenticadas.

Los comandos de shell son potentes, pero muchas tareas repiten los mismos patrones de varios pasos. Los agentes deben redescubrir el flujo de trabajo en cada ejecución, replanteando, reemitiendo comandos y reaprendiendo convenciones, lo que genera resultados inconsistentes y ejecución desperdiciada. Las habilidades del agente⁠(se abre en una nueva ventana) agrupan esos patrones en módulos reutilizables y componibles. Concretamente, una skill es un paquete organizado en una carpeta que incluye ‘SKILL.md⁠(se abre en una nueva ventana)’ (con metadatos e instrucciones) más cualquier recurso de apoyo, como especificaciones de API y recursos de la interfaz de usuario.

Esta estructura se ajusta de forma natural a la arquitectura del entorno de ejecución que describimos anteriormente. El contenedor proporciona archivos persistentes y contexto de ejecución, y la herramienta de línea de comandos proporciona la interfaz de ejecución. Con ambos en su lugar, el modelo puede descubrir archivos de skills usando comandos de shell (ls, cat, etc.) cuando lo necesite, interpretar instrucciones y ejecutar scripts de skills, todo dentro del mismo ciclo del agente.

Proporcionamos API⁠(se abre en una nueva ventana) para gestionar skills en la plataforma de OpenAI. Los desarrolladores cargan y almacenan carpetas de skills como paquetes versionados, que luego se pueden recuperar por ID de skill. Antes de enviar el prompt al modelo, la API de respuestas carga la skill y la incluye en el contexto del modelo. Esta secuencia es determinista:

1. Obtener los metadatos de la skill, incluyendo el nombre y la descripción.
2. Obtener el paquete de la skill, copiarlo en el contenedor y descomprimirlo.
3. Actualizar el contexto del modelo con los metadatos de la skill y la ruta en el contenedor.

Al decidir si una skill es relevante, el modelo explora progresivamente sus instrucciones y ejecuta sus scripts mediante comandos de shell dentro del contenedor.

Para unir todas las piezas: la API de respuestas proporciona orquestación, la herramienta shell proporciona acciones ejecutables, el contenedor alojado proporciona un contexto de ejecución persistente, las skills organizan lógica de flujo de trabajo reutilizable en capas, y la compactación permite que un agente se ejecute durante mucho tiempo con el contexto que necesita.

Con estas primitivas, un solo prompt puede expandirse en un flujo de trabajo de principio a fin: descubrir la skill adecuada, obtener datos, transformarlos en un estado estructurado local, consultarlos de forma eficiente y generar artefactos persistentes. 

El diagrama a continuación muestra cómo funciona este sistema para crear una hoja de cálculo a partir de datos en tiempo real.

Para ver un ejemplo detallado de cómo combinar la herramienta shell y el entorno de computadora para flujos de trabajo de principio a fin, consulta nuestra publicación del blog para desarrolladores⁠(se abre en una nueva ventana) y el cookbook⁠(se abre en una nueva ventana), donde se explica cómo empaquetar una skill y ejecutarla a través de la API de respuestas.

Nos emociona ver lo que los desarrolladores construirán con este conjunto de primitivas. Los modelos de lenguaje están pensados para hacer más que generar texto, imágenes y audio, y seguiremos evolucionando nuestra plataforma para que sea más capaz de manejar tareas complejas del mundo real a escala.