Agent Evaluation

AI Evaluation Fundamentals aporta el marco general para definir objeto, casos, criterios, graders e interpretación. Agent Evaluation es la práctica de juzgar el comportamiento de un sistema agente mediante criterios explícitos sobre un conjunto de tareas y ejecuciones pertinentes. Puede examinar éxito, uso de herramientas, eficiencia, fiabilidad, recuperación, respeto de límites e intervención humana. La unidad evaluada incluye cómo modelo, contexto, instrucciones, harness y entorno trabajan juntos; no se reduce automáticamente a una capacidad del modelo.

La pregunta central es qué comportamiento puede sostenerse sobre ese sistema en las condiciones examinadas y con qué límites de generalización. Un resultado alto en un benchmark no garantiza calidad de ingeniería en producción. Una traza disponible no constituye por sí misma una evaluación y una ejecución exitosa no establece una tasa de éxito. Hacen falta casos, criterios y evidencia interpretables.

Evaluación entre casos y verificación de un cambio

Generated Code Verification pregunta si este cambio satisface esta tarea concreta. Agent Evaluation pregunta cómo se comporta el sistema entre tareas y runs. Los resultados de verificación pueden servir como etiquetas de una suite de coding tasks, pero ambas actividades conservan responsabilidades distintas. Un agente con buen promedio puede fallar en el patch actual; un cambio bien respaldado no demuestra fiabilidad general del agente.

Evaluar también difiere de monitoring. Monitoring observa señales de operación; la evaluación juzga comportamiento frente a criterios y casos seleccionados. Observability aporta señales para investigar y puede alimentar ese juicio. Tener métricas o traces no demuestra que se hayan aplicado criterios pertinentes ni que los casos representen el uso que interesa. Sus tratamientos generales no se desarrollan aquí.

La investigación ha usado entornos interactivos para ampliar lo observado más allá de una respuesta aislada. AgentBench, publicado en ICLR 2024, propone evaluar agentes en varias clases de entorno. Es un ejemplo de diseño de evaluación, no una taxonomía obligatoria ni evidencia de la capacidad actual de todos los sistemas disponibles.

Definir qué se quiere decidir

Una evaluación útil empieza por una decisión: comparar configuraciones, detectar una regresión o entender fallos de una clase de tareas. Esa intención determina qué casos y resultados importan. Medir lo que una herramienta expone fácilmente puede responder otra pregunta. Por ejemplo, el número de llamadas no demuestra corrección ni costo monetario, y la velocidad puede ser irrelevante si el resultado omite parte del encargo.

Conviene declarar el sistema examinado y sus condiciones. Agent Harness organiza el loop y herramientas; Agent Execution Environment aporta recursos y estado de ejecución. Instrucciones, contexto y permisos pueden cambiar qué acciones son posibles. Si varían durante la comparación, un cambio de score no puede atribuirse sin más al modelo.

Los criterios pueden combinar resultados y límites: satisfacer una tarea, evitar modificaciones fuera de alcance, preservar contratos y detenerse correctamente ante falta de autoridad. Una solicitud legítima de intervención humana no necesariamente es un fallo. Debe juzgarse según el encargo y las Agent Permissions and Approval Boundaries, en vez de premiar autonomía ilimitada.

Casos representativos y condiciones reproducibles

El conjunto de casos debe reflejar el trabajo para el que se desea utilizar el sistema. Una suite de cambios locales pequeños informa poco sobre migraciones entre componentes si nunca las incluye. Conviene identificar familias, restricciones y dificultad relevante, sin asumir que existe una única distribución de tareas válida para todos los equipos.

Cada caso necesita un estado inicial identificable, un encargo y criterios de resultado. En un repositorio importa la revisión y cualquier cambio local pertinente. Las herramientas disponibles, datos y dependencias externas también pueden afectar la ejecución. Conservar esas condiciones facilita interpretar diferencias, aunque no garantice resultados idénticos cuando el sistema o el entorno tienen variabilidad.

