Evaluar un agente de código en la construcción de agentes: interpretar tasas de éxito

Pediste a un agente de código que construyera un agente de atención al cliente. Lo primero que hay que evaluar es si el resultado resiste trabajo no visto, no si la transcripción parece plausible. Una demo es un montaje de lo mejor; una ficha de evaluación es un cuaderno de laboratorio.

La evaluación de agentes de código se complica cuando el entregable es otro agente. El constructor puede mostrarte una interfaz pulida, una llamada a una herramienta plausible y una transcripción limpia. Nada de eso demuestra que el agente se sostendrá en tareas que no ha visto.

Las demos ocultan fallos de construcción

Antes de confiar en un agente de código para que construya un agente de IA, somete el resultado a un benchmark que oculte los ejemplos de entrenamiento. La prueba debe ser lo suficientemente desordenada como para detectar atajos. El fallo habitual es evaluar al constructor con las tareas que él mismo ayudó a escribir. Si el agente puede ver la prueba, la tasa de éxito mide memorización, no construcción.

hyper-tau-bench es una configuración concreta para esta verificación. El identificador arXiv 2609.04611 corresponde a un artículo titulado τ^τ-Bench: An Environment for End-To-End, Realistic Agent Construction. El benchmark contiene 53 tareas: 6 airline_plus, 6 retail_plus, 6 telecom y 35 banking_knowledge. En él, un agente enviado se evalúa en tareas de atención al cliente no vistas a través del bucle interno de τ³-bench, y el desarrollador recibe una recompensa igual a la tasa de éxito del agente.

Las tasas de éxito necesitan un techo experto

La tasa de éxito es la métrica que sobrevive al contacto con el trabajo real. Te dice con qué frecuencia el agente completa la tarea, no qué tan atractiva es la transcripción. Compárala contra un techo experto: si un humano puede completar la tarea de forma fiable, la puntuación del agente debe juzgarse contra ese estándar, no contra una demo.

El estándar importa más cuando el agente maneja registros, no un chatbot de juguete. Lee el costo junto con la puntuación: un gasto alto y una tasa de éxito baja apuntan a bucles, un gasto bajo y una tasa de éxito baja apuntan a detención temprana, y una tasa de éxito alta en un arnés frágil apunta a una prueba demasiado fácil.

El arnés es parte de la medición

Una configuración de arnés reproducible convierte una ejecución puntual en una evaluación repetible. Mantén el mismo conjunto de tareas, claves y límites en cada ejecución.

• Elige primero tareas de atención al cliente no vistas. «Hecho» se ve como una lista de tareas que el constructor no ha visto, con registros, llamadas a API y código heredado.
• Conecta el entorno real. Para las tareas de liberación de hyper-tau-bench, configura OPENAI_API_KEY y OPENROUTER_API_KEY. Añade ANTHROPIC_API_KEY solo cuando claude-code sea el arnés del Developer. El entorno está listo cuando las claves requeridas están configuradas.
• Limita el costo antes de la ejecución. Establece un techo de presupuesto y detén la ejecución cuando se alcance. Registra el número de gasto junto a la tasa de éxito.
• Puntúa contra un techo experto. Ejecuta un humano o una línea base conocida y correcta en las mismas tareas, luego compara la tasa de éxito del agente con ese techo. Termina con una brecha, no con una puntuación cruda.
• Reproduce el arnés. Registra la elección del arnés, el conjunto de tareas, las claves y el límite de costo para que otro ingeniero pueda repetir la misma prueba. En hyper-tau-bench, el asiento Developer puede usar codex como arnés predeterminado, o claude-code, opencode o prime-agent. La ejecución es reproducible cuando un compañero puede repetirla desde el registro.

Ejecuciones auditables separan modos de fallo

Cuando la ejecución termina, anota qué cambió el agente, qué rompió y qué no pudo hacer. Un informe útil incluye la lista de tareas, el arnés, el registro de gasto y la brecha de puntuación. Si un compañero no puede repetir la prueba a partir de ese informe, la evaluación es una historia, no una medición.

Usa la ficha de evaluación para separar tres fallos. El constructor puede ser malo en planificación, malo en el uso de herramientas o malo en terminar. Mantén las notas junto a la puntuación para que el patrón sea visible entre ejecuciones antes de escalarlo.

Para un agente de atención al cliente, las verificaciones de mayor valor son las aburridas: ¿puede leer el registro, puede llamar a la API correcta, puede actualizar el estado y puede detenerse cuando la tarea está terminada? Registra qué modo de fallo aparece, luego repite el mismo arnés antes de cambiar el modelo.