Recursos / Artículos / El “harness” importa tanto como el modelo

El “harness” importa tanto como el modelo

Tecnología

Dos equipos pueden usar el mismo modelo y obtener agentes radicalmente distintos. Uno abandona una tarea al primer error de API. El otro conserva el estado, prueba una alternativa, valida el resultado y pide ayuda solo cuando la necesita. La diferencia vive alrededor del modelo.

Ese entorno se suele llamar harness: el conjunto de instrucciones, herramientas, bucle de ejecución, estado, aislamiento, evaluaciones y controles que convierte una capacidad general en un sistema que trabaja.

El modelo no ejecuta solo

Cuando decimos que “el agente ha editado un archivo”, han ocurrido varias decisiones de ingeniería. Una capa le mostró el archivo correcto, una herramienta aplicó el cambio, el entorno limitó el acceso, un bucle devolvió el resultado y quizá una prueba comprobó que seguía funcionando.

El SDK de agentes de OpenAI resume sus primitivas en agentes, transferencias, guardrails, sesiones y trazas (OpenAI Agents SDK). Anthropic describe el harness como el andamiaje que permite al modelo actuar y señala que su diseño altera la forma de descomponer, ejecutar y evaluar trabajos largos (Anthropic).

El modelo sigue siendo importante. Marca el techo de razonamiento y uso de herramientas. El harness determina cuánto de esa capacidad llega de forma fiable al usuario.

Herramientas que no obliguen a adivinar

Una herramienta llamada gestionar_cliente con veinte parámetros opcionales es una invitación al error. Resultan mejores acciones estrechas, nombres inequívocos, esquemas validados y respuestas que distingan éxito, ausencia de datos y fallo temporal.

También importa qué se expone en cada fase. Un agente que está investigando no necesita todavía la función para enviar el informe. Reducir el catálogo baja la ambigüedad y limita acciones prematuras.

Las herramientas deberían ser idempotentes cuando sea posible. Si el agente reintenta después de perder la respuesta, no queremos que cobre dos veces. Cuando la operación no puede ser idempotente, usamos claves de operación, consulta de estado o confirmación humana.

Estado fuera de la conversación

Un trabajo de horas no puede depender de que el modelo “recuerde” en texto libre todo lo que ha hecho. El harness conserva objetivo, plan, pasos, artefactos, decisiones, presupuesto y condiciones de salida en estructuras que el programa puede inspeccionar.

Esto permite reanudar tras una interrupción y evita repetir acciones. También hace posible mostrar progreso sin pedir al modelo que lo reconstruya. En tareas largas, Anthropic propone artefactos estructurados y separación entre planificación, generación y evaluación para que cada ciclo tenga evidencia (Anthropic).

El registro de eventos y el estado actual cumplen funciones distintas. El estado dice dónde estamos; el registro permite entender cómo llegamos. Conviene conservar ambos.

El bucle necesita frenos

“Continúa hasta terminar” no es una estrategia. Un agente puede repetir la misma búsqueda, alternar dos soluciones o seguir refinando un resultado suficiente. El harness establece presupuestos de pasos, tiempo, coste y llamadas a herramientas. También detecta falta de progreso.

Las condiciones de salida deberían ser observables: todas las pruebas pasan, el informe contiene citas para cada afirmación material, no quedan campos obligatorios o un revisor ha aprobado. La autodeclaración del modelo —“tarea completada”— es una señal, no una prueba.

Cuando se alcanza un límite, el sistema debe entregar estado y diagnóstico, no ocultar el problema con una respuesta incompleta. “Faltan dos fuentes porque el repositorio no respondió” permite decidir. “Aquí está el informe” no.

Evaluadores y pruebas en el propio recorrido

En software, el harness puede ejecutar tests, análisis estático y comparación de cambios. En investigación, comprueba citas, cobertura y diversidad de fuentes. En un proceso documental, valida campos, totales y reglas de negocio.

Los evaluadores deterministas deben ir primero: esquemas, permisos, presencia de evidencias, límites numéricos. Los evaluadores basados en modelos son útiles para criterios abiertos, pero necesitan rúbricas, ejemplos y calibración humana.

Anthropic advierte que los agentes multi-turno son más difíciles de evaluar porque un pequeño fallo temprano altera toda la trayectoria (Anthropic). Por eso conviene medir tanto el resultado como el camino: herramienta elegida, argumentos, reintentos, coste y recuperación de errores.

