💻 computer science

From Failed Trajectories to Reliable LLM Agents: Diagnosing and Repairing Harness Flaws

Este artículo presenta HarnessFix, un marco de trabajo guiado por trazas que diagnostica fallos de agentes mediante el análisis de trazas de ejecución y código de soporte para generar parches dirigidos y validados que mejoran significativamente la fiabilidad de los agentes de LLM en múltiples evaluaciones.

Autores originales: Mengzhuo Chen, Junjie Wang, Zhe Liu, Yawen Wang, Qing Wang

Publicado 2026-06-05

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Mengzhuo Chen, Junjie Wang, Zhe Liu, Yawen Wang, Qing Wang

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes un asistente brillante pero a veces confundido (el Agente LLM) intentando resolver acertijos complejos, como reparar un programa de computadora averiado o planificar un viaje. Este asistente no trabaja solo; trabaja dentro de una "sala de control" construida por ingenieros. Esta sala de control se llama Harness (Arnés).

El Harness es el conjunto de reglas, herramientas y controles de seguridad que le dicen al asistente:

Qué herramientas puede usar (como un destornillador o un motor de búsqueda).
Qué información puede ver (como un mapa o un manual).
Cómo informar su progreso.
Cuándo detenerse y decir: "He terminado".

El Problema: La "Caja Negra" del Fallo

A veces, el asistente falla. En el pasado, cuando las cosas salían mal, los ingenieros intentaban arreglarlo de la siguiente manera:

Retocando las instrucciones del Asistente: "¡Oye, intenta tener más cuidado!" (Esto es como decirle a un conductor que "conduzca mejor" sin arreglar los frenos rotos).
Adivinando: Mirar el resultado final y esperar que un cambio aleatorio ayude.

El problema es que estos métodos a menudo no detectan el problema real. Puede que el fallo no sea culpa del asistente; puede que sea que el Harness le dio la herramienta equivocada, le ocultó un mensaje de error crucial o le permitió rendirse antes de terminar el trabajo. Debido a que las acciones del asistente ocurren en una cadena de eventos larga y desordenada, es difícil determinar exactamente dónde se rompió la sala de control.

La Solución: HARNESSFIX (El Detective)

Los autores de este artículo crearon un nuevo sistema llamado HARNESSFIX. Piensa en él como un detective forense para la sala de control. En lugar de adivinar, investiga la escena del crimen (el intento fallido) paso a paso para encontrar la parte exacta que se rompió del Harness.

Así es como funciona HARNESSFIX, usando una analogía simple:

1. El "Traductor" (HTIR)

Primero, el detective toma el registro desordenado y confuso de lo que sucedió (la "traza") y el código de la sala de control, y los traduce en un mapa limpio y organizado llamado HTIR.

Analogía: Imagina una escena del crimen caótica con pistas dispersas. El detective organiza las pistas en una línea de tiempo clara: "A las 10:00, el agente pidió una herramienta. A las 10:01, la herramienta dio un error. A las 10:02, el agente ignoró el error". Este mapa conecta las acciones del agente directamente con las reglas que los gobernaban.

2. El "Diagnóstico" (Encontrar al Culpable)

Luego, el detective observa el mapa para encontrar exactamente dónde se rompió la cadena.

Analogía: El detective pregunta: "¿El agente falló porque no sabía la contraseña? ¿O porque la puerta fue bloqueada por el sistema de seguridad (el Harness)?"
HARNESSFIX identifica si el problema estuvo en la Interfaz de Herramientas (instrucciones incorrectas), el Ciclo de Vida (dejar que el agente se rinda demasiado pronto) o la Observabilidad (ocultar los mensajes de error). Crea un "Informe de Fallos" específico para problemas recurrentes.

3. El "Taller de Reparaciones" (Reparaciones Acotadas)

Una vez identificado el fallo, HARNESSFIX no permite que cualquiera reescriba toda la sala de control. Eso sería peligroso y podría romper otras cosas. En su lugar, utiliza un conjunto de Operadores de Reparación.

