Guía práctica de benchmarks de evaluación de Agent: pruebas de rendimiento desde AgentBench hasta DeepEval

Probé un Agent de atención al cliente con 100 casos de prueba: tasa de éxito del 78%. No parecía mal. Luego ejecuté la misma batería otra vez y la tasa bajó al 65%.

Evaluar un Agent no tiene nada que ver con la evaluación de preguntas y respuestas convencional. En un modelo de QA, si preguntas «¿capital de Francia?» y responde «París», acierta; si dice «Marsella», falla. Blanco o negro. Un Agent piensa, planifica, llama herramientas y puede cambiar de rumbo a mitad de camino. La misma tarea puede completarse por la ruta A hoy, fallar por la B mañana y volver a tener éxito por la C pasado mañana.

Leí montones de papers y documentación de AgentBench, WebArena y otros benchmarks, y cuanto más leía, más confuso estaba. Después de tropezar en varios proyectos, entendí algo clave: evaluar un Agent no basta con mirar el destino; hay que mirar la trayectoria.

1. ¿Por qué evaluar un Agent es más difícil que evaluar QA?

El problema central del Agent es su autonomía. En cada ejecución puede elegir un camino distinto.

Un ejemplo concreto. Probé un Agent de reservas de viajes con la tarea «reserva el vuelo más barato de Pekín a Shanghái para mañana». La primera vez consultó Ctrip, comparó tres vuelos, eligió el más barato y completó la reserva: perfecto. La segunda vez, con la misma tarea, consultó Ctrip, luego Fliggy, entró en un bucle de cinco minutos y acabó en timeout.

Misma entrada, trayectorias distintas. Ahí está la dificultad: no necesitas una etiqueta simple de acierto/error, sino un marco que analice todo el proceso de ejecución.

Marco de evaluación en tres capas

Según la documentación oficial de Anthropic, conviene evaluar un Agent en tres capas:

Capa de razonamiento (Reasoning Layer): ¿La planificación es correcta? ¿Entiende bien la tarea? ¿El plan de ejecución es razonable?

Capa de acción (Action Layer): ¿Elige la herramienta adecuada? ¿Los parámetros son correctos? ¿El orden de las llamadas tiene sentido?

Ejecución global (Overall Execution): ¿Se completó la tarea? ¿Cuántos pasos tomó? ¿Qué tan eficiente fue?

Un dato de la documentación de DeepEval me llamó la atención: el fallo en llamadas a herramientas es el problema más frecuente en Agent. Cerca del 40% de los fallos se deben a elegir mal la herramienta o pasar parámetros incorrectos. La mayoría de los problemas están en la capa de acción, no en la de razonamiento.

Límites de las métricas tradicionales

En evaluación de QA, precisión y F1 suelen bastar. Con Agent, no.

Supón que tu Agent tiene una tasa de éxito del 78%. ¿Qué te dice ese número? Casi nada.

Porque ese 78% puede significar:

• Planificación correcta pero fallo en herramientas (problema en la capa de acción)
• Planificación errónea y esfuerzo inútil después (problema en razonamiento)
• Plan y herramientas correctos, pero fallo en el último paso (problema de ejecución global)

Cada causa exige optimizaciones distintas. Si falla la planificación, toca ajustar el prompt o cambiar el modelo; si fallan las herramientas, revisar definiciones y validaciones; si falla el paso final, puede ser un caso límite mal manejado.

La pregunta clave no es «¿tuvo éxito?», sino «¿dónde falló?».

2. Comparación de cinco benchmarks de evaluación principales

Hay muchos benchmarks de evaluación de Agent. Estos cinco son los que más he investigado o ejecutado en la práctica.

AgentBench: benchmark de capacidades integrales

AgentBench, publicado por Tsinghua en ICLR’24, fue uno de los primeros benchmarks integrales para LLM-as-Agent. Cubre 8 entornos: consultas a bases de datos, navegación web, llamadas a API, ejecución de código, etc.

Mi impresión tras ejecutarlo: la cobertura es amplia y sirve bien para comparar modelos como backbone de Agent. Pero montar el entorno es laborioso (requiere Docker) y solo el Dev set implica más de 4000 llamadas al LLM, con costo elevado.

