Eval de agente en 60 minutos, cómo saber si tu agente es bueno

El mayor punto ciego para fundadores en solitario que han construido su primer agente: nadie sabe si la cosa es de verdad buena. Tecleas unos cuantos prompts, el agente entrega algo, se ve bien, listo. Y luego cambias el system prompt y sigue estando bien. Y luego dos semanas después notas que en algún punto del medio la calidad bajó. Pero, ¿cuándo? ¿En qué cambio?

Justo ahí entra el agent eval. Te montas un pequeño conjunto de tests con inputs y una expectativa. En cada cambio se ejecuta y ves una tasa de aprobados. Cuando baja sabes de inmediato que has roto algo.

En los próximos 60 minutos construyes exactamente eso. Sin framework, sin suscripción cara a una herramienta, simplemente 20 casos de test y un script que los ejecuta. Suficiente para el 80 por ciento de los casos de uso.

1. Define el agente que quieres evaluar

Elige el agente que más usas. No el más chulo, el más usado. Si lo construiste hace dos semanas a partir del playbook de sub-agentes y corre cada día, entonces ese es tu candidato.

Escribe tres frases sobre la tarea. Cuál es el input, cuál es el output, en qué reconoces que el output es bueno. Ejemplo: "El input es una descripción de bug en texto plano. El output es un título de issue de GitHub por debajo de 80 caracteres más tres labels de una lista fija. Bueno significa: el título describe el problema en voz activa, los labels son todos de la lista, ningún label inventado."

Estas tres frases son la spec. Sin ellas no puedes evaluar. Con ellas, todo lo que viene es solo mecánica.

2. Crea el archivo del conjunto de eval

Hazte en el proyecto una carpeta evals/ y dentro un archivo cases.json. El formato es una lista de objetos, cada objeto es un caso de test con input y expected y un id.

[
  {
    "id": "001-simple-bug",
    "input": "Login klappt nicht mit Sonderzeichen im Passwort",
    "expected": {
      "title_max_chars": 80,
      "title_must_contain": ["login", "passwort"],
      "labels_subset_of": ["bug", "auth", "ux", "security"]
    }
  }
]

expected no es una expectativa de output exacta sino una lista de condiciones que el output tiene que cumplir. Eso es importante. Una expectativa de string exacta nunca pasaría porque el output del LLM varía. Quieres condiciones que sean robustas.

3. Reúne al menos veinte casos de test

Veinte es el número mágico. Por debajo de diez es estadística de pacotilla, por encima de cincuenta solo inflas el mantenimiento. Veinte casos que cubran casos de uso reales más dos o tres casos límite feos, ese es el punto óptimo.

No los reúnas de cabeza. Ve a tu historial de chat, a los logs, a tickets reales. Los inputs reales son oro. Los inputs inventados suelen ser demasiado limpios y no cubren los casos límite. Si has usado el agente dos semanas ya tienes veinte inputs reales tirados por algún sitio.

Marca al menos tres de ellos explícitamente como "fue difícil entonces" o "entonces no funcionó". Estos casos son tus tests de regresión. Cuando vuelvan a caerse sabes que un cambio rompió algo.

4. Escribe una función de check por condición

Una pequeña función por tipo de expectativa que devuelve un bool. Por ejemplo title_max_chars comprueba si el título es más corto que el número permitido. labels_subset_of comprueba si todos los labels elegidos están en la lista permitida. must_contain comprueba si determinadas palabras clave están en el output.

Mantenlo simple. JavaScript, Python, lo que escribas de todas formas. Cuatro o cinco de estas mini funciones bastan para empezar.

function checkTitleMaxChars(output, max) {
  return output.title.length <= max
}

function checkLabelsSubsetOf(output, allowed) {
  return output.labels.every(l => allowed.includes(l))
}

Importante: una función hace exactamente una cosa. No un "checkAll" con diez condicionales dentro. Si no, luego no puedes decir qué condición falló.

5. Construye el script runner

Un bucle sobre los casos. Por cada caso llamas al agente, recibes el output, dejas correr las funciones de check sobre él, recoges un pass o fail por caso.

const cases = JSON.parse(fs.readFileSync('evals/cases.json'))
const results = []
for (const c of cases) {
  const output = await callAgent(c.input)
  const checks = runChecks(output, c.expected)
  results.push({
    id: c.id,
    pass: checks.every(c => c.passed),
    failed: checks.filter(c => !c.passed).map(c => c.name)
  })
}
console.log(`Pass-Rate: ${results.filter(r => r.pass).length}/${results.length}`)

