¿Cómo evaluar la planificación de un Agent? Guía práctica de profundidad de razonamiento, descomposición de tareas y autocorrección

Una evaluación de Agent corrió toda la noche y reportó un 94 % de precisión — en papel, impecable. En producción, en tres días llegaron 11 quejas: tareas que se quedaban a medias, bucles infinitos llamando al mismo tool, o pasos importantes saltados de golpe.

Los métodos tradicionales fallan. Un 94 % de precisión solo demuestra aciertos en Q&A de un solo turno, no si puede completar tareas de siete u ocho pasos de razonamiento. Es como medir la capacidad laboral con un examen de opción múltiple: puedes sacar buena nota y aun así no servir para el trabajo.

¿Cómo evaluar la planificación de un Agent? ¿Por qué la precisión sola no basta? ¿Cómo montar un sistema de evaluación que detecte problemas reales? Este artículo detalla metodologías para profundidad de razonamiento, descomposición de tareas y autocorrección, y compara benchmarks como AgentBench, ToolBench y ACPBench.

1. ¿Por qué evaluar un Agent es más complejo que evaluar un modelo?

Evaluar un modelo es bastante directo: das una pregunta y miras si la respuesta es correcta. Opción A o B, si el código pasa los tests, calidad de traducción — muchas dimensiones, pero la lógica es clara.

Un Agent es distinto. El equipo de ingeniería de Anthropic lo planteó en un blog de 2025: la capacidad de un Agent es de «proceso», no de «punto». No evalúas «si sabe», sino «si puede tomar una serie de decisiones correctas en un entorno complejo».

En concreto, un Agent necesita seis capacidades centrales:

1. Llamada a tools: saber cuándo usar qué tool y si los parámetros son correctos
2. Descomposición de tareas: partir un objetivo grande en pasos ejecutables con dependencias razonables
3. Razonamiento: manejar inferencia multi-salto, paso a paso, no de un golpe
4. Memoria: recordar el contexto previo sin olvidar el paso uno al llegar al dos
5. Autocorrección: detectar errores y ajustar, sin ir a ciegas hasta el final
6. Planificación a largo plazo: cadenas de decenas de pasos sin desviarse a mitad de camino

Las métricas clásicas — precisión, F1, BLEU — miden salidas puntuales. Un Agent exige evaluar el «proceso», y eso complica todo.

Un ejemplo. Pides a un Agent reservar un vuelo de Pekín a Shanghái: mañana por la tarde, presupuesto máximo 800 yuanes. Parece simple, pero implica:

• Consultar vuelos (llamada a tool)
• Filtrar resultados que cumplan condiciones (razonamiento)
• Si no hay coincidencia exacta, decidir si relajar horario o presupuesto (decisión)
• Llamar a la API de reserva (llamada a tool)
• Manejar errores de la API (autocorrección)

Si falla un paso, la tarea cae. Pero si solo miras el resultado final — «¿se reservó o no?» — pierdes mucha información. Puede haber elegido mal la hora, superado el presupuesto sin darse cuenta, o no reintentado tras un error de API.

Por eso el eval-driven development (desarrollo guiado por evaluación) importa tanto en Agents. Anthropic recomienda diseñar las evaluaciones desde el desarrollo y usarlas para iterar, no descubrir fallos tras el despliegue.

2. Dimensiones centrales para evaluar la planificación

Evaluar la planificación de un Agent se reduce a tres dimensiones: descomposición de tareas, profundidad de razonamiento y consistencia a largo plazo. Suena abstracto; vamos una por una.

Descomposición de tareas

En pocas palabras: ¿puede el Agent partir un objetivo grande en pasos ejecutables con relaciones razonables entre ellos?

La métrica clave se llama Plan Graph Coherence (coherencia del grafo de planificación). Representas los pasos como un grafo dirigido: cada nodo es una subtarea y las aristas son dependencias. Compruebas dos cosas:

