Orkas Orkas
Inicio Blog Arquitectura
Arquitectura

Detectar bucles no es detectar estancamientos: cómo identificar agentes que dan vueltas sin repetirse

Orkas tiene tres mecanismos de protección contra bucles. Ninguno detecta un modelo capaz que se estanca, porque los tres comprueban si se está repitiendo, y un modelo atascado nunca lo hace. Este es el punto ciego, la definición de progreso basada en los resultados que tomamos de BEACON y lo que planeamos medir antes de cambiar nada.

Esta es la primera de una serie de notas de diseño sobre agentes de largo horizonte, motivada por una lectura detenida de BEACON (Universidad de Zhejiang, arXiv:2605.06078).

Para que un agente mantenga su desempeño durante una tarea larga, creemos que deben funcionar bien dos cosas:

  • Debe seguir avanzando hacia el objetivo. Esto se divide en compactación del contexto (qué se puede olvidar sin riesgo), diseño de hitos (cómo saber que un paso está realmente terminado) y prevención del estancamiento (cuando se atasca, algo tiene que detectarlo).
  • Debe poder reflexionar y mejorar.

Esta publicación trata sobre la prevención del estancamiento, porque es lo que más nos costó.

En pocas palabras También hay que detectar al agente que da vueltas sin repetirse Orkas incluye detección de estancamiento, para que una ejecución larga te avise de que se ha atascado en lugar de gastar en silencio lo que queda de tu presupuesto.
Descargar Orkas — gratis

El síntoma

Recibimos reportes de usuarios y también lo observamos internamente: algunas tareas muy largas dejan de avanzar a mitad de camino.

Al revisar los registros, el agente está ocupado: lee archivos, busca, ejecuta comandos, nunca está inactivo. Pero media hora después no ha avanzado nada.

Nuestra primera explicación fue la pérdida de contexto: la compactación había eliminado el registro de que ya se había probado una vía, así que el agente volvía a intentarlo. Al leer el código junto con los registros, resultó que eso solo explicaba la mitad del problema.

Ya teníamos protecciones: tres niveles

NivelCriterioUmbrales
Repetición exactaNombre de la herramienta + argumentos canonizados, idénticos byte a byteLOOP_WARN=3 advertir / LOOP_HARD=5 forzar la detención
Duplicado aproximadoIdéntico salvo por los campos volátiles de identificador o marca de tiempoNEAR_DUP_LOOP_WARN=6 / NEAR_DUP_LOOP_HARD=12
Convergencia de señales de actividad sin avance≥2 compactaciones y ≥75% del presupuesto del bucle de herramientas consumidoSPIN_CONVERGENCE_MIN_COMPACTIONS=2
SPIN_CONVERGENCE_TOOL_LOOP_RATIO=0.75

El comentario de ese tercer nivel dice, literalmente: Señal compuesta de «puede estar dando vueltas tras una pérdida de contexto». Alguien ya lo había previsto. Así que el problema nunca fue que no hubiéramos construido nada, sino que lo construido no podía detectarlo.

El punto ciego: los tres detectores observan las entradas

La firma en la que se basa cada nivel es tool name + canonicalized args. Eso responde exactamente a una pregunta: ¿estás haciendo lo mismo dos veces?

Pero un modelo capaz que se atasca no repite llamadas. Hace esto:

leer el archivo A → grep X → volver a leer A con otro intervalo de líneas
  → ejecutar un comando ligeramente distinto → leer el archivo B → volver a usar grep …

Cada llamada tiene una firma distinta. Los tres niveles permanecen en silencio. Y durante todo ese tramo, el número de cambios de estado verificables es cero: ningún archivo se ha reescrito realmente, ningún comando produce un resultado nuevo, no ocurre absolutamente nada irreversible.

Detectar bucles no es detectar estancamientos. Lo primero observa las entradas. Lo segundo tiene que observar las salidas.

El artículo aporta precisamente esa definición basada en las salidas

La recompensa de BEACON dentro de un segmento:

r_t = R_ms · γ^(t_k − t)    if the segment ends in a milestone
    = 0                     otherwise

Un segmento que no termina en un hito obtiene exactamente cero, independientemente de cuántas acciones contenga. El número de acciones nunca interviene en la fórmula. Es la formalización más clara que hemos visto de estar ocupado ≠ avanzar.

La capa de referencia es aún más severa. La referencia es el retorno medio del grupo por paso, de modo que un segmento que necesitó 8 pasos cuando el promedio del grupo fue de 5 ve desplazada hacia valores negativos toda su ventaja, y la penalización aumenta en proporción al exceso. Dar vueltas no solo queda sin recompensa; se penaliza de forma activa y proporcional.

La figura 8 del artículo muestra una trayectoria fallida en la que las dos últimas acciones reciben un −2.20 idéntico. Esa cola —el tramo posterior al último hito que nunca llega a otro— es la forma matemática de dar vueltas sin avanzar. Y es común: las trayectorias que completan al menos un subobjetivo, pero no logran completar la tarea, se mantienen en el 39–47% de las muestras.

Un estudio de ablación descarta los activadores basados en el número de pasos