Permisos, aislamiento y aprobaciones

El harness aplica la autoridad real. Una instrucción que dice “no borres archivos” no sustituye un permiso de solo lectura. Las credenciales deben ser mínimas, con ámbito y duración limitados. Los datos y la red del entorno también.

Las acciones de impacto se interrumpen antes de ejecutarse. El mecanismo de intervención humana del SDK de OpenAI permite pausar una ejecución, presentar la llamada propuesta y reanudar después de aprobar o rechazar (OpenAI Agents SDK). La aprobación debe mostrar objeto, efecto y parámetros; “¿permitir herramienta?” aporta poco.

El aislamiento reduce el daño si el modelo interpreta mal una instrucción o un documento contiene contenido hostil. Un entorno temporal, sin secretos innecesarios y con salidas controladas, es una medida de arquitectura, no un consejo al modelo.

Trazas que permitan reproducir

Una respuesta final rara vez explica un fallo. Necesitamos ver qué instrucciones y herramientas recibió el modelo, qué datos recuperó, qué llamadas hizo, cuánto tardaron y qué versión estaba desplegada. El trazado del SDK de OpenAI registra generaciones, herramientas, transferencias y guardrails, y permite añadir eventos propios (OpenAI Agents SDK).

Hay que equilibrar trazabilidad y privacidad. Las trazas pueden contener datos sensibles, de modo que requieren filtrado, acceso restringido y retención definida. Registrar todo sin gobierno crea un nuevo problema.

Cómo comparar modelos sin engañarse

Si al probar un modelo nuevo también cambiamos instrucciones, catálogo de herramientas y número de reintentos, no sabremos qué produjo la mejora. La comparación exige fijar una versión del harness y ejecutar el mismo conjunto de trabajos varias veces, porque el comportamiento no es determinista.

Después evaluamos calidad, tasa de finalización, acciones inválidas, latencia y coste por tarea resuelta. Un modelo barato que necesita cuatro reintentos puede resultar más caro. Uno más capaz puede permitir un harness sencillo; otro pequeño puede rendir bien con enrutamiento y verificadores específicos.

La relación es bidireccional. El harness extrae capacidad del modelo, y el modelo condiciona cuánto andamiaje necesita.

Qué construir primero

Para un agente nuevo priorizaríamos cinco piezas: herramientas estrechas y validadas; estado persistente; límites de ejecución; una prueba verificable de finalización; y trazas reproducibles. Después añadiríamos memoria, subagentes o planificación sofisticada solo cuando los fallos observados lo pidan.

Esta secuencia evita atribuir al modelo problemas del entorno. Si una API devuelve mensajes ambiguos, cambiar de modelo quizá eleve la tasa de acierto, pero arreglar el contrato de la herramienta elimina la ambigüedad para todos.

La carrera por comparar modelos seguirá. Es visible y fácil de resumir en una tabla. El trabajo menos vistoso consiste en diseñar el sistema que los rodea. Ahí es donde una demo aprende a recuperarse de un martes cualquiera en producción.

Preguntas frecuentes

¿Harness y framework son lo mismo?

No. Un framework aporta componentes. El harness es la configuración concreta de entorno, herramientas, estado, bucle, controles y pruebas de una aplicación.

¿Puede un buen harness compensar un modelo débil?

Hasta cierto punto. Reduce ambigüedad y verifica resultados, pero no crea capacidades de razonamiento que el modelo no tiene.

¿Qué parte debe ser determinista?

Permisos, validaciones, límites, cálculos y reglas críticas siempre que puedan expresarse con precisión. Reserve el modelo para la ambigüedad.

¿Cómo evitamos bucles infinitos?

Con presupuestos, detección de repetición, métricas de progreso y condiciones de salida verificables, además de escalado cuando no avanza.

¿Las trazas deben guardar todo el contenido?

No necesariamente. Registre lo suficiente para investigar, con redacción de datos sensibles, control de acceso y retención proporcionada.

Fuentes y lecturas recomendadas

Elaborado con asistencia de herramientas de IA y revisado por el equipo de INSTINTIA, que asume la responsabilidad editorial del contenido.

¿Quieres aplicar esto en tu empresa?

Solicitar diagnóstico gratuito AI Discovery Day