1. Orden topológico válido: existe una secuencia de ejecución razonable, sin ciclos del tipo «hay que hacer B antes que A, pero A antes que B»
2. Sin dependencias circulares: el grafo no tiene ciclos

Un caso real de fallo: pedí a un Agent un informe de análisis de datos y generó este plan:

1. Recopilar datos
2. Limpiar datos
3. Analizar datos
4. Generar informe
5. Según el análisis, ampliar la recopilación de datos

¿Ves el problema? El paso 5 vuelve al 1, pero los pasos anteriores ya se ejecutaron. El Agent no detectó el ciclo y el flujo se quedó repitiendo pasos.

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

Ver precios →Anuncio

Los fallos típicos de descomposición son tres:

• Dependencia circular: como el ejemplo, pasos que forman un anillo
• Salto de pasos: ir directo a la conclusión omitiendo pasos clave
• Subtareas incompletas: pasos que no bastan para alcanzar el objetivo

Profundidad de razonamiento

Esta dimensión mide si el Agent maneja inferencia en varios pasos. DeepSeek-V3-0324 alcanza un 91 % en pruebas multi-salto, según su informe técnico. ¿Qué significa «multi-salto»?

Partes de un hecho conocido y necesitas N pasos para llegar a la respuesta. Por ejemplo:

• Dado: A es mayor que B, B es mayor que C
• Pregunta: ¿A o C es mayor?
• Eso es un problema de 2 saltos

En escenarios reales las cadenas suelen tener 5 pasos o más. Por ejemplo: «encuentra el producto con más ventas el mes pasado y analiza por qué vendió tan bien». Requiere:

1. Consultar ventas del mes anterior
2. Ordenar y encontrar el producto líder
3. Analizar sus características
4. Comparar con otros productos
5. Resumir las causas

Cada paso depende del anterior. La métrica es la precisión multi-salto, desglosada por número de saltos: a veces 3 saltos van bien y a 5 se desmorona.

Consistencia de planificación a largo plazo

Es la dimensión donde más falla la gente. En una tarea de 50 pasos, ¿el Agent recuerda el contexto inicial en el paso 30?

La métrica es State Drift Rate (tasa de deriva de estado): veces que el estado interno difiere del esperado durante la ejecución, dividido entre el total de pasos.

Un caso real: un Agent de atención al cliente gestionaba un reembolso con normalidad hasta que el usuario dijo «no, me refiero a otro pedido». El Agent se desorientó y el resto de la conversación giró en torno a ese «otro pedido», aunque el reembolso seguía siendo el original. Deriva de estado: perdió el ancla del contexto inicial en una conversación larga.

Lo ideal es State Drift Rate < 0.05 — como máximo 5 inconsistencias en 100 pasos. En la práctica, muchos Agents open source rondan entre 0.15 y 0.25; la brecha es enorme.

3. Comparativa en profundidad de los benchmarks principales

Hay bastantes benchmarks para Agents, cada uno con su enfoque. Repaso cuatro populares y una guía de elección.

AgentBench: el generalista

AgentBench, del equipo de Tsinghua en ICLR’24, tiene la cobertura más amplia. Evalúa la capacidad global del LLM como Agent en 8 entornos:

• Interacción con sistema operativo
• Consultas a base de datos
• Razonamiento sobre grafos de conocimiento
• Escenario de compras
• Motor de búsqueda
• Planificación doméstica
• Navegación web
• Videojuegos

Probó 29 LLM mainstream y ofrece comparativas horizontales muy completas. Si quieres ubicar rápido el nivel de un modelo, basta con la versión simplificada de AgentBench.

Pero tiene un hueco claro: no evalúa autocorrección. Solo mide «si acierta a la primera», no «si detecta el error y lo corrige». Y la autocorrección es justo lo que más importa en producción.

ACPBench: especialista en profundidad de razonamiento

