Cómo evaluar habilidades de agentes AI efectivamente

Testing Your AI Agent Skills — GEMINI_API_KEY=your-key npm run eval superlint — –provider=docker –trials=5

Testing Your AI Agent Skills empieza con un comando. Si tu flujo de trabajo no incluye algo parecido a:

GEMINI_API_KEY=your-key npm run eval superlint -- --provider=docker --trials=5

estás confiando en “vibes” y no en ingeniería. Las Skills son código que otros agentes ejecutan. Si no las pruebas, fallan en silencio y rompen cosas.

Resumen rápido (lectores con prisa)

Un eval correcto ejecuta la skill en un entorno aislado (Docker), repite la prueba varias veces y valida resultados con un grader determinista. Esto mide tanto capacidad (pass@k) como fiabilidad (pass^k). Automatiza el gate en CI para evitar merges que degraden la calidad.

Testing Your AI Agent Skills: por qué este comando importa

Ese comando condensa tres principios no negociables:

• Aislamiento: --provider=docker ejecuta la skill en un contenedor efímero. Si el agente borra archivos o instala paquetes, no rompe tu máquina.
• Repetición: --trials=5 reconoce la no-determinismo de los LLMs. Una ejecución no prueba nada; cinco sí dan una métrica.
• Foco: superlint es la unidad de prueba —una Skill— no el modelo entero. Testear por skill te da trazabilidad y responsabilidad.

Si quieres ejemplos y un framework listo, clona: skill-eval

¿Qué mide un buen eval? (y cómo diseñarlo)

Un eval efectivo combina tres capas:

1. Dataset realista

Usa repositorios con errores reales, no ejemplos limpios. Capturan edge cases.

2. Ejecución sandboxed

Docker + skill completa (scripts, assets, references).

3. Grader determinista

Código que valida outcomes, no prompts que se autoevalúan.

Métricas que realmente importan: pass@k y pass^k

Los LLMs varían. Dos métricas clave:

• pass@k: ¿lo resuelve al menos una vez en k intentos? Mide capacidad.
• pass^k: ¿lo resuelve todas las veces en k intentos? Mide fiabilidad.

Para producción, prioriza pass^k. Recomendación práctica: 90%+ pass^k para skills críticas (migraciones, despliegues, cambios en infra).

Recuerda la ley compuesta: si cada paso tiene 95% de éxito y encadenas 5 pasos, la probabilidad de éxito compuesto cae a ~77%. Las pruebas end-to-end capturan eso.

Tipos de graders y cuándo usarlos

– Graders deterministas (script): imprescindibles. Validan artefactos: archivos creados, tests que pasan, DB migrada.

– Graders de rúbrica LLM: útiles para intencionalidad (¿siguió el workflow correcto?). Úsalos con peso menor. Nunca dependas solo de ellos.

Combina ambos. Pondera, por ejemplo, 0.8 para el grader determinista y 0.2 para la rúbrica.

Integración CI: Quality Gate para Skills

No dejes que una PR rompa el comportamiento del agente. Añade esto al pipeline:

name: Skill Eval
on:
  pull_request:
    paths: ['skills/', 'tasks/']

jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run eval my_task -- --trials=5 --provider=docker
        env:
          GEMINI_API_KEY: ${{ secrets.GEMINI_API_KEY }}

Si la tasa de éxito cae bajo el umbral, bloquea el merge. Esto transforma tests en barrera de calidad, no en opción.

Diagnósticos útiles que debe entregar un eval

Un buen sistema no solo dice PASS/FAIL. Debe decir por qué:

Trial 1: FAIL - Agent used 'eslist' (typo) instead of 'eslint'
Trial 2: FAIL - Ignored extends in .eslintrc; used default rules
Trial 3: PASS
Trial 4: PASS
Trial 5: FAIL - Fixed src/utils.js instead of src/main.js

Con eso rehaces el SKILL.md: aclaras paths, ajustas templates, añades checks previos.

Reglas prácticas para diseñar Skills testeables

• SKILL.md = orquestador, <500 líneas. No cargues reglas densas ahí.
• Scripts deterministas en scripts/. No pidas al LLM escribir parsers complejos en tiempo real.
• Assets y references planos. Usa JiT loading: “Si ocurre X, abre references/X.md”.
• Frontmatter claro para discovery: name exacto, descripción con negative triggers.

Referencia práctica: skill-eval

Checklist rápido antes de mergear una skill

• [ ] Eval pasa 5/5 en provider=docker
• [ ] pass^5 ≥ 90% para skills críticas
• [ ] Grader determinista cubre outcomes principales
• [ ] Transcripts almacenados para debugging
• [ ] PR bloqueado si la tasa baja

Cierre: deja de confiar en sensaciones

Testing Your AI Agent Skills no es un lujo: es el último seguro antes de que tu agente se convierta en riesgo operativo. Ejecuta evals en contenedores, repite pruebas, mide pass^k y automatiza la puerta en CI. Hazlo y tus agentes dejarán de ser promesas para convertirse en herramientas confiables. Esto no acaba aquí: empieza con un eval, recoge datos y depura la skill hasta que el Pass Rate deje de ser una estadística y pase a ser garantía.

Como continuación natural para equipos que exploran automatización y evaluación de agentes, visita Dominicode Labs para recursos y proyectos experimentales. Encontrarás plantillas y ejemplos que facilitan implementar pipelines de evaluación reproducibles y seguros.

FAQ

• ¿Por qué usar Docker para evaluar skills?
• ¿Cuántas repeticiones son suficientes?
• ¿Qué debe validar un grader determinista?
• ¿Puedo confiar solo en un grader LLM?
• ¿Cómo integro el eval en CI?
• ¿Qué métricas priorizar para producción?
• ¿Qué hacer si la pass^k es baja?