Analogía: Piensa en ellos como herramientas específicas en un kit de mecánico. Si el problema es un tornillo flojo, el mecánico usa una llave inglesa. Si el problema es un neumático pinchado, usan un gato hidráulico. HARNESSFIX solo usa la "llave inglesa" específica necesaria para ese fallo concreto. Escribe un parche pequeño y preciso para arreglar solo esa parte rota, asegurando que no rompa accidentalmente el motor.

4. El "Inspector de Seguridad" (Validación)

Antes de que se instale el nuevo parche, un inspector de seguridad lo comprueba.

Analogía: El inspector hace dos preguntas:
1. "¿Arregló esto el problema específico que encontramos?"
2. "¿Arregló esto accidentalmente algo más que funcionaba bien?"
Si la respuesta a la segunda pregunta es "Sí", el parche es rechazado. Esto evita que el sistema empeore mientras intenta mejorar.

¿Qué descubrieron?

Los investigadores probaron este sistema de detección en cuatro tipos diferentes de tareas difíciles (reparar software, usar líneas de comandos, realizar investigación y automatizar aplicaciones).

Los Resultados: HARNESSFIX mejoró la tasa de éxito de los agentes entre un 15% y un 50% en comparación con la configuración original.
La Comparación: Funcionó mejor que:
- Expertos humanos que diseñaron manualmente las salas de control.
- Otros sistemas de IA que intentaron arreglarse a sí mismos simplemente cambiando instrucciones o adivinando.
El Descubrimiento: Descubrieron que muchos fallos no se debían a que la IA fuera "tonta", sino a que la "sala de control" tenía fallos ocultos, como ocultar mensajes de error o permitir que la IA se rindiera demasiado pronto. HARNESSFIX encontró estos fallos ocultos y los reparó.

En Resumen

HARNESSFIX es un sistema que trata un intento fallido de la IA como una escena del crimen. No solo culpa a la IA; investiga el entorno en el que trabajaba la IA, encuentra la regla o herramienta específica que está rota y aplica un arreglo preciso y seguro. Esto hace que la IA sea mucho más fiable sin necesidad de reentrenar el cerebro de la IA o adivinar qué salió mal.

Resumen Técnico: De trayectorias fallidas a agentes de LLM fiables: Diagnóstico y reparación de fallos en el harness

1. Declaración del problema

Los agentes basados en LLM dependen cada vez más de los harnesses (arneses): infraestructuras de ejecución en tiempo de ejecución que proporcionan entornos de ejecución, interfaces de herramientas, gestión de contexto, orquestación de ciclo de vida, observabilidad, verificación y gobernanza (resumidos por la taxonomía ETCLOVG). Aunque los métodos actuales de agentes de auto-mejora y evolución automática de harnesses intentan mejorar el rendimiento mediante la supervisión en tiempo de ejecución, la optimización de prompts o la búsqueda de flujos de trabajo, a menudo fallan al intentar diagnosticar eficazmente las causas raíz de los fallos.

Los enfoques actuales sufren tres limitaciones principales:

Evidencia fragmentada: La evidencia del fallo está dispersa en trayectorias de ejecución heterogéneas, ricas en lenguaje y no deterministas, lo que dificulta un diagnóstico preciso.
Brecha de mapeo: Incluso cuando un fallo se localiza dentro de una trayectoria, mapearlo de vuelta a la implementación estática específica del harness (código fuente, prompts, configuraciones) responsable de este es un desafío, debido a que el comportamiento en tiempo de ejecución y los artefactos estáticos a menudo no están alineados explícitamente.
Modificaciones sin alcance definido: Sin un diagnóstico causal dirigido, las mejoras suelen ser amplias, indirectas o mal delimitadas. Además, modificar los mecanismos del harness para corregir un fallo conlleva el riesgo de introducir regresiones en otros puntos, un desafío exacerbado por las dependencias implícitas en los sistemas de agentes.

Los métodos existentes suelen optimizar basándose en resultados finales sin identificar dónde reside la evidencia en la trayectoria o qué capa del harness falló, lo que conduce a correcciones superficiales que no abordan los fallos estructurales subyacentes.

2. Metodología: HARNESSFIX

El artículo propone HARNESSFIX, un marco guiado por trazas diseñado para diagnosticar fallos de agentes y reparar harnesses a través de un pipeline de cuatro agentes. La filosofía central es impulsar la reparación del harness a partir de diagnósticos de fallos detallados y fundamentados en las trazas.

