Google Harness2 abre el código de la auto-mejora de agentes, pero la verificación sigue siendo la prueba decisiva

Google ha publicado como código abierto Google Harness2 tras informar mejoras de hasta 11,5 puntos al modificar el software que rodea a un agente en lugar de su modelo. Esa distinción plantea la tensión central. El marco permite a un agente revisar prompts, herramientas, memoria y otras instrucciones operativas, pero debe evaluar esas revisiones sin respuestas correctas conocidas.

Denominado Harness² por sus autores, el proyecto procede de investigadores afiliados a Google Cloud AI Research y Northwestern University. Su código apareció junto con un artículo de investigación del 9 de octubre de 2026 y utiliza la licencia Apache 2.0. El lanzamiento convierte un método de investigación en software que los desarrolladores pueden inspeccionar, ejecutar y modificar.

El proyecto también cuestiona una suposición habitual sobre los agentes de IA. Los mejores resultados no siempre requieren un modelo más reciente o más grande. Pueden surgir de modificar el harness, es decir, el software y las instrucciones que convierten un modelo de lenguaje en un sistema capaz de actuar.

Ese argumento pone bajo presión a los marcos de agentes fijos. OpenCode, Codex, Claude Code y sistemas similares combinan modelos con prompts, herramientas, memoria y orquestación. Google Harness2 plantea si esos componentes circundantes deberían permanecer fijos tras el despliegue.

La respuesta importa más allá de las clasificaciones de benchmarks. Un harness autoeditable puede adaptarse a tareas desconocidas de ámbito jurídico, administrativo, web y programación. También puede conservar una mala suposición, seleccionar una revisión más débil o consumir considerablemente más cómputo para llegar a una respuesta.

Google Harness2 modifica el software alrededor de un modelo congelado

El lanzamiento traslada la mejora recursiva del entrenamiento del modelo a ocho partes editables del entorno de ejecución del agente.

Un agente de IA es más que el modelo de lenguaje que responde a sus prompts. También depende de instrucciones, herramientas disponibles, contexto almacenado, reglas de delegación y software que controla cada acción. En conjunto, esos componentes forman el harness del agente.

Google Harness2 expone ocho componentes para su revisión: el prompt del sistema, las salvaguardas, la memoria, la orientación sobre herramientas, los subagentes, las habilidades, los scripts y los plugins de middleware. Cada componente se representa como un archivo montado en el entorno de ejecución. Los pesos del modelo subyacente permanecen congelados.

Esa separación es importante. Entrenar o ajustar un modelo requiere infraestructura especializada, datos preparados y un proceso de despliegue independiente. Editar un prompt, una habilidad o una instrucción de herramienta puede hacerse mientras el agente trabaja en una tarea.

El repositorio de código abierto empaqueta el método como un proyecto de Python para Linux. Admite Python 3.12, refinamiento paralelo y secuencial, e integraciones con ejecutores de OpenCode y Codex. Su demostración incluida utiliza editores deterministas y ejecución local de Python, por lo que los desarrolladores pueden inspeccionar el flujo de trabajo sin credenciales de modelo.

Las evaluaciones basadas en modelos requieren más infraestructura. El repositorio especifica Node.js, autenticación de Google Cloud, acceso a modelos mediante Vertex AI y dependencias específicas de cada benchmark. WorkBuddy-Bench requiere Docker, mientras que el benchmark jurídico exige utilidades de procesamiento de documentos.

Esa configuración indica cuál es el público actual del proyecto. Se trata de software de investigación para equipos preparados para realizar evaluaciones controladas, no de una función para consumidores que actualice silenciosamente todos los agentes. El lanzamiento proporciona la maquinaria para experimentar, pero quienes lo adopten aún necesitan tareas, entornos de ejecución, evaluadores y límites operativos.

El marco inicia cada tarea entrante desde un harness base común. No traslada simplemente la configuración específica de la tarea más reciente a la siguiente asignación. En su lugar, refina temporalmente el harness actual y registra lecciones reutilizables en una biblioteca de mejoras independiente.

