Google Harness²: configuración, pruebas y coste real

Volver

Kevin Riedl

15 min de lectura · 16 oct 2026
Última revisión 16 de octubre de 2026

Siguiente

Quizá tu agente de IA no necesite un modelo más inteligente. Quizá necesite una forma mejor de trabajar.

Esa es la idea interesante de Google Harness². En lugar de pedir al agente que vuelva a intentarlo sin más, el framework modifica sus instrucciones, herramientas y procedimientos reutilizables. Prueba alternativas y guarda lo aprendido para otras tareas.

La oportunidad es real. La versión resumida de las redes sociales necesita matices. Harness² no es un asistente de oficina sin código listo para usar. Sus mejoras en benchmarks no garantizan más productividad. Y un archivo editable de reglas no constituye una barrera de seguridad.

Esta guía separa las preguntas importantes: qué ha publicado Google, qué significan los resultados, cuánto cuesta la recursión y cómo plantear una primera evaluación sin entregar las credenciales de la empresa a un agente experimental.

Fuentes revisadas el 16 de octubre de 2026. Los comandos siguientes se contrastaron con el código de la revisión indicada, pero no se ejecutaron como experimentos con modelos. Los resultados de los benchmarks pertenecen a los autores, no a mediciones de Wavect.

¿Qué es Google Harness²?

Google Harness², también escrito Harness2, es un framework de investigación con licencia Apache-2.0 que mejora el entorno de ejecución de un agente ante tareas desconocidas sin modificar los pesos del modelo. Combina experimentos para la tarea actual con una biblioteca persistente que orienta mejoras futuras. El repositorio oficial admite OpenCode y Codex como entornos ejecutores y tres familias de benchmarks. También aclara que no es un producto con soporte oficial de Google.

Un harness es el sistema de trabajo que rodea al modelo: instrucciones, herramientas, memoria y comportamiento de ejecución. Harness² modifica ese sistema, no los parámetros aprendidos del modelo. Los metadatos del paquete identifican el código revisado como versión 0.1.0, compatible con Python 3.12 o 3.13.

«Mundo abierto» describe tareas que no se previeron al diseñar el harness. No significa que haga falta acceso irrestricto a internet, que pueda resolverse cualquier tarea nueva o que el resultado correcto esté garantizado.

Nuestra guía de arquitectura de un harness para agentes explica la base general. Aquí nos centramos en el enfoque recursivo de Google y en la decisión práctica de evaluarlo.

Cómo funciona el harnessing recursivo

Harness² conecta dos ciclos. La sección de metodología del artículo científico describe un paso de Propose, Probe, Compose: proponer, probar y combinar cambios para la tarea actual. Después, una reflexión puede aportar aprendizaje para las siguientes tareas.

Primero se ejecuta una referencia para observar cómo trabaja el harness inicial. El sistema propone una mejora general, por ejemplo en el uso de herramientas, y otra específica de la tarea, como un procedimiento de comprobación más adecuado. Ejecuta ambas alternativas sobre la misma tarea, con idéntico modelo ejecutor y configuración del entorno. A partir de las diferencias observadas, compone y ejecuta un harness revisado.

Imagina una tarea hipotética de conciliación de hojas de cálculo. Una alternativa podría mejorar la planificación; otra, incorporar un script reutilizable para comprobar los datos. La comparación busca qué cambio mejora realmente el comportamiento observado, no qué explicación suena más convincente. Es una ilustración, no una integración de Harness² probada por nosotros.

El segundo ciclo conserva los harnesses adoptados y las lecciones respaldadas por evidencias, incluido un archivo EXPERIENCE.md. Esos registros orientan propuestas futuras. Lo importante es que cada nueva tarea sigue partiendo del mismo harness de ejecución base. No hereda automáticamente todos los cambios realizados para la tarea anterior. Si no hay pruebas suficientes, la reflexión puede no añadir ninguna lección nueva.

