Un crítico independiente eleva entre 5.9 y 9.5 p. p. la precisión de los agentes de programación

Un equipo de investigadores, entre ellos Zhengxin Zhang, Erkang Zhu, Yin Lin, Claire Cardie, Bolin Ding y Jingren Zhou, ha estudiado cuál es la mejor forma de organizar la verificación en los arneses de agentes (agent harnesses). Compararon 17 esquemas en siete modelos de programación de primer nivel y dos benchmarks: Terminal-Bench (TB) y SWE-bench Verified (SWE). El ganador fue la revisión independiente por un crítico aparte. Mejoró la precisión en 5.9–9.5 p. p. en TB y en 3.9–6.6 p. p. en SWE, con un coste de 1.13–1.25x y 1.00–1.04x, respectivamente, sobre la ejecución base.

Cuatro capas en las que se puede pillar al agente

El arnés da al modelo de lenguaje herramientas, le muestra el resultado de su uso y le permite avanzar de forma iterativa hacia el objetivo. La cuestión es en qué punto de ese ciclo conviene insertar la verificación. Los autores dividieron el ciclo de vida del agente en cuatro capas:

• Instrucciones iniciales. Se pide al modelo que se autoverifique ya desde el prompt de arranque.
• Recordatorios a mitad de ejecución. Mientras trabaja, se le lanzan mensajes que le recuerdan la necesidad de comprobar su trabajo.
• Completion gates. El agente no puede dar la tarea por terminada hasta que supere una puerta de control.
• Revisión independiente. Un crítico aparte examina el resultado y, después, el agente introduce las correcciones.

Las dos primeras capas resultaron las más baratas y también las más modestas. La mejora media en los benchmarks de programación es pequeña y depende mucho del modelo, aunque el número de tokens de salida no crece de forma apreciable. Los completion gates exprimen más rendimiento, pero pueden encarecer notablemente la ejecución: el agente choca contra la puerta y gasta tokens en reintentos.

Por qué el crítico gana en costes

La revisión independiente se sitúa en un punto favorable de la curva «precisión–precio». En SWE el sobrecoste se queda en un 0–4 %, y en TB, en un 13–25 %. Para los equipos que pagan los tokens de miles de ejecuciones de agentes al día, esa diferencia entre capas se nota en la factura.

El escalado aquí funciona en dos ejes. Las rondas de revisión adicionales o varios críticos independientes suman en TB hasta 3.5 p. p. más que una única revisión. El resultado es un test-time scaling que no recurre a largas cadenas de razonamiento de un solo modelo, sino a la separación de roles: el ejecutor escribe y el crítico lee sin el lastre de las suposiciones del autor.

Además, los autores introdujeron VisualBench, un conjunto para la evaluación experta de artefactos visuales e interactivos, es decir, interfaces y páginas en las que los tests detectan bastante menos de lo que sería deseable. Los cuatro esquemas de revisión independiente mostraron una ventaja neta positiva frente al base, de entre 13.2 y 23.8 puntos. Cada uno de ellos superó también a los esquemas evaluados de las capas L0–L2.

Cifras clave

• Esquemas de verificación comparados: 17
• Modelos: 7 (modelos de programación de nivel frontier)
• Benchmarks: Terminal-Bench, SWE-bench Verified, VisualBench (evaluación experta)
• Revisión independiente en TB: +5.9–9.5 p. p. con un coste de 1.13–1.25x
• Revisión independiente en SWE: +3.9–6.6 p. p. con un coste de 1.00–1.04x
• VisualBench: preferencia neta de 13.2–23.8 puntos a favor de la revisión
• Rondas o críticos adicionales: hasta +3.5 p. p. en TB sobre la revisión única

Qué llevarse a tu propio arnés

Si estás construyendo un agente de programación, conviene mantener las indicaciones baratas del tipo «compruébalo tú mismo» en el prompt inicial, pero no hay que esperar de ellas un efecto estable: depende del modelo concreto, así que hace falta una ejecución propia. Los completion gates tienen sentido allí donde el coste de un error supera el de los tokens y donde se está dispuesto a vigilar el presupuesto.

La conclusión práctica principal es esta. Un pase aparte del crítico al terminar el trabajo, seguido de una corrección, ofrece la mayor mejora por unidad de coste. Lo mejor es empezar con un crítico y una ronda. Añade una segunda ronda o un segundo crítico cuando, en tu tarea, la revisión única deje de encontrar errores. En tareas visuales e interactivas, donde los tests automáticos son débiles, la revisión independiente está especialmente justificada.

El artículo se publicó en Hugging Face Daily Papers con el número arXiv 2610.34577.