Escenario ideal: elegir entre varios modelos como backbone de Agent y obtener una puntuación integral.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

WebArena: especializado en navegación Web

WebArena se centra en entornos Web. Monta sitios reales (e-commerce, foros, mapas) y pide al Agent completar tareas de navegación.

Por ejemplo: «encuentra un post en Reddit y comenta». Mide la capacidad del Agent para operar en un entorno Web real.

Escenario ideal: Agent de navegador o automatización Web.

τ-Bench: pruebas de diálogo multironda

τ-Bench (se lee tau-bench), con participación de Anthropic, se enfoca en interacción multironda. Simula escenarios reales como atención al cliente en retail o reservas aéreas, con un usuario simulado que dialoga con el Agent.

Lo distintivo: evalúa el rendimiento en conversaciones de varias vueltas, no solo tareas de una sola ronda.

Escenario ideal: Agent conversacional de soporte o reservas.

SWE-Bench: benchmark de capacidades de código

SWE-Bench mide capacidades de programación. Toma issues y PR reales de GitHub y pide al Agent que repare el código.

Es exigente: el Agent debe entender la estructura del proyecto, localizar el problema y escribir código que pase los tests.

Escenario ideal: asistente de programación o Agent de reparación de código.

Claw-Eval / ACE-Bench: benchmarks nuevos de 2026

Claw-Eval (luego renombrado ACE-Bench) es un benchmark de 2026 con dificultad configurable. Puedes ajustar la dificultad de las tareas según el nivel de tu Agent.

La idea es buena: la evaluación no es puntual, sino continua. Si mejora el Agent, sube también la dificultad de las tareas.

Escenario ideal: evaluación empresarial personalizada o un sistema de evaluación que evolucione con el tiempo.

Decisión de selección de benchmark

No hay respuesta única; depende de tu escenario:

Mi recomendación: empieza con AgentBench para fijar una línea base integral y luego profundiza con benchmarks específicos según tu escenario.

3. Sistema de métricas de evaluación de Agent

Tras los benchmarks, ¿con qué métricas medir el rendimiento? Estas seis cubren las distintas capas de evaluación.

1. Tasa de éxito (Success Rate)

La métrica más directa: ¿se completó la tarea?

Pero hay un matiz: ¿qué cuenta como «completado»? ¿Basta con que el Agent diga que terminó, o hace falta un criterio objetivo?

Mi enfoque actual: definir condiciones de aceptación claras. En «reservar vuelo», por ejemplo:

• Existe número de pedido
• La información del vuelo es correcta
• El precio está dentro del rango esperado

Cuanto más explícitas sean las condiciones, más útil será la tasa de éxito.

2. Precisión en llamadas a herramientas

Esta métrica tiene dos partes: elegir la herramienta correcta y pasar los parámetros correctos.

Elegir la herramienta correcta significa que, cuando hace falta invocar una herramienta, el Agent elige la adecuada. Pasar los parámetros correctos implica formato y contenido válidos.

En proyectos reales, esta métrica expone debilidades con claridad. En un Agent obtuve 82% de éxito en tareas pero solo 68% de precisión en herramientas: a menudo confundía operaciones de «consulta» y «reserva».

3. Tasa de progreso (Progress Rate)

En tareas de varios pasos, la tasa de progreso indica hasta dónde llegó el Agent.

Si una tarea tiene 5 pasos y falla en el 4.º, la tasa de éxito es 0%, pero la tasa de progreso es 80%. Juntas dicen que el Agent está cerca del objetivo y quizá solo falta optimizar el último paso.

4. Métricas de calidad de razonamiento

Evalúan la capacidad de planificación del Agent:

PlanQuality (calidad del plan): ¿El plan es razonable? ¿La lógica entre pasos es coherente?

PlanAdherence (adherencia al plan): ¿La ejecución real se desvió del plan original?

Estas métricas suelen evaluarse con otro LLM. PlanQualityMetric de DeepEval funciona así: un LLM juzga la calidad de la planificación del Agent.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

5. Métricas de eficiencia

StepEfficiency (eficiencia de pasos): ¿Cuántos pasos usó el Agent? ¿Cuántos serían teóricamente mínimos?

Si una tarea puede completarse en 3 pasos y el Agent usa 10, StepEfficiency es 30%.