Esa decisión aborda un fallo frecuente en los sistemas adaptativos. Una instrucción que ayuda con el análisis de contratos puede perjudicar una tarea de hojas de cálculo. Acumular directamente cada edición exitosa haría que el harness fuera cada vez más especializado y difícil de razonar.

En cambio, Harness² intenta conservar evidencia sobre por qué una edición ayudó. Una tarea futura puede aprovechar esa experiencia sin heredar toda la configuración de ejecución anterior.

Por tanto, el proyecto representa dos formas de software. Un harness realiza el trabajo, mientras otro mejora el sistema que lo realiza. Esta segunda capa explica por qué los autores describen el método como harnessing recursivo de agentes, en lugar de optimización convencional de prompts.

Para los desarrolladores que ya mantienen manualmente instrucciones para agentes, el lanzamiento formaliza un flujo de trabajo reconocible. Los equipos inspeccionan fallos, revisan instrucciones, vuelven a ejecutar tareas y conservan técnicas útiles. Google Harness2 asigna gran parte de ese ciclo a los agentes y registra los cambios resultantes como artefactos estructurados.

Cómo Google Harness2 refina un agente sin respuestas correctas

Su mecanismo central compara el comportamiento en condiciones equivalentes, en lugar de pedir a un verificador perfecto que identifique la salida correcta.

El marco llama a su principal proceso a nivel de tarea Propose-Probe-Compose. Un proponente estudia primero la ejecución original y sugiere ediciones específicas del harness. Una prueba vuelve a ejecutar la misma tarea con esos candidatos. Después, un compositor combina los cambios respaldados por diferencias entre las trayectorias resultantes.

Una trayectoria es la secuencia registrada de respuestas del modelo, llamadas a herramientas, observaciones y archivos generados. Proporciona al sistema más evidencia que una respuesta final por sí sola. El editor puede ver si una revisión encontró entradas faltantes, invocó una herramienta adecuada o verificó un documento antes de enviarlo.

El sistema divide las propuestas en dos ámbitos. Un editor invariante se centra en el comportamiento general de ejecución, como comprobar las salidas después de escribirlas. Un editor de dominio se centra en conocimientos, formatos o procedimientos específicos de la tarea.

Esta separación reduce la probabilidad de que cada problema reciba la misma corrección genérica. También permite al compositor combinar una regla de proceso ampliamente útil con orientación especializada cuando ambas producen cambios de comportamiento útiles.

De forma crucial, el proceso en línea no recibe la clave de respuestas del benchmark. El artículo de investigación describe un entorno abierto en el que las tareas llegan después de diseñar el harness. Puede que no haya un verificador fiable de verdad fundamental disponible durante la ejecución.

En lugar de declarar correcto a un candidato, el sistema busca contrastes. Supongamos que el agente base pasa por alto varios archivos fuente. Una revisión inventaría todas las entradas, mientras otra añade orientación para la conciliación de hojas de cálculo. Sus trayectorias revelan si esas intervenciones cambiaron el proceso del agente.

El compositor usa esa evidencia para construir otro harness y volver a ejecutar la tarea. El enfoque no elimina el juicio. Desplaza el juicio de comparar una salida con una respuesta conocida a comparar el comportamiento observable entre ejecuciones.

Los desarrolladores pueden dedicar cómputo adicional en tiempo de prueba de dos maneras. La recursión paralela explora varias revisiones candidatas a la vez y luego compone evidencia a partir de esos intentos. La recursión secuencial aplica otro refinamiento después de cada revisión anterior.

La variable k controla ese presupuesto de exploración. Un valor mayor ofrece al sistema más oportunidades de encontrar y probar ediciones, pero cada oportunidad añade llamadas al modelo, uso de herramientas y tiempo de ejecución.

Una vez finalizada la tarea, un segundo nivel de recursión actualiza el harness de mejora continua. Un reflector almacena el harness adoptado y un archivo de experiencia que describe la intervención, la evidencia y el resultado. Las propuestas posteriores pueden consultar esa biblioteca.

