El evaluador de Google falló tres ejecuciones que habían pasado: leía el resumen
Google publica cuatro lecciones de evaluación de un plugin de agente: puntuar la trayectoria, conservar los turnos, comparar ejecución real y solo plan, y usar golden sets.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
Se le pide a un agente que limpie los servicios de Cloud Run. La tarea exige que compruebe la sintaxis del comando antes de ejecutar nada. Su primer paso es exactamente eso: gcloud help run services list. Su mensaje final, en cambio, se centra en advertir al usuario sobre la pérdida permanente de datos. El evaluador automático lee el mensaje final, no encuentra la comprobación de sintaxis y marca la ejecución como fallida.
El agente aprobó. La evaluación falló.
Esa es la primera de las cuatro lecciones que Casey West, responsable de developer relations para infraestructura de IA en Google Cloud, publicó el 16 de octubre a partir de la construcción del plugin Google Cloud Developer para agentes de código. En la suite inicial de 11 prompts, el juez LLM marcó tres ejecuciones como fallos que los logs brutos de llamadas a herramientas mostraban como aprobadas. Once prompts son muy pocos para estimar una tasa de error, y el artículo no lo intenta. Su valor está en nombrar cuatro formas en que las evaluaciones de agentes engañan, cada una con un mecanismo concreto.
El resumen es la opinión del agente sobre su propio trabajo
El mensaje final de un agente es un informe escrito por la parte evaluada. Puede minimizar el trabajo que hizo, como aquí, o describir trabajo que nunca hizo, que es el caso más peligroso. Un juez que evalúa el resumen está evaluando la capacidad narrativa del agente.
La solución de Google es puntuar la trayectoria: qué comandos se ejecutaron, con qué argumentos, en qué orden, si las comprobaciones precedieron a los pasos destructivos y si las acciones se mantuvieron dentro del alcance. No es una idea nueva; el playbook de experiencia de agentes de Microsoft también usó análisis de trayectoria. Lo nuevo es un ejemplo limpio y documentado de un juez basado en el resumen que produce falsos fallos en una suite pequeña, que es justo donde los equipos tienden a confiar en él.
Las llamadas en paralelo esconden errores de orden
La segunda lección es más sutil. El harness envió una llamada de carga de skill y dos búsquedas de documentación en un solo lote de llamadas a herramientas. Los skills se cargan por etapas, así que las instrucciones del skill llegaron después de que las búsquedas ya se hubieran ejecutado sin ellas. La telemetría, aplanada en una lista simple de eventos, hacía que las llamadas parecieran secuenciales y ocultaba el problema.
Para quien construye pipelines de evaluación: conserve la estructura de turnos en sus trazas. Un agente que hace lo correcto en el orden equivocado, o en paralelo antes de que lleguen sus instrucciones, aprobará una lista de verificación y fallará en producción.
Ejecútelo en vivo, ejecútelo como plan y compare
La tercera lección es la más práctica. Ejecute cada prompt de evaluación dos veces: una en vivo, con credenciales reales pero en sandbox, donde el agente ejecuta comandos, y otra solo en plan, con las credenciales retiradas, donde explica lo que haría. Las ejecuciones en vivo ponen a prueba la sintaxis, el manejo de parámetros y la contención antes de acciones destructivas. Las ejecuciones solo en plan exponen la intención que los errores de permisos ocultarían de otro modo.
En un prompt de onboarding, la ejecución en vivo se atascó en un listado de proyecto bloqueado; la ejecución solo en plan produjo un plan de 8,000 caracteres que ignoraba por completo las políticas de la organización, las aprobaciones de administración y la gobernanza. Según el artículo, aproximadamente la mitad de los hallazgos más importantes provinieron de la diferencia entre las dos condiciones.
| Qué detecta | Qué se le escapa | |
|---|---|---|
| Mensaje final, evaluado por un juez | Conclusiones equivocadas en la respuesta | Trabajo hecho pero mal descrito; trabajo descrito pero nunca realizado |
| Trayectoria de ejecución | Comandos equivocados, comprobaciones omitidas, desviación del alcance | Si la acción encajaba con la situación de negocio |
| Ejecución en vivo, credenciales en sandbox | Sintaxis, parámetros, contención ante pasos destructivos | La intención oculta tras errores de permisos |
| Ejecución solo en plan, sin credenciales | Huecos de razonamiento, políticas y aprobaciones ignoradas | Todo lo que solo falla al ejecutar |
| Conjunto de referencia de expertos | Regresiones cuando cambia el modelo o el harness | Casos que nadie ha escrito todavía |
Los conjuntos de referencia prueban el sistema, no el modelo
La cuarta lección trata la evaluación como integración continua de un sistema no determinista. Las ejecuciones se puntúan contra conjuntos de referencia curados por expertos humanos que capturan qué debería pensar el agente, qué comandos debería ejecutar y si resolvió el problema sin romper nada. La línea base es todo el stack, harness, modelo y plugins, porque cualquiera de ellos puede cambiar.
Dónde deja esto a los equipos empresariales
El relato de AWS sobre sus agentes de ventas, publicado el mismo día, llegaba a una conclusión compatible desde otra dirección: comprobaciones deterministas para las respuestas conocidas, jueces solo para el resto, evaluación integrada en cada release. Google añade el lado de la ejecución: para un agente que actúa, el registro de lo que hizo es la evidencia principal y su propio relato de lo que hizo es secundario.
Conviene tener presente un límite. Una trayectoria demuestra qué ocurrió, no que fuera lo correcto. Un agente puede ejecutar todos los comandos correctamente contra el recurso equivocado. La evaluación de la trayectoria responde a «¿hizo lo que especificamos?»; la pregunta «¿era esta la acción adecuada aquí?» sigue necesitando casos de referencia escritos por personas que conocen el negocio y, para acciones con consecuencias, alguien que apruebe antes de la ejecución.