Resumen Técnico: Disecando el Comportamiento de los Modelos a través de las Trayectorias de los Agentes

Planteamiento del Problema

El artículo argumenta que el rendimiento de los agentes de IA es fundamentalmente un problema de sistemas, no meramente un problema de modelado. Si bien los Grandes Modelos de Lenguaje (LLM) poseen capacidades avanzadas, estas suelen quedar sin realizar en la práctica debido a un desalineamiento entre el modelo y el "harness" (arnés): la capa de software que media las llamadas a herramientas, gestiona el bucle de pensamiento-acción-observación y reintroduce los resultados de la ejecución en el contexto.

Los autores formalizan este desalineamiento como la brecha de intención-ejecución: un desajuste bidireccional donde (1) el harness falla al ejecutar lo que el modelo pretende (por ejemplo, debido a errores de parsing o desajustes en la interfaz de la herramienta), y (2) el modelo recibe un relato inexacto de lo que el harness ejecutó (por ejemplo, salidas truncadas o mensajes de error genéricos). Esta brecha provoca que los agentes razonen a partir de premisas falsas, lo que conduce a fallos en cascada incluso cuando el modelo subyacente es capaz. Los autores postulan que minimizar esta brecha es tan crítico como diseñar herramientas o bucles de ejecución, y que los benchmarks actuales a menudo confunden la capacidad del modelo con la fricción del harness.

Metodología

El Simple Strands Agent (SSA)

Para aislar y minimizar la brecha de intención-ejecución, los autores desarrollaron el Simple Strands Agent (SSA), un harness de código abierto y personalizable. El SSA está diseñado para ser un marco único y unificado que se adapta a diferentes familias de modelos mediante ajustes específicos de interfaz estrechos, en lugar de un ajuste basado en tareas.

Componentes Arquitectónicos Clave:

• Límites de Herramientas Ricos en Retroalimentación: El SSA asegura un intercambio de información transparente. Las llamadas a la shell devuelven retroalimentación estructurada (comando, estado, código de salida, salida, texto de error). Las ediciones están ancladas a líneas vecinas, y las ediciones exitosas devuelven diffs unificados para confirmar su aplicación.
• Equilibrio Razonamiento-Herramienta: El harness emplea "estímulos de razonamiento" para equilibrar el pensamiento de cadena de pensamiento (chain-of-thought) interno con la recopilación de evidencia externa. Para los modelos Claude, esto implica objetivos cuantitativos (por ejemplo, "realizar más de 50 llamadas a herramientas") para romper largas cadenas de razonamiento. Para otras familias (Gemini, Grok), se utilizan directivas flexibles ("usa herramientas tanto como sea posible") para evitar el exceso de pensamiento o llamadas a herramientas vacías.
• Alineación Específica del Modelo: El SSA adapta las interfaces de las herramientas para coincidir con las preferencias de los modelos aprendidas durante el entrenamiento. Por ejemplo, utiliza apply_patch para modelos GPT y divide las operaciones atómicas para Grok, en lugar de forzar una interfaz de herramienta monolítica que degrade el rendimiento.

Marco de Análisis de Trayectorias

Yendo más allá de las métricas binarias de aprobado/fallido, los autores introducen un marco para analizar el comportamiento del agente en un espacio de estados de código a nivel de texto.

• Distancia de Solución ($D(t)$): Definen una métrica que mide la distancia entre el estado actual del repositorio del agente y un conjunto de soluciones verificadas como correctas (una aproximación empírica al espacio de soluciones del oráculo). Esto permite rastrear qué tan cerca está un agente de una solución en cada ciclo.
• Cuantificación de Retroceso (Backtracking): Al calcular el cambio en la distancia de la solución ($\Delta D$) entre ediciones, los autores identifican eventos de "retroceso" donde un agente se aleja de una solución ($\Delta D > 0$).
• Firmas de Comportamiento: Utilizando un juez de LLM, las trayectorias se clasifican en fases (explorar, localizar, implementar, verificar) y categorías de llamadas a herramientas (ediciones de fuente, pruebas de scratch, pruebas de suite) para revelar patrones de resolución de problemas específicos de cada familia.

Protocolo de Evaluación

El estudio evalúa 21 modelos de cinco familias (Claude, GPT, Gemini, Grok, Qwen) en tres benchmarks: SWE-Bench-Verified, SWE-Bench-Pro y Terminal-Bench-2. Los autores generan aproximadamente 138,000 trayectorias. Crucialmente, auditan la fuga de historial de git (git-history leakage) en los contenedores públicos de SWE-Bench-Pro, donde los commits futuros son accesibles para el agente, y comparan los resultados contra contenedores "Sanitizados" donde este historial ha sido podado.

