SkillsBench: un benchmark para evaluar el rendimiento de las habilidades de los agentes en diversas tareas

• El primer benchmark para evaluar cuantitativamente la efectividad de las habilidades de agentes (Agent Skills) en agentes basados en modelos de lenguaje grandes (LLM), e incluye 84 tareas en 11 dominios
• Cada tarea se evalúa bajo tres condiciones: sin habilidades, con habilidades curadas y con habilidades autogeneradas, y se recopilaron un total de 7,308 trayectorias de ejecución
• Las habilidades curadas mostraron en promedio una mejora de +16.2 puntos porcentuales en el rendimiento, aunque la variación entre dominios fue grande y en algunas tareas (16 de 84) el rendimiento incluso disminuyó
• Las habilidades autogeneradas (Self-generated Skills) no fueron efectivas en promedio, lo que muestra que los modelos aún no pueden generar conocimiento procedimental de forma estable por sí mismos
• Los módulos de habilidades pequeños y enfocados (de 2 a 3 componentes) fueron más eficientes que las habilidades tipo documento integral, y un modelo pequeño con habilidades logró un rendimiento similar al de un modelo grande sin habilidades

---

Resumen de SKILLSBENCH

• SKILLSBENCH es un benchmark para evaluar el efecto del refuerzo con habilidades en agentes LLM, y fue construido sobre el framework Harbor
  • Cada tarea incluye un entorno en contenedor, un verificador determinista y una respuesta de referencia (oracle)
  • La misma tarea se ejecuta repetidamente con y sin habilidades para medir el efecto puro de las habilidades
• A diferencia de benchmarks previos, que solo evaluaban las capacidades base del modelo, SKILLSBENCH mide directamente cómo impactan las habilidades en el rendimiento

Definición y composición de las habilidades (Agent Skills)

• Una habilidad es un paquete estructurado que contiene conocimiento procedimental (procedural knowledge) y amplía el comportamiento del agente en tiempo de inferencia sin modificar el modelo
  • Componentes: SKILL.md (procedimiento de abordaje de la tarea), scripts ejecutables, plantillas de código, ejemplos, etc.
• Una habilidad debe cumplir con los siguientes cuatro criterios
  • Incluir contenido procedimental
  • Aplicarse a nivel de clase de tareas, no a un solo caso
  • Incluir componentes estructurados
  • Garantizar portabilidad basada en el sistema de archivos
• El system prompt, los ejemplos few-shot, la búsqueda RAG y la documentación de herramientas no se consideran habilidades

Composición de tareas y construcción del dataset

• Cada tarea se compone de cuatro elementos: instrucciones, entorno, respuesta y verificador
  • El entorno está aislado en un contenedor Docker para garantizar la reproducibilidad
  • El verificador usa scripts de prueba deterministas para decidir automáticamente si pasa o falla
• 105 colaboradores enviaron 322 tareas candidatas, y tras validación automática y revisión humana se seleccionaron 84 tareas finales
• Los colaboradores debían cumplir con los siguientes requisitos
  • Instrucciones escritas por humanos (no generadas por LLM)
  • La habilidad debía ofrecer guías procedimentales, no la respuesta de una tarea específica
  • Toda validación debía realizarse de forma determinista (basada en assertions)
  • Debían superar validación estructural automática, ejecución oracle, detección de contenido generado por IA y auditoría de filtraciones
• Para evitar filtraciones, se rechazaban habilidades que incluyeran nombres de archivos específicos de la tarea, constantes o referencias a pruebas

Configuración del benchmark y clasificación de dificultad

• SKILLSBENCH está compuesto por 84 tareas en 11 dominios (software, salud, finanzas, robótica, etc.)
• La dificultad se divide en tres niveles según el tiempo que tomaría a una persona completarlas
  • Core (menos de 60 minutos): 17
  • Extended (1–4 horas): 43
  • Extreme (más de 4 horas): 26

Configuración experimental

• Se evaluaron tres arneses comerciales para agentes: Claude Code, Gemini CLI y Codex CLI
• Se usaron siete modelos: GPT-5.2, Claude Opus 4.5/4.6, Claude Sonnet 4.5, Claude Haiku 4.5, Gemini 3 Pro y Gemini 3 Flash
• La evaluación se realizó bajo tres condiciones
  • No Skills: sin habilidades
  • With Skills: con habilidades curadas
  • Self-Generated Skills: el modelo genera las habilidades y luego las aplica
• Se recopilaron 7,308 trayectorias válidas de ejecución (trajectories)

Métricas de evaluación

• La métrica base fue la tasa de aprobación (pass rate)
• También se calculó la ganancia normalizada (normalized gain) para analizar tanto la mejora absoluta como la relativa
• Cada tarea se repitió 5 veces y se calculó el puntaje promedio

Resultados principales