Los casos conocidos pueden influir en prompts, procedimientos o soluciones disponibles al sistema. Esa exposición limita qué se puede concluir sobre generalización. Una evaluación no debería presentar tareas ajustadas repetidamente al mismo agente como prueba independiente de capacidad nueva. Métodos generales de datasets y evaluación tienen su propio alcance; aquí basta mantener visible la procedencia y las limitaciones del conjunto utilizado.

Coding-Agent Task Evaluation

Las tareas de coding pueden incluir bugs, funcionalidades, refactorizaciones, tests, documentación, upgrades y diagnóstico de CI. Sus resultados útiles difieren. Resolver un bug necesita relacionar el síntoma con un cambio y evidencia pertinente. Una tarea de investigación puede terminar correctamente con una causa todavía no confirmada si ese era el alcance y se documentan los hallazgos.

Una refactorización puede exigir preservar comportamiento y mejorar una estructura acordada; generar muchas líneas no es una medida de éxito. En documentación importa precisión y coherencia con fuentes. En upgrades importan resolución efectiva y compatibilidad. En CI interesa identificar ejecución, evidencia y causa candidata o confirmada, sin asumir autoridad para desplegar. La suite debe juzgar cada tarea con sus expectativas.

SWE-bench plantea problemas de mantenimiento derivados de issues reales sobre repositorios existentes, en vez de limitar el trabajo a completar funciones aisladas. Ese diseño ilustra por qué el contexto del repositorio y los cambios coordinados importan al evaluar coding. No convierte aplicar un patch ni pasar cualquier test visible en una definición universal de éxito profesional.

Un patch puede aplicarse y compilar sin resolver la necesidad. También puede satisfacer un test estrecho mediante una excepción artificial o modificar el propio criterio de éxito. AI-Assisted Test Generation y AI-Assisted Code Review aportan actividades útiles, pero sus artefactos no sustituyen evaluar el resultado contra la tarea y sus restricciones.

Tool-Use and Trace Evaluation

La evaluación de herramientas puede examinar selección, argumentos, orden, fallos, reintentos y uso de la evidencia obtenida. Una llamada correcta a una herramienta irrelevante puede desperdiciar trabajo; una llamada que falla puede ser razonable si descubre un límite real y conduce a recuperación. No basta con contar éxitos de API sin interpretar qué necesitaba la tarea.

Agent Tracing organiza evidencia de eventos observables: solicitudes, resultados, estados, errores, acciones y terminación. No requiere registrar private chain-of-thought. Un evaluador puede comprobar que se pidió una lectura, qué resultado devolvió y si el cambio posterior contradice ese dato. Eso es diferente de exigir acceso a razonamiento interno para justificar toda decisión.

Importa preservar correlación y resultados parciales. Una respuesta asociada a otra solicitud puede dar apariencia de progreso a un recorrido incorrecto. Un proceso detenido por límite de tiempo necesita distinguirse de una tarea completada. Development Context and Execution Records conserva evidencia útil para este análisis sin convertir la disponibilidad de un log en un juicio de calidad.

También pueden observarse intentos de acciones fuera de los límites autorizados, aun cuando el entorno los haya bloqueado. Ese evento y su consecuencia real son dimensiones diferentes. La evaluación necesita criterios explícitos para interpretarlos y datos seleccionados sin exponer secretos innecesarios. No se prescribe aquí una plataforma de tracing ni una política general de seguridad.

Harness-Aware Evaluation

Harness-aware evaluation considera que herramientas, entrega de contexto, instrucciones, permisos y recursos condicionan el comportamiento observado. Un agente que no encuentra un archivo porque el índice está obsoleto no exhibe necesariamente el mismo tipo de fallo que uno que ignora evidencia correcta. Una comparación que cambia simultáneamente esas condiciones puede mostrar un resultado práctico, pero tiene capacidad limitada para atribuir causas.

Model-only evaluation intenta aislar capacidades del modelo bajo un diseño apropiado. Agent Evaluation observa el sistema que actúa. No son enfoques intercambiables ni hay que atribuir cada error del conjunto al modelo. Tampoco corresponde exculparlo automáticamente porque existe un harness: la evidencia debe permitir ubicar qué parte del recorrido produjo el resultado.

