Tu agente empeora un pull request: haz que la evaluación bloquee el cambio
La barrera correcta tiene dos capas: una evaluación de Amazon Bedrock AgentCore que hace fallar el trabajo de GitHub Actions cuando el agente candidato incumple los criterios aprobados, y una regla del repositorio que exige superar esa comprobación antes de fusionar. Sin la segunda capa, el fallo aparece en el pull request, pero no necesariamente impide incorporar el cambio.
El flujo mínimo despliega la versión candidata fuera de producción, ejecuta un conjunto estable de casos, recupera las trazas de cada sesión, calcula las puntuaciones y las contrasta con una línea base versionada. La decisión debe ser automática: si falta un resultado, se infringe un requisito crítico o la caída supera el margen permitido, el trabajo termina con error.
Construye un entorno de evaluación desechable
Separa la prueba del despliegue de producción. El workflow necesita credenciales temporales de AWS, permisos limitados a los recursos de evaluación, un AgentCore Runtime con observabilidad activa y, si el agente utiliza herramientas externas, el servidor MCP que permita recorrerlas. Para autenticar GitHub Actions ante AWS, conviene federar el repositorio mediante OIDC y restringir la confianza al repositorio, la organización y las referencias autorizadas.
Asigna un identificador distinto a cada sesión. AgentCore Evaluations trabaja con las trazas de las interacciones; mezclar casos bajo una misma sesión impide atribuir con claridad una respuesta, una llamada de herramienta y su puntuación al escenario que las produjo.
Ordena el trabajo para que un fallo parcial no deje una aprobación engañosa:
- Obtener las credenciales y desplegar la versión incluida en el pull request.
- Esperar a que el runtime esté listo antes de enviar solicitudes.
- Invocar cada caso con una sesión identificable y aguardar la ingestión de sus trazas.
- Ejecutar los evaluadores, guardar una salida estructurada y aplicar las reglas de aceptación.
- Publicar un resumen en el pull request y eliminar los recursos con una condición que también se ejecute tras un error.
Define qué significa «empeorar»
Una regresión no puede depender de la impresión de quien revise el pull request. Versiona el corpus de solicitudes, las referencias esperadas cuando sean necesarias, las trayectorias de herramientas que deban respetarse y la configuración de los evaluadores. Cambiar el agente y su línea base en la misma revisión debe requerir una justificación explícita, porque de otro modo el examen puede adaptarse al candidato.
Usa la evaluación bajo demanda para puntuar las sesiones recién creadas por un pull request. Para establecer una referencia o comparar conjuntos más amplios, la evaluación por lotes de AgentCore descubre sesiones en CloudWatch Logs, ejecuta los evaluadores y devuelve promedios agregados, recuentos y detalles por sesión; AWS la contempla para medir líneas base, comparar antes y después y detectar regresiones.
La comparación solo es válida si conserva el mismo corpus, los mismos evaluadores y la configuración relevante. Si cambia el modelo que actúa como juez, el conjunto de casos o la definición de una métrica, crea una nueva línea base en lugar de presentar el salto como efecto exclusivo del código.
Elige la identidad según el control que quieras probar
Una prueba funcional con credenciales de máquina no demuestra por sí sola la autorización de una persona. El ejemplo oficial de AWS para GitHub Actions usa un token M2M con ámbitos pero sin la afirmación custom:roles; el middleware del ejemplo omite entonces la comprobación de rol y permite acceder a todas sus herramientas. AWS advierte que, para probar específicamente los roles, debe utilizarse el recorrido con una cuenta de servicio y contexto de usuario.
Ese comportamiento no es una propiedad universal de OAuth ni de todos los tokens M2M: procede de cómo está construido el middleware del ejemplo. Si solo quieres medir la respuesta, la elección de herramientas o sus parámetros, un cliente M2M con ámbitos restringidos puede servir. Si el cambio afecta al reenvío del token o a permisos por usuario, ejecuta una suite independiente con usuarios de prueba y casos positivos y negativos para cada rol.
Mantén separados los resultados de calidad y autorización. Un candidato puede responder correctamente y, al mismo tiempo, exponer una herramienta indebida; también puede denegar bien el acceso pero seleccionar mal una herramienta permitida. Un promedio común ocultaría cuál de los dos controles falló.
Convierte las métricas en reglas reproducibles
No bloquees por un único promedio global. Define de antemano qué dimensiones son críticas, el suelo aceptable de cada una y la pérdida tolerada frente a la línea base. Así evitas que una mejora en utilidad compense una regresión grave en selección de herramientas, corrección o cumplimiento de una restricción.
Combina tres tipos de condición:
- Invariantes deterministas: respuesta con esquema válido, parámetros obligatorios presentes, herramienta prohibida no invocada y acceso denegado cuando corresponda.
- Suelo absoluto: una métrica crítica no puede quedar por debajo del nivel previamente aprobado.
- Delta frente a la base: el candidato no puede perder más que el margen acordado para una dimensión concreta.
Los evaluadores basados en modelos pueden producir variación, por lo que el margen no debe elegirse a partir de una única ejecución favorable. Calíbralo con repeticiones del mismo corpus y separa los fallos de infraestructura de las regresiones: ambos deben impedir la aprobación automática, aunque el informe los identifique con causas distintas.
Aplica un criterio de fallo cerrado. Cero sesiones recuperadas, una evaluación incompleta, un evaluador ausente o un archivo de resultados ilegible no equivalen a superar la prueba. El resumen del pull request debe indicar la versión de la línea base, los evaluadores ejecutados, los casos que fallaron y la regla que produjo el bloqueo.
Haz obligatorio el resultado en GitHub
Da un nombre estable al trabajo de evaluación y regístralo como comprobación requerida en la protección de la rama o en su ruleset. Las reglas de comprobaciones obligatorias de GitHub exigen que todos los estados requeridos se aprueben antes de fusionar y permiten seleccionar una aplicación concreta como fuente esperada.
Revisa también la lista de actores autorizados a eludir el ruleset: una excepción administrativa puede permitir la fusión aunque el check falle. Antes de activar el bloqueo general, ejecuta la suite sobre cambios conocidos, identifica casos inestables y fija los umbrales sin ajustarlos después de ver cada candidato.
La cadena queda completa cuando una respuesta o trayectoria peor genera una métrica identificable, esa métrica infringe una regla versionada, el workflow devuelve error y GitHub conserva la fusión bloqueada. La suite M2M acredita únicamente el comportamiento observado con esa identidad; los permisos por rol requieren su propio recorrido de usuario.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.