🤖 AI

Harness-Bench: Measuring Harness Effects across Models in Realistic Agent Workflows

Harness-Bench es un punto de referencia de diagnóstico compuesto por 106 tareas realistas en entornos controlados que evalúa cómo las diferentes configuraciones de capa de sistema (harnesses) afectan el rendimiento de los agentes de LLM, revelando que los resultados de ejecución varían significativamente entre las combinaciones de modelo y harness, y destacando la necesidad de informar las capacidades del agente a nivel de configuración en lugar de atribuirlas exclusivamente al modelo base.

Autores originales: Yilun Yao, Xinyu Tan, Chao-Hsuan Liu, Yaoming Li, Zhengyang Wang, Wenhan Yu, Zhewen Tan, Yuxuan Tian, Guangxiang Zhao, Lin Sun, Xiangzheng Zhang, Tong Yang

Publicado 2026-05-28

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Yilun Yao, Xinyu Tan, Chao-Hsuan Liu, Yaoming Li, Zhengyang Wang, Wenhan Yu, Zhewen Tan, Yuxuan Tian, Guangxiang Zhao, Lin Sun, Xiangzheng Zhang, Tong Yang

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 chef brillante y de clase mundial (el Modelo de IA). Este chef puede cocinar cualquier cosa si se le dan las instrucciones adecuadas. Pero en el mundo real, un chef no simplemente está de pie en un vacío; trabaja en una cocina con herramientas específicas, un conjunto de reglas, un gerente que revisa los pedidos y un sistema para manejar errores.

Este artículo, Harness-Bench, trata sobre probar ese sistema de cocina (llamado "harness" o arnés), no solo al chef.

El Problema: Hemos estado ignorando la cocina

Hasta ahora, cuando las personas probaban agentes de IA, principalmente preguntaban: "¿Qué tan bueno es el chef?". Miraban el plato final (¿completó la IA la tarea?) pero ignoraban cómo estaba configurada la cocina.

¿Tenía el chef los cuchillos adecuados (herramientas)?
¿Sabía el chef cómo manejar una sartén quemada (recuperación)?
¿Detuvo el gerente de la cocina (el sistema) al chef de usar ingredientes incorrectos (permisos)?

Los autores argumentan que no puedes juzgar la capacidad de una IA solo mirando el modelo. Debes mirar el Modelo + El Sistema de Cocina juntos. Un gran chef en una cocina desordenada y rota fallará, mientras que un buen chef en una cocina perfecta y bien organizada podría tener éxito.

La Solución: Un "Simulador de Cocina" para la IA

Los investigadores construyeron Harness-Bench, un campo de pruebas gigante con 106 desafíos de cocina diferentes (tareas). Estas no son solo preguntas simples; son trabajos complejos como corregir código, analizar datos financieros o gestionar un proyecto.

Así es como lo probaron:

Los Mismos Ingredientes, Diferentes Cocinas: Tomaron las mismas 106 tareas y se las dieron a diferentes modelos de IA.
La Variable: Mantuvieron la tarea exactamente igual pero cambiaron el "sistema de cocina" (el arnés) en cada ejecución. Algunas cocinas eran de alta tecnología y estrictas; otras eran informales y simples.
El Resultado: Ejecutaron más de 5.000 experimentos.

Lo Que Encontraron

Los resultados fueron sorprendentes y claros: La cocina importa tanto como el chef.

Diferencias Enormes: Cuando usaron el mismo modelo de IA pero lo pusieron en diferentes "cocinas", la tasa de éxito varió enormemente. Un sistema de cocina obtuvo una tasa de éxito del 76%, mientras que otro obtuvo solo el 52% con el mismo modelo exacto.
La Cocina "Inteligente" Gana: Los sistemas de mejor rendimiento no fueron simplemente aquellos con los modelos de IA más inteligentes. Fueron aquellos donde el sistema ayudó a la IA a mantenerse en la pista, recuperarse de errores y usar las herramientas correctamente.
El Problema de la "Deriva": Los investigadores descubrieron que la IA a menudo comienza con un buen plan pero luego "se desvía". Podría pensar lógicamente pero olvidar guardar realmente el archivo, o podría ignorar un error de herramienta y seguir intentando lo mismo. Los mejores "sistemas de cocina" detectaron estas desviaciones y las corrigieron.

