Durante 2026 la palabra harness se ha colado en todas las conversaciones sobre agentes de IAAI AgentsSistemas que executan tarefas de varios pasos sen supervisión constante. Escóitase falar do «harness de Claude Code», de «cambiar de harness» ou de que «o harness importa máis que o modelo». Ata naceu unha disciplina con nome propio, harness engineering, cuxa paternidade se disputan un artigo de Mitchell Hashimoto de febreiro de 2026 e outro de LangChain de marzo. Parece un termo recén inventado, pero non o é: os electricistas de automoción levan un século montando harnesses e os programadores levan décadas escribíndoos. O único novo é a que lle aplicamos.
Que é un harness, nunha frase
A definición máis clara é a que usa Anthropic na súa guía de avaliación de axentes: «un harness de axente (ou scaffold) é o sistema que permite a un modelo actuar como axente: procesa as entradas, orquestra as chamadas a ferramentas e devolve os resultados». Dito en curto: é todo o que rodea o modelo para que poida traballar. O bucle que decide cando volver chamalo, as ferramentas que pode usar, o contexto que lle chega en cada paso, os permisos que o limitan e as trazas que rexistran o que fixo.
LangChain resúmeo cunha ecuación que se fixo popular este ano: axente = modelo + harness. Un modelo en bruto non é un axente; convértese nun cando un arnésArnésLa infraestrutura que rodea o modelo e o converte en axente: bucle, ferramentas, contexto, permisos e trazas lle dá estado, execución de ferramentas, bucles de realimentación e límites que se poden facer cumprir.
A imaxe que mellor o explica: o modelo é o motor e o harness é o resto do coche. Chasis, transmisión, freos, dirección, cadro de mandos. Un motor excelente sobre unha mesa non te leva a ningures, e o mesmo motor rende de forma moi distinta segundo o vehículo onde o montes.
De onde vén o nome
Harness significa arnés: as correas que suxeitan a un animal de tiro, ou o equipo que impide caer a quen traballa en altura. A enxeñaría xa se quedara coa palabra dúas veces antes de que chegase á intelixencia artificial.
O arnés de cables
En automoción y aviación, un wiring harness es el mazo de cables que recorre el vehículo y conecta el motor con el cuadro, las luces, los sensores y la centralita: cables agrupados y atados con una funda resistente, rematados con conectores. Se popularizó en la industria del automóvil en los años veinte, cuando quedó claro que los cables sueltos no sobrevivían a la vibración, la abrasión y la humidade. Un avión moderno leva dentro mazos que, estirados, sumarían quilómetros.
Lo interesante para a nosa analoxía é que o arnés non fai nada por si mesmo: conecta, ordena e protexe o que xa existe. Sen el, ningunha peza fala coas demais.
O arnés de probas
En software, un test harness é o conxunto de stubs e drivers que rodea a unha peza de programa para poder executala de forma controlada: inxectalle entradas, recolle saídas, compáraas co esperado e deixa un informe. É infraestrutura de imitación que permite automatizar as probas, e é vocabulario corrente en enxeñaría de software desde hai décadas.
É exactamente a mesma idea que hoxe se aplica aos axentes: unha estrutura externa que suxeita á peza, a alimenta e observa o que fai. Cando os modelos de linguaxe comezaron a usar ferramentas e a encadear pasos, facía falta un nome para o código que os envolve. O termo estaba esperando no armario.
Dous sentidos que convén non mesturar
- Harness de execución (agent harness): o contorno que fai funcionar ao axente en produción. É o sentido dominante e o que se usa cando alguén di «o harness de Claude Code». Microsoft converteuno incluso en nomenclatura oficial de produto: na súa documentación de setembro de 2026 define o harness como «o andamiaxe de execución que converte un modelo de linguaxeModelo de linguaxe de grande tamaño (LLM, Large Language Model)Modelo de linguaxe grande, a base dos chatbots actuais nun axente capaz de traballar».
- Harness de avaliación (evaluation harness): o andamiaxeAndamiaxeA estrutura de código que conecta e orquestra a un axente de IA que executa unha batería de probas contra un modelo para medilo de forma reproducible. É o herdeiro directo do test harness clásico.
Son curmáns irmáns: en ambos casos hai unha estrutura externa que suxeita ao modelo e observa o seu comportamento. E en ambos casos, quen constrúe o arnés condiciona o resultado.
Por que o harness decide o resultado
Esta es la parte que le interesa a una empresa, y en 2026 ha dejado de ser una opinión para convertirse en un dato.
Mismo modelo, distinto arnés, otro resultado. En febrero de 2026, LangChain publicó un experimento limpio: congelaron el modelo (GPT-5.2-Codex) y trabajaron solo el harness. Su puntuación en Terminal-Bench 2.0 pasó del 52,8 % al 66,5 %, casi catorce puntos, saltando de fuera del top 30 al top 5 de la clasificación. Su propio resumen: «solo cambiamos el harness». Lo que tocaron fueron bucles de auto-verificación, inxección de contexto do entorno, detección de bucles infinitos e análise automática de trazas. Nada de eso é o modelo.
As táboas de clasificación miden parellas, non modelos. Un estudo de setembro de 2026 auditou 254 envíos ao leaderboard de SWE-bench e atopou o dato máis eloquente do ano: para un mesmo modelo, cambiar de scaffold move o resultado ata 29,8 puntos porcentuais, mentres que todo o top 30 cabe en 8,8 puntos. Dito doutro modo: a diferenza entre arneses é máis de tres veces maior que a distancia entre os trinta mellores sistemas do mundo. Os seus autores piden que se declare sempre a parella modelo-arnés.
Un artigo de posición de maio de 2026 di sen rodeos que o harness de execución «é a miúdo un determinante máis forte do rendemento do axente que o modelo ao que envolve», e mentres non se publique que arnés se usou, as comparacións de leaderboard deberían tratarse como incompletas e potencialmente enganosas. A propia Anthropic formúlao de maneira máis sinxela: «cando avaliamos "un axente", estamos avaliando o harness e o modelo traballando xuntos».
E custa diñeiro. Nun experimento de Anthropic de marzo de 2026 sobre desenvolvemento de aplicacións de longa duración, o mesmo encargo lanzado sen arnés resolveuse en 20 minutos e 9 dólares, mentres que co arnés completo tardou case seis horas e custou uns 200 dólares. A diferenza non é o prezo: é que o primeiro era un borrador e o segundo, unha aplicación rematada. O arnés é o que converte unha demo en traballo.
A consecuencia práctica é incómoda para o marketing do sector: cando comparas dous produtos de IA, boa parte da diferenza non está no modelo, que moitas veces é literalmente o mesmo. O modelo compráse; o arnés constrúese.
Anatomía de un harness
Un arnés digno dese nome resolve seis cousas:
- O bucle. Chamar ao modelo, executar o que pida, devolverlle o resultado e repetir ata terminar ou ata esgotar o límite. Fácil de describir, difícil de facer ben: aquí se deciden os custos e os bloqueos.
- As ferramentas. O que o axente pode facer de verdade: ler correo, consultar o ERP, crear un evento, abrir unha incidencia. Como se describen e se nomean cambia o rendemento tanto como cambiar de modelo.
- O contexto. Que entra na xanela de contexto en cada paso e que se resume, se descarta ou se garda fóra. É o pescozo de botella de todas as tarefas longas.
- Os permisos. Que pode facer sen preguntar e que esixe confirmación humana. É a diferenza entre un asistente útil e un incidente.
- A memoria e o estado. Que sobrevive entre pasos e entre execucións, e se unha tarefa interrompida se retoma onde quedou. Anthropic identifica xusto aquí o problema central dos axentes de longa duración: traballan en sesións separadas e cada sesión nova comeza sen recordo do anterior.
- A observabilidade. Trazas, rexistros e reprodución paso a paso. Sen isto non se depura un axente: adiviñase.
Hai un sétimo detalle pouco intuitivo que merece mención: os axentes son malos xuíces do seu propio traballo. Cando se lles pide avaliar o que acaban de producir, tenden a eloxialo aínda que a calidade sexa mediocre. Por iso os bos arneses separan o axente que traballa do axente que xulga.
Se queres a versión curta e ligada co resto do vocabulario, tena na ficha Harness da NAiOS Wiki, xunto a Scaffold, Loop engineering e Guardrails.
Por que isto xustifica pedir permiso
Hay una razón dura detrás de la manía de los arneses serios por pedir confirmación. El benchmark τ-bench, que mide agentes conversando con clientes y aplicando reglas de negocio, encontró que agentes punteros resolvían menos del 50 % de las tareas, y que al repetir la misma tarea ocho veces acertaban las ocho en menos del 25 % de los casos. La conclusión no es que los agentes no sirvan: es que la consistencia no se da por supuesta, y por eso las acciones con consecuencias no deberían ejecutarse sin alguén mirando.
Como xestiona NAiOS o harness
En NAiOS non usamos un modelo: usamos o mellor dispoñible en cada momento e cambiámolo cando aparece un mellor. O que non cambia é o arnés. Estes son os módulos que o forman.
NAiOS Agents: o bucle
NAiOS Agents é a capa que converte o chat reactivo en axentes que traballan sós. Executa un bucle durable plan→act→observe cun worker de fondo, de xeito que unha tarefa longa sobrevive a un reinicio e retómase onde estaba: xusto o problema de memoria entre sesións do que falabamos. Inclúe execución manual ou programada (por cron ou por evento), memoria e base de coñecemento por axente, delegación a outros axentes, workspace illado e un timeline reproducible para ver, paso a paso, que pensou e que fixo. Iso último é a observabilidade: cando algo sae raro, mírase, non adiviñase.
Connectors e MCP: as ferramentas
Un axente sen ferramentas é un chat con ínfulas. NAiOS Connectors conecta por OAuth máis de mil servizos —Gmail, Slack, GitHub, Calendar, Notion e compañía— e exponos como ferramentas deny-by-default: só chegan ao modelo as dos conectores que ti activaches, illadas por usuario. NAiOS MCP fai o mesmo con calquera servidor MCP que rexistres, clasificando cada ferramenta en lectura ou sensible.
Knowledge Base: o contexto
A RAG Knowledge Base alimenta a xanela de contextoXanela de contextoCantidade de texto que un modelo pode recordar nunha conversa co que sabe a túa empresa: documentos, follas de cálculo, catálogos, audio e vídeo, con busca semántica e consultas SQL xeradas por IA. Un axente que non pode consultar o teu coñecemento improvisa; un que sí, responde cos teus datos.
HITL: os permisos
La regla es fija en toda la plataforma: leer es libre, actuar pide permiso. Las acciones con efectos —enviar un correo, publicar, escribir en un servicio externo, emitir una factura— se detienen en una tarjeta de confirmación que muestra qué se va a hacer y con qué cuenta. Las herramientas de alto riesgo mantienen esa confirmación incluso en agentes auto-aprobados. De dónde viene esa forma de trabajar lo contamos en El origen de HITL.
Catro casos de uso reais
- O peche da mañá. Un axente programado ás 7:00 revisa o correo da noite con NAiOS Mail, clasifica o urxente, cruza cada remitente co CRM e deixache un resumo con borradores de resposta preparados. Ningún se envía sen o teu clic.
- Atención ao cliente que sabe apartarse. En NAiOSOmni, un axente responde por WhatsApp ou Telegram co coñecemento da túa KB e pausa automaticamente en canto unha persoa do equipo entra na conversa. O harness decide cando o axente calla.
- Reunións que deixan tarefas, non notas. Meeting Agent entra na videochamada, transcribe con diarización e saca resumo e action items; o axente convérteos en tarefas asignadas. Todo o traballo aburrido de despois da reunión, feito.
- Vixilancia continua do negocio. Un axente recorrente revisa cada noite tesouraría, stock ou campañas activas e avisa só cando algo se sae do normal. Vixía, non actúa: a decisión segue sendo túa.
Como saber se a túa plataforma ten un bo harness
Catro preguntas para calquera demo, incómodas de responder se o arnés é frouxo:
- Se a tarefa se interrompe a medio, ¿retómase soa ou hai que empezar de cero?
- ¿Podo ver, paso a paso, que fixo o axente a semana pasada e con que datos?
- ¿Que accións pode executar sen preguntarme, e quen decide esa lista?
- Se mañá sae un modelo mellor, ¿podo cambialo sen refacer as miñas automatizacións?
Cando cambias de modelo e todo segue funcionando, é que tiñas un harness. Cando cambias de modelo e se rompe medio sistema, é que tiñas un prompt con sorte.
En resumo
- O harness é o contorno que rodea ao modelo: bucle, ferramentas, contexto, permisos, memoria e trazas. Axente = modelo + harness.
- O nome vén do arnés: o feixe de cables dun vehículo e o test harness do software clásico. O que naceu en 2026 é a disciplina, non a palabra.
- Os datos deste ano son contundentes: mesmo modelo e distinto arnés cambian o resultado máis que escoller outro modelo.
- O modelo compráse e cámbiase; o arnés constrúese, e aí está a diferenza real entre produtos.
- En NAiOS ese arnés ten nome e módulos: Agents para o bucle, Connectors e MCPProtocolo de contexto de modelo (MCP)Protocolo estándar para que los modelos se conecten con herramientas externas para as ferramentas, Knowledge Base para o contexto e HITL para os permisos.
Fontes
- Anthropic, Demystifying evals for AI agents — 9 de xaneiro de 2026. Definición de agent harness e por que unha avaliación mide sempre o modelo e o arnés xuntos.
- LangChain, Improving Deep Agents with harness engineering — 17 de febreiro de 2026. Do 52,8 % ao 66,5 % en Terminal-Bench 2.0 sen tocar o modelo.
- Anthropic, Harness design for long-running application development — 24 de marzo de 2026. Custo e duración con e sen arnés, e por que convén separar quen traballa de quen xulga.
- LangChain, The Anatomy of an Agent Harness — 10 de marzo de 2026. «Axente = modelo + harness» e as pezas que o compoñen.
- Zhang et al., Stop Comparing LLM Agents Without Disclosing the Harness — arXiv, 7 de maio de 2026. O arnés como determinante do rendemento por riba do modelo.
- Liu et al., Coding Agents Have Converged — arXiv, 15 de setembro de 2026. Auditoría de 254 envíos a SWE-bench: 29,8 puntos de variación por arnés fronte a 8,8 puntos de todo o top 30.
- Microsoft, Agent Harness (Microsoft Agent Framework) — actualizado en setembro de 2026. O harness como concepto de produto documentado.
- Yao et al., τ-bench — arXiv, 2024. Fiabilidade dos axentes ao repetir a mesma tarefa.