Para una empresa, la distinción importa. Se aprende mediante artefactos persistentes y mejores configuraciones, no reentrenando continuamente el modelo. Tampoco es una verificación independiente: varias ejecuciones pueden compartir el mismo error de interpretación.

Los ocho componentes editables

Nuestra regla de despliegue es sencilla: el sistema puede mejorar su método, pero sus permisos deben quedar fuera del harness editable. Un archivo que diga «no exportar datos de clientes» no debería ser el único control que impide exportarlos.

¿Qué significan las mejoras de +11,5 y +4,5 puntos?

Las mejoras del anuncio aparecen en las tablas de los autores. Son máximos obtenidos en distintas combinaciones de modelo y harness, no un incremento universal. Los resultados principales y el diseño experimental presentan medias de tres ejecuciones con el orden de tareas mezclado. Las siguientes comparaciones corresponden a un paso de mejora, k=1.

El dato de WorkBuddy no significa que todas las tareas de oficina mejoren un 11,5 %. Con Gemini 3.5 Flash bajo OpenCode, la media publicada pasa de 72,4 a 77,5: una mejora de 5,1 puntos. Importa la referencia concreta.

Hay otro detalle fácil de pasar por alto: el editor del harness utilizado por defecto en el experimento principal es Claude Opus 4.8, incluso cuando quien ejecuta la tarea es Gemini o GLM-5. Se compara el mismo modelo ejecutor, sin cambiar sus pesos, antes y después de la mejora. Eso no significa que todo el proceso use exclusivamente ese modelo. El artículo estudia por separado configuraciones en las que ejecutor y editor sí son el mismo modelo.

Las filas + Recursion muestran cambios adicionales con recursión paralela y k=5. No deben presentarse como el resultado del ajuste básico de un paso. Tampoco deben mezclarse máximos de filas distintas para inventar una configuración ganadora.

La conclusión positiva es más precisa y útil: hay evidencia de que cambiar cómo trabaja un modelo existente puede mejorar sus resultados en varios benchmarks profesionales. Eso no determina la tasa de aceptación en tu producción, el coste operativo ni el esfuerzo de revisión humana necesario.

¿Cuánto cuesta ejecutar Harness²?

La licencia del código no es la factura de funcionamiento. Una ejecución recursiva paga tanto la exploración como el resultado entregado.

El diseño paralelo documentado incluye k ejecuciones de referencia, k pruebas de variantes generales, k pruebas específicas del dominio y k ejecuciones de harnesses combinados. En total son 4k ejecuciones del agente: cuatro con k=1 y veinte con k=5. Es una cuenta derivada del algoritmo, no una factura medida que se multiplique por cuatro o por veinte.

El editor, la composición, la reflexión, la posible selección final y la evaluación independiente añaden trabajo. La longitud de las secuencias, la caché, los precios de cada modelo, los fallos y los reintentos determinan el coste real. Ejecutar en paralelo puede reducir el tiempo transcurrido si hay capacidad, pero no elimina esos consumos.

El artículo no ignora el problema. Su análisis del coste computacional cuenta los tokens anteriores a la entrega, tanto de ejecución como de mejora, y muestra una relación favorable entre calidad y cómputo entre las configuraciones comparadas. Aun así, la columna de pasos de ejecución de las tablas principales no equivale a un registro completo de costes de producción. La eficiencia en tokens de un benchmark no es un caso de negocio en euros.

Medir el coste por resultado aceptado

Aplica los mismos criterios de aceptación, definidos de forma independiente, al harness fijo y a Harness²:

Coste por resultado aceptado = todos los costes de ejecución, modelos de mejora, evaluación, infraestructura y revisión humana del conjunto evaluado / entregables aceptados independientemente.

Cuenta cada coste una sola vez. Si no se acepta ningún entregable, no presentes un coste unitario finito.

