RiseHarness enseña a los agentes de terminal a corregir su propio harness sin reentrenamiento

Un agente de terminal puede resolver una tarea al primer intento y fallarla en el segundo, aunque el modelo, el prompt y la configuración sigan siendo los mismos. RiseHarness ataca precisamente esa inestabilidad: este framework, descrito en un artículo que aparece en Hugging Face Daily Papers, reescribe de forma iterativa el arnés (harness) del agente con los pesos del modelo completamente congelados. En el resumen, los autores no ofrecen resultados numéricos, así que lo que se puede evaluar es el enfoque en sí. Y es bastante concreto.

La brecha entre «sabe hacerlo» y «lo hace de forma fiable»

La premisa es sencilla. En tareas largas de terminal, cada acción del agente modifica el contexto, y el contexto condiciona la siguiente acción. Un error aleatorio en un paso temprano se propaga por toda la trayectoria. El resultado es que la misma tarea, con la misma configuración, termina bien en una ejecución y mal en otra. Los autores lo llaman la brecha entre capacidad y ejecución fiable.

Por eso RiseHarness no persigue las tareas que el modelo nunca resuelve. Le interesan las tareas «volteadoras» (flipping tasks), en las que hay ejecuciones exitosas y fallidas. La ejecución exitosa se convierte en la referencia con la que se compara la fallida. Así resulta más fácil separar un problema sistemático del harness de una simple mala suerte.

Cómo funciona el ciclo

El análisis se alimenta de dos tipos de datos: las trayectorias del agente y las trazas internas de un monitor de runtime. Estas últimas muestran cómo interactúan las acciones del modelo con la ejecución de comandos, el feedback, la gestión del contexto y la decisión de dar la tarea por terminada. Son los puntos que más suelen romperse a larga distancia.

Para conectar las observaciones con el código real se utiliza el Harness Handbook. Este documento relaciona la evidencia de las ejecuciones con el comportamiento del harness y su código fuente. Ayuda a encontrar problemas recurrentes en mecanismos compartidos por muchas tareas, en lugar de parchear casos aislados.

Lo más interesante viene después. RiseHarness busca implementaciones relevantes en otros frameworks de agentes y las adapta como referencias de diseño para un modelo concreto y su protocolo de ejecución. Los cambios candidatos pasan por comprobaciones de comportamiento y por una nueva evaluación sobre las tareas. Las versiones con una mejora medible se convierten en la base de la siguiente iteración. Así, un mismo harness reúne mecanismos adecuados de distintos proyectos, y los datos recientes de las ejecuciones orientan los cambios siguientes.

Qué se sabe del método

• Los pesos del modelo no cambian: solo se optimiza el harness.
• La unidad de adaptación es un modelo concreto, no un «agente» abstracto.
• Tienen prioridad las tareas con resultados mixtos bajo la misma configuración.
• Fuentes de señal: las trayectorias del agente y las trazas del monitor de runtime.
• Los cambios solo se aceptan tras superar comprobaciones de comportamiento y ejecuciones repetidas.
• Evaluación: éxito y fiabilidad en distintos modelos, ablaciones sobre las trazas de ejecución y la investigación externa, y transferencia a benchmarks desconocidos con el mismo modelo.

El último punto es importante. Las mejoras de un harness pueden sobreajustarse con facilidad al conjunto de tareas con el que se seleccionaron. Probar con benchmarks desconocidos y el mismo modelo permite saber si el método encontró mecanismos de interacción generales o si simplemente ajustó el comportamiento. El resumen no incluye cifras concretas de estas pruebas, por lo que habrá que consultar el texto completo del artículo.

Qué se puede aplicar en la práctica

Para los equipos que construyen agentes de programación y de terminal, hay tres ideas útiles. Primero, medir la estabilidad y no solo pass@1: conviene ejecutar cada tarea varias veces y seguir por separado las que dan resultados mixtos. Segundo, registrar los eventos internos del harness igual que las acciones del modelo. Sin trazas de ejecución, de feedback y de decisiones de finalización, analizar un fallo se reduce a adivinar. Tercero, revisar el harness al cambiar de modelo: según la lógica de los autores, los mecanismos que funcionaron bien con un modelo no tienen por qué servir para otro.

También se ven las limitaciones. El método requiere muchas ejecuciones repetidas, es decir, un presupuesto de cómputo considerable, y depende de la calidad del monitor. Hasta qué punto los mecanismos «prestados» y adaptados conviven bien entre sí lo mostrarán las ablaciones del texto completo. Aun así, la idea parece práctica: parte de la falta de fiabilidad de los agentes reside en el harness, y se puede corregir con ingeniería, sin tocar los pesos.