# Cómo evaluar el arnés de un agente sin confundirlo con el modelo > Una comparación útil mantiene el modelo y la tarea constantes para descubrir qué aportan las herramientas, el contexto y la recuperación. - Author: Viktor Berthelius (BRTHLS) - Published: 2026-10-03 - Updated: 2026-10-29 - Category: automation aiops - Tags: harness, evaluacion, agentes - Language: es - Canonical: https://www.brthls.com/magazine/evaluar-harness-agente-mismo-modelo-es - Source: BRTHLS Magazine — https://www.brthls.com --- *Nota de edición: pieza evergreen preparada el 28 de octubre de 2026 para completar retrospectivamente el calendario editorial de octubre. La fecha de edición no acredita una publicación anterior.* ## Problema Un equipo cambia de agente de programación y observa mejores resultados. Atribuye la mejora al modelo, aunque también han cambiado las instrucciones, el buscador del repositorio, los límites de ejecución y la forma de conservar el trabajo. La comparación ha movido demasiadas piezas para explicar ninguna. El arnés es el entorno que convierte las respuestas del modelo en trabajo: prepara contexto, ofrece herramientas, ejecuta acciones y decide cómo continuar tras un fallo. Si se evalúa como una caja negra, cualquier mejora puede desaparecer al cambiar una integración. ## Tesis Evalúa el arnés como una hipótesis de producto. Mantén estable lo que puedas y cambia una capacidad concreta: recuperación, descripción de herramientas, persistencia o comprobación del resultado. La pregunta útil es qué mecanismo elimina qué fallo. Anthropic describe en su trabajo sobre agentes de larga duración la necesidad de dejar artefactos que permitan continuar entre sesiones. Su guía de herramientas propone evaluarlas con agentes y revisar la información que devuelven. Son prácticas de ingeniería; no demuestran que un diseño concreto funcione en cualquier empresa. ## Framework ### Diseña una comparación que pueda perder Elige tareas de tu operación con una salida verificable. Una reparación debe resolver el comportamiento defectuoso sin romper el contrato; un análisis debe poder reconstruirse desde sus datos. Guarda el estado inicial y los criterios antes de ejecutar. Después compara la configuración habitual con una variante acotada. Si cambias el buscador, conserva el modelo, las instrucciones y los permisos. Si necesitas cambiar también el modelo, registra otra comparación: juntar ambas decisiones impide aprender de sus diferencias. ### Clasifica el fallo antes de optimizar Distingue entre evidencia no encontrada, evidencia mal interpretada, herramienta mal utilizada y resultado no comprobado. Cada clase pide una intervención diferente. Una descripción más precisa de la herramienta puede ayudar al tercer caso sin resolver el primero. Incluye recuperación: interrumpe una tarea en un punto seguro, vuelve a iniciarla y observa si conserva el trabajo útil. Mide también el esfuerzo humano necesario para aceptar la entrega. Un agente que redacta mucho y exige rehacerlo todo no ha ganado capacidad operativa. ### Una evaluación de arnés que un revisor puede repetir Supuesto de trabajo: el agente debe corregir una exportación que pierde un campo. Prepara un repositorio de prueba con el fallo, una entrada sintética y una comprobación independiente del archivo exportado. El resultado esperado queda escrito antes de dar acceso al agente. En ambas configuraciones conserva el mismo commit inicial, modelo, permisos y límite de ejecución. La variante incorpora una búsqueda que devuelve la definición del campo y sus consumidores. La configuración de referencia conserva el buscador habitual. Esta es una propuesta experimental; no describe resultados obtenidos por BRTHLS. | Observación del ensayo | Diagnóstico que permite | Decisión siguiente | | --- | --- | --- | | Encuentra el campo, pero modifica solo la pantalla | Fallo al seguir los consumidores | Mejorar navegación y contexto del contrato | | Corrige la exportación y rompe una entrada válida | Solución incompleta | Revisar los casos de aceptación | | Genera el archivo correcto y permite repetir la prueba | Entrega verificable | Comparar esfuerzo y repetibilidad | | El evaluador cambia a la vez que la implementación | Evidencia contaminada | Repetir con la comprobación independiente | Guarda por ejecución el estado inicial, el cambio producido, el resultado del evaluador y las intervenciones del revisor. Ejecuta las configuraciones en entornos separados y alterna su orden para reducir ventajas de caché o aprendizaje accidental. Repite antes de atribuir una mejora al arnés: una ejecución favorable sirve para investigar un mecanismo, pero no establece su fiabilidad. El criterio de compra queda así delimitado: la búsqueda nueva merece mantenerse si facilita entregas aceptables en los casos reservados, sin ampliar permisos ni desplazar la revisión a una tarea más costosa. Si solo mejora la demostración preparada para ella, todavía no hay evidencia de generalización. ## Por qué importa ahora La compra de agentes incorpora decisiones sobre entornos de trabajo, conectores y memoria. Un benchmark del modelo informa sobre parte de esa compra, pero deja fuera las fricciones que aparecen al acceder al repositorio real o al continuar una tarea incompleta. Separar esas capas permite negociar mejor con proveedores y decidir dónde invertir trabajo propio. También facilita retirar una integración que cuesta más de lo que aporta sin tener que reemplazar toda la plataforma. ## Anti-ejemplo Caso hipotético: el nuevo agente corrige una incidencia que el anterior no pudo resolver. El equipo declara ganador al nuevo modelo. Después descubre que el anterior no tenía acceso al archivo de configuración que explicaba el fallo. Se ha medido acceso a información, pero se ha comprado inteligencia. ## Protocolo (3 pasos) | Paso | Trabajo concreto | Criterio de decisión | | --- | --- | --- | | Congelar | Guardar tarea, estado inicial y configuración | La comparación puede repetirse | | Aislar | Cambiar una capacidad del arnés | El efecto tiene una explicación plausible | | Revisar | Inspeccionar resultados, fallos y trabajo humano | La mejora sobrevive a casos distintos | ## Relacionado - [Eval-driven development: el prototipo debe descubrir el benchmark](/magazine/eval-driven-development-prototipo-antes-benchmark-es) - [Programmatic Tool Calling: cuando el agente escribe el flujo de control de sus herramientas](/magazine/programmatic-tool-calling-codigo-orquesta-herramientas-es) ## Fuentes consultadas - [Anthropic — Effective harnesses for long-running agents](https://www.anthropic.com/research/effective-harnesses-for-long-running-agents) - [Anthropic — Writing effective tools for agents](https://www.anthropic.com/research/writing-tools-for-agents) ## Próximo paso Escoge una tarea que haya fallado por una causa conocida y compara el arnés actual con una única modificación. Conserva también el resultado desfavorable: es lo que evita convertir la evaluación en una demostración comercial. ## Lecturas conectadas - [Eval-driven development: el prototipo debe descubrir el benchmark](https://www.brthls.com/magazine/eval-driven-development-prototipo-antes-benchmark-es) — Conexión editorial. - [Programmatic Tool Calling: cuando el agente escribe el flujo de control de sus herramientas](https://www.brthls.com/magazine/programmatic-tool-calling-codigo-orquesta-herramientas-es) — Conexión editorial. - [Memory Tax: la memoria de un agente debe justificar lo que pierde](https://www.brthls.com/magazine/memory-tax-memoria-agentes-valor-neto-es) — Temas en común: evaluacion. --- _Cite as: Berthelius, V. (2026). "Cómo evaluar el arnés de un agente sin confundirlo con el modelo". BRTHLS Magazine. https://www.brthls.com/magazine/evaluar-harness-agente-mismo-modelo-es_