Cómo evitar que un agente de IA entre en bucle y queme tokens
Un fallo de alcance en las herramientas de objetivo hizo que un agente hiciera 105 llamadas a la misma función sin dar respuesta. El informe del incidente señala dónde poner los límites.
Una petición de planificación trivial disparó 105 llamadas a la misma herramienta de objetivo. El sistema no se cayó en ningún momento: se limitó a seguir consumiendo tokens hasta que lo cortó el límite de turnos, sin llegar a producir una respuesta útil. El fallo no estaba en la lógica del agente, sino en el alcance de sus herramientas: las de objetivo estaban expuestas de forma global en lugar de quedar restringidas al nodo que era dueño del estado del objetivo.
Es el incidente que se ha documentado como INC-001, y el patrón es fácil de reconocer. Con las herramientas abiertas a todos los nodos, cualquiera podía pedir el mismo objetivo incompleto. El grafo reevaluaba, volvía a la misma decisión y repetía la llamada. Un bucle así no rompe nada, y precisamente por eso pasa desapercibido: no hay excepción, no hay caída, solo una factura que sube hasta que alguien o algo corta por número de turnos. Los detalles completos están en el informe del incidente.
Los controles que sí sirven
La primera medida es de diseño: asignar a cada herramienta un nodo dueño explícito. Después, acotar por arriba el número de turnos y el de llamadas por herramienta. También conviene detectar las transiciones que no aportan progreso, porque son la señal temprana de que el grafo está dando vueltas. Y probar la ruta real de planificación a ejecución con una petición pequeña, no con un caso de laboratorio.
El propio informe resume el problema en una línea que merece quedarse pegada al monitor: un valor de configuración no es una guarda si el bucle en producción no lo lee y lo aplica. Un test de regresión debería comprobar dos cosas concretas: que una petición del tipo 4+4 termina, y que los nodos de planificación no pueden llamar a las herramientas de estado de objetivo.
El escáner
La herramienta PreventAI marca patrones de código asociados a este tipo de incidente. Se lanza con prevention-scanner scan . --format json y devuelve la salida en JSON. El propio fabricante avisa de que el análisis es heurístico, así que no sustituye a nada: hay que combinarlo con pruebas de grafo, de carga y de terminación.
Merece la pena revisar el reparto en cualquier agente que ya esté en producción. Estos bucles no avisan con un error en los logs, avisan con el consumo. Antes de añadir otro nodo o otra herramienta, conviene mirar qué nodo posee cada una y qué pasa si dos empiezan a pedir lo mismo.
