Comando /goal: Cómo Ejecutar Código de Codex y Claude como Agentes Autónomos 24/7

Cada laboratorio de IA importante lanzó la misma primitiva en las últimas seis semanas. Anthropic añadió /goal a Claude Code. OpenAI lo implementó dentro de Codex CLI y la aplicación de escritorio de Codex. Nous Research lo integró en Hermes. El nombre es consistente a propósito; la industria se está decantando por una interfaz compartida para una cosa: un agente que funciona en un bucle cerrado hasta que se alcanza un estado final medible, sin pedirte permiso en cada paso.

Si has estado haciendo el baile manual de "aprobar, enviar un prompt, decirle al agente que continúe, repetir", /goal es el comando de barra que lo termina. Le das al agente un objetivo, este trabaja para alcanzarlo y regresa cuando el objetivo se cumple.

Esta guía es para desarrolladores y constructores de API. Cubriremos lo que /goal realmente hace por debajo, cómo configurarlo en Codex y Claude Code, una estructura de prompt que produce resultados reales en lugar de bucles infinitos, y cómo conectar todo esto a tu flujo de trabajo de API usando Apidog.

Descarga Apidog gratis si quieres seguir los ejemplos de API más adelante en la guía.

Qué hace realmente /goal

En una línea: /goal permite que un agente de IA realice un bucle en una tarea hasta que se active una condición de parada, sin necesidad de que tú lo apruebes.

El mecanismo subyacente es simple. Un modelo validador pequeño y rápido se ejecuta después de cada paso que toma el agente principal y responde a una pregunta: "¿Se ha cumplido el objetivo?" Si no, el modelo principal continúa. Si sí, el bucle se cierra y el agente informa. Este es el mismo patrón que el "bucle Ralph" popularizó a principios de 2026, excepto que ahora se envía como un comando de primera clase dentro de las herramientas oficiales.

El contraste con el uso normal del agente:

• Sin /goal: tú eres el bucle. Lees la salida, decides si es correcta, le indicas el siguiente paso, apruebas una llamada a una herramienta, y así sucesivamente. Cada iteración te cuesta atención.
• Con /goal: el agente posee el bucle. Planifica, ejecuta, se autovalida y solo se muestra cuando termina, alcanza una restricción o se queda sin presupuesto.

Un ejemplo concreto: decirle a Claude Code /goal create a landing page activa la investigación, el andamiaje, el estilismo, la depuración y una vista previa final, todo en una ejecución continua. Te alejas, regresas y lo lanzas o iteras.

Por qué esto está de repente en todas partes

La razón por la que /goal se está implementando en todos los proveedores ahora mismo es que las tareas de agente de largo alcance estaban fallando de dos maneras predecibles:

1. Desviación. Sin un validador que verificara el objetivo original, los modelos se desviaban y producían una salida segura pero incorrecta.
2. Supervisión constante. Incluso cuando el modelo podía hacer el trabajo, los usuarios tenían que supervisar cada iteración, lo que anulaba el propósito de un agente.

Un segundo modelo validador soluciona ambos problemas. Es económico (modelo pequeño, prompt conciso) y proporciona al bucle una condición de parada clara. Ese es todo el truco. Una vez que los laboratorios se dieron cuenta de que este patrón funcionaba, todos lo implementaron con el mismo nombre en cuestión de semanas.

Configuración de /goal en Codex

El CLI de Codex te da el mayor control. Aquí está la configuración mínima:

1. Habilitar objetivos en la aplicación de escritorio: abre el escritorio de Codex, ve a Configuración → Configuración, y establece goals = true. El CLI hereda esto.
2. Inicia el CLI en modo completamente automático para que dejes de ver los prompts de aprobación:

codex --approval-mode full-auto

3. Establece un objetivo:

/goal [tu objetivo aquí]

Eso es todo. Codex imprimirá una confirmación de que el objetivo está registrado y luego comenzará a ejecutarse.