La Gran Conclusión

El artículo concluye que debemos dejar de decir "Este modelo de IA es 90% bueno". En su lugar, deberíamos decir: "Este modelo de IA es 90% bueno cuando se empareja con este sistema específico".

Si quieres construir un agente de IA confiable, no puedes simplemente elegir el cerebro más inteligente; tienes que construir el mejor cuerpo y sistema nervioso (el arnés) para ir con él. Harness-Bench es la herramienta que crearon para ayudar a los ingenieros a medir y mejorar ese cuerpo.

En Resumen

Piénsalo como probar un coche de carreras. No puedes simplemente mirar el motor (el modelo de IA) y decir que es rápido. Tienes que probar el motor en diferentes pistas con diferentes neumáticos y conductores (el arnés). Harness-Bench es la nueva pista que demuestra que la velocidad del coche depende en gran medida de la pista y los neumáticos, no solo del motor.

Resumen Técnico: Harness-Bench

Enunciado del Problema

Los agentes de Modelos de Lenguaje Grande (LLM) se despliegan cada vez más como sistemas ejecutables que interactúan con entornos externos, utilizando herramientas, modificando espacios de trabajo y produciendo artefactos concretos. En estos flujos de trabajo, el rendimiento práctico no depende únicamente de las capacidades de razonamiento del modelo base, sino también críticamente del harness: la capa del sistema que gestiona el contexto, las herramientas, el estado, las restricciones, los permisos, el seguimiento y la recuperación.

Las evaluaciones existentes enfrentan una limitación significativa: suelen abstraer los detalles de la ejecución, confunden el harness con el sistema completo del agente, o mantienen el harness fijo mientras comparan modelos. En consecuencia, existe una falta de protocolos de diagnóstico para estudiar cómo las configuraciones modelo–harness específicas afectan las tasas de éxito, los costos de tokens, la robustez y la trazabilidad en flujos de trabajo realistas. Esto oscurece la variación de la capa de ejecución que a menudo determina si un agente tiene éxito o fracasa.

Metodología

Los autores presentan Harness-Bench, una evaluación de diagnóstico diseñada para evaluar los efectos de la configuración del harness bajo condiciones externas compartidas.

Diseño de la Evaluación

Suite de Tareas: La evaluación consta de 106 tareas offline en entornos aislados (sandbox) construidas a partir de patrones de uso práctico de agentes. Estas tareas abarcan ocho categorías, incluyendo ingeniería de software, análisis de datos, operaciones de espacio de trabajo, trabajo de conocimiento, comunicación de oficina, flujos de trabajo profesionales verticales, autonomía de larga duración y DevOps.
Validación: Cada tarea es revisada manualmente según cuatro criterios: Realismo (flujo de trabajo de usuario plausible), Solubilidad (completable con los recursos proporcionados), Verificabilidad por oráculo (verificable mediante comprobaciones deterministas o rúbricas) e Integridad (evitar que los agentes eludan las restricciones).
Protocolo de Evaluación: La evaluación fija las condiciones externas de la tarea (prompt de la tarea, estado inicial del entorno aislado, presupuesto, tiempo límite y evaluador) mientras varía la configuración del harness y el backend del modelo.
- A diferencia de trabajos anteriores que fuerzan a los sistemas a una política interna común, Harness-Bench preserva el comportamiento de ejecución nativo de cada harness (prompts, interfaces de herramientas, gestión del estado y mecanismos de recuperación).
- Este enfoque trata al harness como la variable principal de interés, midiendo el rendimiento del par Modelo + Harness en lugar de aislar mecanismos individuales.

Ejecución y Puntuación