Este diseño hace que la experiencia sea más portable que un prompt terminado. Una lección almacenada podría indicar que las tareas de generación de documentos se benefician de reabrir los archivos finales y comprobar las secciones obligatorias. Ese proceso puede aplicarse en distintos dominios aunque los documentos exactos sean diferentes.

La distinción también conecta el marco con el trabajo cotidiano basado en conocimiento. Un agente podría necesitar combinar notas de reuniones, hojas de cálculo, políticas y documentos de proyecto antes de producir un memorando de decisión. A menudo, la parte difícil es rastrear afirmaciones entre fuentes, no generar prosa fluida.

Los equipos ya pueden reducir esa carga creando una base de conocimiento consultable. Harness² amplía la idea hacia la política de ejecución: el agente puede revisar cómo recopila, comprueba y utiliza ese material para una tarea concreta.

Sin embargo, el mecanismo sigue siendo experimental. El contraste de comportamiento es evidencia, no verdad. Dos candidatos pueden compartir la misma premisa equivocada, y una trayectoria pulida aún puede conducir a un entregable deficiente.

Las mejoras en benchmarks ponen bajo presión a los harnesses de agentes fijos

Los resultados comunicados sugieren que el diseño del harness puede cambiar el rendimiento tanto como sustituir modelos, especialmente en sistemas de partida más débiles.

Los investigadores evaluaron Harness² en tres benchmarks profesionales. WorkBuddy-Bench cubre tareas de programación, web y oficina. JobBench prueba trabajo profesional, mientras que Harvey’s Legal Agent Benchmark mide el rendimiento en tareas jurídicas.

Las pruebas cubrieron cuatro combinaciones de dos modelos y dos harnesses iniciales. Los modelos fueron Gemini 3.5 Flash y GLM-5. Los harnesses de ejecución iniciales fueron OpenCode y Codex, mientras que Claude Opus 4.8 actuó como editor predeterminado en los experimentos principales.

Un único paso de refinamiento mejoró todas las combinaciones probadas de modelos y harnesses en los tres benchmarks, según los autores. Las mayores mejoras comunicadas alcanzaron 11,5 puntos en WorkBuddy-Bench, 4,5 puntos en JobBench y 11,8 puntos porcentuales en la tasa de aprobación parcial del benchmark jurídico.

El mayor cambio en WorkBuddy-Bench apareció con GLM-5 bajo OpenCode. Su puntuación media aumentó de 64,2 a 75,7 tras un paso. Gemini 3.5 Flash bajo OpenCode pasó de 72,4 a 77,5.

Esas cifras respaldan una inferencia práctica. El harness puede reducir parte de la brecha entre modelos al corregir comportamientos de ejecución que la capacidad bruta del modelo no resuelve.

Los resultados variaron según la configuración. GLM-5 bajo Codex ganó solo 1,2 puntos en JobBench, pasando de 23,6 a 24,8. Gemini bajo OpenCode mejoró 4,5 puntos en el mismo benchmark.

Esta variación importa más que la mayor cifra destacada. El método no produjo una mejora uniforme en todos los modelos, harnesses y tareas. Su valor dependió del sistema de partida y del dominio.

Los investigadores también aumentaron el presupuesto de recursión. Con Gemini bajo OpenCode, pasar de un paso de refinamiento a recursión paralela con k=5 elevó aún más el rendimiento en WorkBuddy-Bench. Programación alcanzó 80,8, web llegó a 81,7 y oficina a 83,4.

El artículo informa de que tanto las puntuaciones paralelas como las secuenciales aumentaron a medida que el presupuesto pasó de uno a cinco en dominios seleccionados de WorkBuddy-Bench. Los métodos competidores mostraron cambios menores o menos consistentes en esas pruebas.

Una exploración mayor no fue toda la explicación. En un estudio de ablación, eliminar la biblioteca de mejoras redujo el rendimiento medio de WorkBuddy-Bench en 3,1 puntos. Eliminar los roles de editor acotados costó 2,9 puntos, mientras que omitir la composición costó 1,6 puntos.

