Harness² y la recursión de agentes

Si has trabajado con inteligencia artificial, seguramente has visto que un mismo modelo puede comportarse de manera muy diferente dependiendo de las instrucciones que recibe, las herramientas que tiene disponibles y la forma en que se organiza su trabajo. Un buen modelo importa, pero en la recursión de agentes también importa el sistema que lo rodea: esa es la premisa detrás de Harness².

Ahí entra Harness² (Harness2), un proyecto de Google Research que explora cómo mejorar el sistema de ejecución de un agente de IA a partir de la evidencia obtenida al realizar tareas y aquí lo interesante es que busca hacerlo sin modificar ni volver a entrenar los pesos del modelo base. En lugar de cambiar el motor, trabaja sobre el equipo que permite que ese motor actúe como agente.

En este artículo vamos a conocer qué es Harness² de forma simple y práctica, porque no necesitas empezar siendo especialista en agentes autónomos: la idea es entender primero el problema y después observar cómo se traduce en código.

Harness² es un proyecto de investigación disponible públicamente. Su repositorio aclara que no es un producto de Google oficialmente soportado. Los resultados experimentales citados más adelante corresponden a las configuraciones y benchmarks descritos por sus autores; no son una garantía de mejora en cualquier aplicación. Repositorio oficial.

¿Qué es Harness²?

Para entender de qué se trata, primero tenemos que separar dos conceptos: el modelo y el harness; ¿y qué es un harness en inteligencia artificial? pues imagina que un modelo de IA es el motor de un automóvil. El motor puede ser potente, pero para llegar a un destino necesita dirección, controles, sensores, reglas y una manera de coordinarse con el resto del vehículo.

En un agente de IA, el harness es ese sistema de recursión de agentes que rodea al modelo y le permite ejecutar tareas y puede incluir instrucciones, herramientas, memoria, habilidades, subagentes y lógica de orquestación. Dos agentes que usan el mismo modelo pueden obtener resultados distintos si sus harnesses están diseñados de forma diferente.

¿Qué hace Harness²?

Harness² es un framework de recursión de agentes para la adaptación recursiva del harness de un agente, es decir, prueba cambios al sistema que guía al agente, observa qué resultados producen y utiliza esa evidencia para decidir qué mejorar. El proyecto trabaja en dos niveles conectados:

1. Recursión a nivel de tarea: refina el harness para resolver mejor la tarea que tiene delante.
2. Recursión a nivel de mejora: conserva aprendizajes respaldados por evidencia para orientar el refinamiento de tareas futuras.

La clave es que la mejora sucede alrededor del modelo: Harness² mantiene fijos sus pesos durante ese proceso; esto no significa que el modelo nunca se pueda entrenar por otros medios, sino que el método estudiado no necesita hacerlo para adaptar el harness.

¿Cómo funciona Harness²? (Propose–Probe–Compose)

La mecánica principal puede entenderse con tres verbos: proponer, probar y componer. El repositorio lo describe como un proceso contrastivo: el sistema compara lo que ocurre al ejecutar variantes del harness en la misma tarea, en vez de depender exclusivamente de una respuesta correcta conocida de antemano.

Propose: proponer un cambio

El sistema plantea modificaciones posibles al harness. Puede considerar reglas generales que deberían servir en diferentes contextos y otras más específicas del dominio de trabajo. Por ejemplo, si un agente concilia movimientos contables, una propuesta podría cambiar la forma en que el script suma cargos y abonos. La propuesta es una hipótesis: todavía no sabemos si realmente mejora el resultado.

Probe: probar las alternativas

Después se ejecutan las variantes en la misma tarea. Es importante comparar condiciones equivalentes: si cada versión resuelve un problema completamente diferente, resultará más difícil atribuir la diferencia al cambio realizado. En la analogía del taller, no basta con decir “esta pieza parece mejor”, hay que ponerla a prueba y observar qué cambia.

Compose: componer una versión refinada

El sistema utiliza los contrastes entre las ejecuciones para construir un harness refinado. La comparación entre resultados ayuda a identificar qué modificación parece haber contribuido y cómo integrar las mejoras. Aquí, el enfoque busca guiar estos cambios mediante evidencia de comportamiento, incluso cuando no se dispone de una respuesta de referencia para cada tarea desconocida. Esto es especialmente relevante para escenarios abiertos, donde no todas las tareas futuras pueden anticiparse durante el diseño inicial.