• Las habilidades curadas mostraron en promedio una mejora de +16.2 puntos porcentuales, con un rango de +13.6 a +23.3 puntos porcentuales según la configuración
  • La variación por dominio fue amplia: salud mostró la mayor mejora (+51.9 puntos porcentuales) y la ingeniería de software la menor (+4.5 puntos porcentuales)
  • En 16 de las 84 tareas, el rendimiento incluso disminuyó
• Las habilidades autogeneradas no mostraron efecto promedio o tuvieron un impacto negativo
  • Esto indica que los modelos aún no pueden generar conocimiento procedimental de forma estable por sí mismos
• Las habilidades enfocadas (2–3 módulos) fueron más eficientes que las de tipo documento integral
• La combinación de modelo pequeño + habilidades logró un rendimiento similar al de un modelo grande sin habilidades

Conclusión

• SKILLSBENCH ofrece un marco de evaluación centrado en habilidades y demuestra cuantitativamente cómo las habilidades impactan la capacidad real de los agentes LLM para resolver tareas
• Los resultados muestran que la calidad del diseño de las habilidades y su adecuación al dominio son factores decisivos para mejorar el rendimiento
• Puede servir como base para investigaciones futuras orientadas a aclarar los principios de diseño estructural de las habilidades y los límites de su generación automática

[GN⁺]

Comentarios de Hacker News

• El concepto de “Self-Generated Skills” es interesante, pero quiero señalar que no es lo mismo que lo que la gente suele imaginar como “el proceso en el que un LLM aprende habilidades por sí solo”
  En el estudio, simplemente se le da un prompt para que genere conocimiento procedimental relevante antes de resolver el problema, así que está lejos de ser una verdadera “habilidad aprendida por experiencia”
  Ojalá los medios distingan bien esa diferencia al cubrirlo

  • El alcance de las ‘tasks’ del experimento es demasiado limitado. Solo usan un archivo Markdown y un verificador, y no abordan problemas realistas como codebases existentes o refactorización
    Aunque el LLM genere habilidades por sí mismo, la estructura no permite exploración ni aprendizaje, así que al final solo repite su propio contexto
    Generalizar estos resultados puede llevar a malentendidos
  • El propósito original de una ‘skill’ es ser como una breve nota de how-to que se invoca y usa cuando hace falta
    Si ese conocimiento ya está dentro del modelo, no hay necesidad de escribirlo como documento, y solo tiene sentido cuando se trata de información realmente difícil de hacer explícita
  • A mí también me interesa la idea de que un LLM organice como habilidad las lecciones aprendidas después de intentar algo
    Crear la skill antes del intento es un enfoque desconectado de la realidad
  • Yo he creado skills útiles mediante una ‘role play session’
    Hacer que el agente formule preguntas y pase por el proceso de resolver el problema, para luego resumir el resultado como una skill comprimida basada en evidencia, me ha funcionado bien
  • Como resumí en thisistheway.to/ai, nosotros tratamos las fallas del agente como oportunidades de aprendizaje
    ① detectar la falla → ② diagnosticar la causa → ③ elegir la herramienta de mejora → ④ registrarlo como un artefacto versionado → ⑤ elevarlo a gate si hace falta
    Incluimos este loop como instrucción base para todos los agentes

• Yo uso por separado un skill-creator para Claude
  Para evitar que Claude vuelva a escribir como skill información que ya conoce, exigimos que el documento incluya solo
  ① información fuera de los datos de entrenamiento, ② contexto válido solo para la sesión actual, ③ información que alinee la conducta de Claude en el futuro
  El contenido completo está en este enlace de GitHub

  • Los LLM son débiles para reflexionar sobre lo que saben y no saben, pero aun así creo que este enfoque es muy útil
  • Aun así, es riesgoso asumir que Claude puede elegir “el mejor conocimiento”
    Los datos de entrenamiento de internet tienen una calidad muy irregular, así que es difícil esperar que el modelo haga una “selección a nivel experto”
  • Me gusta que este documento de skill se lea como una buena entrada de blog
    Tener como criterio que una buena skill sea un texto con ideas no obvias puede ser una buena referencia
  • Este tipo de insights prácticos quizá los investigadores podrían publicarlos primero en arXiv antes de convertirlos en paper

• Lo más interesante de los resultados del estudio es que las skills autogeneradas reducen el rendimiento (-1.3pp), mientras que las skills curadas lo mejoran mucho (+16.2pp)
  Eso coincide con la hipótesis de que los LLM son excelentes consumidores de conocimiento procedimental, pero débiles como productores
  El efecto además es mucho mayor en healthcare que en software, probablemente porque ya hay abundantes datos de SWE

  • Yo también me fijé en esa diferencia. Cuando se trata de librerías nuevas o poco comunes, el efecto de las skills aumenta de forma dramática
    Por ejemplo, Adobe React Spectrum UI se usa fatal sin skills, pero con una skill bien hecha cambia por completo

