Qué es

Terminología · Verificación de fuentes · Ingeniería de LLM · Modelos de lenguaje · IA · ExplicaciónTratopedia · 15 ago 2026

La acuñación, y la redefinición que se la tragó Treinta y tres días de diferencia. Todo lo posterior a la segunda la repite.

• 33días desde que la expresión se acuñó para una costumbre hasta que pasó a significar todo lo que rodea al modelo
• 2aportaciones distintas — una el nombre, otra la definición — confundidas con una sola disputa por el mérito
• 1comparación encontrada que mantiene fijo el modelo y solo cambia el harness
• 0fuentes que concilian el único desacuerdo que queda: si esto contiene la ingeniería de contexto o está dentro de ella

• Mitchell Hashimoto · 5 feb 2026

  “He acabado llamando a esto ingeniería de harness”

  La acuñación, y lo pequeña que era.

  • Todo lo que es: cada vez que descubres que un agente comete un error, te tomas el tiempo de idear una solución para que el agente no vuelva a cometerlo nunca.
  • Se presenta en dos formas, y ese es todo su alcance: un AGENTS.md donde cada línea de ese archivo se basa en un mal comportamiento del agente, y “herramientas reales, programadas” — scripts para capturas de pantalla y pruebas filtradas. Sin sandbox, sin orquestación, sin sustrato de ejecución.
  • Lo hace a regañadientes: no necesito inventar ningún término nuevo aquí; si existe otro, me subo al carro. Nadie le dijo que llegaría uno en cinco semanas y se llevaría la palabra consigo.

• Vivek Trivedy · LangChain · 10 mar 2026

  Agente = Modelo + Harness

  Treinta y tres días después, y mucho más grande.

  • Su glosa: si no eres el modelo, eres el harness. Todo trozo de código, configuración y lógica de ejecución que no sea el modelo en sí — sistema de archivos, sandbox, navegador, orquestación, hooks.
  • Tiene cuidado de señalar que es una elección, no un hecho: hay muchas maneras desordenadas de trazar las fronteras… pero en mi opinión esta es la más limpia.
  • Toda definición posterior a esta la repite, y ninguna repite la de Hashimoto. Toda la deriva está en esos 33 días.

• Wikipedia · última edición 13 ago 2026

  “La infraestructura de software que rodea a un modelo”

  Una entrada de enciclopedia, cinco meses después del nombre.

  • En su totalidad: lo que “gestiona el uso de herramientas, la memoria, la persistencia del estado, los entornos de ejecución y los bucles de retroalimentación, en contraposición al razonamiento propio del modelo.”
  • La ingeniería de contexto, más de un año más antigua, sigue sin tener artículo propio — es un párrafo dentro de otra entrada.
  • Además fecha mal una de sus propias fuentes por un año. Véase la sección tres.

• Zhong & Zhu · arXiv · 13 may 2026

  “Un sustrato de ejecución”

  Lo mismo, escrito como programa de investigación.

  • Su primer movimiento: la explicación dominante sitúa esta brecha en la capacidad del modelo. Nosotros proponemos otro locus.
  • Once responsabilidades de componente y una escalera de cuatro niveles, de H0 a H3. Tres de las once — atribución de fallos, auditoría de entropía, registro de intervenciones — existen para juzgar una ejecución a posteriori, no para hacerla funcionar.
  • Aquí solo se leyó el resumen, así que nada en esta página recoge ningún resultado del artículo.

¿Con cuánta firmeza se sostiene cada una? Qué se leyó, qué sigue faltando y en qué se equivocó esta página la primera vez.

Cronología

La práctica, luego la palabra, luego la enciclopedia Nueve meses desde un método publicado entero hasta una entrada de Wikipedia.

