Resumen Técnico: LIVEPLAN – Monitoreo en Línea y Dirección Correctiva de Agentes de Programación

Declaración del Problema

Corregir incidencias de GitHub en proyectos de software a gran escala es una tarea de largo horizonte que a menudo requiere que los agentes atraviesen trayectorias complejas. Los agentes actuales basados en LLM sufren frecuentemente de deriva de comportamiento e ineficiencias, tales como saltarse fases críticas (p. ej., la validación), repetir acciones fallidas o oscilar entre pensamientos sin progresar. Estos problemas conducen a fallos en las tareas o a costes inflados incluso cuando el agente finalmente tiene éxito.

Los enfoques existentes para corregir estas derivas sufren tres limitaciones principales:

1. Confusión entre Juez y Asesor: Los métodos previos suelen utilizar un único LLM tanto para diagnosticar problemas en la trayectoria como para recomendar correcciones. Esto crea un conflicto de interés donde el "asesor" está incentivado a encontrar problemas (sesgo de sicofancia), generando potencialmente consejos engañosos que descarrilan una trayectoria que en realidad estaba en el buen camino.
2. Activación Ineficiente: Los enfoques que dependen de la evaluación periódica por LLM (p. ej., cada $N$ pasos) o del análisis post-hoc suelen proporcionar retroalimentación demasiado tarde para que el agente se recupere o incurren en costes excesivos al tener que volver a ejecutar trayectorias completas.
3. Fiabilidad de los Jueces LLM: El uso de un LLM como juez introduce falta de fiabilidad; pueden pasar por alto problemas reales o señalar problemas espurios debido a alucinaciones, careciendo del determinismo requerido para una intervención robusta.

Metodología: LIVEPLAN

El artículo propone LIVEPLAN, un marco de monitoreo e intervención en línea que desacopla el juicio del asesoramiento. Está implementado sobre el framework SWE-agent y consta de tres componentes principales:

1. Monitor (Juez Determinista)

En lugar de utilizar un LLM, LIVEPLAN emplea un monitor determinista basado en reglas para evaluar la trayectoria del agente en tiempo real.

• Representaciones de la Trayectoria: El monitor utiliza dos representaciones abstractas:
  • GRAPHECTORY: Un grafo enriquecido donde los nodos son acciones distintas del agente y las aristas representan la ejecución cronológica. Rastrea bucles de acción y bucles de auto-referencia (self-loops).
  • LANGUTORY: Una abstracción de las acciones de bajo nivel en una secuencia de fases de resolución de problemas (p. ej., Navegación, Reproducción, Parcheo, Validación).
• Detección de Señales: El monitor comprueba estas representaciones contra una base de datos configurable de señales generales para detectar derivas de comportamiento. Estas incluyen:
  • Derivas de Bloqueo (Blocking Drifts): Violaciones críticas como saltarse fases (p. ej., enviar sin haber parcheado), parcheo prematuro o oscilación (razonamiento/acciones repetidas sin progreso). Estas activan una intervención inmediata.
  • Derivas de No Bloqueo (Non-Blocking Drifts): Ineficiencias como el estancamiento prolongado en una sola fase o acciones repetidas. Estas activan un consejo de dirección pero no bloquean la ejecución.
• Procesador de Intervención: Si se detecta una deriva, el procesador decide si bloquear la acción actual (para derivas de bloqueo) o añadir un consejo al historial (para derivas de no bloqueo), hasta un límite configurable para evitar el estancamiento.

2. Asesor (Corrección Basada en LLM)

El Asesor basado en LLM se consulta únicamente cuando el Monitor detecta una deriva.

• Entrada: Recibe la descripción del problema, una sección de la trayectoria reciente (desde el último consejo), el último consejo (si lo hay) y el consejo predefinido correspondiente a la deriva detectada.
• Salida: Genera una corrección de alto nivel para el siguiente paso en lugar de un replanificación global. Esto mantiene la intervención enfocada y evita la sobre-restricción del ejecutor.
• Mecanismo de Enfriamiento (Cooling Mechanism): Para gestionar el coste y la latencia, el Asesor está sujeto a un periodo de "enfriamiento" ($\theta_c$), asegurando que no sea invocado por cada paso individual incluso si las derivas son frecuentes.

