For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/es/articles/claude-code-loop-engineering-four-ways.md.
Este artículo explica cuatro patrones de bucles de Claude Code: por turnos, por objetivos, programados y proactivos, junto con sus activador...

No afirme que el cambio en la interfaz de usuario está completo solo porque la edición fue exitosa.
Si cualquiera de las comprobaciones falla, debe solucionar el problema y volver a ejecutar desde el paso 1.
La idea central no radica en la redacción en sí, sino en que esta habilidad permite que Claude obtenga la misma evidencia que un revisor humano.
Las comprobaciones cuantitativas son especialmente efectivas:
Cuanto más cuantificable sea el proceso de verificación, menor será la frecuencia de intervención humana.
Cuando una sola ronda de operación puede no ser suficiente, pero se puede describir claramente el punto final, el mecanismo de bucle basado en objetivos es particularmente útil.
Claude Code no permite que el agente operativo juzgue por sí mismo si el resultado es "suficientemente bueno", sino que utiliza un evaluador independiente después de cada ronda de operación.

El usuario inicia un objetivo en la sesión actual.
El bucle finaliza cuando ocurre lo siguiente:
El bucle basado en objetivos es adecuado para tareas con un punto final verificable, como:
El ejemplo oficial de Anthropic es el siguiente:
/goal Hacer que la puntuación de Lighthouse de la página principal sea de 90 o más, detenerse después de 5 intentos.
Otro ejemplo práctico:
/goal Todas las pruebas en el directorio test/auth pasan y el paso de lint no muestra errores
Según la documentación actual de Claude Code, el comando /goal requiere la versión 2.1.139 o superior de Claude Code.
Cuando Claude completa una ronda de operación, un modelo evaluador ligero y rápido verifica si se cumplen las condiciones.
Si las condiciones no se cumplen, comienza automáticamente una nueva ronda de operación; si se cumplen, se elimina el objetivo actual y se devuelve el control de la sesión al usuario.
Esta separación es importante porque el modelo de trabajo no debe ser el único juez de su propia salida.
Una condición de finalización efectiva debe tener:
Objetivo débil:
/goal Mejorar la página de inicio
La palabra "mejorar" no define un punto final medible.
Objetivo fuerte:
/goal Aumentar la puntuación de rendimiento de Lighthouse para móviles a al menos 90,
mantener la accesibilidad en 95 o más, y detenerse después de 5 intentos
Objetivo débil:
/goal Arreglar las pruebas
Objetivo fuerte:
/goal Todas las pruebas en el directorio test/payments pasan, sin pruebas omitidas,
y el comando npm run lint tiene código de salida 0
El modelo no debe adivinar qué significa el éxito.
/goal no cambia los permisosEl objetivo abarca varias rondas, pero no aprueba automáticamente todas las llamadas de herramientas.
En el modo de permisos predeterminado, Claude aún puede hacer una pausa para confirmar comandos que no están permitidos.
Para objetivos no supervisados, Anthropic recomienda combinar /goal con el modo automático cuando esté disponible y sea apropiado. Esto debe hacerse después de revisar las herramientas permitidas, los límites del repositorio y los posibles efectos secundarios.
/loop y /scheduleAlgunos trabajos no se activan por la finalización de la ronda anterior, sino por el tiempo.
La tarea sigue siendo similar, pero la entrada cambia:
Cada ejecución se inicia mediante un intervalo de tiempo o una programación configurada.
El bucle local se detiene cuando usted lo cancela, cierra el entorno o el trabajo de monitoreo finaliza.
Las rutinas en la nube continúan ejecutándose según su configuración hasta que se pausan o deshabilitan.
Los bucles basados en tiempo son adecuados para:
El ejemplo oficial usa /loop:
/loop 5m Revisar mis solicitudes de extracción, procesar los comentarios de revisión y corregir las CI fallidas
Este mensaje se vuelve a ejecutar según el intervalo configurado.
Los bucles locales dependen de la máquina y la sesión actuales. Si la computadora se apaga o el proceso se detiene, el bucle también se detiene.
Para trabajos que deben continuar cuando la computadora portátil está cerrada, Claude Code puede usar /schedule para crear rutinas en la nube.
Una rutina activa podría comenzar de la siguiente manera:
/schedule Cada hora: Verificar nuevos informes de errores en #project-feedback
Las rutinas de Claude Code se ejecutan en la infraestructura en la nube administrada por Anthropic y pueden activarse mediante:
Al momento de escribir esto, las rutinas están en vista previa de investigación, por lo que el comportamiento, las limitaciones y la interfaz de API pueden cambiar. La disponibilidad también depende del plan de Claude correspondiente, las políticas de la organización y si la versión web de Claude Code está habilitada.
Un error común es ejecutar bucles con una frecuencia mucho mayor que la tasa de cambio del sistema externo.
Si el nuevo problema aparece solo unas pocas veces al día, no tiene sentido verificar la cola de problemas cada minuto. Esto aumenta el uso de tokens, el número de llamadas a herramientas y...
No añada ruido que afecte los resultados.
Haga coincidir el intervalo de sondeo con la frecuencia esperada de cambio:
| Patrón de cambio externo | Frecuencia de sondeo inicial razonable |
|---|---|
| Estado de CI después de un push activo | Cada 5–10 minutos |
| Canal de comentarios del equipo | Cada 30–60 minutos |
| Resumen diario de Slack | Una vez al día por la mañana |
| Actualización de dependencias | Diario o semanal |
| Desviación de documentación | Cada noche o semanal |
Estas son sugerencias iniciales, no reglas universales. Cuando el sistema externo lo admita, la activación por eventos suele ser mejor que el sondeo.
El bucle activo es una combinación de los elementos básicos anteriores.
Se ejecuta sin supervisión, responde al trabajo planificado o entrante, y lleva cada elemento de tarea a través de un flujo definido.