JobBench mostró un patrón similar. Eliminar la biblioteca redujo su puntuación en 1,8 puntos, los editores genéricos perdieron 3,7 puntos y omitir la composición restó 1,9 puntos. Estos resultados indican que la experiencia retenida, las propuestas especializadas y la combinación basada en evidencia contribuyeron de forma independiente.

Un estudio de caso de JobBench ilustra el mecanismo. El agente base no logró reconciliar información entre archivos fuente y no volvió a abrir su resultado final para verificarlo. Su puntuación fue de 43,1.

Una intervención propuesta exigía un inventario de cada entrada y una trazabilidad explícita de las fuentes. Otra añadió directrices de dominio para reconciliar calendarios, lugares, mano de obra y presupuestos. El compositor conservó las cuatro modificaciones introducidas por esas intervenciones, y la nueva ejecución obtuvo 77,8.

Ese ejemplo refuerza el argumento a favor de mejorar el arnés del agente, porque el fallo fue procedimental. Al modelo no le faltaban ni capacidades lingüísticas básicas ni acceso a los archivos. Le faltaba un método operativo fiable.

Los arneses fijos siguieron teniendo un rendimiento distinto según el dominio. La comparación del artículo concluyó que Claude Code lideraba entre los sistemas fijos en tareas de código y oficina, mientras que Codex lideraba en tareas web. Ningún arnés sin modificar lideró en todas partes.

Partiendo de OpenCode con un presupuesto de recursión mayor, Harness² superó a la alternativa fija más sólida por 4,6 puntos en código, 5,8 en web y 4,9 en oficina. Los autores señalan explícitamente que este resultado adaptativo utilizó cómputo adicional durante la prueba.

Por tanto, la presión competitiva se dirige al enfoque de arnés fijo, no a un producto concreto. Un proveedor puede mejorar su modelo, pero los usuarios pueden seguir recibiendo resultados inconsistentes si las instrucciones y herramientas circundantes no pueden adaptarse.

Los arneses de agentes auto-mejorables siguen necesitando verificaciones independientes

Harness² puede mejorar el proceso de un agente, pero sus propias pruebas muestran que las ediciones recursivas a veces seleccionan comportamientos peores o propagan una suposición equivocada.

Los resultados del benchmark proceden de los autores del proyecto y aún no han establecido fiabilidad en producción en despliegues independientes. El artículo informa medias de tres ejecuciones, lo que ayuda a medir la variabilidad, pero no sustituye la replicación externa.

El método también consume cómputo adicional antes de entregar su resultado final. Cada propuesta, prueba, composición y nueva ejecución consume tokens y tiempo de ejecución. El procesamiento paralelo puede reducir el tiempo transcurrido cuando hay capacidad disponible, pero no elimina el coste subyacente de recursos.

El artículo sitúa las configuraciones evaluadas en una frontera empírica de cómputo-rendimiento para JobBench y WorkBuddy-Bench. Ese resultado significa que las mejoras medidas se compararon favorablemente con las alternativas probadas. No significa que la recursión sea económica para toda carga de trabajo de producción.

Una tarea de bajo valor quizá no justifique varias ejecuciones del modelo. Un memorando jurídico o una decisión operativa podrían justificar más comprobaciones, pero esos ámbitos también exigen controles más estrictos que los que proporciona un ejecutor de benchmarks.

La advertencia más importante procede del propio análisis de fallos de los autores. Examinaron nueve regresiones y las agruparon en fallos de selección de candidatos, premisas incorrectas compartidas e incertidumbre de evaluación o ejecución.

En un ejemplo de programación, el marco seleccionó una salida con puntuación de 55 frente a una alternativa con puntuación de 95. En una tarea jurídica, una revisión más limitada redujo la cobertura y rebajó la puntuación de 54 a 26.

Otros fallos comenzaron con una suposición incorrecta compartida entre candidatos. Esos errores produjeron pérdidas de entre 2 y 11 puntos. Si todas las ediciones propuestas aceptan la misma premisa falsa, comparar su comportamiento no revela el error original.

El artículo también identifica decisiones ausentes del juez y la variabilidad ordinaria entre ejecuciones como problemas de atribución. Una puntuación modificada puede reflejar la edición, la ejecución estocástica o el ruido de evaluación. Más pruebas ayudan, pero aumentan el coste.