La opción recursiva resuelve más trabajo correctamente, pero cada resultado aceptado cuesta más. Puede merecer la pena por el valor de las entregas o por una respuesta más rápida. Lo importante es decidirlo expresamente, sin confundir una mejora de puntuación con ahorro automático.

Para un modelo operativo más general, consulta el coste de un agente de IA por acción. En el experimento con Harness², la pregunta es si los intentos adicionales compran suficiente trabajo utilizable.

¿Es seguro conectar Harness² a los sistemas de la empresa?

La configuración de investigación por sí sola no basta. La guía de experimentos dice expresamente que esta publicación no restringe la red de los ejecutores y que Codex funciona con su sandbox desactivado.

También documenta una ejecución de validación en la que Codex descargó la rúbrica pública de evaluación de su tarea de JobBench sin recibir instrucciones para hacerlo. Es una advertencia concreta para reproducir resultados. No demuestra que los resultados originales del artículo estén contaminados.

Hay que separar dos riesgos. Encontrar las respuestas o criterios reservados compromete una evaluación. Acceder a credenciales reales, archivos ajenos o sistemas externos pone en peligro el entorno. Añadir una frase a guardrails.md no resuelve ninguno.

Para empezar recomendamos un entorno aislado y desechable, archivos sintéticos o saneados, credenciales de modelos limitadas, restricciones de salida de red impuestas externamente y un presupuesto que el agente no pueda aumentar. No montes perfiles personales de nube, secretos de producción, directorios personales sensibles ni un socket Docker del host sin restricciones dentro de su entorno.

La instalación y la ejecución de benchmarks requieren políticas de red diferentes. La primera descarga dependencias; la segunda no debería consultar respuestas públicas ni criterios de evaluación. Comprueba los bloqueos de forma práctica en lugar de asumir que un archivo de configuración los hace efectivos.

Revisa también las lecciones antes de reutilizarlas. Una biblioteca organizada por dominios no constituye automáticamente una separación de datos entre clientes. El aislamiento entre clientes, la retención, el acceso a artefactos y la eliminación deben quedar fuera de la decisión del modelo. Trata scripts, plugins y entregables generados como no fiables hasta revisarlos.

Cómo probar Google Harness² sin iniciar un benchmark de pago

La guía de configuración recomienda Linux y Python 3.12 para los benchmarks. Las ejecuciones con modelos también necesitan Node.js 20 o posterior, Google Cloud CLI y acceso a los modelos configurados. LAB añade dependencias de procesamiento documental; WorkBuddy necesita Docker.

Es una configuración técnica, no un registro en una aplicación sin código. Una persona que no programe puede definir la tarea y valorar el resultado. Alguien debe seguir responsabilizándose del entorno, las credenciales, el aislamiento y los fallos.

Empezar con la demostración sin credenciales de modelos

En un entorno Linux aislado y desechable, la secuencia contrastada con el código es:

git clone https://github.com/google-research/harness2.git
cd harness2
git checkout 1cfe254e8d25b15f37048c3730134686abe60335
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2

Así se fija la revisión del repositorio examinada. La demostración utiliza editores deterministas y ejecuciones reales de Python sin credenciales de modelos. Muestra la mecánica de la recursión, no la mejora de un LLM en los benchmarks. Instalar el entorno y sus dependencias sigue requiriendo acceso a la red.

Previsualizar una ejecución con modelos muy acotada

Continúa solo después de configurar un proyecto de nube limitado, los modelos deseados para ejecutar, mejorar y evaluar, y los controles externos anteriores. Los valores por defecto no garantizan reproducir todas las configuraciones del artículo. Revisa .env.example; la ruta documentada de Vertex utiliza Application Default Credentials.

La guía de benchmarks distingue la instalación de JobBench, LAB y WorkBuddy. Los conjuntos de datos y el código de terceros conservan sus propias condiciones. WorkBuddy, en particular, tiene una licencia específica con una limitación territorial: revísala antes de descargar ese benchmark. La licencia Apache de Harness² no la sustituye.