Una comparación puede mantener el encargo y la base del repositorio constantes mientras cambia una herramienta. Debe declarar qué otras condiciones permanecieron estables y cuáles no pudieron controlarse. Si las dos condiciones se ejecutan en la misma conversación, hay familiaridad y transferencia de información posibles. Ese diagnóstico puede ser útil para medir recuperación, pero no debería presentarse como un experimento aislado de consumo del modelo.

Eficiencia y costo con calidad

Más llamadas no significan mejor agente: pueden expresar repetición, consultas irrelevantes o recuperación fallida. Menos llamadas tampoco significan mejor resultado: pueden omitir evidencia necesaria o dejar trabajo incompleto. Una métrica de eficiencia necesita interpretarse junto con la calidad y los límites respetados. La reducción solo es útil para la decisión si no destruye el resultado que interesa.

AI Agents That Matter cuestiona evaluaciones centradas únicamente en accuracy y señala problemas de costo, sobreajuste y reproducibilidad. Esas observaciones motivan declarar varias dimensiones en lugar de convertir un único leaderboard en una recomendación universal. Aquí se utilizan como fundamento de la cautela, sin adoptar resultados históricos como comparación vigente de productos.

Costo puede incluir consumo medido, tiempo de herramientas, recursos e intervención humana. No son unidades intercambiables. Si el runtime no expone tokens reales, una cantidad de caracteres recuperados es un proxy de texto, no una medición de tokens. Deben distinguirse además tiempo de herramienta, duración de tarea y tiempo total de entrega; cada uno responde una pregunta diferente.

Variabilidad, fallos y recuperación

Una ejecución no representa toda la distribución de resultados. Cuando hay variabilidad relevante, conviene examinar más de un run y conservar condiciones y resultados, según el costo y la decisión que se necesita tomar. No existe un número universal de repeticiones que vuelva concluyente cualquier evaluación. Una muestra pequeña debe comunicarse como tal.

Coding-Agent Failure Modes and Recovery permite analizar causas candidatas como contexto perdido, supuestos inválidos, ejecución incompleta o loops improductivos. La evaluación puede distinguir frecuencia de éxito inicial, recuperación y costo adicional. Repetir hasta encontrar un éxito y reportar solo ese run oculta información importante sobre fiabilidad.

La diversidad de soluciones no es necesariamente un fallo. Dos patches diferentes pueden satisfacer la misma tarea; dos secuencias de herramientas pueden obtener evidencia suficiente con compromisos distintos. Los criterios deben observar resultados y riesgos pertinentes, sin exigir que el agente reproduzca una única trayectoria humana si esa trayectoria no es parte del contrato.

Juicios, agregados y límites

Los resultados necesitan criterios verificables y evaluadores adecuados a cada dimensión. Un check automatizado puede detectar una propiedad estrecha; la inspección humana puede aportar contexto pero también variar. La procedencia y los límites del juicio deben quedar visibles. Este documento no define métodos generales de graders, LLM-as-Judge o Human Evaluation ni crea un framework para ejecutarlos.

Un agregado debe conservar su denominador y sus exclusiones. Si se omiten tareas bloqueadas, timeouts o intervenciones, el score responde otra pregunta. También interesa separar familias: una mejora en documentación puede ocultar una regresión en cambios de dependencias si solo se comunica el promedio. El grado de detalle depende de la decisión, sin exigir descomponer cada métrica indefinidamente.

Una conclusión útil declara qué sistema se evaluó, sobre qué casos, con qué evidencia y qué no puede inferirse. Un benchmark puede orientar selección o mejora, pero no reemplaza Generated Code Verification al entregar un cambio concreto ni demuestra seguridad o fiabilidad ilimitadas en producción. Mantener esa frontera permite aprender de resultados sin convertir una cifra o un trace en autoridad automática.

Fuentes

Fuentes primarias consultadas el 2026-10-28. Las definiciones y límites son síntesis editorial del Atlas; las menciones de estudios no expresan rankings actuales ni configuran una metodología obligatoria.

• SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024: ejemplo de tareas de mantenimiento situadas en repositorios.
• AgentBench: Evaluating LLMs as Agents, ICLR 2024: evaluación en entornos interactivos.
• AI Agents That Matter, 2024: costo, sobreajuste y reproducibilidad en evaluación de agentes.