La actividad del repositorio también ha revelado riesgos de implementación. Un problema abierto de identidad de caché informa de que los experimentos reanudados pueden reutilizar resultados anteriores después de que cambien las instrucciones de la tarea o los archivos fuente mientras los identificadores de tarea permanecen constantes.

El autor del problema reprodujo el comportamiento sin llamadas al modelo y señaló que el contenido de entrada no aparece en partes de la identidad de ejecución guardada. El informe no cuantifica ningún efecto sobre las puntuaciones publicadas del benchmark, y no se adjuntó ninguna resolución de un mantenedor cuando se revisó.

Aun así, el problema ilustra el desafío operativo más amplio. Un sistema recursivo necesita una procedencia fiable de las tareas, el material fuente, las revisiones del arnés, las salidas almacenadas en caché y la configuración de evaluación. De lo contrario, una mejora aparente puede reflejar pruebas obsoletas.

La seguridad plantea otra preocupación. Los ocho componentes editables incluyen salvaguardas, scripts, plugins e instrucciones de herramientas. Esos archivos pueden influir en aquello a lo que accede un agente y en las acciones que realiza.

Un editor autónomo no debería recibir autoridad sin restricciones para debilitar controles de acceso, ejecutar scripts no revisados o conservar detalles sensibles de las tareas. El uso en producción necesita permisos a nivel de componente, límites de seguridad inmutables, registros de auditoría y reversión.

La experiencia persistente merece una cautela similar. Una lección útil de un cliente, departamento o asunto jurídico puede exponer información confidencial al recuperarse para otro. Por tanto, una biblioteca de mejoras necesita separación de datos y políticas de retención, no solo relevancia semántica.

Los equipos también deberían distinguir la optimización del rendimiento de la validación de seguridad. Una puntuación de benchmark premia la finalización de tareas según su evaluador. No mide automáticamente la privacidad, la autorización, la precisión factual ni la resistencia a entradas maliciosas.

Google Harness2 demuestra por sí mismo por qué importa esta distinción. Su compositor puede preferir un candidato convincente desde el punto de vista conductual que es objetivamente más débil. La ausencia de una verdad de referencia es el problema que aborda el marco, pero sigue siendo un límite que el marco no puede eliminar.

Un diseño de producción sensato permitiría al sistema modificar directrices de menor riesgo mientras protege las políticas centrales. La redacción de prompts y las listas de comprobación de flujos de trabajo podrían ser editables. Las reglas de credenciales, los límites de red, las puertas de aprobación y los límites para acciones destructivas deberían permanecer fuera de la autoridad del agente.

La revisión humana también sigue siendo valiosa para los cambios propuestos que persisten entre tareas. El marco puede generar pruebas que expliquen por qué se adoptó una edición. Los operadores pueden utilizar ese registro para aprobar, rechazar o restringir el cambio antes de que entre en una biblioteca compartida.

El arnés recursivo de agentes cambia la hoja de ruta de la ingeniería de agentes

La próxima prueba es si las organizaciones pueden reproducir las mejoras mientras controlan el cómputo, las regresiones y la memoria persistente.

La primera señal que observar es la replicación independiente de benchmarks. El repositorio expone código, configuraciones, prompts y comandos de evaluación, lo que ofrece a equipos externos un punto de partida práctico. Las reproducciones deberían informar tanto de las puntuaciones finales como del uso total del modelo.

Una replicación satisfactoria entre distintos proveedores reforzaría la afirmación central. Mostraría que el arnés adaptativo no está estrechamente acoplado a los modelos, el editor o el entorno de Google Cloud evaluados.

No lograr reproducir las mejoras debilitaría el argumento de la generalidad. Los investigadores tendrían que identificar si la diferencia procedió del comportamiento del modelo, las versiones del benchmark, los entornos de ejecución o la configuración de evaluación.

La segunda señal es el rendimiento en flujos de tareas reales, en lugar de ejecuciones aisladas de benchmarks. La recursión a nivel de arnés promete valor acumulativo porque las lecciones de tareas anteriores orientan propuestas posteriores.