Si no eres técnico, empieza con la aplicación de escritorio de Codex en lugar del CLI. La funcionalidad es la misma, pero obtienes una interfaz de usuario para pausar, borrar y observar el uso de tokens.

Configuración de /goal en Claude Code

El CLI de Claude Code funciona de forma casi idéntica. Inicia el CLI, escribe /goal y síguelo con la descripción de la tarea. La documentación oficial se encuentra en el sitio de documentación de Claude Code.

Si te encuentras con errores de configuración al iniciar Claude Code, la solución para la configuración de empresa custom3p inválida cubre el modo de fallo más común. Para una mirada más profunda sobre cómo manejar Claude Code con flujos de trabajo multiagente junto con /goal, consulta nuestro análisis de Ruflo, una capa multiagente sobre Claude Code.

Un consejo fácil de pasar por alto: /goal te muestra el recuento de tokens en vivo y una barra de progreso para la tarea en ejecución dentro de Claude Code. Observa el recuento de tokens, no solo la salida. Un objetivo que está consumiendo tokens sin progreso es una señal de que el validador no está logrando converger, y deberías presionar /pause o /goal clear.

La estructura de prompt que realmente funciona

La sintaxis para /goal es trivial. La parte difícil es escribir un prompt que produzca un resultado utilizable en lugar de un agente que se ejecute durante dos horas y te entregue algo sutilmente incorrecto.

Cada prompt efectivo de /goal tiene tres componentes:

1. El trabajo: lo que quieres que se haga, en una línea.
2. El estado final medible: cómo se ve "hecho", en una forma que el validador pueda verificar.
3. Las restricciones: reglas que deben mantenerse en todo momento.

El esqueleto:

/goal [haz el trabajo] hasta [estado final medible] sin [restricciones que deben mantenerse]

Un ejemplo real para una tarea de codificación:

/goal arreglar cada prueba fallida hasta que npm test salga con 0 sin modificar ningún archivo fuera del directorio /auth

El estado final es verificable (código de salida de npm test), y la restricción es un límite estricto que el validador puede hacer cumplir en cada iteración. El agente no puede simular la finalización porque el validador ejecuta el comando de prueba.

Para tareas ambiguas ("haz que esta UI se sienta moderna"), /goal funciona mal porque el estado final no es medible. O bien reescribes el objetivo para que sea medible ("hasta que la puntuación de accesibilidad de Lighthouse sea 90+"), o te quedas con un prompt normal.

Estructura avanzada para tareas más largas

Para objetivos más grandes, expande el esqueleto en cuatro bloques:

/goal
Objetivo: [objetivo de una línea]
Criterios de éxito:
  - [criterio medible 1]
  - [criterio medible 2]
Restricciones:
  - [límite 1]
  - [límite 2]
Contexto:
  - [archivos, repositorios, claves API que el agente debe conocer]

Este formato le da al validador cosas concretas para verificar en cada iteración del bucle. Sin criterios de éxito, el validador recurre a una coincidencia semántica difusa, que es de donde proviene la deriva.

Ejemplos que vale la pena tomar prestados

/goal no es solo para escribir código. Algunos patrones que funcionan bien:

Investigación

/goal recopilar todos los benchmarks públicos para Claude Opus 4.7 publicados desde abril de 2026, guardar las fuentes y producir una tabla Markdown ordenada por fecha hasta que la tabla cubra al menos 10 benchmarks distintos

Mantenimiento de repositorio

/goal encontrar código muerto, dependencias no utilizadas y archivos obsoletos en este repositorio, luego proponer una descripción de PR listando eliminaciones seguras hasta que cada elemento tenga una justificación

Documentación

/goal reescribir README.md para que un nuevo colaborador pueda instalar, ejecutar, probar y entender el proyecto hasta que cada uno de esos cuatro pasos tenga un comando que funcione y una salida esperada

Trabajo de funciones

