AgentLens: evaluar agentes de código por la trayectoria, no solo el resultado

La mayoría de los benchmarks de agentes de código reducen cada ejecución a un único bit: la tarea pasó o no pasó. Esa crítica no es nuestra, es de los autores de AgentLens, un trabajo publicado el 9 de julio en arXiv que propone evaluar justo lo contrario: la trayectoria completa del agente, desde la primera instrucción hasta el mensaje final.

El punto de partida es una observación difícil de discutir. Quien usa un agente de código en su día a día no experimenta un resultado binario, sino todo el recorrido: si el agente sigue las instrucciones o las reinterpreta a su manera, cómo usa sus herramientas, si verifica su propio trabajo antes de darlo por bueno, cómo se recupera cuando se equivoca y cómo comunica lo que va haciendo. Dos agentes pueden resolver la misma tarea y ofrecer experiencias opuestas.

Cómo evalúa AgentLens

El sistema combina dos mecanismos. Donde existe una comprobación objetiva (tests, verificación formal), la aplica. Donde no, recurre a revisiones de trayectoria escritas por un LLM y a comparaciones lado a lado entre ejecuciones. El resultado es que cada run produce una explicación legible de por qué la puntuación es la que es, en lugar de un número seco.

Los autores subrayan que esto convierte el benchmark en algo más que una tabla de clasificación. Ellos mismos lo usan para tres cosas: diagnosticar el comportamiento de modelos, comparar versiones sucesivas de su propio agente y cazar regresiones de producto en un pipeline de evaluación nocturno. El código está publicado como open source en GitHub.

Por qué el bit único se queda corto

Las métricas de porcentaje de tareas resueltas han sido útiles para comparar modelos, pero esconden diferencias que pesan en el uso real. Un agente puede pasar la tarea después de tocar veinte archivos que nadie le pidió tocar. Otro puede resolverla igual de bien pidiendo confirmación antes de borrar algo delicado. En un ranking clásico ambos puntúan idéntico; para el desarrollador que los sufre o los disfruta, no se parecen en nada.

Para los equipos que construyen productos sobre agentes, el argumento del pipeline nocturno es probablemente el más práctico del artículo: las regresiones de comportamiento (un agente que de pronto verifica menos, o que abusa de una herramienta) no aparecen en las tasas de éxito hasta que ya son graves. Una revisión de trayectoria las detecta antes.

Las cautelas razonables

Las revisiones escritas por LLMs heredan los sesgos del modelo que las escribe, y las comparaciones lado a lado tienen problemas conocidos, como la sensibilidad al orden de presentación. Emparejarlas con verificación formal donde es posible mitiga parte del riesgo, pero no lo elimina: la parte subjetiva del benchmark es tan fiable como su juez. Que el código sea abierto ayuda, porque permite auditar los prompts de evaluación en lugar de fiarse de la nota.

Para quién es útil: equipos que desarrollan agentes de código y quieren comparar versiones del suyo propio, evaluadores de modelos que necesitan algo más fino que pass@1, y equipos de producto que quieran montar una evaluación continua. Para el usuario final de herramientas tipo Claude Code el efecto es indirecto pero real: si los proveedores adoptan evaluaciones de trayectoria, los agentes que fallan con elegancia dejarán de puntuar igual que los que fallan a secas.

En EP evaluamos agentes con frecuencia y el veredicto de pasó o no pasó nunca cuenta la historia completa. Un benchmark que explica el porqué de cada nota vale más como herramienta de diagnóstico que como clasificación, y ese nos parece exactamente el uso que sus autores le están dando.