El artículo ofrece evidencia inicial de esa transferencia. Una biblioteca de experiencia construida sobre JobBench mejoró el refinamiento de un paso en WorkBuddy-Bench en 0,6 puntos para código, 0,5 para web y 2,9 para oficina.

Esas mejoras son menores que los resultados más sólidos a nivel de tarea, y un análisis utilizó retrospectivamente la experiencia de tareas posteriores. Un despliegue en vivo debería demostrar que las lecciones útiles se acumulan en orden cronológico sin importar información futura.

Los operadores deberían medir las tasas de regresión junto con el rendimiento medio. También deberían seguir la frecuencia de intervención, la latencia, el consumo del modelo y el porcentaje de ediciones persistentes que superan la revisión humana.

La tercera señal es una capa más sólida de verificación y gobernanza. Los autores recomiendan pruebas que cuestionen las suposiciones compartidas, ejecución repetida para separar las ediciones de la variabilidad y mejores métodos de selección que equilibren cobertura y precisión.

Las correcciones del repositorio pueden aportar otro indicador. Identidades de caché conscientes del contenido, revisiones de benchmarks fijadas e invalidación fiable facilitarían la reproducción de experimentos. Límites de seguridad claros para los componentes editables harían más seguro el despliegue.

El campo de investigación más amplio también pondrá a prueba formas alternativas de adaptación del arnés. Meta-Harness busca configuraciones antes del despliegue. ReasoningBank recupera experiencia de razonamiento útil mientras mantiene fijo el arnés. Harness Scaling revisa un arnés para tareas individuales.

Harness² combina adaptación de tareas en línea con un mecanismo persistente de mejora. Esa combinación es su principal distinción, pero también concentra el riesgo. Una mala revisión a nivel de tarea afecta a un resultado, mientras que una mala lección retenida puede influir en tareas posteriores.

Para los desarrolladores, el mensaje práctico no es que todos los agentes deban reescribirse de inmediato. Es que los prompts, la memoria, las herramientas y la orquestación merecen evaluarse como un sistema conectado.

Los equipos pueden empezar con experimentos acotados. Pueden seleccionar tareas representativas, conservar un arnés base inmutable, permitir revisiones solo en un entorno aislado y comparar la calidad de salida frente al cómputo total. Cada cambio persistente debería seguir siendo atribuible y reversible.

Los trabajadores del conocimiento deberían prestar atención porque la calidad del arnés determina el comportamiento visible del agente. Un modelo puede parecer poco fiable cuando sus instrucciones de herramientas son débiles, su memoria tiene ruido o su flujo de trabajo omite la verificación. A la inversa, un procedimiento mejor puede mejorar los resultados sin cambiar el modelo.

La publicación abierta hace que esas hipótesis sean comprobables. Ofrece a los investigadores una implementación común para estudiar cómo los agentes diagnostican fallos, revisan instrucciones operativas y conservan experiencia.

Google Harness2 traslada, en última instancia, el debate sobre la auto-mejora desde la inteligencia abstracta de los modelos hacia artefactos de software inspeccionables. Es un cambio útil porque los equipos pueden revisar archivos, rastrear revisiones y medir ejecuciones.

No resuelve la pregunta más difícil: ¿quién verifica al mejorador cuando no existe una clave de respuestas? El marco sustituye la edición ciega por evidencia conductual estructurada, pero la evidencia aún puede inducir a error.

Durante los próximos meses, habrá que observar las replicaciones independientes, los resultados en vivo entre tareas y controles más estrictos sobre los componentes editables. Esas señales determinarán si el arnés recursivo de agentes se convierte en una capa de ingeniería fiable o sigue siendo un prometedor flujo de trabajo de investigación.

Para los equipos que evalúan agentes de IA ahora, la acción inmediata es sencilla. Prueben por separado el modelo y su arnés, registren cada cambio y exijan pruebas claras antes de conservar una revisión automatizada. Google Harness2 proporciona un marco concreto para ese experimento, mientras que sus fallos reportados demuestran por qué la supervisión sigue siendo importante.