3. Flujo de Trabajo

El sistema opera en un bucle: el agente propone un paso $\rightarrow$ el Monitor actualiza tentativamente las representaciones de la trayectoria $\rightarrow$ se comprueban las reglas. Si no se encuentra una deriva, el paso se ejecuta. Si se encuentra una deriva, se consulta al Asesor (si el enfriamiento lo permite) y el consejo resultante se inyecta en el contexto del agente para dirigir el siguiente paso.

Contribuciones Clave

1. Técnica: La introducción de LIVEPLAN, que separa la detección determinista de las derivas de comportamiento de la generación de consejos correctivos mediante LLM. Esta arquitectura evita la alucinación y el sesgo inherentes al uso de un único LLM para ambas tareas.
2. Evaluación Empírica: Una evaluación a gran escala en dos benchmarks (SWE-bench Verified y SWE-bench Pro) utilizando cinco LLM diversos (tres ejecutores, dos asesores). El estudio generó 7,752 trayectorias, proporcionando un conjunto de datos para futuras investigaciones.
3. Análisis Centrado en el Proceso: Más allá de las tasas de resolución, el artículo analiza el cumplimiento de la trayectoria, la prevalencia de derivas y la divergencia de estrategia, ofreciendo información sobre cómo las intervenciones mejoran el rendimiento del agente.

Resultados Experimentales

LIVEPLAN fue evaluado contra el vanilla SWE-agent, SAGE (un baseline de replanificación) y variantes abladas (Asesor Periódico, Consejo Predefinido).

• Tasas de Resolución: LIVEPLAN superó consistentemente a todos los baselines.
  • En SWE-bench Pro, logró ganancias de hasta un 15.2% (promedio de 9.9%) sobre los agentes vanilla.
  • En SWE-bench Verified, logró ganancias de hasta un 11.2%.
  • Las mejoras fueron más pronunciadas en instancias de dificultad media y difícil.
• Eficiencia de Costes: El coste adicional por instancia fue mínimo, con un promedio de $0.08. En algunos casos (p. ej., MiniMax-M2.5), LIVEPLAN de hecho redujo los costes totales al acortar trayectorias ineficientes.
• Comparación con SAGE: LIVEPLAN superó significativamente a SAGE, que a menudo fallaba porque sus replanificaciones globales eran factualmente incorrectas (alucinaban rutas de archivos o métodos), causando el fallo inmediato de los agentes. El consejo dirigido de LIVEPLAN hacia el siguiente paso resultó ser más robusto.
• Comparación con el Asesor Periódico: Aunque los asesores periódicos se activan con frecuencia, a menudo proporcionan consejos erróneos. LIVEPLAN activó al Asesor con menos frecuencia pero con mayor precisión, resultando en mejores tasas de resolución.
• Robustez: Una reevaluación en un subconjunto de instancias con resultados deterministas confirmó que las ganancias no fueron artefactos de la no-determinidad de las ejecuciones.

Significado y Reivindicaciones

El artículo afirma que LIVEPLAN representa un paso significativo hacia la dirección en línea de agentes de programación al abordar la inestabilidad fundamental de usar LLM como jueces. Al confiar en reglas deterministas para detectar cuándo un agente tiene problemas y reservar los LLM solo para determinar qué hacer a continuación, el sistema logra:

• Mayor Fiabilidad: Evita la "replanificación engañosa" que causa que los agentes abandonen trayectorias exitosas.
• Escalabilidad: Incurre en un overhead computacional mínimo comparado con métodos que vuelven a ejecutar agentes o invocan LLM en cada paso.
• Generalizabilidad: El enfoque es agnóstico al modelo y funciona a través de diferentes arquitecturas de LLM y dificultades de benchmark.

Los autores concluyen que, si bien la intervención en el tiempo de inferencia es efectiva, el trabajo futuro debería centrarse en el entrenamiento posterior consciente de la intervención para asegurar que los agentes puedan ejecutar de manera fiable los consejos correctivos proporcionados por sistemas como LIVEPLAN.