Las habilidades de agentes de IA necesitan auditorías de comportamiento, no tasas de éxito
Las habilidades de agentes de IA parecen fáciles de evaluar hasta que la tasa de éxito casi no cambia.
El estudio de auditoría contrafactual de trazas reportó una mejora promedio de +0,3 puntos porcentuales en el éxito de tareas gracias a las habilidades en una configuración de prueba de referencia, mientras que la misma auditoría encontró 522 formas concretas en que esas habilidades modificaron el comportamiento del agente en 49 tareas.1 Un panel basado en tasas de éxito diría que eso es casi nada. Una auditoría de trazas ve el cambio real.
Las habilidades de agentes de IA necesitan auditorías de comportamiento, no tasas de éxito. Una habilidad puede cambiar qué herramienta elige un agente, qué ruta lee, qué evidencia omite, qué riesgo ignora y qué efecto secundario produce, aunque el resultado final de la tarea parezca igual.
Resumen rápido
Las habilidades de agentes de IA no deberían ganarse la confianza solo por sus tasas de éxito. Una tasa de éxito le dice al equipo si la tarea final salió bien según un evaluador de referencia. Una auditoría de comportamiento pregunta si la habilidad cambió las acciones del agente de la forma que el equipo quería.
La investigación reciente vuelve difícil ignorar esa brecha. La auditoría contrafactual de trazas compara ejecuciones de agentes con y sin una habilidad, y expone patrones inducidos por la habilidad que las métricas comunes de éxito no detectan.1 Behavioral Integrity Verification compara lo que una habilidad afirma hacer con lo que realmente hace, y luego reporta una discrepancia extendida entre descripción y comportamiento en un corpus amplio de habilidades.2 SkillsBench muestra que las habilidades curadas pueden mejorar el rendimiento de los agentes, pero también muestra que las habilidades autogeneradas pueden no ayudar y que algunas tareas empeoran con habilidades.3
La regla práctica: no instales una habilidad porque subió una prueba de referencia. Instala una habilidad después de que la traza demuestre que ese comportamiento corresponde.
Puntos clave
Para equipos que usan habilidades de agentes: - Trata cada habilidad como código que cambia comportamiento, incluso cuando el archivo solo contiene Markdown. - Audita cambios en trazas, efectos secundarios y modos de falla antes de compartir la habilidad entre proyectos.
Para autores de habilidades: - Declara el comportamiento esperado, las herramientas permitidas, las acciones prohibidas y las obligaciones de evidencia. - Prueba la habilidad con trazas emparejadas, no solo con resultados finales de tareas.
Para revisores de seguridad: - Compara las capacidades declaradas con las capacidades observadas. - Marca la expansión oculta, el acceso externo, las acciones destructivas y los saltos de política como defectos de la habilidad.
Para equipos de evaluación: - Reporta por separado la tasa de éxito, el cambio de comportamiento, el cambio en efectos secundarios y la carga de revisión. - Una tasa de éxito plana aún puede ocultar un cambio de comportamiento peligroso.
¿Por qué las tasas de éxito no detectan el riesgo de una habilidad?
Las tasas de éxito comprimen el objeto equivocado.
Una habilidad cambia al agente antes de que empiece la tarea. Puede agregar un procedimiento de dominio, una preferencia de herramientas, reglas de formato, pasos de revisión, lenguaje de confianza o comportamiento de recuperación. El evaluador de referencia suele ver solo el artefacto final: correcto o incorrecto.
Eso crea un punto ciego:
| Efecto de la habilidad | Lo que ve la tasa de éxito | Lo que ve la auditoría de comportamiento |
|---|---|---|
| Mejor orden de herramientas | Tal vez éxito | Qué llamada se adelantó y por qué. |
| Lecturas adicionales de archivos | Tal vez éxito | Qué archivos entraron en contexto. |
| Parches más agresivos | Tal vez éxito | Tamaño del diff, propiedad y riesgo de reversión. |
| Verificación omitida | Tal vez éxito | Evidencia faltante antes de completar. |
| Acceso externo oculto | Tal vez éxito | Expansión de límites de red o MCP. |
| Menor carga de revisión | Tal vez éxito | Traza más pequeña, prueba más clara, menos afirmaciones sin resolver. |
La respuesta final puede verse correcta mientras la habilidad vuelve la ejecución menos confiable. También puede pasar lo contrario: una habilidad puede producir un resultado fallido y, aun así, enseñar un mejor patrón de búsqueda o recuperación que merece reparación en lugar de eliminación.
La tasa de éxito pertenece a la auditoría. No puede ser la auditoría.
¿Qué aportó la auditoría contrafactual de trazas?
La auditoría contrafactual de trazas compara dos ejecuciones: una con la habilidad y otra sin ella.1
El punto del artículo pesa porque la mejora principal en tasa de éxito se mantiene diminuta en la configuración reportada de WebArena. El éxito promedio de las tareas sube apenas +0,3 puntos porcentuales cuando la prueba de referencia usa habilidades.1 Sin embargo, los autores identifican 522 patrones de comportamiento inducidos por habilidades en 49 tareas, con cambios en pasos de validación, interacción con formularios, recuperación de errores, navegación de páginas y patrones de mal uso.1
Esa separación es el centro del argumento.
La habilidad afectó el comportamiento incluso cuando el éxito agregado de las tareas casi no se movió.
CTA funciona alineando trazas en fases e identificando patrones inducidos por la habilidad. La auditoría no solo pregunta si una tarea pasó. Pregunta dónde la habilidad cambió la trayectoria, si el cambio ayudó o perjudicó, y qué instrucción de la habilidad parece responsable.1
Ese método les da a los equipos un mejor objeto de revisión:
| Pregunta de auditoría | Por qué importa |
|---|---|
| ¿Qué paso cambió? | Conecta el comportamiento con una ubicación de la traza. |
| ¿Qué instrucción causó el cambio? | Conecta el comportamiento con el texto de la habilidad. |
| ¿El cambio ayudó, perjudicó o solo movió el costo? | Evita el teatro de las tasas de éxito. |
| ¿El cambio creó efectos secundarios? | Detecta riesgos ocultos detrás del éxito. |
| ¿El cambio se generaliza entre tareas? | Separa una ejecución afortunada de una habilidad que vale la pena conservar. |
Los equipos necesitan ese objeto antes de promover una habilidad de experimento local a proceso compartido.
¿Qué aportó Behavioral Integrity Verification?
Behavioral Integrity Verification plantea otra pregunta: ¿una habilidad hace lo que su descripción dice?2
El artículo de BIV estudia repositorios de habilidades a gran escala y reporta que más del 80% de las habilidades analizadas mostraron alguna forma de desviación entre descripción y comportamiento.2 Los autores clasifican la mayoría de las desviaciones como producto de descuidos más que de intención adversaria, pero también encuentran casos adversarios y patrones de riesgo de varias etapas.2
Ese hallazgo importa porque las descripciones guían la activación.
En sistemas de agentes, la descripción de una habilidad suele decidir si esa habilidad entra en contexto. La descripción dice cuándo debería cargarla el agente. Si la descripción minimiza capacidades, oculta efectos secundarios o no menciona acceso a herramientas, tanto el agente como el usuario toman una mala decisión de enrutamiento antes de que empiece cualquier razonamiento específico de la tarea.
BIV señala la falta de una capa de manifiesto para las habilidades:
| Superficie declarada | Lo que debería verificar la auditoría de comportamiento |
|---|---|
| Condición de activación | ¿La habilidad se ejecuta solo para la clase de tarea declarada? |
| Capacidad | ¿El comportamiento observado se mantiene dentro de lo afirmado? |
| Uso de herramientas | ¿Qué herramientas, comandos, servidores MCP o archivos provoca la habilidad? |
| Efectos secundarios | ¿La habilidad lee, escribe, elimina, envía, gasta, publica o despliega? |
| Acceso externo | ¿La habilidad crea movimiento de red, navegador o terceros? |
| Afirmación de seguridad | ¿La habilidad realmente agrega la comprobación prometida? |
| Límite de rechazo | ¿La habilidad conserva las acciones bloqueadas? |
La versión más alarmante es una habilidad maliciosa que miente. La versión común es una habilidad descuidada que olvida decir la verdad.
Ambas versiones necesitan auditoría.
¿Qué aportó SkillsBench?
SkillsBench muestra por qué los equipos no deberían corregir de más y declarar inútiles las habilidades.
La prueba de referencia evalúa habilidades de agentes en 86 tareas y 7.308 trayectorias.3 El artículo reporta que las habilidades curadas mejoran la tasa promedio de éxito en 16,2 puntos porcentuales frente a una línea base sin habilidades, mientras que las habilidades autogeneradas no aportan beneficios en promedio.3 También reporta deltas negativos en algunas tareas, lo que significa que una habilidad puede empeorar cierto trabajo.3
Ese resultado da una visión equilibrada.
Las habilidades pueden ayudar. La calidad de la habilidad importa. El ajuste con la tarea importa. La fuente importa. El método de evaluación importa.
La lección de adopción no es “evita las habilidades”. La lección es “revisa las habilidades como paquetes de capacidad”.
Una habilidad útil debería responder:
| Pregunta | Respuesta requerida |
|---|---|
| ¿Qué trabajo mejora la habilidad? | Clase concreta de tarea y lector/usuario. |
| ¿Qué comportamiento debería cambiar? | Elección de herramientas, comprobación de evidencia, formato, revisión o patrón de recuperación. |
| ¿Qué comportamiento no debe cambiar? | Herramientas, rutas, efectos secundarios y límites de autoridad prohibidos. |
| ¿Qué evidencia demuestra que la habilidad ayudó? | Cambio de traza, tasa de éxito, esfuerzo de revisión y perfil de efectos secundarios. |
| ¿Cómo puede retirarla el equipo? | Versión, responsable, reversión y ruta de reemplazo. |
La habilidad solo merece promoción cuando el comportamiento observado coincide con esas respuestas.
¿Cómo se ve una auditoría de comportamiento?
Una auditoría de comportamiento compara el comportamiento esperado de la habilidad con el comportamiento observado del agente.
La auditoría mínima tiene cuatro pasadas.
| Pasada de auditoría | Evidencia |
|---|---|
| Auditoría de declaración | Descripción de la habilidad, condición de activación, capacidades, herramientas y acciones prohibidas. |
| Auditoría contrafactual de trazas | Ejecuciones emparejadas con y sin la habilidad sobre el mismo conjunto de tareas. |
| Auditoría de efectos secundarios | Archivos, comandos, llamadas de red, escrituras externas, aprobaciones y estado de reversión. |
| Auditoría de fallas | Ejecuciones fallidas, casi fallas, errores recuperados y patrones repetidos de reparación. |
El resultado debería parecerse menos a una tabla de posiciones y más a un paquete de revisión.
Para cada tarea, captura:
- Nombre de la tarea y categoría de riesgo.
- Versión y fuente de la habilidad.
- Traza base.
- Traza con habilidad.
- Pasos cambiados.
- Llamadas de herramientas cambiadas.
- Efectos secundarios cambiados.
- Evidencia ganada o perdida.
- Resultado final.
- Decisión del revisor: conservar, revisar, acotar, bloquear o retirar.
Ese paquete le da a un revisor humano una forma de emitir un juicio que sobreviva más allá de una sola ejecución de referencia.
¿Dónde encajan los contratos de habilidades?
ContractSkill apunta a una forma más limpia para las habilidades que necesitan un comportamiento más estricto.4
El artículo sostiene que las habilidades para agentes web escritas en lenguaje natural pueden ser ambiguas, frágiles y difíciles de depurar. Propone habilidades basadas en contratos con definiciones explícitas de tareas, precondiciones, poscondiciones y procedimientos a nivel de paso, de modo que un sistema pueda localizar fallas y reparar la parte afectada en lugar de reescribir toda la habilidad.4
Ese marco de contrato encaja con las auditorías de comportamiento.
| Habilidad libre | Habilidad con forma de contrato |
|---|---|
| “Ten cuidado al publicar”. | “Antes de publicar, verifica URLs de fuentes, renderizado de ruta, esquema y reversión”. |
| “Revisa la página”. | “Obtén la ruta, confirma estado 200, confirma marcador cambiado, confirma que no haya texto de respaldo”. |
| “Evita comandos riesgosos”. | “Bloquea eliminación, force push, POST externo y escrituras fuera de rutas propias”. |
| “Traduce con naturalidad”. | “Preserva URLs y citas; traduce encabezados visibles; bloquea residuo en inglés”. |
Las habilidades con forma de contrato reducen la ambigüedad. También abaratan las auditorías porque el comportamiento esperado queda en una estructura que el revisor puede comparar con la traza.
El contrato no debería volver enorme cada habilidad. Las habilidades simples siguen funcionando para tareas de bajo riesgo relacionadas con formato de escritura o listas de verificación. Los contratos importan cuando una habilidad puede alterar sistemas externos, contenido público, datos, dinero, postura de seguridad o comportamiento compartido del proyecto.
¿Cómo se repara una mala habilidad?
No elimines una habilidad útil porque una ejecución falló. Primero identifica dónde se rompió el comportamiento.
AgentRx se enfoca en reparar fallas de agentes localizando pasos críticos de falla en trayectorias de ejecución, generando restricciones y validando reparaciones contra un registro auditable.5 El artículo aborda el comportamiento de agentes en general, no archivos de habilidades en particular, pero la forma de reparación encaja bien con las habilidades: encontrar el paso de falla, derivar una restricción, probar el comportamiento reparado y conservar evidencia.
La reparación de habilidades debería seguir la misma secuencia:
| Falla | Reparación |
|---|---|
| La habilidad se activa demasiado ampliamente | Acotar la descripción y los ejemplos de activación. |
| La habilidad cambia la herramienta equivocada | Agregar reglas de selección de herramientas y contraejemplos. |
| La habilidad omite verificación | Agregar una condición de detención antes de completar. |
| La habilidad crea un diff demasiado grande | Agregar límites de propiedad y rutas modificadas. |
| La habilidad provoca movimiento de red | Agregar reglas de salida y requisitos de aprobación. |
| La habilidad mejora una tarea pero perjudica otra | Dividir la habilidad o limitarla a la clase de tarea donde gana. |
La reparación debería terminar con una nueva auditoría, no con un mensaje de commit confiado.
Si la traza todavía muestra el comportamiento equivocado después de la reparación, retira la habilidad.
El estándar mínimo
Antes de que un equipo comparta una habilidad de agente de IA, exige un paquete de auditoría de comportamiento.
| Campo | Evidencia requerida |
|---|---|
| Fuente | Repositorio, autor, versión y ruta de instalación. |
| Propósito | La clase de tarea que la habilidad afirma mejorar. |
| Activación | La condición exacta que debería cargar la habilidad. |
| Comportamiento permitido | Herramientas, archivos, recursos y acciones en los que la habilidad puede influir. |
| Comportamiento prohibido | Herramientas, rutas, efectos secundarios y autoridad que la habilidad no debe expandir. |
| Trazas contrafactuales | Misma tarea con y sin la habilidad. |
| Cambio de resultado | Tasa de éxito, tasa de falla, esfuerzo de revisión y costo de entorno de ejecución. |
| Cambio de comportamiento | Pasos, llamadas de herramientas, efectos secundarios y evidencia cambiados. |
| Decisión de riesgo | Conservar, revisar, acotar, bloquear o retirar. |
| Reversión | Cómo el equipo elimina la habilidad y vuelve al comportamiento anterior. |
Ese paquete obliga a hacer la pregunta correcta.
La pregunta no es “¿la habilidad ayudó una vez?”. La pregunta es “¿la habilidad cambia de forma confiable el comportamiento del modo que el equipo quiere?”.
El estándar digno
Las habilidades hacen que los agentes se sientan mejores rápidamente. Esa velocidad tienta a los equipos a acumular archivos de proceso, comandos, agentes, hooks y prompts porque cada uno parece barato.
El contexto barato también cambia comportamiento.
Una habilidad digna se gana su lugar mejorando todo el flujo de trabajo. Debería reducir la carga de revisión, afinar la evidencia, acotar el riesgo o enseñar un procedimiento que el agente no podía ejecutar de forma confiable sin ella. Una habilidad que solo hace que el agente suene más seguro debería irse. Una habilidad que mejora la tasa de éxito mientras expande efectos secundarios ocultos debería fallar la revisión.
El estándar debe mantenerse simple:
- Declara qué debería cambiar la habilidad.
- Demuestra que la traza cambió de esa forma.
- Nombra qué no debe cambiar.
- Demuestra que la traza respetó ese límite.
- Conserva la habilidad solo cuando el comportamiento merece existir.
Las habilidades de agentes de IA no son notas mágicas. Son parches de comportamiento. Trátalas como código.
Resumen breve
Las habilidades de agentes de IA necesitan auditorías de comportamiento porque las tasas de éxito ocultan demasiado. La auditoría contrafactual de trazas muestra que las habilidades pueden cambiar cientos de patrones de traza mientras el éxito agregado apenas se mueve.1 Behavioral Integrity Verification muestra que las descripciones de habilidades a menudo se apartan de las capacidades reales.2 SkillsBench muestra que las habilidades curadas pueden ayudar, pero las habilidades autogeneradas y el desajuste con la tarea pueden fallar o perjudicar.3
La regla operativa es directa: evalúa el comportamiento, no solo la puntuación. Una habilidad merece confianza cuando su declaración, trazas, efectos secundarios, fallas, reparaciones y ruta de reversión encajan.
Preguntas frecuentes
¿Qué es una auditoría de comportamiento para habilidades de agentes de IA?
Una auditoría de comportamiento revisa cómo una habilidad cambia la ejecución real de un agente: llamadas de herramientas, acceso a archivos, efectos secundarios, pasos de verificación, comportamiento de recuperación y resultado final. Compara el comportamiento observado con el propósito y los límites declarados de la habilidad.
¿Por qué las tasas de éxito no bastan para evaluar habilidades?
Las tasas de éxito muestran si una tarea tuvo éxito según un evaluador. No muestran si la habilidad amplió el acceso a herramientas, omitió evidencia, aumentó los efectos secundarios o cambió el comportamiento de maneras que el equipo no quería.
¿Qué es la auditoría contrafactual de trazas?
La auditoría contrafactual de trazas compara trayectorias de agentes con y sin una habilidad, alinea fases de trazas e identifica patrones de comportamiento inducidos por la habilidad. Ayuda a los equipos a ver cambios de comportamiento que las métricas agregadas de éxito pueden pasar por alto.1
¿Qué es Behavioral Integrity Verification?
Behavioral Integrity Verification compara las descripciones de habilidades con el comportamiento real de las habilidades. Detecta cuando la capacidad declarada, la condición de activación o la afirmación de seguridad de una habilidad no coincide con el comportamiento observado.2
¿Qué debería auditar un equipo antes de compartir una habilidad?
Los equipos deberían auditar la fuente de la habilidad, la condición de activación, las capacidades declaradas, las acciones permitidas y prohibidas, las trazas emparejadas, los efectos secundarios, los casos de falla, la ruta de reparación y el plan de reversión.
Referencias
-
Xuanyu Zhang, Yiding Liu, Chengsong Huang, Ensheng Shi, Weizhi Ma, Yifei Zhang, Qun Liu, Shumin Deng, Jiahang Shen, and Shiqi Wang, “Counterfactual Trace Auditing of LLM Agent Skills,” arXiv:2605.11946v1, enviado el 13 de mayo de 2026. Fuente para la comparación de trazas emparejadas, la detección de patrones inducidos por habilidades, la alineación de fases, la evaluación de habilidades en WebArena, la mejora agregada de +0,3 puntos porcentuales en tasa de éxito y los 522 patrones de comportamiento en 49 tareas. ↩↩↩↩↩↩↩↩
-
Ning Liu, Meng Fang, Youtao Zhang, Dominik T. Matt, Stanislav Pletnev, Hongzhi Wang, and Erwin Schoitsch, “Behavioral Integrity Verification for Agentic AI Skills,” arXiv:2605.11770v1, enviado el 13 de mayo de 2026. Fuente para la verificación entre capacidad declarada y capacidad real de habilidades, el análisis de habilidades a escala de repositorio, los hallazgos de desviación entre descripción y comportamiento, las categorías de desviación por descuido y adversarias, y los patrones de riesgo de varias etapas. ↩↩↩↩↩↩
-
Lingkai Kong, Xiangliang Zhang, and Jiamou Liu, “SkillsBench: Can LLMs Learn from Their Own and Other Agents’ Skills for Reliable Task Execution?,” arXiv:2602.12670v1, enviado el 17 de febrero de 2026. Fuente para la evaluación de SkillsBench con 86 tareas y 7.308 trayectorias, la mejora en tasa de éxito con habilidades curadas, el resultado de habilidades autogeneradas y los deltas negativos por tarea. ↩↩↩↩↩
-
Meiyi Ma, Fengan Xia, Canran Xu, Wenqi Li, Aranya Roy, Zhaopeng Tu, Ranveer Chandra, and Dongmei Zhang, “ContractSkill: Contract-based Skill Design for LLM-powered Web Agents,” arXiv:2603.20340v1, enviado el 25 de marzo de 2026. Fuente para las definiciones de habilidades basadas en contratos, precondiciones, poscondiciones, procedimientos a nivel de paso, verificación determinista, localización de fallas y reparación local mínima. ↩↩
-
Cunxiang Wang, Ruoxi Sun, Yidong Wang, Piji Li, and Yue Zhang, “AgentRx: Scalable Automated Failure Diagnosis and Repair for LLM Agents,” arXiv:2602.02475v1, enviado el 3 de febrero de 2026. Fuente para la localización de pasos críticos de falla, generación de restricciones, validación de trazas y registros auditables de reparación para fallas de agentes LLM. ↩