Un segundo ciclo: aprender de la experiencia

Harness² añade otra capa a la recursión de agentes: después de adoptar un harness, puede registrar la solución y las lecciones justificadas por las ejecuciones y esa experiencia persistente alimenta los siguientes refinamientos.

Pensemos en dos niveles de aprendizaje:

• Mejorar el trabajo actual: probar cambios para una tarea concreta.
• Mejorar la forma de mejorar: guardar lecciones útiles y respaldadas por evidencia para los siguientes trabajos.

No es una memoria infalible ni significa que cada lección vaya a funcionar en cualquier escenario. Las experiencias se organizan por dominio y deben interpretarse según el contexto del que proceden.

Los ocho componentes que Harness² puede editar

El README oficial identifica ocho componentes editables alrededor del modelo. En términos sencillos:

Estos ejemplos son explicaciones prácticas, no una lista de configuraciones recomendadas para todos los casos. La documentación agrupa estos componentes según su papel en el contexto, la interfaz de herramientas, la delegación y el comportamiento durante la ejecución. 

Ejemplo: un agente que calcula mal el saldo

Supongamos que tenemos una hoja de transacciones. Los importes positivos representan cargos y los negativos representan abonos y queremos sumar todos los movimientos con su signo para obtener el total neto. Nuestro primer script contiene un error: suma solo los importes mayores que cero.

from decimal import Decimal

importes = [Decimal("100.25"), Decimal("-20.10"), Decimal("5.00")]

def total_original(importes):
    # Error: excluye todos los importes negativos.
    return sum((x for x in importes if x > 0), Decimal("0"))

print(f"Total original: {total_original(importes):.2f}")Lenguaje del código: PHP (php)

El resultado del código es 105.25. Sin embargo, el total correcto es 85.15, porque hay que sumar también el movimiento de -20.10. Podemos escribir una variante corregida:

def total_corregido(importes):
    return sum(importes, Decimal("0"))

print(f"Total corregido: {total_corregido(importes):.2f}")Lenguaje del código: PHP (php)

Ahora obtenemos 85.15 y ¿cómo se conecta esto con Harness²?

1. Propose: proponer eliminar el filtro que descarta importes negativos.
2. Probe: ejecutar el script original y el modificado con el mismo libro contable.
3. Compose: utilizar la diferencia observada para integrar la corrección en el harness.
4. Experiencia: si las pruebas dan evidencia suficiente, registrar que en conciliaciones de este tipo hay que conservar los signos de los importes.

Esta explicación manual no reproduce por sí sola todo el framework, pero sirve para visualizar el razonamiento. Aquí lo interesante es que la demostración oficial de Harness² utiliza precisamente un pequeño caso de conciliación de transacciones para ejercitar el flujo real de adaptación con editores deterministas.

• Repositorio del experimento: https://github.com/Orliluq/harness2_tutorial.git

El cuaderno .ipynb que acompaña este artículo contiene las celdas preparadas para ejecutar este flujo en orden. Puedes abrirlo en Google Colab y cargar allí el archivo descargado.

¿Qué demuestra esta práctica?

Demuestra cómo recorrer el flujo real de adaptación de recursión de agentes y biblioteca de experiencia con la implementación local determinista incluida en Harness² y permite explorar los archivos generados y comparar el enfoque paralelo con el secuencial.

No demuestra que un modelo de lenguaje concreto haya mejorado su rendimiento en un benchmark, ni que las mejoras publicadas se reproduzcan automáticamente. La demo utiliza editores programados para este escenario y no llama a un LLM remoto.

¿Cómo ejecutar un benchmark real con modelos de IA?

El paso siguiente es configurar uno de los benchmarks compatibles: JobBench para tareas profesionales, LAB para trabajo jurídico o WorkBuddy-Bench para tareas de oficina, web y código. Este proceso no es tan simple como ejecutar la demo local.

El entorno de benchmarks requiere dependencias adicionales. Entre ellas están Linux, Python 3.12, uv, Node.js 20 o posterior y Google Cloud CLI. Para las configuraciones de Vertex AI hay que configurar el proyecto y los modelos correspondientes, y autenticar la sesión de Google Cloud. Algunos benchmarks añaden requisitos específicos: LAB necesita Pandoc y Poppler, mientras que WorkBuddy-Bench requiere Docker. Un flujo de ejemplo descrito en la documentación oficial para LAB es:

harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel --only-domains antitrust-competition --max-tasks 1
harness2-judge --bench lab --k 1 --mode parallel
harness2-report --bench lab --k 1 --mode parallel

Ese ejemplo es ilustrativo y solo podrá ejecutarse tras completar los requisitos, la autenticación y la configuración de modelos. Las llamadas a modelos pueden generar costes; conviene empezar con una selección pequeña y revisar los precios antes de lanzar experimentos grandes; para esto, consulta SETUP.md, BENCHMARKS.md y EXPERIMENTS.md.

Ahora bien, los benchmarks son públicos y algunos criterios o rúbricas pueden estar accesibles en Internet. Si un agente también tiene acceso a la web durante una evaluación, podría obtener información que no debería formar parte de la tarea. El propio proyecto advierte de este riesgo y recomienda configurar restricciones de red para evitar que el agente consulte respuestas o criterios de evaluación. Por eso, una evaluación responsable debe controlar qué información puede ver el agente, documentar la configuración utilizada y distinguir entre una ejecución incompleta y un resultado realmente incorrecto.

Resultados publicados: ¿mejora realmente a los agentes?

El README del proyecto informa de resultados positivos en tres benchmarks profesionales y cuatro configuraciones de modelo y harness. Entre los resultados máximos reportados aparecen mejoras de hasta 11,5 puntos en WorkBuddy-Bench, 4,5 puntos en JobBench y 11,8 puntos porcentuales en la tasa de aprobación parcial de LAB. Los autores también indican que aumentar el presupuesto de recursión puede aportar mejoras adicionales en sus experimentos.

Estas cifras deben leerse con contexto porque son resultados de las configuraciones y tareas evaluadas, no una promesa de rendimiento para cualquier modelo, benchmark o aplicación propia. Para juzgar si Harness² vale la pena en un proyecto real, habría que comparar una línea base y la versión refinada usando las mismas tareas, modelos, presupuesto, herramientas y condiciones de evaluación. 

Parallel vs. Sequential: ¿qué significa cada modo?

Harness² permite aumentar el presupuesto de recursión de dos maneras:

• Parallel (paralelo): explora varias alternativas de forma más amplia y utiliza la evidencia reunida para componer harnesses refinados.
• Sequential (secuencial): realiza pasos consecutivos, llevando al siguiente paso el harness refinado y la evidencia acumulada.

Una analogía sencilla sería que, el modo paralelo se parece a probar varias soluciones candidatas antes de elegir una composición; el secuencial se parece a ajustar una solución, volver a probarla y continuar desde ese resultado y el modo más conveniente depende del objetivo, los recursos disponibles y la forma de la tarea.

¿Cuándo podría ser útil Harness²?

Un enfoque como Harness² resulta interesante cuando:

• Las tareas varían y no todas pueden preverse durante el diseño del agente.
• El rendimiento depende mucho de instrucciones, herramientas, scripts o coordinación.
• Es posible probar varias ejecuciones y conservar evidencia de qué cambios ayudaron.
• El equipo necesita mejorar su sistema de agentes sin empezar por reentrenar el modelo.

Aun así, no toda aplicación necesita recursión automatizada, porque en un flujo sencillo, una instrucción mejor escrita o un test determinista puede ser suficiente. La optimización debe justificarse con resultados observables, no solo por lo sofisticado del framework.

El modelo importa, pero el sistema también

Harness² propone una idea poderosa y fácil de olvidar, el que aplicar la recursión de agentes para mejorar un sistema no siempre significa cambiar el modelo de lenguaje. A veces, el avance está en las instrucciones, las herramientas, los scripts, la coordinación y la forma sistemática de comprobar qué funciona.

Su ciclo Propose–Probe–Compose permite comparar cambios sobre una tarea, mientras que la segunda capa conserva aprendizajes respaldados por evidencia para futuras adaptaciones. La lección para quienes construimos soluciones con IA: no basta con preguntarnos qué modelo utilizar, también debemos observar cómo trabaja, con qué herramientas cuenta y cómo aprendemos de los resultados sin confundir una mejora observada con una garantía universal.