1. oct 2022El bucle, como artículo. Yao y sus colegas publican ReAct, que hace que un modelo alterne entre razonar y actuar. Todo harness posterior ejecuta ese ciclo: el modelo razona, el harness actúa y captura lo ocurrido, el modelo lee el resultado.
2. feb 2023Las herramientas, como artículo. Toolformer muestra que un modelo puede enseñarse a sí mismo a llamar a herramientas externas. Wikipedia lo señala, junto con ReAct, como el mecanismo anterior al término.
3. dic 2024La idea, sin la palabra. Anthropic sostiene que la interfaz agente–ordenador merece tanta inversión como la interfaz persona–ordenador, y que la definición de una herramienta debe diseñarse de modo que el modelo no pueda usarla mal con facilidad.
4. 26 nov 2025La práctica entera, publicada. Justin Young, de Anthropic, describe los harnesses de agentes de larga duración: un agente inicializador que deja puestos init.sh, un archivo de progreso y un primer commit; un agente de codificación que hace una funcionalidad por sesión y deja el repositorio limpio. La lista de funcionalidades es JSON y no Markdown porque es menos probable que el modelo la sobrescriba. La palabra “harness” aparece por todo el texto como un sustantivo corriente. Nadie ha nombrado todavía la disciplina.
5. 23 ene 2026El sustantivo ya es corriente en un segundo laboratorio — y no necesita defensa. Michael Bolin, de OpenAI, al describir cómo funciona el bucle del agente Codex, suelta la palabra de pasada: esperamos que esta entrada te dé una buena idea del papel que juega nuestro agente (o “harness”) al hacer uso de un LLM. Un paréntesis, como el más llano de dos nombres para la misma cosa — dos semanas antes de que alguien nombrara la disciplina.
6. 4 feb 2026Y a estas alturas, ninguna glosa. Celia Chen, de OpenAI, escribe que la aplicación web, la CLI, la extensión del IDE y la app de macOS están “todas impulsadas por el mismo harness de Codex—el bucle y la lógica del agente que subyacen a todas las experiencias de Codex.” Ya no hay paréntesis. Es sencillamente la palabra para esa cosa.
7. 5 feb 2026La expresión se acuña, un día después, por alguien que no quería acuñarla. Mitchell Hashimoto, al relatar su propia adopción de herramientas de IA, llega al paso cinco — Engineer the Harness — y necesita una palabra: no sé si existe ya un término ampliamente aceptado en el sector para esto, pero he acabado llamándolo “ingeniería de harness”. Y añade: no necesito inventar ningún término nuevo aquí; si existe otro, me subo al carro. Lo que él entiende por ello es un AGENTS.md y unos cuantos scripts — cada línea del archivo ganada por un mal comportamiento del agente que ha visto de verdad.
8. 10 mar 2026La palabra queda tomada, y agrandada enormemente. Vivek Trivedy, de LangChain, publica The Anatomy of an Agent Harness, define Agente = Modelo + Harness y deriva cada componente hacia atrás a partir de un comportamiento: sistemas de archivos para el estado duradero, bash para la autonomía sin herramientas preconstruidas, sandboxes para tener un sitio seguro donde actuar. Treinta y tres días después de la acuñación, la misma expresión abarca ya todo lo que no es el modelo. Esta es la entrada que cita toda fuente posterior, y la definición que ninguna de ellas cambia.
9. 2 abr 2026El lado del usuario cobra forma. Birgitta Böckeler, de Thoughtworks, divide el harness en guías que dirigen antes de que el agente actúe y sensores que observan después, cada uno computacional o inferencial. En un recuadro escribe la frase que la enfrenta a todos los demás: un harness de usuario es una forma específica de ingeniería de contexto.
10. 13 may 2026Se convierte en un programa de investigación. Hailin Zhong y Shengxin Zhu publican en arXiv una formalización de dieciséis páginas: once responsabilidades de componente, una escalera de cuatro niveles de H0 a H3 y una propuesta de juzgar la ejecución de un agente por las pruebas que deja y no por si apareció un parche.
11. 15 may 2026La práctica consigue su regla de una línea. Addy Osmani, en O'Reilly Radar: cada vez que descubres que un agente comete un error, te tomas el tiempo de idear una solución para que el agente no vuelva a cometerlo nunca. Atribuye la acuñación a Trivedy.
12. 17 jun 2026Un proveedor traza la frontera. Databricks publica una explicación con ocho bloques constructivos, siete modos de fallo y una tabla que sitúa las tres disciplinas en una jerarquía: la ingeniería de prompts y la de contexto viven ambas dentro de la ingeniería de harness.
13. 13 ago 2026La enciclopedia se pone al día — cinco meses después del bautizo. El artículo Agent harness de Wikipedia recibe su última edición, con una sección que reconoce que nadie está seguro de quién lo nombró y una cita que fecha en 2026 la entrada de Anthropic de noviembre de 2025.

El argumento

Quién lo nombró, y un desacuerdo que sigue abierto La cuestión del mérito tiene respuesta. La de la frontera, no.

Lo que añaden otros

Qué se construye en la práctica Böckeler da la forma; Anthropic da el ejemplo resuelto.

1. 1Pon guías delante del agenteControles anticipativos: archivos de instrucciones, skills, modificaciones de código, un script de arranque. Se adelantan al comportamiento que no quieres y dirigen antes de que el agente actúe. Un harness que solo tenga esto nunca llega a saber si sus reglas funcionaron.
2. 2Pon sensores detrásControles retroactivos: pruebas, linters, comprobadores de tipos, un agente revisor. La observación más afilada de Böckeler es que un sensor debería escribir para su lector — un mensaje de linter que le dice al modelo cómo arreglar la cosa es una forma positiva de inyección de prompts. Un harness que solo tenga esto repite sus errores.
3. 3Sé consciente de cuál de los dos tipos estás usandoLos controles computacionales son deterministas y rápidos — pruebas, linters, análisis estructural, de milisegundos a segundos, fiables. Los inferenciales son semánticos — revisión por IA, “LLM como juez” — más lentos, más caros y no deterministas. Los sensores computacionales baratos pueden ejecutarse en cada cambio; los inferenciales tienen que ganarse su sitio.
4. 4Escribe el estado donde el modelo no se lo vaya a comerEl ejemplo resuelto de Anthropic es el consejo más concreto que se ha encontrado en ninguna parte: una lista de funcionalidades con más de 200 descripciones de extremo a extremo, todas empezando como fallidas, que los agentes pueden editar solo cambiando un campo passes. Es JSON y no Markdown porque, de forma medible, es menos probable que el modelo sobrescriba JSON. Más un archivo de progreso y un commit de git al final de cada sesión.
5. 5Convierte cada error en una reglaLa regla de Hashimoto — la frase para la que se acuñó el término, y lo más parecido a un método que tiene este campo: tratar los errores como señales permanentes, no como malas ejecuciones que hay que reintentar. Cada uno se gana una línea en el archivo de instrucciones, una comprobación en el hook de pre-commit, un aviso en el agente revisor. Solo añades una restricción cuando has visto un fallo real — lo que evita que al harness le crezcan reglas que nadie necesitaba.

¿Funciona algo de esto? Las pruebas, calificadas Dos de estas mantienen quieto el modelo. Una no.

Conclusión

Qué llevarse de esto Cinco cosas, en el orden en que importan.