interactivamente en una terminal o un IDE.
Esto es útil. Pero esto también lleva a una pregunta natural:
¿Puede Codex convertirse en una parte integrable de nuestro propio flujo de trabajo?
Respondamos eso en esta publicación.
Específicamente, exploraremos cómo ejecutar Codex como un agente sin cabeza dentro de un pequeño flujo de trabajo de automatización e ilustraremos la idea con un estudio de caso concreto.
1. La forma del flujo de trabajo que queremos
Podemos pensar en Codex como un agente muy capaz.
Cuando usamos Codex de forma interactiva, vive dentro de una conversación. Debes estar allí todo el tiempo para revisarlo y orientarlo hacia lo que realmente deseas.
Un flujo de trabajo sin cabeza no requiere eso. Allí, Codex deja de ser un interlocutor de conversación y se convierte en sólo un paso al que se puede recurrir en un proceso más amplio.
En un nivel alto, podemos pensar en el flujo de trabajo de esta manera:
El truco consiste en mantener ese paso limitado: el flujo de trabajo proporciona el contexto de la tarea para Codex, y Codex devuelve un resultado que el siguiente paso puede consumir fácilmente.
Este patrón es útil cuando el proceso general es repetible, pero un paso requiere trabajo de agencia. Por ejemplo, es posible que un trabajo programado deba preparar un resumen de investigación semanal, o que un flujo de trabajo de CI deba ejecutar una revisión automatizada.
Al incorporar a Codex a un flujo de trabajo más amplio, obtenemos los beneficios de ambas partes: el código ordinario mantiene el proceso determinista, estructurado y fácil de inspeccionar, mientras que Codex maneja las partes abiertas que realmente pueden beneficiarse de un agente.
Esta es la forma del flujo de trabajo que construiremos en el estudio de caso.
2. Estudio de caso: creación de un flujo de trabajo de resumen de investigación
Aquí, creamos un pequeño flujo de trabajo de automatización que solicita al Codex que investigue los desarrollos recientes sobre un tema y convierte el resultado en un resumen HTML.
En código, nuestro flujo de trabajo se ve así en Python:
ejecutar = preparar_research_task() breve = run_codex(ejecutar) html_path = render_digest(breve)
La división del trabajo es muy sencilla. Python prepara la tarea y produce el artefacto final. El paso intermedio de investigación, de duración abierta, está a cargo del Codex.
Ahora analicemos el flujo de trabajo pieza por pieza.
2.1 Preparando la carrera
En el primer paso, solo preparamos los insumos necesarios para la ejecución del Codex. Esto significa tres cosas: el mensaje, el esquema de salida y las ubicaciones de los archivos para el resumen final y el seguimiento de ejecución.
Al igual que configurar un agente habitual, debemos preparar un mensaje para que Codex aclare la tarea y el resultado esperado.
Comenzamos con el mensaje. Al igual que configurar un agente habitual, debemos decirle a Codex cuál es la tarea y cuál es el resultado esperado. Usamos la siguiente plantilla de aviso:
Investigue desarrollos de materiales en {{TOPIC}} desde {{WINDOW_START}} hasta {{WINDOW_END}}, inclusive, utilizando la búsqueda web en vivo. Regresa en la mayoría de los {{MAX_EVENTS}} eventos. Para cada evento, incluya: – fecha – título – categoría – resumen – por qué es importante – fuentes Devuelve solo el objeto JSON descrito por el esquema proporcionado.
Luego Python convierte esto en un mensaje concreto para una ejecución:
desde fecha y hora fecha de importación, timedelta def prepare_research_task (tema: str, as_of: date, lookback_days: int, max_events: int,) -> dict: window_end = as_of window_start = as_of – timedelta(days=lookback_days – 1) solicitud = (PROMPT_TEMPLATE .replace(“{{TOPIC}}”, tema) .replace(“{{WINDOW_START}}”, window_start.isoformat()) .replace(“{{WINDOW_END}}”, window_end.isoformat()) .replace(“{{MAX_EVENTS}}”, str(max_events)) ) return { “prompt”: rápido, “schema_file”: “schemas/evidence_brief.schema.json”, “brief_file”: “salidas/brief.json”, “trace_file”: “salidas/run.jsonl”, }
Tenga en cuenta que en lugar de pedirle al Codex que devuelva un informe de formato libre, le pedimos que devuelva un JSON estructurado. Esto es importante porque el siguiente paso puede consumir el resultado del Codex mediante programación. Aquí está el esquema que utilizamos:
{ “topic”: “…”, “window_start”: “AAAA-MM-DD”, “window_end”: “AAAA-MM-DD”, “summary”: “…”, “eventos”: [
{
“date”: “YYYY-MM-DD”,
“title”: “…”,
“category”: “…”,
“summary”: “…”,
“why_it_matters”: “…”,
“sources”: [
{
“publisher”: “…”,
“title”: “…”,
“published_date”: “YYYY-MM-DD”,
“url”: “https://…”
}
]
} ]}
Además, usamos brief_file para almacenar la respuesta estructurada final y trace_file para almacenar el seguimiento de ejecución de la ejecución sin cabeza. Esas rutas se utilizarán cuando llamemos al Codex en el siguiente paso.
En este punto, todavía no ha sucedido nada significativo. Sólo hicimos el trabajo de preparación necesario.
2.2 Ejecutar Codex sin cabeza
Lo primero es lo primero, asegúrese de que la CLI del Codex esté disponible desde la línea de comandos. Si ya tienes Node.js y npm instalados, puedes hacer esto:
instalación npm –global @openai/codex
Luego inicie sesión y verifique la instalación:
inicio de sesión del codex estado de inicio de sesión del codex codex –versión
Para ejecutar Codex de forma no interactiva, necesitamos codex exec. El comando principal se ve así:
codex –search exec \ –model gpt-5.6-sol \ –json \ –output-schema esquemas/evidence_brief.schema.json \ -o salidas/brief.json \ –
Algunas explicaciones sobre los argumentos:
–search: permite que Codex utilice búsqueda web en vivo. –modelo: qué modelo usar para la ejecución. –output-schema: le dice al Codex la forma de salida esperada. -o: le dice a Codex que escriba la respuesta final en brief.json. –json: hace que Codex emita eventos JSONL a la salida estándar, que escribimos en run.jsonl (el archivo de seguimiento). -: le dice a Codex que lea el mensaje de la entrada estándar.
Codex CLI también admite controles de ejecución que son útiles en entornos automatizados. Por ejemplo, tenemos el argumento –sandbox, como –sandbox read-only (limita la ejecución al acceso de solo lectura) y –sandbox workspace-write (permite cambios dentro del espacio de trabajo). Estas configuraciones son útiles cuando el agente puede inspeccionar o modificar archivos locales.
En Python, podemos usar subprocess.run() para llamar al mismo comando:
importar json importar subproceso desde pathlib importar ruta def run_codex(ejecutar: dict) -> dict: comando = [
“codex”,
“–search”,
“exec”,
“–model”,
“gpt-5.6-sol”,
“–json”,
“–output-schema”,
run[“schema_file”]”-o”, ejecutar[“brief_file”]”-“, ]Ruta(ejecutar[“brief_file”]).parent.mkdir(padres=Verdadero, existe_ok=Verdadero,) con open(ejecutar[“trace_file”]”w”, codificación=”utf-8″) como seguimiento: subproceso.run(comando, entrada=ejecutar[“prompt”]text=True, stdout=trace, check=True, ) devuelve json.loads( Path(run[“brief_file”]).read_text(codificación=”utf-8″) )
2.3 Representar el resumen como HTML
En este paso final, convertimos el resumen estructurado producido por Codex a HTML:
desde pathlib importar Ruta def render_digest( breve: dict, archivo_salida: str = “outputs/digest.html”, ) -> Ruta: html = f”””
{breve[“summary”]}
{“”.unirse(f”
{evento[‘title’]}
“f”
{evento[‘summary’]}
“para el evento en breve[“events”]
)} “”” ruta_salida = Ruta(archivo_salida) ruta_salida.write_text(html, codificación=”utf-8″) devuelve ruta_salida
El renderizador anterior recibe un diccionario Python normal y escribe un archivo HTML.
Con esto concluye nuestro flujo de trabajo de tres pasos.
2.4 Ejecutar el flujo de trabajo
Ahora ejecutemos el flujo de trabajo sobre un tema concreto.
Aquí, utilizo la infraestructura del centro de datos de IA como tema de investigación. Últimamente se está produciendo bastante desarrollo. Quiero utilizar Codex para ayudarme a ver las tendencias.
run = prepare_research_task( topic=”Infraestructura del centro de datos de IA”, as_of=date(2026, 7, 12), lookback_days=30, max_events=6, ) brief = run_codex(run) html_path = render_digest(breve)
Codex realizó una investigación profunda y generó un diccionario estructurado de resumen, y luego render_digest() convierte el resumen estructurado en una página HTML en outputs/digest.html.
El resumen HTML contiene el resumen, una línea de tiempo, tarjetas de eventos y enlaces de origen. Este es el resultado final del flujo de trabajo.
Debido a que usamos –json, Codex escribe el flujo de eventos en la salida estándar, que guardamos para ejecutar[“trace_file”]. El seguimiento consta de eventos, que pueden ser cuando comienza la ejecución, cuando Codex realiza búsquedas en la web o cuando se producen mensajes intermedios. Esto es útil para inspeccionar y depurar ejecuciones sin cabeza.
3. Cuando este patrón es útil
En muchos flujos de trabajo, algunos pasos realizan un procesamiento determinista, mientras que otros resuelven preguntas abiertas. Al colocar un agente dentro de un flujo de trabajo orquestado por el código determinista, obtenemos tanto adaptabilidad como control.
Pero aquí no estamos creando un agente personalizado desde cero. Estamos utilizando Codex, que ya nos brinda un entorno agente capaz, capacidad de uso de herramientas, zona de pruebas, etc.
Con codex exec, podemos acceder a esas capacidades directamente desde un script.
Por supuesto, Codex todavía se puede utilizar de forma interactiva. Pero la ejecución sin cabeza le otorga otra función, es decir, un componente invocable dentro de los flujos de trabajo que ya utilizamos.
¡Probar!