/goal añadir un alternador de tema oscuro/claro, persistir la elección en localStorage, actualizar los estilos para ambos temas y verificar en el navegador hasta que el alternador funcione sin recargar la página y sobreviva a una actualización

El patrón común: cada ejemplo establece un estado final verificable. Esa es la línea entre un objetivo que termina y un objetivo que da vueltas.

Combinando /goal con flujos de trabajo de desarrollo de API

La mayor parte de la cobertura de /goal hasta ahora ha sido sobre tareas de codificación genéricas. El caso de uso más interesante para los ingenieros de backend y plataforma es el trabajo de API, donde el estado final es casi siempre comprobable.

Los endpoints de API son perfectos para /goal porque "hecho" es inequívoco: la solicitud devuelve 200, el esquema de respuesta coincide y el contrato está documentado. Puedes escribir un objetivo que diga "haz que este endpoint pase sus pruebas" y el validador tiene una señal concreta para leer.

Un flujo de trabajo que se mantiene en la práctica:

1. Diseña el contrato primero en Apidog. Define el endpoint, el esquema de solicitud, el esquema de respuesta y las cargas útiles de ejemplo dentro de Apidog. Esto se convierte en la fuente de la verdad.
2. Exporta la especificación. Apidog exporta OpenAPI 3.x, que entregas a Codex o Claude Code como contexto.
3. Ejecuta /goal. Dile al agente: "implementa el endpoint hasta que todos los casos de prueba de Apidog pasen".
4. El validador comprueba el ejecutor de pruebas. En cada iteración del bucle, el validador ejecuta las pruebas CLI de Apidog contra el servicio en ejecución. El agente solo finaliza cuando todos los casos están en verde.

Esto es sustancialmente mejor que dejar que el agente invente sus propias pruebas, porque el contrato ya está establecido. El agente no puede enviar una suite de pruebas que pase pero que omita casos extremos que la especificación cubría.

Si no has usado Apidog antes, la plataforma de API combina diseño, mocking, pruebas y documentación en una sola herramienta, lo cual es importante aquí porque /goal funciona mejor cuando el validador solo tiene que ejecutar un comando para verificar el estado. Nuestra guía de flujo de trabajo de API de diseño primero cubre la configuración de contrato primero en detalle, y la descripción general de la herramienta de prueba de API para ingenieros de control de calidad muestra cómo estructurar los casos de prueba con los que el agente iterará.

Si estás trabajando con servidores MCP (el protocolo que la mayoría de las herramientas de codificación de IA usan ahora para llamar a herramientas externas), el mismo patrón se aplica. Consulta pruebas de servidor MCP con Apidog para la configuración que permite a los agentes de /goal ejecutarse de forma segura contra tu servidor MCP local.

Consejos profesionales de la ejecución de /goal en producción

Algunas cosas que solo aprendes después de poner /goal a trabajar de verdad:

• Un objetivo a la vez. Tanto Codex como Claude Code te restringen a un único objetivo activo. Intentar apilarlos produce estados extraños. Usa /goal clear entre ejecuciones.
• Combínalo con /plan. Un flujo de trabajo útil es /plan primero, revisar el plan, luego /goal con el plan como contexto. Esto reduce a la mitad el número de iteraciones porque el agente no rediseña el enfoque a mitad del bucle.
• Usa archivos markdown como borradores. Dile al agente que mantenga un archivo progress.md. Obtendrás un rastro de auditoría legible y el agente obtendrá un contexto persistente entre iteraciones.
• Deja que el modelo escriba su propio objetivo. Ingresa tu idea general en un prompt normal y pide al modelo que la convierta en una invocación de /goal con criterios de éxito. El modelo escribe mejores prompts de objetivo que tú, porque sabe lo que el validador realmente puede verificar.
• Observa al validador, no al modelo principal. Si el bucle no se cierra, el problema es casi siempre que los criterios de éxito no son medibles. Ajusta los criterios, no intentes el mismo objetivo.
• /goal es para trabajo de largo plazo. Para un refactor de una línea, un prompt normal es más rápido. El bucle autónomo tiene una sobrecarga.