ACPBench de IBM se centra en razonamiento profundo sobre lógica de planificación. ACP son Action, Change, Planning — el nombre lo dice todo.

Su diferencial es la verificación formal del razonamiento. No solo mira si la salida es correcta, sino si el proceso cumple reglas lógicas. Si pides planificar un viaje, valida que cada paso cumpla sus precondiciones y que la causalidad sea coherente.

Encaja cuando necesitas probar a fondo la planificación, no solo el resultado final. La cobertura es estrecha: planificación lógica, sin tools ni multimodal.

ToolBench: dedicado a llamadas a tools

ToolBench evalúa la capacidad de invocar APIs. Si desarrollas un Agent orientado a tools — un asistente que llama APIs externas — este benchmark encaja mejor.

Ofrece escenarios masivos de API-planning y mide:

• Si elige la API correcta
• Si los parámetros son correctos
• Si encadena varias APIs con lógica coherente
• Si maneja fallos de invocación

Muy útil para evaluar el uso de herramientas.

DeepPlanning: planificación de largo ciclo

DeepPlanning se enfoca en planificación agentic de largo plazo. Donde otros benchmarks prueban 5-10 pasos, aquí van cadenas de 20-50 pasos o más.

Sirve para consistencia a largo plazo: ¿recuerda el objetivo inicial tras decenas de pasos? ¿Se pierde a mitad de camino? DeepPlanning ayuda a detectarlo.

Guía de elección

Mi recomendación: primero AgentBench para la línea base; luego el benchmark especializado según tu negocio. Si tu Agent vive de tools, prioriza ToolBench; si de planificación compleja, ACPBench y DeepPlanning.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

4. Evaluación práctica de la autocorrección

Esta sección puede ser la más importante del artículo. En producción un Agent no acierta siempre. La clave: ¿detecta el error? ¿Puede corregirlo?

¿Por qué importa la autocorrección?

Los datos hablan. Reflexion es un framework clásico de autorreflexión: subió la tasa de HumanEval del 80 % al 91 % — 11 puntos porcentuales, nada trivial. En AlfWorld resolvió 130 de 134 retos, un 97 % de éxito.

"Reflexion es un framework de autorreflexión que, tras un fallo, hace que el Agent analice la causa y ajuste la estrategia, elevando la tasa de HumanEval del 80 % al 91 % y alcanzando un 97 % en AlfWorld (130/134)."

Otro estudio (equipo Galileo) muestra que la autorreflexión mejora el rendimiento en resolución de problemas entre un 9 % y un 18,5 %. La diferencia es grande.

Cómo funciona la arquitectura Reflexion

El mecanismo es simple, cuatro pasos:

1. Ejecución: el Agent intenta completar la tarea
2. Reflexión: si falla, analiza la causa
3. Corrección: ajusta la estrategia según la reflexión
4. Reintento: prueba de nuevo con la nueva estrategia

Lo crucial es la reflexión: no un «inténtalo otra vez» a ciegas, sino explicar «por qué falló» y «cómo cambiar». Eso exige metacognición — revisar el propio proceso de pensamiento.

¿Cómo evaluar la autocorrección?

Un esquema operativo:

Paso 1: inyectar errores controlados

En el entorno de prueba provoca escenarios de error reproducibles:

• Timeout en llamada a tool
• Código de error de API
• Formato de parámetros incorrecto
• Recurso inexistente

Deben ser reproducibles para comparar Agents en las mismas condiciones.

Paso 2: observar la reacción del Agent

Registra:

• ¿Reconoce que hubo un error?
• ¿Intenta analizar la causa?
• ¿Qué estrategia de corrección adopta?
• ¿Tuvo éxito tras corregir?
• ¿Cuántos reintentos?

Paso 3: métricas

Tres indicadores centrales:

1. Tasa de recuperación: proporción de errores corregidos con éxito por el propio Agent
2. Reintentos medios: intentos desde el error hasta el éxito
3. Tasa de logro final: porcentaje de tareas completadas incluyendo las que requirieron corrección

Una buena evaluación distingue «acierto a la primera» de «falló pero se corrigió». Lo primero habla de capacidad base; lo segundo, de autocorrección.

Un ejemplo concreto

Probé un Agent con la tarea: consultar usuarios en la base de datos y generar un informe.

En la primera ejecución la consulta SQL era incorrecta y la base devolvió vacío. Dos caminos:

• Sin autocorrección: genera el informe con datos vacíos — todo «no se encontraron datos»
• Con autocorrección: detecta el vacío, reflexiona si la consulta falló, corrige y reintenta

La evaluación captura esa diferencia. En el informe puedes separar:

• Tasa de éxito a la primera
• Tasa de éxito tras corrección
• Tasa de fallo definitivo

Esas tres cifras forman el perfil completo del Agent.

5. Construir tu sistema de evaluación de Agent

Bastante teoría; toca aterrizar. Una arquitectura en tres capas lista para usar.

Arquitectura en tres capas

Capa 1: capacidades básicas

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

Obtener 15% dto. →Anuncio

Prueba habilidades puntuales, cada una por separado:

• Precisión en llamadas a tools: API y parámetros correctos
• Precisión en descomposición de tareas simples
• Precisión en razonamiento de un solo paso

Enfoque de tests unitarios: cada prueba corre sola, sin interferencias.

Capa 2: tareas de escenario

Simula flujos de negocio reales:

• Varios procesos típicos
• Cada uno con 5-15 pasos
• Ramas normales y de excepción (escenarios que exigen corrección)

Aquí evalúas combinación de capacidades, no puntos aislados.

Capa 3: evaluación integral

Agrega todos los resultados:

• Resumen por dimensión
• Puntuación ponderada según importancia del negocio
• Informe visual

Estandarizar el flujo de evaluación

Para un sistema repetible, organízalo así:

# Levantar entorno de evaluación
docker compose -f eval-spec.yml up --build

# Ejecutar benchmark indicado, 3 repeticiones para la media
python run_eval.py --benchmark agentbench-v2.1 --num-trials 3

# Exportar informe
python export_report.py --format markdown --output eval_results.md

Lo importante: «3 repeticiones». La salida de un Agent tiene aleatoriedad; una sola corrida es inestable; la media de varias es más fiable.

Lista de métricas clave

Una tabla lista para usar como estándar:

Estos umbrales son referencias de experiencia. Ajusta según tu escenario — algunos exigen más, otros pueden relajarse.

Conclusión

La idea central: evaluar un Agent no es mirar el resultado final, sino la calidad del proceso. Las métricas clásicas solo dicen «acierto o fallo»; un Agent necesita análisis fino del camino — cómo llegó ahí, si tomó desvíos, si se corrigió solo.

El eval-driven development debería ser el flujo estándar. No esperes al despliegue para descubrir fallos; monta la evaluación en desarrollo y deja que los datos guíen la iteración.

Si vas a empezar ya:

1. Corre AgentBench para una línea base
2. Elige 2-3 benchmarks especializados según tu escenario
3. Monta la arquitectura en tres capas y estandariza el flujo
4. Evalúa en cada iteración y compara con datos

La fiabilidad de un Agent no se juzga «a ojo»; hay que demostrarla con evaluaciones. Espero que esta guía te evite algunos errores típicos.

Referencias

• Anthropic Engineering: Demystifying evals for AI agents - Blog de ingeniería oficial, 2025
• AgentBench: Evaluating LLMs as Agents (ICLR’24) - Equipo Tsinghua, benchmark académico
• Survey on Evaluation of LLM-based Agents - Revisión arXiv, 2026
• Self-Reflection in LLM Agents - Paper Reflexion
• ACPBench: Reasoning about Action, Change, and Planning - Investigación IBM