Recopilación de Datos: Cada ejecución registra los artefactos finales, las trazas de ejecución, las estadísticas de uso y las salidas del validador. El estudio analizó 5.194 trayectorias de ejecución a través de 6 harnesses configurables y 8 backends de modelos (más una evaluación de referencia de Codex).
Métricas de Puntuación: La puntuación general es una combinación multiplicativa de tres componentes:
1. Seguridad ( $S$ ): Una puerta binaria (0 o 1) para violaciones de permisos o seguridad.
2. Completitud ( $C$ ): Medida mediante validadores deterministas específicos de la tarea o juicios basados en rúbricas.
3. Proceso ( $P$ ): Un agregado de Robustez, adecuación del uso de herramientas y Consistencia, evaluado mediante rúbricas de proceso basadas en LLM.
- Fórmula: $PuntuaciónTarea = S \cdot C \cdot P$ .
- Esta puntuación conservadora asegura que un crédito agregado alto requiera la completitud de la tarea, la ausencia de violaciones de seguridad y un comportamiento de ejecución confiable.

Contribuciones Clave

Activo de Evaluación: El lanzamiento de Harness-Bench, una suite de 106 tareas offline en entornos aislados con manifiestos de tareas, accesorios, evaluadores y trazas de ejecución diseñadas para flujos de trabajo de agentes de extremo a extremo realistas.
Protocolo de Evaluación: Un protocolo novedoso que fija las condiciones externas de la tarea mientras preserva los comportamientos nativos del harness, permitiendo comparaciones a nivel de configuración entre harnesses representativos y backends de modelos.
Análisis de Diagnóstico: Un análisis a gran escala de 5.194 trayectorias que revela una variación sustancial en la completitud, la calidad del proceso, la eficiencia y los modos de fallo entre diferentes pares modelo–harness.

Resultados Clave

Variación a Nivel de Configuración: Bajo el mismo conjunto de tareas y grupo de backends de modelos, las puntuaciones agregadas variaron significativamente entre los harnesses. NanoBot logró la puntuación más alta (76,2%), mientras que OpenClaw logró la más baja (52,4%), una diferencia de 23,8 puntos. Esto demuestra que la elección del harness es un determinante crítico del rendimiento.
Dependencia Modelo-Harness: Los backends de modelos más fuertes tendieron a exhibir una menor varianza cruzada entre harnesses, lo que sugiere que son más tolerantes a las diferencias en los prompts y la gestión del estado. Por el contrario, los backends más débiles mostraron una mayor sensibilidad al sustrato de ejecución.
Eficiencia: Los harnesses con mayor puntuación a menudo demostraron perfiles de proceso mejores (uso de herramientas, consistencia, robustez) y, en algunos casos, mayor eficiencia (menos tokens/vueltas) en comparación con sus contrapartes de menor puntuación.
Modos de Fallo: El análisis de las trayectorias fallidas identificó recurrentes "fallos de alineación de ejecución" donde un razonamiento plausible se desacopló de la retroalimentación de las herramientas o de las salidas verificables. El fallo más común fue violaciones de Contrato/Formato (36,4%), seguido por problemas de Herramientas/Recuperación (24,6%) y brechas de Evidencia/Anclaje (14,6%).

Significado y Afirmaciones

El artículo argumenta que la capacidad del agente debe informarse a nivel de configuración modelo–harness en lugar de atribuirse únicamente al modelo base. Los resultados sugieren que la capa de ejecución no es meramente un detalle de implementación, sino un componente fundamental del rendimiento del agente que moldea cómo se expone, restringe y realiza la capacidad.

Harness-Bench proporciona una base reproducible para:

Diagnosticar fallos recurrentes de alineación de ejecución donde el razonamiento se desacopla de la evidencia o el estado.
Mejorar pilas de ejecución de agentes fiables, eficientes, conscientes de los permisos y auditables.
Cambiar el paradigma de evaluación de métricas "solo modelo" a diagnósticos a "nivel de sistema" que tengan en cuenta la interacción entre el razonamiento del modelo y el entorno de ejecución.

Los autores mantienen una postura modesta, señalando que la evaluación mide configuraciones completas de harness bajo condiciones controladas y en entornos aislados. Por lo tanto, los resultados se presentan como mediciones de diagnóstico bajo un protocolo fijo en lugar de garantías estadísticas para todas las implementaciones posibles en el mundo real.