Si has operado un agente de código más de una semana, has construido un harness sin llamarlo así. El andamiaje del prompt, el pequeño script que ensambla los ficheros correctos antes de empezar, el hook que corre los tests antes de fiarte del “hecho”, el retry que haces a mano cuando un run muere. Eso no es el modelo. Es la maquinaria alrededor del modelo, y resulta que la maquinaria es casi todo el trabajo.
El término que circula para esto en la comunidad es harness engineering. Lo oyes de gente que opera agentes en serio, en los escritos de ingeniería de Anthropic y en foros de desarrolladores como Latent.Space, usado con soltura pero apuntando a lo mismo: la disciplina de construir y afinar el bucle dentro del que corre el modelo. Lo uso aquí en ese sentido general, porque nombra algo que muchos llevamos haciendo sin nombre. La afirmación interesante debajo del término es que cuando el trabajo con agentes falla a escala, el harness suele ser la razón del fallo, y el harness suele ser lo que merece la pena arreglar. Es un capítulo de construir software con agentes de IA, y quizá el menos glamuroso.
Qué es de verdad un harness
Redúcelo y un harness es el bucle exterior alrededor de una llamada al modelo. El modelo hace una cosa: dado algo de contexto, produce el siguiente output. Todo lo que decide qué contexto recibe, qué herramientas puede llamar, qué pasa con el resultado, y qué pasa cuando el resultado está mal, eso es el harness.
En concreto, un harness de código hace al menos esto:
- Ensamblado de contexto. Qué ficheros, qué decisiones previas, qué restricciones entran en la ventana, y en qué orden. Falla esto y hasta un modelo fuerte produce disparates con seguridad, que es el tema entero de context engineering para agentes de código.
- Mediación de herramientas. Qué puede correr el agente, con qué permisos, y cómo vuelven los resultados. Un runner de tests, un editor de ficheros, una shell, cada uno con su frontera.
- Verificación. Qué comprueba el output antes de que alguien se fíe. La diferencia entre “el agente dijo hecho” y “el gate pasó”.
- Recuperación. Qué pasa cuando un paso falla o un run muere, tratado en la recuperación como flujo de primera clase.
- Routing. Qué motor recibe qué tarea, la preocupación detrás de enrutar cada tarea al motor correcto.
Nada de eso es el modelo. Todo ello determina si el modelo es útil. Por eso harness engineering se volvió algo de lo que hablar: la palanca se movió.
Por qué el harness se volvió el cuello de botella
Durante un tiempo, la forma obvia de mejorar los agentes era un modelo mejor, y funcionó, hasta que dejó de ser lo que importaba en el trabajo real.
La evidencia más clara que he corrido yo mismo está en el experimento de recuperación. A través de cuatro episodios acumulativos con gates ocultos, un agente de código con un prompt fuerte se quedó clavado en una tasa de aprobado de dos tercios. El mismo agente con una skill de recuperación hecha a mano se quedó en el mismo sitio. Modelos más grandes en controles de un solo run hicieron lo mismo. Lo que llegó al 100% no fue un modelo más listo, fue un harness que sostuvo el contrato y volvió a puntuar el trabajo tras cada intento. Mismo executor, distinto bucle alrededor, distinto resultado.
Esa es la forma general del argumento de los agentes necesitan un runtime, no un modelo más grande. Cuando el modelo es lo bastante bueno como para escribir código correcto desde contexto correcto, la frontera se mueve al sistema que suministra el contexto correcto, verifica el output y recupera cuando deriva. El modelo se volvió commodity. El harness no.
Los propios escritos de ingeniería de Anthropic apuntan en la misma dirección, ya sea en construir agentes efectivos o en su relato de un sistema multiagente de investigación: casi todo lo que hace fiable a un agente a escala es arquitectura alrededor del modelo, no el modelo en aislamiento.
Las partes de un harness que merece la pena diseñar
Tratar el harness como un artefacto de verdad significa que tiene partes que diseñas a propósito, no andamiaje que acumulas por accidente.
El contrato de contexto. Qué entra siempre, qué no entra nunca, y cómo evitas que la ventana se llene de ruido. Un harness que vuelca el repo entero en cada llamada no es ingeniería, es esperanza. Aquí es donde gestionar la ventana de contexto deja de ser un truco y se vuelve una restricción de diseño.
La capa de verificación. Gates que corren sobre el output da igual lo que el agente afirme. Un harness cuya única señal de completitud es el agente diciendo “hecho” no tiene capa de verificación, tiene un buzón de sugerencias.
El camino de recuperación. Checkpoints, último estado bueno, una forma de resumir sin empezar de cero. Un harness sin esto convierte cada fallo en un rescate manual.
El formato de handoff. Qué viaja cuando el trabajo se mueve entre agentes o sesiones, el tema de handoffs entre agentes. Un harness que no puede hacer handoff no escala más allá de una sesión en una cabeza.
La capa de instrucciones. Los ficheros de reglas que el agente lee, y sobre todo, si siguen siendo verdad. Un harness que alimenta a los agentes con reglas obsoletas está diseñando el bucle equivocado con cuidado.
Puedes construir todo esto a mano, y si operas agentes en serio ya lo haces. La pregunta que fuerza harness engineering es si lo construyes a propósito, con partes sobre las que puedes razonar, o lo acumulas como un montón de scripts que solo tú entiendes.
Dónde encaja PaellaDoc
Harness engineering como frase es útil porque nombra el trabajo real: la fiabilidad del output de un agente viene del bucle alrededor del modelo, y ese bucle es algo que diseñas. La versión incómoda es que ahora mismo, para casi todos, el harness es una persona. Tú eres el ensamblador de contexto, el verificador, el camino de recuperación y el router, sosteniéndolo en la cabeza, que es justo el argumento de tú eres el runtime. PaellaDoc es un harness que no tienes que ser tú: el contrato de contexto, los gates, la recuperación y el routing construidos como sistema, portable entre motores, para que el bucle sobreviva fuera de la memoria de un operador. No un modelo mejor. Un bucle mejor alrededor del modelo que corras.
FAQ
¿Qué es harness engineering?
Es la práctica emergente de construir y afinar el bucle dentro del que corre un agente de código: cómo se ensambla el contexto, qué herramientas puede llamar el agente, cómo se verifica el output y cómo se recuperan los fallos. El término se usa con soltura por la comunidad de operación de agentes, incluidos los escritos de ingeniería de Anthropic, para nombrar el sistema alrededor del modelo en oposición al modelo en sí.
¿El harness importa más que el modelo?
Cuando el modelo es lo bastante bueno como para escribir código correcto desde contexto correcto, sí, el harness pasa a ser donde se gana o se pierde la fiabilidad. En un test de recuperación controlado, el mismo agente de código se quedaba clavado o llegaba al 100% dependiendo solo del bucle a su alrededor, no del modelo. Por debajo de ese umbral el modelo aún importa; por encima, domina el harness.
¿En qué se diferencia un harness de simplemente hacer buenos prompts?
Un prompt es una entrada a una llamada. Un harness es el bucle entero: ensambla contexto a través de muchas llamadas, corre herramientas, verifica el output contra gates, recupera runs fallidos, y mueve trabajo entre sesiones. Un buen prompt es parte de ello, pero un prompt sin verificación, sin recuperación y sin gestión de contexto no es un harness, es una sola tirada de dados.