Google Research publicó Harness², un framework open source que mejora un agente de IA reescribiendo su harness (prompts, herramientas, memoria, skills y orquestación) sin tocar los pesos del modelo. El paper se subió a arXiv el 9 de octubre de 2026 y el código está disponible bajo licencia Apache 2.0.
La premisa la conocen bien quienes leen yoDEV: la capacidad de un agente depende tanto del sistema que rodea al modelo como del modelo mismo. Harness² da un paso más. En lugar de que una persona ajuste ese sistema a mano, el agente propone cambios a su propio harness, los prueba y se queda con lo que funciona.
¿Qué partes de un agente de IA se pueden optimizar sin tocar el modelo?
El harness es todo lo que rodea al modelo y le permite actuar como agente, y Harness² expone ocho componentes editables. Los autores llaman harnessing al proceso de optimizar ese sistema. Ya cubrimos la disciplina en sí en Harness Engineering: El Nuevo Trabajo del Engineer; Harness² es un intento de automatizarla.
Los ocho componentes son:
- system prompt
- guardrails
- memoria
- guía de herramientas (tool guidance)
- subagentes
- skills
- scripts
- plugins
En conjunto controlan cómo se construye el contexto, cómo se ve la interfaz de herramientas, cómo se delega el trabajo y cómo se comporta el agente dentro del tool loop.
Si trabajas con Claude Code, Codex u OpenCode, esa lista te resultará familiar. Corresponde casi uno a uno con tu CLAUDE.md o AGENTS.md, tu carpeta de skills, tus definiciones de subagentes y tus hooks. Harness² trata esos archivos como algo que se optimiza, no como algo que escribes una vez y olvidas.
¿Cómo mejora un agente de IA su propio harness?
Harness² mejora el harness con dos niveles de recursión, y en ambos el modelo queda fijo.
La recursión a nivel de tarea refina el harness para la tarea que tiene delante. Lo hace con un paso de tres partes que los autores llaman Propose–Probe–Compose:
- Propose. Un editor sugiere cambios al harness. Algunos son generales (invariant) y otros son específicos del dominio.
- Probe. Los harness candidatos se ejecutan sobre la misma tarea.
- Compose. Un compositor arma un harness refinado a partir de los contrastes de comportamiento entre esas ejecuciones.
El detalle clave es que esto funciona sin feedback de ground truth. El agente no necesita conocer la respuesta correcta. Aprende de cómo distintas versiones del harness se comportan de forma diferente ante el mismo problema.
La recursión a nivel de harnessing opera entre tareas. Después de cada tarea, un “reflector de experiencia” guarda el harness adoptado y las lecciones respaldadas por evidencia. Todo eso va a un improvement harness persistente, que guía el refinamiento en la siguiente tarea, aunque nunca se haya visto antes. Esa es la parte de “mundo abierto” del título: el escenario en el que aparecen tareas que nadie anticipó al diseñar el harness.
¿Recursión paralela o secuencial: cuál conviene?
Depende de si quieres explorar más opciones o refinar más a fondo. Harness² escala la recursión a nivel de tarea de dos formas, ambas controladas por --k, el presupuesto de recursión:
--mode parallelpruebaKharness candidatos generales yKespecíficos del dominio, y luego produceKcomposiciones a partir de la evidencia compartida. Explora más ancho.--mode sequentiallleva el harness refinado y su evidencia acumulada a través deKpasos sucesivos de Propose–Probe–Compose. Refina más profundo.
--k 1 es un solo paso. Según los autores, un solo paso ya ayuda, y un presupuesto mayor ayuda todavía más.
¿Cuánto mejora el agente según los benchmarks?
Según los propios autores, un solo paso de Harness² mejoró dos modelos frente a sus harness base:
- Se probaron GLM-5 y Gemini 3.5 Flash en cuatro configuraciones modelo–harness.
- Las mejoras llegaron a 11,5 puntos en WorkBuddy-Bench.
- Llegaron a 4,5 puntos en JobBench.
- Llegaron a 11,8 puntos porcentuales en la tasa de aprobación parcial de LAB.
Hay dos matices importantes.
Primero, son cifras de los propios autores en un preprint. Todavía no se han reproducido de forma independiente.
Segundo, los benchmarks miden trabajo profesional, no programación. JobBench cubre tareas profesionales generales y LAB cubre trabajo legal. WorkBuddy-Bench cubre oficina, web y código, y solo su subconjunto code se parece a lo que la mayoría de nosotros hace todo el día. Los resultados muestran que el método funciona en trabajo de conocimiento abierto. Todavía no dicen cuánto mejora un coding agent sobre tu repositorio.
¿Cómo instalar Harness² y probar la demo sin API keys?
Puedes correr la demo local en pocos minutos y sin credenciales de ningún modelo. El README pide Linux, Python 3.12 y uv. Desde la raíz del repositorio:
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'
harness2-demo --output runs/demo --k 2
La demo ejecuta ambos modos de recursión con editores deterministas y ejecuciones reales de Python. Es la forma más rápida de ver el ciclo Propose–Probe–Compose e inspeccionar cómo se ve en disco un harness adoptado.
¿Qué necesitas para usarlo con Vertex AI?
Las ejecuciones con modelos reales requieren más preparación. Necesitas:
- Node.js 20 o superior
- Google Cloud CLI
- las dependencias del benchmark que elijas: LAB necesita Pandoc y Poppler, y WorkBuddy-Bench necesita Docker
Los modelos se configuran con un archivo .env que apunta a un proyecto de Vertex AI:
cp .env.example .env
# Edit .env with your Vertex AI project and model IDs.
gcloud auth application-default login
La guía de instalación documenta cuatro variables:
HARNESS2_SOLVER_MODEL, el modelo ejecutorHARNESS2_IMPROVER_MODEL, que por defecto es el mismo que el ejecutorHARNESS2_JUDGE_MODELHARNESS2_RUNS_DIR
La configuración incluida usa Gemini en Vertex como ejecutor y como juez. Como improver acepta Claude en Vertex o Gemini.
El ejemplo del README ejecuta una sola tarea de LAB de punta a punta:
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
Estas ejecuciones generan costos de API, y los autores recomiendan empezar con una selección pequeña de tareas. Si agregas --dry-run a harness2, ves la selección de tareas sin llamar a ningún modelo. Los resultados quedan en runs/, incluidos los harness adoptados y las notas de reflexión. Si vuelves a correr el mismo comando, la ejecución se reanuda.
¿Funciona con OpenCode y Codex CLI?
Sí. OpenCode es el ejecutor por defecto, y Codex se activa con --substrate cx. Para usar Codex con Gemini, el repo incluye harness2-bridge, un servidor local de LiteLLM que expone Vertex AI a través de una interfaz compatible con la Responses API. Para usar otro endpoint de la Responses API, la guía documenta HARNESS2_CODEX_BASE_URL, HARNESS2_CODEX_API_KEY y HARNESS2_CODEX_MODEL.
Al momento de publicar esta nota, la versión soporta estos dos ejecutores y estos tres benchmarks. Es un repositorio en etapa temprana, así que es probable que esa lista cambie.
¿Qué riesgos de seguridad tiene?
El README lo dice explícitamente: el acceso a red del ejecutor no tiene restricciones y Codex se ejecuta con su sandbox desactivado. Cuando el bridge corre para WorkBuddy, escucha en 0.0.0.0, es decir, en todas las interfaces de red, y la guía advierte que debes restringir quién puede alcanzarlo.
Los autores también señalan un problema de integridad: las rúbricas públicas de los benchmarks pueden estar disponibles en internet. Recomiendan configurar restricciones de red antes de cualquier evaluación. No lo corras en una máquina con acceso a algo que te importe. El consejo vale doble porque el proyecto aclara que no es un producto con soporte oficial de Google y que queda fuera del programa de recompensas por vulnerabilidades open source de Google.
¿Por qué importa si no corres benchmarks?
Porque la idea de fondo se aplica a cualquier agente que uses, aunque Harness² sea un artefacto de investigación y no una herramienta que vayas a sumar a tu flujo diario la próxima semana. Tu harness es un conjunto de archivos, y esos archivos se pueden medir y mejorar de forma sistemática: corre variantes sobre la misma tarea, compara el comportamiento, quédate con lo que gana y registra por qué.
Es la misma dirección que el trabajo de Microsoft con SkillOpt, pero aplicada a todo el harness en lugar de a una sola skill. Ahora Google Research tiene una versión pública y reproducible de ese ciclo. Si tu equipo mantiene una pila creciente de instrucciones para agentes, es una buena referencia para dejar de ajustarlas a ojo.
¿Y tú? ¿Qué parte de tu harness cambias con más frecuencia: el system prompt, las skills o la memoria?
- Las ajusto a mano cuando algo falla
- Pruebo variantes y comparo resultados
- Casi no las toco después de escribirlas
- Prefiero otra opción (cuéntanos cuál)
Comenta abajo o, si este artículo te llegó por correo, responde directamente al email: tu respuesta se publica aquí.
Relacionado: Composer 2.5: Por Qué el Harness Importa Más que el Modelo