Este ejemplo de LAB selecciona un único dominio y previsualiza como máximo una tarea de ese dominio:

export HARNESS2_RUNS_DIR=runs/lab-first-k1
harness2-setup lab
harness2-check --bench lab
harness2 --bench lab --k 1 --mode parallel --seed 42 \
  --only-domains antitrust-competition --max-tasks 1 \
  --workers 1 --dry-run

harness2-check comprueba dependencias, credenciales y configuración sin llamar a un modelo. No confirma que todos los modelos seleccionados estén disponibles. --dry-run también previsualiza la selección de tareas sin llamadas a modelos.

El límite importante es --max-tasks: se aplica por dominio, no al conjunto completo de la ejecución. Combínalo con un solo valor de --only-domains para este primer ensayo. --workers 1 limita la concurrencia entre dominios, no la factura total de API. Utiliza además un límite de gasto externo.

Eliminar --dry-run inicia trabajo de modelos facturable. Mantén separadas ejecución y evaluación para que esa frontera sea explícita:

harness2 --bench lab --k 1 --mode parallel --seed 42 \
  --only-domains antitrust-competition --max-tasks 1 --workers 1
harness2-judge --bench lab --k 1 --mode parallel --seed 42
harness2-report --bench lab --k 1 --mode parallel --seed 42

Al evaluar y generar informes, conserva el mismo benchmark, ejecutor, subconjunto cuando proceda, presupuesto de recursión, modo y semilla. La semilla mezcla las tareas; no fija el muestreo del modelo. Usa otro directorio de resultados al cambiar modelos o selección de tareas. Para evaluar las ejecuciones de referencia, añade --bases al comando de evaluación correspondiente; el informe estándar cubre resultados del harness refinado.

No confundas esta interfaz de benchmarks con un conector listo para tus procesos de oficina. Una tarea empresarial necesita un adaptador adecuado, acceso a datos, comprobaciones de aceptación y responsabilidad operativa.

Un piloto que permita decidir con evidencia

Antes de aumentar k, comprueba que la mejora exista fuera de la propia reflexión del sistema. La guía de evaluación de agentes de Anthropic distingue el registro de ejecución del resultado real en el entorno. Esa es la distinción relevante: un mensaje seguro de haber terminado no equivale a una hoja conciliada o a un registro actualizado correctamente.

Nuestra matriz propuesta exige más que una demostración que funciona:

La publicación deja sin puntuación las evaluaciones fallidas, en lugar de asignarles cero. Informa expresamente de esa cobertura. Una puntuación que solo considere tareas evaluadas correctamente puede ocultar fallos operativos.

Evalúa también cuándo no debe usarse recursión. Un script determinista y económico quizá ya resuelva de forma fiable una transformación estable. Reservar llamadas exploratorias para tareas ambiguas y valiosas es una buena hipótesis de piloto, no una función que deba suponerse activada automáticamente.

Dónde encaja Harness² en un proyecto de Wavect

Harness² resulta interesante cuando una familia recurrente de tareas valiosas tiene demasiada variación para un procedimiento fijo, pero suficiente estructura para evaluar sus resultados. Resulta menos convincente si el trabajo ya es determinista, admite muy poca latencia o cada nuevo intento produce efectos secundarios inaceptables.

Nuestros servicios de ingeniería de IA empiezan por el proceso y sus criterios de aceptación, no por prometer que un framework se volverá fiable por sí solo. El caso de Twinsoft AI aporta contexto de otro proyecto, no una afirmación de que Twinsoft utilice Harness². Usa nuestra lista de QA previa al lanzamiento para definir las pruebas que debe aportar el piloto y después comenta un piloto acotado con Wavect.

La pregunta comercial útil no es «¿cuántos intentos de agentes compramos?», sino «¿qué resultados aceptados de forma independiente hicieron posibles esos intentos y a qué coste total?».