Cuando /goal te fallará

Limitaciones honestas a tener en cuenta:

• Costo. Un bucle que se ejecuta durante una hora consume más tokens que la misma tarea realizada manualmente. Establece un presupuesto.
• Tareas sin señal. El pulido de la interfaz de usuario, el tono de la prosa, el gusto del diseño; nada de esto tiene un validador claro. El agente se rendirá o inventará una condición de parada falsa.
• Efectos secundarios externos. Un objetivo que implica enviar correos electrónicos, realizar pagos o llamar a APIs de producción necesita restricciones estrictas. El agente no inferirá cautela por sí mismo. Si todavía estás construyendo el control de acceso para que los agentes de IA llamen a tus APIs, el artículo sobre el uso de GitHub Copilot y la API de facturación para equipos cubre cómo los principales proveedores manejan esto.
• Contexto obsoleto. Los objetivos de larga duración pueden desviarse de la especificación original si el código base cambia a mitad del bucle. Pausa y reinicia en lugar de dejar que continúe con un contexto antiguo.

Lo que esto significa para cómo construyes con IA

/goal es el cambio de "IA como autocompletar" a "IA como un trabajador al que das instrucciones y supervisas". El cambio de interfaz es pequeño (un comando de barra), pero la implicación es grande: el trabajo que haces como desarrollador se mueve hacia la escritura de mejores criterios de éxito y restricciones, y se aleja de escribir las líneas de código reales.

Los equipos que sacan el máximo partido de esto son los que ya tienen contratos comprobables, un CI sólido y especificaciones claras. Si tu API tiene un documento OpenAPI definido y un conjunto de pruebas, puedes entregar a un agente /goal un endpoint y una fecha límite. Si tu API solo existe en la cabeza de alguien, el agente no tiene nada contra lo que validar y el bucle se deshace.

Aquí es donde las plataformas API se convierten en infraestructura clave para los flujos de trabajo de IA. Apidog está construido en torno al desarrollo de API con un enfoque de diseño primero, y eso se vuelve mucho más útil cuando el agente que realiza la implementación puede leer tu especificación y verificar su propio trabajo contra tus casos de prueba. Descarga Apidog si quieres configurar el flujo de trabajo de contrato primero descrito anteriormente.

Preguntas frecuentes

¿Funciona /goal en la aplicación web de Codex? Sí. Funciona en Codex CLI, Codex de escritorio, la aplicación Codex y Claude Code CLI. Hermes también es compatible con el mismo comando. La paridad de características entre proveedores es el objetivo.

¿En qué se diferencia /goal de un prompt regular? Un prompt regular se ejecuta una vez y se detiene. /goal se ejecuta en un bucle cerrado con un modelo validador que verifica la condición de parada después de cada paso. El agente decide cuándo detenerse, no tú.

¿Puede el agente romper las restricciones que he establecido? El validador aplica las restricciones en cada iteración, por lo que el agente no debería violarlas. En la práctica, cuanto más vaga sea la formulación de la restricción, más margen tendrá el agente para interpretarla. Sé explícito: "sin modificar ningún archivo fuera de /auth" es aplicable; "sin romper nada" no lo es.

¿Costará /goal más que una sesión normal de Claude o Codex? Sí. Espera gastar más tokens. El validador se ejecuta en un modelo más barato y pequeño, pero el modelo principal sigue haciendo el trabajo, y lo hace de forma más autónoma. Establece un presupuesto o usa /pause para controlar el gasto.

¿Qué pasa si quiero probar la salida del agente contra una API real? Usa una herramienta como Apidog para bloquear el contrato de la API y ejecutar casos de prueba reales contra la implementación. El validador del agente puede llamar al CLI de Apidog, lo que te da un estado final medible. Consulta la guía gratuita de API de Claude si estás iniciando un servicio basado en Claude con un presupuesto limitado.