También importa el consumo de tokens, ligado directamente al costo. Dos Agent que completan la misma tarea con 1000 y 5000 tokens implican una diferencia de costo de 5×.

6. Métricas de estabilidad

¿El rendimiento es estable? Si ejecutas la misma tarea 10 veces, ¿cuál es la desviación estándar de la tasa de éxito?

Antes no le daba mucha importancia, hasta que tras un despliegue vi un Agent que en pruebas iba bien pero en producción fluctuaba mucho. Resultó que el timeout de producción era más corto que en pruebas y algunas tareas se cortaban a medias.

Correspondencia con el marco de tres capas

Si una métrica baja, sabes en qué capa está el problema y hacia dónde optimizar.

4. Comparación de herramientas open source: DeepEval vs LangSmith vs Arize Phoenix

Con las métricas definidas, ¿qué herramienta usar? Comparé tres opciones open source populares.

DeepEval: primera opción para evaluación a nivel de componente

DeepEval es un framework Python open source de Confident AI, pensado para evaluar LLM y Agent.

Su característica central: evaluación a nivel de componente. Puedes insertar evaluación en cualquier nodo del Agent, no solo en el resultado final.

Incluye 6 métricas principales:

• TaskCompletionMetric (finalización de tarea)
• StepEfficiencyMetric (eficiencia de pasos)
• ToolCorrectnessMetric (corrección de herramientas)
• ArgumentCorrectnessMetric (corrección de parámetros)
• PlanQualityMetric (calidad de planificación)
• PlanAdherenceMetric (adherencia al plan)

En un proyecto de reservas de viajes, DeepEval funcionó muy bien. El decorador @observe rastrea automáticamente razonamiento y llamadas a herramientas durante la ejecución y evalúa capa por capa.

DeepEval también tiene la plataforma Confident AI para visualizar resultados y gestionar datasets. La parte open source ya basta para muchos casos.

LangSmith: producto oficial de LangChain

Si desarrollas Agent con LangChain, LangSmith es la opción más cómoda. Se integra sin fricción y rastrea automáticamente toda la cadena de ejecución.

Su fortaleza es el trazado de extremo a extremo: cada llamada al LLM y cada ejecución de herramienta quedan registradas en la trayectoria completa.

Es un producto comercial con límites de precio. Para pruebas pequeñas va bien; a escala, el costo sube.

Arize Phoenix: prioridad en observabilidad

Arize Phoenix se basa en OpenTelemetry y se centra en observabilidad.

Trata la ejecución del Agent como un sistema distribuido: llamadas al LLM y a herramientas son Spans; la trayectoria completa es un Trace.

Phoenix encaja muy bien con monitorización en producción: detección de anomalías, análisis de rendimiento, etc.

Decisión de selección

Depende de tu contexto:

¿Usas LangChain?
  → Sí: prioriza LangSmith (integración fluida)
  → No: ¿Necesitas monitorización en producción?
       → Sí: Arize Phoenix + DeepEval
       → No: solo evaluación en desarrollo → DeepEval

Mi combinación habitual: DeepEval en desarrollo y Arize Phoenix en producción. Se complementan bien.

5. Código en la práctica: evaluar un Agent de reservas de viajes con DeepEval

Tras la teoría, algo concreto. A continuación, un ejemplo completo de evaluación con DeepEval que usé en un proyecto real de reservas de viajes.

Implementación del Agent

Primero, un Agent sencillo de reservas con el decorador @observe en cada componente:

from deepeval.tracing import observe
from deepeval.metrics import (
    PlanQualityMetric,
    PlanAdherenceMetric,
    ToolCorrectnessMetric,
    ArgumentCorrectnessMetric,
    TaskCompletionMetric,
    StepEfficiencyMetric
)

# 定义工具
@observe(type="tool")
def search_flights(origin: str, destination: str, date: str):
    """搜索航班"""
    # 实际项目中这里会调用真实的 API
    # 示例返回模拟数据
    return [
        {"flight": "CA1234", "price": 500, "time": "08:00"},
        {"flight": "MU5678", "price": 450, "time": "10:30"},
        {"flight": "CZ9012", "price": 520, "time": "14:00"}
    ]

