Qué es harness engineering: el arnés que hace útil al modelo
Qué es harness engineering: mejorar el arnés del LLM (contexto, tools, hooks, verificación) sin cambiar el modelo. Caso LangChain en Terminal Bench 2.0.
Harness engineering es la disciplina de diseñar y mejorar el arnés alrededor de un modelo de lenguaje: cómo le entregas contexto, qué herramientas tiene, qué reglas se ejecutan siempre y cómo se corrigen los errores en bucle. El modelo razona; el harness lo vuelve fiable en producción. LangChain lo demostró en Terminal Bench 2.0: mismo gpt-5.2-codex, puntuación de 52,8 % a 66,5 % solo tocando el arnés.
Si has visto el mismo modelo comportarse genial en un chat y mal en tu agente de código, casi seguro que el problema no era el cerebro. Era el envoltorio.
Navegación rápida
Salta directamente a lo que buscas:
Qué es harness engineering | Harness vs modelo | Qué incluye un harness | Tres niveles: prompt, contexto, harness | Caso LangChain | En producción | MCP, Claude Code y Converly | FAQ
Qué es harness engineering
En la fórmula que repite LangChain: agente = modelo + harness. El modelo fija el techo de capacidad. El harness determina qué tan cerca llegas de ese techo en un entorno real.
Harness engineering es el trabajo sistemático de mejorar ese arnés: prompts de sistema, entrega de contexto, herramientas, middleware (hooks alrededor de llamadas al modelo y a herramientas), memoria, validaciones, corrección de errores y orquestación del bucle agéntico. No sustituye al modelo; lo moldea para tareas concretas: rendimiento en benchmarks, eficiencia de tokens, latencia, tasa de éxito en producción.
La idea no nació ayer. Mitchell Hashimoto la popularizó en su relato sobre adopción de IA en desarrollo. LangChain la convirtió en caso de estudio con números públicos. Y en el ecosistema de coding agents — Claude Code, Cursor, Codex CLI — la estás practicando aunque no uses el nombre: cada regla en CLAUDE.md, cada hook, cada servidor MCP es una pieza del harness.
Para mí, la definición práctica es esta: si cambias solo el texto de un turno, haces prompt engineering; si cambias cómo se ensambla y entrega el contexto, haces context engineering; si cambias el sistema entero alrededor del modelo — herramientas, bucles, guardrails, telemetría — haces harness engineering.
Harness vs modelo
El mismo gpt-5.2-codex, Claude Opus o Gemini puede parecer un genio en la web de Anthropic y un becario torpe en tu repo. Eso no invalida el modelo; expone el harness.
| Dimensión | Modelo | Harness |
|---|---|---|
| Qué es | Pesos, razonamiento, conocimiento general | Runtime, políticas, herramientas, bucles de control |
| Quién lo controla | Proveedor (OpenAI, Anthropic, Google…) | Tú, tu equipo, tu plataforma |
| Cómo mejoras | Cambiar de versión, fine-tuning, routing multi-modelo | Prompts, MCP, hooks, middleware, evals, tracing |
| Efecto típico | Sube el techo de capacidad | Sube el suelo de fiabilidad |
| Coste de iterar | Alto (nuevo modelo, nueva factura) | Bajo (config, código, reglas versionadas) |
LangChain lo dejó claro en su experimento: mantuvieron fijo gpt-5.2-codex y solo movieron tres palancas — prompt de sistema, herramientas y middleware. Resultado: +13,7 puntos en Terminal Bench 2.0, de 52,8 % a 66,5 %, saltando de fuera del Top 30 al Top 5 del leaderboard. Sin fine-tuning, sin cambiar de modelo.
Eso encaja con lo que veo en proyectos reales. Un cliente migra de Sonnet a Opus y espera magia; la mejora real llega cuando añaden verificación automática, contexto de entorno al arrancar la sesión y hooks que impiden salir sin pasar tests. El modelo importa. Pero en producción, el harness suele ser la palanca más barata y más predecible.
Qué incluye un harness
Piensa en el harness como todo lo que rodea al LLM para convertir texto en acción fiable. LangChain comprime su espacio de optimización en tres perillas; en la práctica el arnés es más ancho:
Entrega de contexto
Cómo llega al modelo la información relevante: estructura de directorios, dependencias instaladas, restricciones de tiempo, especificación de la tarea, documentación interna. No es «escribir un prompt largo»; es un mecanismo de onboarding que reduce que el agente pierda tokens descubriendo lo obvio.
Herramientas y bibliotecas
File system, bash, búsqueda, APIs, servidores MCP. Sin herramientas tienes un chat. Con herramientas tienes un agente de IA. El harness decide qué hay en la caja y con qué permisos.
Memoria y estado
Conversación, resúmenes, índices RAG, MCPs de memoria frente a metacognición. El harness define qué persiste entre turnos y qué se olvida a propósito para no inflar la ventana.
Validaciones y corrección de errores
Tests, linters, checklists antes de terminar, bucles build-verify-fix. El modelo tiende a declarar victoria tras la primera solución plausible; el harness empuja a verificar contra la spec, no contra el propio código.
Orquestación y middleware
Hooks en puntos concretos del bucle: antes de usar una herramienta, al salir, al detectar un patrón repetitivo. En Claude Code eso son los hooks. En LangChain, PreCompletionChecklistMiddleware o LoopDetectionMiddleware. Misma idea: política determinista donde el prompt es probabilístico.
Telemetría y mejora continua
Traces, evals, benchmarks repetibles. LangChain usó LangSmith para ver modos de fallo a escala y alimentar un skill de análisis de traces. Sin medición, harness engineering se convierte en intuición.
Tres niveles: prompt, contexto y harness
Estos tres términos se solapan en conversaciones de LinkedIn, pero resuelven capas distintas del stack. La tabla resume cómo los separo cuando diseño un agente:
| Nivel | Qué optimizas | Ejemplo | Límite |
|---|---|---|---|
| Prompt engineering | Instrucciones en el turno o system prompt | «Responde en JSON», «sé conciso», few-shot | El modelo puede ignorarlo; no hay enforcement |
| Context engineering | Qué información entra y en qué orden | Mapa de directorios al inicio, spec de tarea, warnings de timeout | Mejora comprensión, pero no garantiza comportamiento |
| Harness engineering | Sistema completo alrededor del LLM | Hooks, middleware, herramientas, bucles de verificación, evals | Más trabajo inicial; comportamiento repetible |
Visualmente, el flujo que uso con clientes se parece al diagrama de portada: Usuario → Cliente (IDE/CLI) → Backend → capas de prompt, contexto y harness → Modelo. Cada capa responde a una pregunta distinta:
- Prompt: ¿Qué le pido que haga?
- Contexto: ¿Qué necesita saber para hacerlo bien?
- Harness: ¿Qué ocurre siempre, con o sin cooperación del modelo?
Si algo debe ocurrir siempre — formatear, bloquear rm -rf, ejecutar tests antes de cerrar — no lo dejes solo en un prompt. Ponlo en el harness.
Caso LangChain: Terminal Bench 2.0
La mejor prueba pública hasta ahora es el artículo Improving Deep Agents with harness engineering de LangChain (febrero 2026). Resumo el experimento porque los números son contundentes.
Setup: agente deepagents-cli, benchmark Terminal Bench 2.0 (89 tareas: ML, debugging, biología…), orquestación con Harbor y sandboxes Daytona. Modelo fijo: gpt-5.2-codex.
| Fase | Cambio principal | Puntuación |
|---|---|---|
| Baseline | Prompt genérico + herramientas estándar | 52,8 % (fuera del Top 30) |
| Iteración intermedia | Build-verify, contexto de entorno, anti-bucles, reasoning high | 63,6 % |
Solo xhigh reasoning | Demasiado compute → timeouts | 53,9 % |
| Final | «Reasoning sandwich» xhigh-high-xhigh + mejoras anteriores | 66,5 % (Top 5) |
Qué movió la aguja
Build & self-verify. LangChain estructuró el prompt en cuatro fases: planificar, construir, verificar (contra la spec, no contra el código propio), corregir. Añadieron PreCompletionChecklistMiddleware: intercepta al agente antes de salir y le recuerda verificar.
Contexto de entorno. LocalContextMiddleware mapea directorios y detecta herramientas (Python, etc.) al arrancar. Menos tokens quemados en descubrimiento; menos errores por rutas mal interpretadas.
Anti doom loops. LoopDetectionMiddleware cuenta ediciones por archivo y avisa tras N repeticiones. Los modelos entran en bucles miopes; el harness empuja a replantear.
Presupuesto de razonamiento. Más reasoning no siempre es mejor: solo xhigh empeoró por timeouts. La heurística ganadora fue gastar más compute en planificación y verificación, menos en implementación — el «reasoning sandwich».
Lo relevante para tu equipo: 13,7 puntos de mejora sin tocar el modelo. Eso es harness engineering medido, no opinión.
Harness engineering en producción
En Converly no vendemos benchmarks; desplegamos agentes que atienden llamadas, cualifican leads y ejecutan flujos de negocio. Ahí el harness no es un experimento de leaderboard — es lo que separa un demo de un sistema que aguanta el lunes por la mañana.
Principios que aplico
1. Medir antes de opinar. Traces, logs de herramientas, tasa de éxito por tipo de tarea. LangChain usó LangSmith; tú puedes usar lo que tengas, pero necesitas ver dónde falla el bucle, no solo leer la respuesta final.
2. Separar probabilístico de determinístico. Instrucciones en CLAUDE.md para convenciones de estilo. Hooks para seguridad y QA. La anatomía del setup de proyecto en Claude Code es básicamente un harness versionado en git.
3. Contexto como producto. No esperes que el agente «descubra» tu infra. Inyecta mapas, restricciones, criterios de evaluación y presupuestos de tiempo cuando el entorno los tenga.
4. Bucle de verificación explícito. En código: tests. En voz: confirmación de datos críticos. En contenido: checklist contra la spec del cliente. El patrón build-verify-fix de LangChain generaliza fuera de Terminal Bench.
5. Diseñar para el modelo de hoy, no para el de 2028. Middleware anti-bucles y checklists de salida son parches conscientes. Cuando los modelos mejoren, algunos desaparecerán. Hoy, sin ellos, pierdes fiabilidad.
6. Evitar overfitting al benchmark. LangChain advierte: cambios que arreglan una tarea pueden regresar otras. Human-in-the-loop en la revisión de propuestas del trace analyzer ayuda a generalizar.
Cuándo invertir en harness vs cambiar de modelo
| Señal | Prioriza harness | Prioriza modelo |
|---|---|---|
| Fallos por no seguir proceso | ✓ | |
| Fallos por no entender dominio complejo | ✓ | |
| Mismo error repetido en traces | ✓ | |
| Respuestas correctas pero lentas/caras | ✓ (routing, reasoning budget) | ✓ (modelo más pequeño) |
| Alucinaciones factuales profundas | Parcial (RAG, tools) | ✓ |
En coding agents concretamente, muchos equipos suben de modelo antes de arreglar verificación y contexto de entorno. LangChain sugiere lo contrario: exprime el harness del modelo que ya pagas.
MCP, Claude Code y Converly
Si ya usas Claude Code, gran parte de tu harness está montado sin llamarlo así:
| Pieza | Rol en el harness |
|---|---|
CLAUDE.md / reglas de proyecto | Prompt + contexto persistente |
| Servidores MCP | Capa de herramientas (APIs, datos, acciones) |
| Hooks | Middleware determinístico en eventos del bucle |
| Subagentes / skills | Delegación y especialización |
| Converly LM | Routing de modelo: tareas rutinarias a local, razonamiento pesado a cloud |
MCP no es el harness entero; es la caja de herramientas. Los hooks son el cinturón de seguridad. Juntos forman el arnés que convierte un LLM en un agente operativo.
En Converly aplicamos la misma lógica fuera del IDE: agentes de voz con validación de datos antes de cerrar una cita, recordatorios con bucles de confirmación, integraciones MCP para CRM y calendario. El modelo elige palabras; el harness garantiza que no cuelgue sin despedirse ni confirme una hora que no existe en el calendario.
La lección de LangChain para nosotros es directa: antes de cambiar de proveedor o de modelo, audita el harness. A menudo el 80 % del gap está en verificación, contexto y middleware — no en el peso del siguiente release.
Preguntas frecuentes
¿Harness engineering es lo mismo que prompt engineering?
No. Prompt engineering optimiza instrucciones textuales. Harness engineering optimiza el sistema completo: herramientas, hooks, entrega de contexto, bucles de corrección, evals y orquestación. El prompt es una pieza del arnés, no el arnés entero.
¿Necesito LangChain para hacer harness engineering?
No. LangChain popularizó el término y publicó el caso Terminal Bench, pero la disciplina es agnóstica. En Claude Code usas hooks, MCP y configuración de proyecto. En otros stacks, middleware, guardrails y pipelines de eval. El patrón importa más que el framework.
¿Qué mejoró exactamente el agente de LangChain en Terminal Bench 2.0?
Con el mismo gpt-5.2-codex, pasaron de 52,8 % a 66,5 % (+13,7 puntos) solo cambiando prompt de sistema, herramientas y middleware: bucles build-verify, inyección de contexto de entorno, detección de bucles y presupuesto adaptativo de reasoning. Fuente: post oficial de LangChain.
¿Cuándo debería cambiar de modelo en lugar de mejorar el harness?
Cuando el cuello de botella es comprensión profunda de dominio, razonamiento multi-paso que el harness no puede compensar, o límites duros del contexto. Si los traces muestran que el agente entiende la tarea pero no sigue proceso, verifica mal o se queda en bucles, arregla el harness primero.
¿Los guardrails del harness quedarán obsoletos cuando mejoren los modelos?
Probablemente algunos sí — checklists forzados, anti-bucles agresivos. Otros no — entrega de contexto, herramientas, políticas de seguridad, evals. Hashimoto y LangChain coinciden: diseña para las limitaciones de hoy, pero separa lo temporal de lo estructural.
Lecturas relacionadas
- ¿Qué son los agentes de IA?
- ¿Qué es un servidor MCP?
- Guía de hooks de Claude Code
- Metacog vs memory MCPs
- Recortar tu factura de Claude Code con Converly LM
- Anatomía del setup de proyecto en Claude Code
- Finance Skills: Claude para análisis financiero
- ¿Qué es el prompt engineering?
- 3 trucos para optimizar tokens (Fable 5)
- 75 años de evolución de la IA en 5 saltos
- Vocabulario de IA: 20 conceptos esenciales
- CMAXHGuardian: agente Blue Team
Última actualización: junio de 2026. Cifras de Terminal Bench 2.0 según el artículo de LangChain sobre harness engineering.
Artículos relacionados
3 trucos para optimizar tokens en Claude Code (Fable 5)
Optimiza tokens y ventana de contexto en Claude Code tras Fable 5: /compact, desglose de contexto y conectores activos. Ahorro acumulativo para uso intensivo diario.
¿Qué son los agentes de IA? La explicación en palabras llanas
Un agente de IA es tu modelo de siempre dentro de un bucle, con una meta y herramientas. Te explico qué son, cómo se diferencian de un workflow y por dónde empezar.
Implementar WebMCP en un sitio web de reclutamiento
Cómo implementar WebMCP en un sitio de reclutamiento: registrar herramientas con entradas tipadas, dejar de scrapear HTML y exponer tu web como herramientas para agentes de IA.