• No tiene mucho sentido simplemente decirle al modelo “crea una skill”
  Si no amplías su conocimiento con información nueva o recursos externos, al final no es más que un ciclo de volver a meter su propia salida como entrada
  Yo uso este skill-creator, que al generar una skill hace investigación automáticamente y la refina según información reciente o workflows actuales

  • En el estudio no le dieron al agente autonomía para explorar ni acceso a materiales
    En esas condiciones, crear skills no tiene sentido
  • En la práctica, es mucho más útil si la skill se usa en campo y luego se mejora automáticamente con feedback

• Mientras más capas de automatización con LLM metas, más tiende a caer la calidad en cada etapa
  Si la persona define la idea y el plan de implementación y el LLM solo programa, funciona bien, pero si también le delegas la planificación ocurre una caída fuerte de calidad

  • Yo a este fenómeno le llamo ‘semantic collapse’
    Cuando repites resúmenes o reproducciones una y otra vez, el significado termina colapsando
    Cada cierto tiempo hace falta input humano fresco
  • Pero con una buena gestión de contexto puede pasar lo contrario
    Yo hago que el LLM primero escriba un informe de exploración de un codebase grande, y luego trabajo en una sesión nueva usando eso como referencia
    Consume más tokens, pero evita perder detalles importantes
  • Aletheia de Google incluso mejora el rendimiento en este tipo de estructura en pipeline
    Al final, la clave es si le das al modelo suficiente conocimiento del mundo
  • Me dan ganas de comparar este proceso con el teléfono descompuesto
    El lenguaje natural es inherentemente inestable, así que mientras más se retransmite, más se distorsiona
    Que logremos comunicarnos tan bien ya de por sí es sorprendente
  • Pero si hay un loop de feedback, la historia cambia
    En una estructura open loop la precisión cae, pero si cada etapa puede ajustarse a sí misma, todo es mucho más estable

• Estoy creando un data warehouse agentic-ready ( GitHub.com/mathisdrn/orca )
  Al principio quería optimizar skills con benchmarks, pero enfoques como DsPy y GEPA, que usan el propio lenguaje del modelo como evaluador y builder, resultan más eficientes
  Me pregunto si los skill-creator de Anthropic u OpenAI también tienen esta estructura de autooptimización

• No me parece que este estudio sea sorprendente ni que tenga gran relevancia práctica
  En la realidad, casi nunca pasa que el modelo genere skills solo con su conocimiento latente
  Como el estudio experimentó bajo esas condiciones limitadas, el resultado era esperable
  Lo más interesante sería que el modelo entreviste a humanos o genere skills después de una investigación profunda

  • Estoy totalmente de acuerdo con esa crítica.
    De hecho, me sorprende más que este paper haya salido
  • La ciencia moderna fomenta publicar también “resultados no sorprendentes”
    Además, estudios así ayudan a frenar a “managers que le piden al modelo que escriba documentos de best practices sin ningún contexto”
  • En el pasado sí hubo casos en los que enfoques como “planificar y luego ejecutar” realmente funcionaron
    Este estudio no toma en cuenta ese contexto
  • Al final es como decir que CLAUDE.md o AGENTS.md no sirven solo porque el modelo los haya escrito por sí mismo

• Últimamente siento que demasiada gente inteligente está gastando energía en estos debates sobre IA
  Antes simplemente hacían software útil, y ahora están atrapados en el nuevo tema de IA que sale cada semana
  Tiene un efecto de nerd-sniping incluso más fuerte que Web3 o los frameworks de JS
  Este artículo en realidad solo confirma un resultado bastante predecible

  • Ahora mismo estamos en un proceso de evolución distribuida, así que hay muchos intentos redundantes
    Pero también es muy posible que pronto salga un nuevo modelo y vuelva irrelevantes estas discusiones
    A muchos equipos les dicen que giren hacia una “estrategia de skills”, pero en medio de eso aparece un modelo nuevo que ya lo hace mejor
    Al final todos siguen sin encontrar dirección dentro de una estructura de supervivencia inestable

• Yo también he visto con frecuencia la caída de calidad en documentación autogenerada
  Cuando un LLM extrae ‘best practices’ desde el código, muchas veces termina documentando patrones erróneos tal cual
  Por ejemplo, vimos casos de mal uso de ConfigureAwait(false) o Task.Run en código C#
  Para resolver esto, estamos construyendo un sistema de conocimiento curado
  Creemos que el agentic coding basado en Markdown será la próxima capa de abstracción

  • Eso sí, a diferencia de lenguajes anteriores, la capa de LLM es no determinista
    Todavía no está claro cómo afecta esa característica al comportamiento total del sistema

• El título enviado era “Self-generated agent skills are useless”, pero eso va contra las guías de HN
  Lo justo es mantener el título original y expresar la opinión en los comentarios

  • Pero también es un problema que el resultado central quede enterrado bajo un título demasiado ambiguo
    Creo que un título más claro puede darle a la comunidad una mejor visión
    La intención no era buscar clics, sino destacar el hallazgo principal