@observe(type="tool")
def book_flight(flight_number: str, passenger_info: dict):
    """预订航班"""
    # 实际项目中这里会调用真实的预订 API
    return {"order_id": "ORD123456", "status": "confirmed"}

# Agent 主体
@observe(type="agent")
def travel_agent(user_input: str):
    """
    旅行预订 Agent
    输入：用户的预订请求
    输出：预订结果或失败信息
    """
    # 推理层：解析任务并制定计划
    @observe(type="reasoning")
    def parse_and_plan(input_text):
        # 这里应该调用 LLM 来解析和规划
        # 示例使用简单的规则解析
        plan = {
            "task": "book_flight",
            "origin": "北京",
            "destination": "上海",
            "date": "明天",
            "steps": ["search", "compare", "book"]
        }
        return plan

    plan = parse_and_plan(user_input)

    # 行动层：执行工具调用
    # 步骤1：搜索航班
    flights = search_flights(
        plan["origin"],
        plan["destination"],
        plan["date"]
    )

    # 步骤2：选择最便宜的航班
    cheapest = min(flights, key=lambda x: x["price"])

    # 步骤3：预订
    result = book_flight(
        cheapest["flight"],
        {"name": "测试用户"}
    )

    return result

Configuración de métricas de evaluación

from deepeval import evaluate
from deepeval.test_case import LLMTestCase

# 定义测试数据
test_cases = [
    LLMTestCase(
        input="预订明天从北京到上海最便宜的航班",
        expected_output={"order_id": "ORD123456", "status": "confirmed"}
    ),
    LLMTestCase(
        input="帮我查一下下周三从广州到深圳的航班",
        expected_output={"flights": [...]}
    )
]

# 配置评估指标
metrics = [
    TaskCompletionMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    ),
    StepEfficiencyMetric(
        threshold=0.5,  # 期望至少 50% 效率
        minimum_steps=3  # 最少需要 3 步
    ),
    ToolCorrectnessMetric(
        threshold=0.8
    ),
    ArgumentCorrectnessMetric(
        threshold=0.8
    ),
    PlanQualityMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    )
]

Ejecución de la evaluación

# 方法1：单次评估
for test_case in test_cases:
    result = travel_agent(test_case.input)
    test_case.actual_output = result

evaluate(test_cases, metrics)

# 方法2：数据集批量评估
from deepeval.dataset import EvaluationDataset, Golden

dataset = EvaluationDataset(goldens=[
    Golden(input="预订明天从北京到上海最便宜的航班"),
    Golden(input="查找下周从成都到昆明的航班信息")
])

for golden in dataset.evals_iterator(metrics=metrics):
    output = travel_agent(golden.input)
    # 评估会自动记录和计算

Interpretación de resultados

DeepEval devuelve la puntuación y el estado de aprobación de cada métrica. Supón que obtienes:

¿Qué indica esto?

• La tasa de finalización es alta (85%): la mayoría de tareas se completan
• La eficiencia de pasos es baja (45%): el Agent probablemente da pasos de más
• La selección de herramientas es muy buena (90%), pero la corrección de parámetros no (72%)

La dirección de optimización queda clara: priorizar la lógica de construcción de parámetros y reducir pasos innecesarios.

6. Evaluación en entorno de producción

Terminada la evaluación en desarrollo y desplegado el Agent, ¿acaba ahí? Lejos de eso.

En producción el comportamiento suele diferir: entradas más aleatorias, más casos límite y más presión de concurrencia. Hace falta un bucle completo de evaluación de desarrollo a producción.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Fase de desarrollo: establecer la línea base

El objetivo en desarrollo es fijar la capacidad de referencia del Agent.

Primero ejecuta un benchmark integral como AgentBench para medir capacidades generales. Luego prueba escenarios concretos con un dataset personalizado que cubra tareas típicas, casos límite y fallos.

En desarrollo conviene:

• Cobertura del dataset de prueba ≥ 80% de escenarios de usuario
• Valor de referencia explícito para cada métrica
• Registro de casos fallidos y análisis de la distribución de causas

Fase de despliegue: gris y pruebas A/B

No publiques a todo el tráfico de golpe. Empieza en gris.

La evaluación en gris compara el rendimiento del grupo de tratamiento frente al control.