El script es deliberadamente tonto. Sin paralelización, sin caching, sin lógica de retry. Quieres ver si tu agente es bueno, no optimizar el runner. Si los veinte casos tardan dos minutos eso está perfectamente bien.

6. Haz la primera ejecución y anota la tasa de aprobados

Ejecuta el script una vez con el agente actual. Anota la tasa de aprobados. Probablemente no 20 de 20. Si lo es, tus casos de eval son demasiado flojos.

Un agente en solitario aterriza típicamente en doce de veinte. Eso no es grave. Esa es tu baseline. A partir de ahora todo es mejorar o empeorar.

Escribe la tasa de aprobados en un archivo evals/baseline.txt con la fecha y un comentario corto. "2026-04-30: 12/20, los que fallan son principalmente los casos con input poco claro." Este comentario es oro cuando dentro de dos semanas quieras saber qué no funcionaba entonces.

7. Haz un pequeño cambio en el system prompt

Cambia exactamente una cosa. Por ejemplo: en el system prompt escribes una frase sobre cómo debe tratar el agente el input poco claro. No diez cambios a la vez. Uno.

Ejecuta el eval otra vez. Anota la tasa de aprobados. Si sube, genial, conserva el cambio. Si baja, revierte. Si se queda igual: quizá el cambio ayude en casos de uso reales de todas formas, pero no tienes evidencia de eval de que aporte nada.

Ese es el núcleo de todo el patrón de eval: haces el cambio para que el eval mejore y no porque tu instinto diga que sería mejor. El instinto miente, la tasa de aprobados del eval miente con más dificultad.

8. LLM-as-judge para condiciones difusas

Algunas condiciones no las puedes comprobar de forma dura. "El título suena natural" es uno de esos ejemplos. Ahí llamas a un segundo LLM, le das el output y la condición, y dejas que devuelva un pass o fail con justificación.

async function llmJudge(output, criterion) {
  const prompt = `
Output: ${output}
Criterion: ${criterion}
Antworte mit PASS oder FAIL und einem Satz Begründung.
`
  const judgment = await callJudgeLLM(prompt)
  return judgment.startsWith('PASS')
}

Importante: el LLM juez no es el mismo agente que estás evaluando. Si no, se lo arregla todo a su favor. Coge un modelo distinto, idealmente uno barato porque esto corre cien veces por ejecución. Haiku o Gemini Flash son buenos jueces para tareas así.

LLM-as-judge no es perfecto. Cuenta con que el veredicto del juez sea aproximadamente un 80 por ciento correcto. Para una tendencia eso basta, para decisiones duras de compliance no.

9. Integra el eval en tu workflow de cambios

A partir de ahora: cada vez que toqueteas el agente, el eval corre antes y después. No commiteas un cambio sin conocer la tasa de aprobados. Si usas Git, escribes la tasa de aprobados en el mensaje de commit. "Pass: 15/20 (was 14/20)".

Esto tiene un efecto psicológico que no hay que subestimar: dejas de trastear con el agente cuando está en 18/20. Ya no haces "lo mejoro un poquito más" y rompes algo en el proceso. La tasa de aprobados es tu señal de parada.

10. Deja crecer los casos cuando algo te sorprenda

Cuando el agente la lía de verdad en el mundo real y el eval no lo detecta, entonces tu eval es el hueco. Mete la liada como un caso nuevo. Con el tiempo el conjunto de eval se vuelve robusto y atrapa el 90 por ciento de los problemas antes de que aterricen en producción.

Esa es la regla más importante: el conjunto de eval está vivo. Crece con el agente. Tira los casos que ya no testean nada, mete nuevos, y una vez por trimestre comprueba si los casos viejos siguen encajando con la tarea actual.

Qué viene después

Una vez que tienes el eval, el siguiente paso es la comparación multi-modelo. Deja correr los mismos veinte casos contra Sonnet, Haiku, Gemini Flash y GPT-5-mini. Te sorprenderá lo distintas que son las tasas de aprobados y con qué frecuencia el modelo más barato no es en realidad mucho peor que el más caro. Para eso tenemos la Lesson 1.5 "Modelle vergleichen" y la Recipe 5.x "Modell-Routing nach Pass-Rate". Echa un vistazo también al playbook "Hooks gegen Halluzinationen" si quieres comprobar la robustez de los casos de eval.

Source

• Anthropic Cookbook: Evaluations Patterns, github.com/anthropics/anthropic-cookbook (sección evaluation/)
• Promptfoo Docs: promptfoo.dev/docs (código abierto, licencia MIT, bueno para tus propios setups de eval)
• Inspect (UK AISI): inspect.ai-safety-institute.org.uk/docs (framework de eval open source, Python)