Harness de agentes de IA: la capa de fiabilidad alrededor del LLM
Un LLM genera texto y llamadas a herramientas. Un harness de agentes de IA convierte esas propuestas en un proceso acotado, observable y verificable. Construye el contexto, ofrece herramientas aprobadas, comprueba permisos, ejecuta acciones, devuelve evidencia, verifica el resultado y decide si la ejecución puede terminar.
Esta separación evita un diagnóstico caro. Si el agente usó datos obsoletos, llamó una herramienta con demasiado poder o declaró éxito sin probar, cambiar a un modelo más fuerte puede repetir el fallo. El defecto está en el sistema que rodea al modelo.
Este artículo responde a la intención neutral de arquitectura y build-or-buy para harness de agentes de IA. Nuestra definición de agente de IA cubre la categoría general. El artículo sobre ingeniería de contexto profundiza en retrieval. Las páginas de jcode, DeepSeek, TrueForge y QM siguen siendo reviews de productos concretos.
¿Qué es un harness de agentes de IA?
Es la capa de ejecución y control que conecta un objetivo del usuario con un resultado aceptado mediante un LLM. Se ocupa de contexto, llamadas al modelo, contratos de herramientas, políticas, ejecución, estado, verificación, recuperación y telemetría. La guía de Anthropic para construir agentes eficaces también trata retrieval, herramientas y memoria como ampliaciones alrededor del modelo, y recomienda añadir complejidad solo cuando mejora resultados medidos.
| Capa | Qué decide | Evidencia que debe producir |
|---|---|---|
| 0. Objetivo | Alcance, éxito y riesgo | Contrato de tarea y responsable de aprobación |
| 1. Constructor de contexto | Qué instrucciones, datos, historial y esquemas entran | Fuentes, versiones y traza de retrieval |
| 2. LLM | Qué respuesta o acción propone | Versión del modelo, petición y llamada propuesta |
| 3. Puerta de políticas | Permitir, bloquear o pedir aprobación humana | Regla, actor, decisión y motivo |
| 4. Herramientas y runtime | Cómo se ejecuta el trabajo aprobado dentro de límites | Entradas, salidas, efectos, tiempos y errores |
| 5. Verificación | Si el resultado cumple aceptación y seguridad | Pruebas, notas, fallos y petición de reparación |
| 6. Resultado aceptado | Qué puede devolverse, guardarse o publicarse | Artefacto final, procedencia y estado |
Dos preocupaciones cruzan todas las capas. Las restricciones fijan permisos, presupuestos, timeouts, límites de datos y reglas de parada. La observabilidad registra trazas, latencia, coste, errores y resultados. Deben gobernar todo el bucle.
Cómo funciona el bucle del harness
- Convierte la intención en un contrato. Define entregable, sistemas permitidos, acciones prohibidas, presupuesto, plazo y pruebas de aceptación.
- Compila el menor contexto útil. Selecciona instrucciones actuales, registros autoritativos y solo las herramientas necesarias. La guía de ingeniería de contexto de Anthropic trata el contexto como un recurso finito que se debe cuidar durante toda la ejecución.
- Deja que el modelo proponga, no que autorice. El LLM elige una respuesta o llamada estructurada, pero no se concede acceso.
- Evalúa la acción propuesta. Reglas deterministas revisan identidad, alcance, argumentos, clase de datos, ritmo, gasto y reversibilidad. Una persona aprueba excepciones importantes. La documentación de guardrails del OpenAI Agents SDK separa controles de entrada, salida y herramientas. Un filtro de prompt no es una política completa.
- Ejecuta en un runtime controlado. Las herramientas reciben entradas tipadas, credenciales mínimas, límites de red y archivos, timeouts, reintentos e idempotencia. Sus resultados son evidencia no confiable, no instrucciones nuevas.
- Verifica antes de devolver. Prioriza assertions, tests, validación de esquemas y conciliación. Usa un juez LLM solo cuando las reglas no expresan la calidad.
- Registra y aprende. El modelo de tracing del OpenAI Agents SDK registra generaciones, herramientas, handoffs y guardrails. En producción, redacta datos sensibles y guarda la auditoría fuera del alcance de escritura del agente.
¿Dónde ocurren la mayoría de los fallos?
No existe un porcentaje universal y creíble que asigne la mayoría de los fallos a contexto, herramientas, restricciones o verificación. Depende del flujo, modelo, superficie de herramientas y definición de éxito. Clasifica el primer contrato roto en la traza.
| Capa | Síntoma | Primer diagnóstico | Corrección probable |
|---|---|---|---|
| Contexto | Respuesta segura basada en evidencia obsoleta, irrelevante o ausente | Reproducir contexto y versiones exactas | Mejorar retrieval, frescura, compactación o instrucciones |
| Herramientas | Función incorrecta, argumentos inválidos, timeout o efecto duplicado | Revisar esquema, argumentos, respuesta y reintento | Reducir interfaz, validar entradas e idempotencia |
| Restricciones | Acceso a datos o acciones fuera del alcance | Comprobar identidad, permiso y aprobación efectivos | Privilegio mínimo, política determinista y autoridad humana |
| Verificación | Salida plausible marcada como completa aunque la tarea real falló | Comparar artefacto con pruebas independientes | Tests de entorno, jueces, umbrales y bucles de reparación |
La verificación suele ser el último tramo ausente porque una respuesta fluida parece terminada. La guía de Anthropic sobre evals de agentes recomienda evaluar trazas multivuelta y estado del entorno, no solo la respuesta final. La seguridad cruza varias capas. La OWASP AI Agent Security Cheat Sheet recomienda tratar contenido externo como no confiable, limitar privilegios, validar herramientas y exigir aprobación humana para acciones de alto impacto.
Harness frente a framework, motor de workflows y API de modelo
| Categoría | Trabajo principal | Lo que no demuestra |
|---|---|---|
| API de modelo | Generar texto, razonamiento y llamadas | Autorización, estado duradero, recuperación o corrección de negocio |
| Framework de agentes | Dar abstracciones para agentes, herramientas, handoffs y memoria | Controles de despliegue y operación completos |
| Motor de workflows | Ejecutar pasos, reintentos y horarios definidos | Acciones elegidas por el modelo seguras o calidad semántica |
| Harness de agentes | Unir modelo, contexto, herramientas, políticas, runtime, verificación y telemetría | Fiabilidad sin pruebas específicas y responsabilidad operativa |
¿Construir, ampliar o comprar?
| Opción | Mejor encaje | Coste principal |
|---|---|---|
| Bucle propio ligero | Un flujo estrecho con controles especiales y buen equipo de plataforma | Todas las integraciones, regresiones e incidentes |
| Framework o harness abierto | Velocidad, control de código y capacidad de operar la pila | Upgrades, controles faltantes y extensiones |
| Plataforma gestionada | Capacidades estándar, piloto rápido y poco equipo de plataforma | Límites del proveedor, datos, precio y portabilidad |
No elijas por cantidad de funciones. Ejecuta el mismo conjunto de aceptación y compara resultados aceptados, latencia P50 y P95, minutos de revisión, acciones inseguras bloqueadas, recuperación y coste por tarea aceptada. Nuestro plan de piloto en 30/60/90 días aporta la secuencia. La checklist de seguridad para sandboxes de evals profundiza en contención.
Ayuda para IA en producción
Si estás construyendo un producto de IA y te preocupan el coste de inferencia, la arquitectura o la preparación para producción, Wavect ayuda a fundadores a convertir prototipos de IA en sistemas fiables.
Ruta de servicio:
Checklist de aceptación para producción
- Contrato: resultado, responsable, plazo, presupuesto y acciones prohibidas.
- Contexto: fuentes autoritativas, frescura, IDs, aislamiento y pruebas de compactación.
- Herramientas: esquemas tipados, credenciales mínimas, validación, timeouts, reintentos e idempotencia.
- Política: controles deterministas, aprobación explícita y sin bypass silencioso.
- Runtime: límites de red, archivos, paquetes, secretos y recursos, con cancelación y recuperación.
- Verificación: tareas representativas, varios intentos, jueces independientes y entorno real.
- Observabilidad: trazas correlacionadas, redacción, coste, latencia, errores y resultados aceptados.
- Operación: versiones fijadas, evals antes de upgrades, rollback, incidentes y retención.
El servicio de AI Enablement de Wavect puede convertir un flujo en arquitectura, conjunto de aceptación, permisos y handover. Si comparas frameworks o necesitas rescatar una demo frágil, reserva una revisión de arquitectura de agentes.
Preguntas frecuentes
¿Qué es un harness de agentes en una frase?
¿Es igual que un framework de agentes?
¿Un modelo mejor puede sustituir el harness?
¿Qué debe registrar?
¿Por dónde empezar?
Reflexiones finales
El LLM es el componente de razonamiento, no el sistema de fiabilidad. El harness decide qué entra, qué acciones propuestas pueden ejecutarse, cómo funcionan las herramientas, qué evidencia prueba la finalización y qué puede reconstruirse tras un fallo.
Empieza por el mapa de fallos y la checklist, no por una lista de frameworks. Un harness simple que demuestra un resultado de negocio vale más que una pila llena de funciones incapaz de explicar por qué acertó o falló.