Contribuciones Clave

1. Harness SSA: Introducción del Simple Strands Agent, que reproduce o supera las cifras oficiales de los model cards para 21 modelos de cinco familias utilizando un único harness mínimamente adaptado, demostrando que el alto rendimiento es alcanzable sin un ajuste específico de la tarea.
2. Métrica de Distancia de Solución: Definición de una métrica de espacio de estados de código a nivel de texto que rastrea la calidad de la trayectoria y la distancia hacia las soluciones verificadas, permitiendo el análisis más allá de las puntuaciones binarias de pass@1.
3. Análisis a Nivel de Trayectoria: Identificación de firmas de comportamiento estables y específicas de cada familia (por ejemplo, ratios de edición/prueba, cronogramas de fases, tasas de retroceso) que diferencian a los modelos incluso cuando sus puntuaciones de pass@1 son indistinguibles.
4. Auditoría de Integridad de la Evaluación: Cuantificación de un canal de fuga de historial de git en los contenedores públicos de SWE-Bench-Pro, mostrando que esto infla el pass@1 hasta en un 6.9% para ciertos modelos, y proporcionando una base de comparación "Sanitizada" para una comparación más justa.

Resultados Experimentales

• Rendimiento: El SSA logra puntuaciones de pass@1 que igualan o superan los números oficiales de los model cards en los tres benchmarks. Por ejemplo, en SWE-Bench-Verified, Opus 4.6 y Gemini 3.1 Pro lograron un 80.80% de pass@1, mientras que GPT-5.4 alcanzó un 80.16%.
• Comportamientos Divergentes: A pesar de tener puntuaciones de pass@1 similares, los modelos exhiben trayectorias radicalmente distintas.
  • Retroceso (Backtracking): Existe un desacoplamiento entre la tasa de resolución y el retroceso. Gemini 3.1 Pro tuvo la mayor tasa de retroceso (14.3%) pero empató en la tasa de resolución más alta, mientras que GPT-5.4 tuvo el menor retroceso (1.2%) con una tasa de resolución similar.
  • Cronogramas de Fase: Los modelos difieren en cómo asignan el esfuerzo. Opus 4.6 realiza pruebas de scratch significativas temprano y las ediciones alcanzan su pico en el medio, mientras que GPT-5.4 aumenta gradualmente las pruebas de scratch y pasa más tiempo en las fases de implementación/verificación.
  • Uso de Herramientas: Los modelos GPT tienden a agrupar la escritura de scripts y su ejecución en llamadas únicas, mientras que los modelos Claude y Qwen suelen separar la escritura de la ejecución de los scripts.
• Impacto de la Fuga (Leakage): En SWE-Bench-Pro, eliminar el historial de git futuro (Sanitizado) redujo el pass@1 para varios modelos. Opus 4.6 cayó un 6.87% (de 57.45% a 50.58%), y GPT-5.4 cayó un 3.32%. Esto confirma que los benchmarks públicos pueden sobreestimar la capacidad del modelo debido a la fuga ambiental.

Significado y Reivindicaciones

El artículo sostiene que la brecha entre las capacidades documentadas de los modelos y el rendimiento realizado de los agentes se debe en gran medida a la fricción del harness y no a limitaciones fundamentales de los diseños de agente único basados en ReAct simple. Al minimizar la brecha bidireccional de intención-ejecución, un harness bien diseñado puede desbloquear todo el potencial de diversas familias de modelos.

Además, los autores argumentan que a medida que los modelos convergen en el rendimiento de los benchmarks de alto nivel, el pass@1 deja de ser un diferenciador. En su lugar, comprender la trayectoria —cómo los modelos resuelven problemas, su estabilidad y su eficiencia en el espacio de estados de código— se convierte en la métrica crítica para el co-diseño de modelo-harness. El trabajo enfatiza que los agentes efectivos requieren no solo modelos poderosos, sino interfaces que se alineen con los comportamientos y preferencias aprendidos específicos de cada modelo.

Los autores concluyen que el objetivo del diseño de agentes debe ser mantener fijos los invariantes de ejecución mientras se adaptan las interfaces para encontrar a cada familia de modelos "donde su entrenamiento la dejó", en lugar de forzar una superficie de herramientas de talla única.