A. Representación Intermedia de Trazas Sensible al Harness (HTIR)

Para abordar la heterogeneidad de las trazas de ejecución puras, HARNESSFIX compila las trazas puras y el código del harness en una HTIR unificada. Esta representación normaliza la evidencia fragmentada y captura:

Nodos (TraceSteps): Pasos de ejecución recuperables (llamadas al modelo, acciones de herramientas, validaciones) con identificadores únicos.
Atributos: Mensajes de petición/respuesta, estado de ejecución y efectos de artefactos/estado (lectura/escritura/desconocido).
Enlaces:
- Enlaces temporales: Preservan el orden de ejecución.
- Enlaces de procedencia de entrada: Rastrean cómo se construyó una petición a partir del contenido previo de la trayectoria y la lógica del harness (por ejemplo, ensamblaje de memoria, construcción de prompts).
- Enlaces de flujo de control: Explican por qué un paso fue activado por el controlador del harness (por ejemplo, reintento, delegación, terminación).
Evidencia diagnóstica local al nodo: Una visión localizada para cada paso que combina la procedencia de la entrada, el flujo de control y los efectos de los artefactos.
Faceta de responsabilidad de la capa del Harness: Mapea cada paso a las capas relevantes de ETCLOVG (Ejecución, Herramientas, Contexto, Ciclo de Vida, Observabilidad, Verificación, Gobernanza) basándose en la evidencia adjunta.

B. Diagnóstico de Fallos del Harness

Un Agente de Diagnóstico procesa la HTIR para producir registros de diagnóstico estructurados:

Localización de síntomas: Identifica el síntoma del fallo a partir del resultado de la evaluación final.
Retroceso de evidencia (Backtracking): Utiliza enlaces temporales, de procedencia y de flujo de control para generar un conjunto clasificado de pasos candidatos responsables.
Adjudicación de candidatos: Inspecciona la evidencia local del nodo y las referencias al código del harness para seleccionar el paso (o pasos) responsable(s) final(es).
Mapeo de capas: Asigna las capas ETCLOVG implicadas a los pasos responsables.
Consolidación de fallos: Agrupa los registros de diagnóstico a través de múltiples ejecuciones para identificar patrones de fallos recurrentes, resumiéndolos en Registros de Fallos accionables.

C. Reparación con Alcance Definido

Para evitar ediciones inestables y rupturas arquitectónicas, HARNESSFIX emplea Operadores de Reparación en lugar de una auto-edición de forma libre.

Mapeo: Los registros de fallos se mapean a operadores de reparación específicos (por ejemplo, "estrechamiento del esquema de la herramienta", "protección de bucles") destilados de los registros de cambios de versión en repositorios de agentes.
Especificación de reparación: El operador seleccionado se instancia en una especificación específica del fallo que define:
- Objetivo y Alcance: Artefactos concretos del harness a modificar.
  vi Restricciones de Edición: Recursos prohibidos (por ejemplo, datos de benchmark, evaluadores).
- Comportamiento Requerido: El comportamiento específico que el parche debe implementar.
- Validación y Riesgo: Criterios de aceptación, incluyendo la reducción del fallo objetivo y los límites de regresión.

D. Validación de Parches y Memoria del Harness

Un Agente de Validación asegura la seguridad y la eficacia:

Pre-validación: Comprueba si el diff candidato cumple con la especificación de reparación y la sintaxis básica.
Evaluación del conjunto de validación: Evalúa el parche en un conjunto de validación no utilizado para asegurar que reduce la ocurrencia del fallo objetivo ( $\Delta D_{target} \ge \delta_{min}$ ) sin introducir regresiones inaceptables ( $R_{new} \le r_{max}$ ).
Memoria del Harness: Registra los resultados (aceptados o rechazados) para informar futuras iteraciones, proporcionando ejemplos para fallos similares o explicando las razones del rechazo.

3. Contribuciones Clave