Una tarea programada, una solicitud API, un evento de GitHub, un mensaje, un problema u otra señal externa inicia el trabajo.
Cada tarea independiente finaliza una vez alcanzado su objetivo.
Las rutinas circundantes continúan recibiendo trabajo futuro hasta que alguien las deshabilita.
El bucle activo es ideal para flujos de trabajo repetitivos y bien definidos:
El ejemplo de Anthropic combina varias funcionalidades de Claude Code:
/schedule para verificar nuevos informes./goal para definir lo que debe completarse en una ejecución.Las instrucciones combinadas podrían verse así:
/schedule cada hora: revisa los informes de errores en #project-feedback.
/goal: no detenerse hasta que cada informe encontrado en esta ejecución
sea clasificado, procesado y respondido.
Al corregir errores, utiliza un flujo de trabajo en un árbol de trabajo paralelo
para explorar tres soluciones, revisadas por un revisor independiente.
Esto ya no es solo un mensaje repetido. Es un pequeño sistema operativo para un flujo de trabajo específico.
Los flujos de trabajo dinámicos son scripts para coordinar subagentes a gran escala.
Claude escribe un script de orquestación en JavaScript que el entorno de ejecución ejecuta en segundo plano. Los resultados intermedios pueden mantenerse en variables del script sin saturar el contexto principal de la conversación.
Anthropic posiciona los flujos de trabajo para tareas como:
La documentación actual indica que los flujos de trabajo dinámicos requieren Claude Code versión 2.1.154 o superior. Pueden coordinar decenas o cientos de agentes, por lo que deben probarse a pequeña escala antes de realizar tareas de producción masivas.
Las tareas programadas, la orquestación, los bucles de retroalimentación y las colas de trabajo no son conceptos nuevos en ingeniería.
La verdadera transformación es que los agentes de codificación ahora pueden participar más en el bucle:
El mensaje no ha desaparecido. Se ha convertido en un componente de un sistema de control más grande.
Ahora, las preguntas de diseño más importantes son:
Un mensaje bien escrito no puede compensar la falta de condiciones de detención.
Anthropic insiste en la validación: permitir que Claude verifique y mida su propio resultado.
Si se le pide a un ingeniero humano que construya una página sin acceso al navegador, trabaja a ciegas. La situación es similar para los agentes.
Las herramientas de validación útiles incluyen:
Un script que devuelve un código de salida 0 o 1 suele ser más barato y fiable que pedirle al modelo que razone desde cero si se ha cumplido un requisito.
Por ejemplo:
npm test
npm run lint
npm run typecheck
Un script de validación combinado podría ser:
#!/usr/bin/env bash
set -euo pipefail
npm run typecheck
npm run lint
npm test
Claude puede ejecutar este script después de cada cambio. El bucle no necesita reinterpretar todo el proceso de aceptación cada vez.
Anthropic también sugiere usar un revisor con contexto nuevo.
El agente implementador ya ha visto su propio razonamiento y podría repetir los mismos supuestos. Un revisor independiente está menos limitado por esa ruta y puede examinar los resultados desde otro ángulo.
Para cambios de alto valor, el sistema puede usar:
Más agentes no siempre es mejor. Solo agréguelos cuando el valor de la revisión justifique el costo adicional.
Los bucles que pueden continuar indefinidamente son poderosos pero peligrosos.
Existen tres modos principales de fallo.
Cada ciclo puede consumir tokens de entrada, tokens de salida, llamadas a herramientas y uso de modelos de pago.
Sin un límite de rondas o presupuesto, los bucles abiertos pueden seguir consumiendo costos mientras generan poco valor adicional.
Claude Agent SDK admite tanto:
max_turns / maxTurnsmax_budget_usd / maxBudgetUsdLa documentación oficial del SDK indica:
Por defecto, ninguno de los dos límites está configurado.
Para agentes en producción, los límites explícitos son una línea base razonable.
El agente puede editar repetidamente el mismo archivo sin generar nuevas pruebas aprobadas o mejoras medibles.
Describe tu idea una vez y We0 AI puede generar un sitio de presentacion, paginas y CMS, y ayudarte a atraer clientes y trafico tras el lanzamiento.
Una generación completa de proyectos para registro gratuito
Lo mejor para probar un flujo de generación completo y ver rápidamente el primer borrador del proyecto.
Incluso si el sistema está probando diferentes variantes de un mismo enfoque fallido, los registros pueden parecer activos.
Las señales útiles de falta de progreso incluyen:
Cuando el progreso se estanca, un bucle robusto debe detenerse o escalar.
La iteración puede hacer que una solución defectuosa sea más compleja en lugar de más correcta.
El agente puede añadir capas alrededor de suposiciones erróneas, generando código que parece cada vez más completo, pero que se aleja del comportamiento esperado.
Las revisiones independientes, las pruebas deterministas y las rutas claras de reversión ayudan a prevenir este tipo de fallos.
Un bucle práctico debe incluir al menos tres tipos de barreras.
El estado de finalización debe poder verificarse mediante pruebas, scripts, evaluadores u observación externa del estado.
Ejemplos:
Establezca al menos un límite superior estricto:
Un límite convierte un fallo infinito en un fallo finito.
Deténgase cuando el sistema ya no avance hacia el objetivo.
Por ejemplo:
Si después de tres intentos consecutivos no se generan nuevas pruebas aprobadas
y se modifican los mismos archivos, detén la ejecución e informa el bloqueo.
Una implementación de producción puede rastrear esto mediante scripts o estado del flujo de trabajo, no solo confiando en instrucciones.
Los bucles deben diseñarse para invertir recursos de razonamiento en las etapas de mayor valor.
Anthropic recomienda las siguientes medidas de control de costos.
Las tareas pequeñas no necesitan un flujo de trabajo multiagente.
Comience de la siguiente manera:
/goal cuando se necesiten más rondas./loop o /schedule cuando el trabajo deba activarse por tiempo.Los modelos rápidos y de bajo costo pueden manejar:
Reserve los modelos más potentes para:
Los flujos de trabajo dinámicos pueden crear una gran cantidad de agentes.
Primero ejecute en un entorno pequeño:
Todo el trabajo acumulado.
Los proyectos piloto revelan consumo de tokens, cuellos de botella en herramientas, fallos comunes y eslabones de control faltantes.
Cuando el flujo sea determinista, simplemente escriba el código una vez y deje que Claude lo ejecute.
Por ejemplo:
Los bucles basados en tiempo deben reflejar la velocidad de cambio del sistema subyacente.
Intervalos demasiado cortos aumentan costos sin ofrecer mejores resultados.
Anthropic ofrece varios comandos para verificar el consumo:
/usage
Este comando muestra el uso reciente en áreas como habilidades, subagentes e integración MCP.
Ejecutar /goal sin parámetros muestra las rondas y el consumo de tokens del objetivo actual, mientras que /workflows muestra el uso de agentes de flujo de trabajo y ofrece controles para detenerlos.
La disponibilidad puede variar según la versión de Claude Code y las funciones habilitadas.
La automatización no debe confundirse con el acceso sin restricciones.
Claude Code admite modos de permisos que controlan qué herramientas y comandos pueden ejecutarse.
Para trabajo autónomo en máquinas de desarrollo, Anthropic recomienda mantener reglas explícitas de permiso o usar un modo que apruebe automáticamente operaciones comunes limitadas, mientras sigue controlando comandos de alto riesgo.
Los modos que evitan permisos deben usarse solo en entornos aislados, como:
Un bucle activo que pueda editar archivos, ejecutar comandos de shell, acceder a sistemas externos y crear solicitudes de extracción debe contar con:
El objetivo no es eliminar todas las decisiones humanas, sino reservar la intervención humana para decisiones que realmente requieran juicio.
Consulte el siguiente proceso de decisión.
Anthropic recomienda comenzar con una tarea en la que actualmente usted sea un cuello de botella.
Hágase tres preguntas.
Ejemplos:
Un objetivo útil describe un estado, no solo una actividad.
Mejor redacción:
Todas las pruebas de pago pasan y no quedan errores de TypeScript.
Peor redacción:
Seguir mejorando el módulo de pagos.
Si la tarea aparece cada hora, día, semana o después de eventos conocidos, puede ser adecuada para un bucle o rutina.
Si alguna respuesta es afirmativa, tiene un candidato para su primer bucle.
Imagine un equipo que repara repetidamente verificaciones fallidas en solicitudes de extracción.
Revisa las PR actuales, repara las pruebas de CI fallidas y explica los cambios.
El desarrollador reejecuta manualmente esta operación cada vez que cambia el CI.
Cree una habilidad que pueda:
/goal Todas las verificaciones necesarias de CI pasan, detenerse después de 4 intentos
La sesión puede continuar con múltiples intentos de reparación.
/loop 10m Revisar PR, procesar nuevos comentarios de revisión,
y reparar cualquier verificación obligatoria fallida.
El agente verifica cambios externos.
Cree una rutina en la nube activada por eventos de solicitud de extracción o un cronograma.
Limítelo a:
La evolución es gradual. Cada fase agrega automatización solo después de que la fase anterior tenga verificaciones confiables.
"Mejorar el código base" puede continuar indefinidamente.
Divídalo en resultados observables.
Use pruebas, scripts o evaluadores independientes.
Un solo agente con un validador potente puede ser mejor que un flujo de trabajo grande y mal coordinado.
Sondear cada minuto no es inherentemente más receptivo.
Los bucles sin límite superior pueden llevar a fallos costosos.
Use permisos, hooks, sandboxes y entornos aislados para la ejecución determinista.
Cuando el mismo error se repite, mejore la habilidad, regla, validador o flujo de trabajo que lo genera.
La ingeniería de bucles es el diseño de flujos de trabajo de agentes repetitivos hasta que se cumpla una condición de parada. Se centra en activadores, verificación, límites, permisos y escalamiento, no solo en la redacción de las indicaciones.
Anthropic clasifica los bucles en basados en rondas, basados en objetivos, basados en tiempo y activos.
Su principal diferencia radica en el mecanismo que desencadena un nuevo ciclo y la entidad o factor que determina cuándo detener el trabajo.
/goal en Claude Code?/goal establece una condición de finalización para la sesión actual. Tras cada ronda, un evaluador independiente comprueba si se cumple dicha condición; si no es así, se inicia la siguiente ronda, hasta alcanzar el objetivo o el límite configurado.
/loop y /schedule?/loop ejecuta repetidamente un mensaje en la máquina local a intervalos determinados, por lo que el bucle se detiene cuando la máquina o la sesión finaliza. /schedule, en cambio, crea una tarea rutinaria en la nube que puede seguir ejecutándose en la infraestructura gestionada por Anthropic, incluso si el portátil está apagado.
Si el flujo de trabajo carece de límites, el bucle podría ejecutarse más tiempo del previsto. Antes de permitir una ejecución no supervisada, se debe definir una condición de finalización cuantificable, un límite duro de rondas o costes, y una regla de detención ante falta de progreso.
No. Una sesión normal de Claude Code con habilidades de verificación reutilizables puede ser suficiente. Los flujos de trabajo dinámicos y los múltiples agentes son más útiles cuando se requiere procesamiento paralelo a gran escala o revisiones independientes.
Usa el tipo de bucle más simple, elige modelos más pequeños para tareas rutinarias, haz pruebas en cargas de trabajo reducidas, sustituye el razonamiento determinista con scripts, evita sondeos innecesarios y establece límites claros de rondas o presupuesto.
Sí, siempre que sus permisos, repositorios, credenciales, presupuesto, condiciones de parada y rutas de escalada estén estrictamente controlados. No utilices modos que omitan permisos en máquinas normales que contengan datos sensibles o valiosos.
SKILL.md./goal, comportamiento de evaluación, control de estado y requisitos.Los bucles de Claude Code no son simples mensajes repetidos, sino sistemas controlados donde colaboran desencadenantes, herramientas, validación, permisos, presupuesto y condiciones de parada.
Los bucles basados en rondas permiten que el humano controle cada paso siguiente; los bucles de objetivo delegan la condición de finalización al evaluador; los bucles programados delegan el desencadenante. Los bucles proactivos combinan estos elementos básicos en flujos de trabajo no supervisados que pueden ejecutarse repetidamente.
La mejora más importante no suele consistir en añadir más agentes, sino en dotar a los agentes existentes de mecanismos fiables de autoverificación, criterios de finalización claramente definidos y la capacidad de detener el sistema cuando se agota el progreso o el presupuesto.
Un bucle útil no es el que puede ejecutarse para siempre, sino el que puede demostrar cuándo debe detenerse.
Empieza con una sola frase y obtén un sitio completo en minutos.