Ingeniería de harness para agentes de IA: cómo construir el sistema alrededor del modelo

Por qué un modelo no basta

Los modelos de lenguaje generan texto a partir de la información que reciben. Esa simplicidad implica varias limitaciones prácticas cuando les pedimos ejecutar trabajo real en un proyecto de software:

• No saben qué archivos existen en un repositorio salvo que se los muestres.
• No pueden ejecutar pruebas, abrir una base de datos o navegar por la web por sí mismos.
• No mantienen estado entre sesiones salvo que se lo proveas explícitamente.
• Pueden declarar tareas como completadas cuando en realidad fallaron.
• Si no hay límites, pueden intentar acciones no deseadas.
• Tienen un límite de contexto: demasiado texto dispersa la atención.

Un harness aborda cada una de estas limitaciones proveyendo el entorno, las herramientas y las reglas necesarias para que un agente sea realmente útil y seguro.

¿Qué es un harness de agente?

Un harness conecta el modelo con la información y las herramientas, coordina los pasos de una tarea y verifica los resultados. Dependiendo del sistema, un harness puede incluir:

• Instrucciones y reglas del proyecto (un punto de entrada claro como AGENTS.md).
• Mecanismos de recuperación de contexto y memoria.
• Herramientas controladas: terminal, navegador, base de datos, linters.
• Un entorno controlado donde ejecutar acciones (sandbox).
• Flujo de trabajo con pasos, aprobaciones y reintentos.
• Pruebas, evaluaciones y registros (logs) que permiten verificar resultados.

El modelo propone acciones; el harness le da capacidades y valida lo que ocurrió. Productos distintos pueden usar el mismo modelo y comportarse muy distinto según cómo esté construido su harness —una razón clave por la que la experiencia práctica varía tanto entre herramientas.

Prompt, contexto y harness engineering: diferencias prácticas

Es útil distinguir tres capas relacionadas:

• Prompt engineering: se ocupa de cómo formular la instrucción al modelo.
• Context engineering: decide qué información específica verá el modelo en cada momento.
• Harness engineering: diseña todo lo demás: herramientas, permisos, runtime, verificación y estado.

Un prompt puede pedir ejecutar pruebas, pero no puede correrlas. El harness debe exponer un comando de testeo y reportar el resultado. Un prompt puede instruir seguir una arquitectura; el harness puede facilitar la documentación relevante y forzar límites mediante linters o pruebas automáticas.

El bucle del agente

El harness no invoca al modelo una sola vez: ejecuta un ciclo repetitivo:

1. Construye o actualiza el contexto con la información más reciente.
2. Envía ese contexto al modelo y recibe una propuesta de acción.
3. Ejecuta la acción en un entorno controlado y comprueba el resultado.
4. Registra lo sucedido y decide si repetir, solicitar ayuda humana o detenerse.

El ciclo termina cuando las verificaciones pasan o cuando se alcanza un límite (por ejemplo, un tope de pasos). Importante: el modelo puede decir que terminó, pero es el harness quien decide si las pruebas efectivamente pasaron.

Las seis capas de un harness

Aunque el diseño depende del caso de uso, la mayoría de harnesses incluyen seis capas clave:

1. Instrucciones

   • Un punto de entrada claro (por ejemplo, AGENTS.md) donde se indique cómo navegar el proyecto, qué documentos son canónicos y qué verificaciones son obligatorias. Esta guía debe ser concisa y apuntar a documentación mantenida.

2. Contexto

   • No todo el contexto es útil; se requiere elegir qué archivos o fragmentos exponer. Técnicas comunes: búsqueda y recuperación selectiva, resumen de salidas largas, compactación de historiales largos y archivos de notas con hallazgos clave.

3. Herramientas

   • Terminal, ejecutores de tests, navegadores controlados, linters, y clientes de base de datos que el harness controla. Deben ofrecer interfaces seguras y auditables.

4. Entorno de ejecución (sandbox)

   • Ejecutar acciones en un entorno restringido evita cambios no deseados y limita el impacto de errores. Aquí se define qué operaciones son de solo lectura y cuáles requieren aprobación.

5. Flujo y control de estado

   • Gestión de pasos, límites de iteraciones, checkpoints y la capacidad de guardar progreso para reanudar tareas largas.

6. Verificación y registro

   • Pruebas automatizadas, evaluaciones y logs que permiten a un tercero (o al mismo harness) comprobar si una acción cumplió los criterios.

Seguridad y control de costos

Seguridad y costos atraviesan todas las capas. Entre los controles habituales están:

• Permisos mínimos: exponer solo lo necesario, preferiblemente en modos de solo lectura.
• Límites de recursos: tope de pasos, tiempo de ejecución y uso de llamadas al modelo.
• Aprobaciones humanas para acciones sensibles (p. ej., despliegues o cambios en producción).
• Auditoría y logs: conservar registros que expliquen por qué el agente tomó cierta acción.

Para equipos latinoamericanos, donde presupuestos de nube y requisitos regulatorios pueden ser una preocupación, diseñar límites claros y una estrategia de rollback es especialmente relevante.

Mini-harness práctico: qué incluir y por qué

Un harness pequeño y efectivo puede centrarse en unas pocas garantías esenciales:

• Sandbox: para ejecutar comandos sin afectar la base de código real.
• Pruebas en modo read-only: ejecutar tests que no modifiquen el estado y reportar resultados.
• Límite de pasos: evitar bucles largos y consumo inesperado.
• Guardado de progreso: checkpoints en archivos que el agente pueda re-leer.
• Verificación final: una comprobación que confirme que los tests pasaron y que las modificaciones (si hubo) cumplen criterios.

Este conjunto mínimo permite que un agente escriba o modifique código, pruebe cambios y responda con evidencia sobre su funcionamiento, sin permisos excesivos.

Cómo mejorar un harness con el tiempo

Los harnesses tienen vida útil: a medida que cambian los proyectos y las herramientas, deben evolucionar. Algunas prácticas de mejora:

• Añadir más tests automáticos que reflejen casos reales del producto.
• Afinar la recuperación de contexto para priorizar lo verdaderamente relevante.
• Medir y limitar costos de llamadas al modelo, ajustando tamaños de contexto y frecuencia de invocación.
• Introducir sub-agentes para tareas especializadas y recuperar solo resúmenes.
• Automatizar aprobaciones con reglas claras y permitir intervención humana cuando el riesgo aumenta.

Conclusión

Diseñar un harness es tan importante como elegir el modelo. Mientras el modelo ofrece capacidad de razonamiento y generación, el harness define los límites, las herramientas y las verificaciones que transforman esas respuestas en resultados útiles y confiables. Para equipos en América Latina —y en cualquier lugar— un harness bien pensado protege recursos, mejora la productividad y reduce riesgos operativos, permitiendo que los agentes de IA agreguen valor real al flujo de trabajo de desarrollo.

Preguntas frecuentes (breve)

• ¿Puedo usar un harness sin tests? Técnicamente sí, pero sin pruebas automatizadas no hay forma objetiva de verificar resultados.
• ¿Qué es más importante: prompt o harness? Ambos; el prompt guía al modelo, pero el harness determina qué puede hacer y comprobar.
• ¿Es necesario un entorno de solo lectura? Para operaciones exploratorias, sí; para cambios en producción, se requieren aprobaciones adicionales.