ParticiónPuntuaciónFrente a la referencia (72.8)
División aleatoria en 5 partes74.2+1.4
Hitos reales91.4+17.2

Dividir según cantidades arbitrarias de pasos aporta muy poco. Dividir según una estructura real aporta mucho.

Ahora volvamos a nuestro criterio de tercer nivel: 75% del presupuesto del bucle de herramientas consumido. Es un activador basado en un número arbitrario de pasos. Pregunta cuánto has consumido, no qué has logrado. La forma correcta es:

✗  if steps > N                              → intervene
✓  if steps > N AND zero verified milestones → intervene

El segundo no se activará por error en una tarea que legítimamente requiere mucho tiempo y está avanzando, porque esa tarea alcanza hitos por el camino. El primero sí.

También hay un bucle de retroalimentación positiva

Pongamos las constantes una junto a otra. La compactación se activa al alcanzar el 82% de la ventana de contexto. La convergencia de señales de actividad sin avance requiere dos compactaciones y el 75% del presupuesto del bucle para activarse.

dar vueltas → se llena el contexto → se activa la compactación → el resumen pierde el estado duradero
            → reconstruir lo perdido → seguir dando vueltas

El detector infiere que se está dando vueltas al observar que la compactación se repitió, pero la compactación es precisamente el paso que causa la amnesia. Está detectando un síntoma posterior y tiene que esperar a que el bucle complete dos vueltas.

Peor aún, su intervención consiste en instar al modelo a volver a apoyarse en su estado persistente. Si ese estado persistente es precisamente lo que la compactación eliminó, no queda nada en lo que apoyarse. Es un parche en la capa de instrucciones para un problema de la capa de estado.

Lo que estamos incorporando: detección de estancamiento basada en las salidas

Un cuarto nivel, construido a partir de dos contadores. Ambos se derivan mecánicamente de las observaciones de herramientas que el sistema anfitrión ya registra; ninguno necesita el juicio del modelo.

Pasos desde el último hito verificado. La métrica de progreso más sencilla posible, usada en el criterio compuesto anterior en lugar de por sí sola.

Nuevos cambios de estado sin duplicados. El más útil de los dos:

  • Una lectura de archivo cuyo hash de contenido coincide con el de una lectura anterior no aporta información nueva: volver a leer el mismo archivo en un rango de líneas diferente no cambia el hash.
  • Un comando cuyo nombre, código de salida y hash de salida coinciden con los de una ejecución anterior no aporta información nueva.
  • Una escritura cuyo hash posterior es igual al anterior significa que en realidad no se escribió nada.

Este contador se dirige exactamente al caso que la comparación de firmas no detecta: cada acción es diferente y la ganancia de información es cero. El criterio es mecánico y no necesita comprensión semántica.

Después, la presión debería ser continua en lugar de limitarse a un único recordatorio:

mostrar el contador en el contexto para que el modelo pueda verlo
  → exigir una revisión del plan (reconocer que esta vía no tiene salida)
    → preguntar al usuario
      → detener la ejecución, conservando los hitos ya alcanzados

Ese último escalón importa. Si la ejecución va a detenerse, debería hacerlo conservando lo logrado: ese mismo 39–47% de progreso parcial que el artículo midió y que se estaba descartando.

Lo que el artículo no nos da

BEACON es un método de entrenamiento. Moldea los gradientes para que la política entrenada sea menos propensa a divagar, pero no tiene un mecanismo propio de detección o intervención durante la ejecución. Aporta una definición del progreso, no un controlador. Nos corresponde diseñar los umbrales, las escalas de intervención y las condiciones de interrupción.

Su referencia por paso también necesita como punto de comparación la longitud media de los segmentos de un grupo. En producción, una tarea concreta de un usuario suele ejecutarse exactamente una vez, por lo que no hay grupo. El mejor sustituto disponible son las estadísticas históricas de tareas similares, que tienen bastante más ruido y no ofrecen ninguna de las garantías de aislamiento de la varianza del artículo.

El primer paso es medir, no corregir

Antes de cambiar cualquier lógica de decisión, queremos incorporar mediciones y responder a una pregunta que hoy no podemos contestar: de los estancamientos que ocurren en producción, ¿cuántos son del tipo amnesia y cuántos del tipo sin gradiente?

  • Si en su mayoría van acompañados de una ganancia de información nula mientras todas las firmas de llamadas difieren → tipo sin gradiente. Los tres niveles existentes no pueden detectarlo por su propia estructura, y la solución es la detección basada en las salidas.
  • Si en su mayoría van acompañados de la relectura de contenido que ya se eliminó durante la compactación → tipo amnesia. Lo que hay que corregir es qué conserva la compactación.

Esas dos conclusiones requieren inversiones completamente diferentes. Medir primero es más barato que diseñar primero, y la instrumentación tiene un costo casi nulo porque las observaciones ya existen.

Todo lo anterior depende de una noción en la que esta nota se ha apoyado sin definirla: un hito verificado. La siguiente nota trata de eso. Por qué declarar que un paso está completo no demuestra que lo esté, qué dos mitades ya existen en el producto sin haberse conectado nunca y un criterio que el artículo no contempla: fijarse en la irreversibilidad, no en la importancia.