# 灰度评估示例
def ab_test_evaluation():
    # 对照组：旧版本 Agent
    control_results = evaluate_agent(old_agent, test_cases)

    # 灰度组：新版本 Agent
    treatment_results = evaluate_agent(new_agent, test_cases)

    # 对比关键指标
    comparison = {
        "success_rate": {
            "control": control_results.success_rate,
            "treatment": treatment_results.success_rate,
            "delta": treatment_results.success_rate - control_results.success_rate
        },
        "step_efficiency": {
            "control": control_results.step_efficiency,
            "treatment": treatment_results.step_efficiency,
            "delta": treatment_results.step_efficiency - control_results.step_efficiency
        }
    }

    return comparison

Proporción de gris recomendada: 1% durante 24 horas, luego 5%, 10%, 20%, 50% y 100%. En cada paso revisa las métricas clave.

Fase de producción: monitorización continua

En producción, la evaluación se convierte en monitorización.

El foco es detectar anomalías: caída brusca de la tasa de éxito, aumento de latencia o fallos repetidos en una herramienta. Las alertas deben llegar a tiempo, antes de que los usuarios reporten el problema a escala.

Estrategia de muestreo: no puedes evaluar cada petición. Recomendación:

• Tareas normales: muestreo del 1%-5%
• Tareas críticas (pago, reservas): evaluación al 100%
• Peticiones anómalas (fallo, timeout): 100% en cola de evaluación

Control de costos: evaluar también cuesta, sobre todo si usas un LLM para calidad de razonamiento. Algunos trucos:

• Modelos pequeños para evaluar (por ejemplo gpt-4o-mini)
• Evaluación asíncrona sin bloquear el flujo principal
• Circuit breaker con límite de muestras 100-1000

La necesidad de revisión manual

Por buena que sea la evaluación automática, hay casos límite que requieren revisión humana.

Mi enfoque actual: los casos marcados como «inciertoos» por la evaluación automática van a una cola de revisión manual. Cada semana reviso 10-20 casos para comprobar la precisión de la evaluación automática.

La revisión manual también detecta problemas que la evaluación automática no cubre: tono inadecuado en las respuestas o confusión para el usuario — difíciles de medir automáticamente, pero muy dañinos para la experiencia.

Un bucle completo de evaluación

Resumiendo el flujo:

Fase de desarrollo
├── Benchmark AgentBench
├── Evaluación con dataset personalizado
└── Análisis de casos fallidos
    ↓
Fase de despliegue
├── Prueba en gris (1% → 5% → 10% → ...)
├── Evaluación A/B comparativa
└── Mecanismo de rollback
    ↓
Fase de producción
├── Monitorización por muestreo (1%-5%)
├── Alertas por detección de anomalías
├── Cola de revisión manual
    ↓
Optimización iterativa
├── Atribución de fallos
├── Ajuste de prompts/herramientas
└── Reevaluación
    ↓ (bucle)

Es un proceso continuo, no un trabajo puntual. Las capacidades del Agent pueden degradarse, cambian los escenarios de usuario y aparecen problemas nuevos — la evaluación debe evolucionar con ellos.

Conclusión

Evaluar un Agent, en pocas palabras: no mires solo el destino, mira la trayectoria.

Errores que cometí: creer que 78% de éxito bastaba y descubrir en producción fluctuaciones del 30% en la misma tarea. Pensar que las herramientas iban bien cuando el 40% de los fallos eran parámetros incorrectos. Confiar en que la evaluación de desarrollo cubría producción.

El marco de tres capas ordenó el razonamiento: razonamiento (plan), acción (herramientas), ejecución global (resultado). Los cinco benchmarks ayudaron a fijar la línea base: AgentBench integral, τ-Bench multironda, SWE-Bench para código. DeepEval permitió evaluación en código: @observe rastrea componentes y seis métricas analizan capa por capa.

Próximos pasos:

1. Ejecuta AgentBench con tu Agent y establece la línea base
2. Usa DeepEval para evaluación a nivel de componente y localiza puntos débiles
3. Monta monitorización en producción con detección de anomalías y revisión manual

La evaluación no es el final, es el punto de partida. A medida que evoluciona el Agent, la evaluación debe evolucionar con él.