Marco HARNESSFIX: Un marco basado en trazas y dirigido por el diagnóstico que conecta explícitamente la evidencia de fallos con el diagnóstico sensible al harness y los cambios de harness con alcance definido, yendo más allá de la evolución de prompts basada en resultados.
HTIR: Una representación de trazas sensible al harness que normaliza las trayectorias heterogéneas de los agentes en estructuras de evidencia a nivel de paso, permitiendo una atribución y planificación de reparación precisas.
Evaluación Empírica: Evaluación exhaustiva en cuatro benchmarks (SWE-Bench Verified, Terminal-Bench 2.0 Verified, GAIA, AppWorld) demostrando ganancias de rendimiento significativas.
Análisis Sistemático: Un análisis detallado de las reparaciones aceptadas que revela patrones recurrentes de fallos de harness a través de las capas ETCLOVG y los puntos de estrés específicos de diferentes configuraciones de tareas.

4. Resultados Experimentales

Los autores evaluaron HARNESSFIX en cuatro benchmarks, comparándolo con los harnesses iniciales ( $H_0$ ), harnesses diseñados por humanos y baselines de auto-evolución (GEPA, SCOPE, ReCreate).

Ganancias de Rendimiento: HARNESSFIX mejoró el rendimiento en el conjunto de prueba frente a los harnesses iniciales entre un 15.2% y un 50.0% en los benchmarks:
- SWE-Bench Verified: 45.0% $\to$ 57.0% (mejora relativa del 26.7%).
- Terminal-Bench 2.0 Verified: 17.6% $\to$ 26.5% (mejora relativa del 50.0%).
- GAIA: 43.3% $\to$ 61.7% (mejora relativa del 42.3%).
- AppWorld: 36.7% $\to$ 42.2% (mejora relativa del 15.2%).
Comparación con Baselines: HARNESSFIX superó a todos los baselines de auto-evolución y a los harnesses diseñados por humanos más fuertes en cada benchmark. Por ejemplo, en SWE-Bench, resolvió 57 tareas frente a las 48 del mejor harness diseñado por humanos (Trae-Agent).
Estudio de Ablación: Eliminar componentes clave degradó significativamente el rendimiento:
- La reparación solo de prompts no logró mejorar Terminal-Bench y obtuvo ganancias mínimas en otros casos, resaltando la insuficiencia de la guía suave por sí sola.
- Sin el diagnóstico basado en trazas, se obtuvieron mejoras intermedias pero se quedó por detrás del sistema completo, confirmando la necesidad de una atribución precisa a nivel de paso.
- Sin los operadores de reparación con alcance definido, se produjeron regresiones, demostando la necesidad de restringir las ediciones a operadores específicos.
- Sin la aceptación consciente de la regresión, las puntuaciones finales disminuyeron, probando que la validación es crítica para convertir candidatos útiles en cambios de harness seguros.

5. Significación y Reivindicaciones

El artículo afirma que la reparación del harness es un desafío distinto y crítico de la optimización de prompts. La importancia de HARNESSFIX radica en su capacidad para:

Cerrar la Brecha Runtime-Static: Mediante el uso de HTIR, conecta eficazmente los fallos de ejecución dinámica con los artefactos de implementación estática del harness.
Permitir una Reparación Dirigida y Segura: El uso de operadores de reparación con alcance definido y validación consciente de la regresión permite modificaciones profundas en los mecanismos de tiempo de ejecución (interfaces de herramientas, guardas de ciclo de vida, observabilidad) sin la inestabilidad asociada a la auto-edición recursiva.
Generalizarse a través de Dominios: El éxito del marco en diversos dominios (ingeniería de software, flujos de trabajo de terminal, QA de investigación y automatización de aplicaciones) sugiere que la reparación de harnesses basada en trazas es un enfoque generalizable para mejorar la fiabilidad de los agentes.
Revelar Fallos Sistémicos: El análisis revela que diferentes dominios de tareas estresan diferentes capas del harness (por ejemplo, AppWorld estresa la Verificación y el Ciclo de Vida, mientras que GAIA estresa la Interfaz de Herramientas y la Observabilidad), lo que sugiere que la ingeniería de agentes eficaz requiere un ajuste de harness específico del dominio en lugar de una ingeniería de prompts de talla única.

Los autores concluyen que, a medida que los agentes abordan tareas cada vez más complejas, el harness se convierte en un determinante primario de la fiabilidad del sistema, y HARNESSFIX proporciona un método sistemático para diagnosticar y reparar estos fallos de infraestructura.