Amazon Bedrock AgentCore Evaluation convierte las regresiones de agentes en solicitudes de extracción fallidas
Amazon ha integrado Amazon Bedrock AgentCore evaluation en una puerta de calidad funcional de GitHub Actions, sustituyendo las comprobaciones subjetivas de agentes por cuatro pruebas con puntuación.
La canalización de referencia despliega un agente de IA y un servidor Model Context Protocol protegido mediante OAuth, y después invoca el agente con prompts representativos. Puntúa las trazas resultantes y falla la solicitud de extracción cuando cualquier métrica requerida queda por debajo de un umbral configurado.
Esto cambia el debate sobre las pruebas de agentes. La competencia inmediata no es AWS frente a otro proveedor de nube. Es la evaluación automatizada y repetible frente a las comprobaciones manuales puntuales que muchos equipos de desarrollo todavía utilizan antes de fusionar cambios en agentes.
Amazon publicó la implementación el 8 de septiembre de 2026. La canalización de evaluación conecta AgentCore Runtime, AgentCore Evaluations, Amazon Cognito, CloudWatch, AWS CDK y GitHub Actions.
El resultado importante no es otro panel de pruebas. Una respuesta fallida ahora puede convertirse en una compilación de software fallida, antes de que el comportamiento modificado del agente llegue a un entorno compartido o a producción.
Amazon Bedrock AgentCore Evaluation se convierte en una puerta de fusión
AWS ha convertido la calidad de los agentes de una opinión durante la revisión en una condición para las solicitudes de extracción.
El flujo de trabajo de referencia se ejecuta cuando una solicitud de extracción dirigida a la rama principal modifica código del agente, código del servidor MCP, infraestructura o scripts de evaluación. Crea una pila temporal de desarrollo que contiene dos entornos de ejecución de AgentCore.
Un entorno aloja un agente basado en Strands. El otro aloja un servidor MCP, que expone herramientas mediante un protocolo estándar para conectar aplicaciones de IA con capacidades externas.
Un grupo de usuarios compartido de Amazon Cognito protege ambos entornos. El flujo de trabajo despliega esta infraestructura mediante AWS Cloud Development Kit y, después, obtiene de los resultados del despliegue los identificadores de ejecución y los puntos de conexión de autenticación.
GitHub Actions obtiene credenciales temporales de AWS mediante federación OpenID Connect. OIDC permite a GitHub intercambiar un token de identidad de corta duración por un rol de AWS, evitando una clave de acceso permanente de AWS en los secretos del repositorio.
El flujo de trabajo sigue almacenando el ARN del rol de AWS como un secreto de GitHub. Sin embargo, las credenciales de AWS resultantes son temporales y están limitadas por las políticas de confianza y permisos del rol. GitHub documenta este modelo de seguridad de OIDC.
Después del despliegue, la canalización espera a que ambos entornos estén listos. Esta pausa es importante desde el punto de vista operativo, porque un entorno recién creado no puede aceptar solicitudes de inmediato.
AWS afirma que una invocación temprana devuelve una respuesta 424 Failed Dependency. El flujo de trabajo proporcionado consulta el servicio de control de AgentCore y prepara el servidor MCP antes de iniciar su ejecución de pruebas.
A continuación, la canalización obtiene un token de acceso OAuth y envía prompts de prueba al punto de conexión HTTPS del agente. Cada prompt recibe un identificador de sesión distinto, lo que permite al proceso de evaluación asociar las trazas emitidas con la interacción correcta.
El conjunto de datos de ejemplo abarca varios tipos de comportamiento. Pide al agente calcular una suma sencilla, devolver la hora UTC actual, encontrar el precio de una acción de Apple y obtener el número de empleados.
Estos ejemplos evalúan más que la redacción de las respuestas. Prueban capacidades integradas, herramientas MCP públicas, herramientas empresariales protegidas, selección de herramientas y los parámetros enviados a cada herramienta elegida.
El script de evaluación aplica cuatro evaluadores integrados:
GoalSuccessRate pregunta si la sesión cumplió el objetivo del usuario.
Correctness compara la respuesta con las expectativas o el contexto disponibles.
ToolSelectionAccuracy comprueba si el agente eligió una herramienta adecuada.
ToolParameterAccuracy comprueba si el agente proporcionó argumentos apropiados.
La configuración de referencia utiliza 0.8 en una escala de cero a uno como umbral de aceptación. Si una puntuación requerida cae por debajo de esa marca, el script finaliza sin éxito y GitHub marca el trabajo como fallido.
El flujo de trabajo también puede publicar los resultados de la evaluación en la solicitud de extracción. Los revisores ven el fallo medido junto al cambio de código, en lugar de reconstruir el comportamiento del agente a partir de registros o conversaciones locales.
Por último, el paso de limpieza se ejecuta incluso cuando falla la evaluación. Destruye la pila temporal de CDK para que las solicitudes de extracción fallidas no dejen entornos de desarrollo ejecutándose indefinidamente.
Esta secuencia crea la tensión central. Las pruebas manuales pueden revelar un problema evidente, pero rara vez proporcionan una regla reproducible que toda solicitud de extracción relevante deba cumplir.
Por qué las pruebas manuales de agentes están ahora bajo presión
La canalización presiona a los equipos que consideran una respuesta del agente como algo que se debe inspeccionar, en lugar de como un artefacto que la entrega de software debe validar.
Las pruebas tradicionales de aplicaciones tienen resultados claros. Una función devuelve el valor esperado, una API coincide con un esquema o una operación de base de datos preserva un invariante.
Los agentes de IA complican ese modelo. Sus respuestas pueden variar, y una frase final correcta no demuestra que el agente haya seguido una ruta aceptable.
Un agente que usa herramientas podría seleccionar el servicio equivocado, revelar un resultado no autorizado o enviar parámetros malformados. También podría llegar a una respuesta plausible mediante una secuencia de llamadas costosa o insegura.
Los cambios en los prompts crean otro problema. Un pequeño ajuste en las instrucciones del sistema puede alterar la elección de herramientas, el comportamiento de rechazo, el detalle de las respuestas o la finalización de tareas en escenarios no relacionados.
Las actualizaciones de modelos y los cambios en dependencias introducen riesgos similares. Las pruebas unitarias convencionales pueden confirmar que la aplicación se ejecuta, sin detectar una disminución significativa del comportamiento.
Los equipos suelen compensarlo con conjuntos manuales de prompts. Un desarrollador introduce varias preguntas conocidas, lee las respuestas y fusiona los cambios cuando nada parece manifiestamente incorrecto.
Ese método ofrece una cobertura limitada y un criterio inconsistente. También genera poca evidencia sobre qué comportamiento cambió entre dos revisiones.
La canalización de AWS añade una ruta de evaluación común a cada solicitud de extracción relevante. Despliega el código propuesto, ejecuta ese código, recopila telemetría y aplica los mismos evaluadores.
AgentCore funciona con spans de OpenTelemetry, que son registros estructurados de llamadas al modelo, actividad de herramientas y otras operaciones dentro de una interacción. AgentCore Observability envía esas trazas a CloudWatch.
Para la evaluación bajo demanda, la canalización selecciona spans de una sesión concreta y los pasa al servicio de evaluación. Los modos de evaluación también incluyen supervisión en línea y análisis por lotes asíncrono.
Esta distinción es importante para los equipos de entrega. La evaluación bajo demanda encaja en una solicitud de extracción porque se dirige a un conjunto pequeño y controlado de interacciones y devuelve puntuaciones detalladas.
La evaluación en línea cumple un propósito distinto. Muestrea tráfico desplegado y supervisa el comportamiento después del lanzamiento, cuando los usuarios reales generan solicitudes que un conjunto de datos de prueba no anticipó.
La evaluación por lotes procesa colecciones más grandes de sesiones. Es más adecuada para comparaciones de referencia, auditorías periódicas y análisis antes y después de un cambio.
La puerta de solicitudes de extracción no sustituye estos modos. Traslada el primer punto de control medible más cerca del cambio de código.
Este enfoque también cambia quién debe reaccionar ante una regresión. Sin una puerta, los equipos de calidad o los usuarios suelen encontrar el problema después del despliegue.
Con una comprobación obligatoria de GitHub, el autor debe resolver el comportamiento fallido antes de fusionar. La retroalimentación llega mientras las decisiones relevantes de código y prompts siguen recientes.
Esto es especialmente útil para equipos que mantienen agentes compartidos. Un cambio de respuesta que parece aceptable para un desarrollador puede romper un flujo de trabajo de herramientas perteneciente a otro grupo.
Un conjunto de datos de evaluación seleccionado puede preservar esas expectativas. Se convierte en un registro ejecutable de las tareas que el agente debe seguir realizando.
Los desarrolladores todavía necesitan acceso al contexto de respaldo de esas expectativas. Una base de conocimiento de ingeniería puede ayudar a los equipos a conectar casos de evaluación con especificaciones, incidentes y decisiones de diseño.
El cambio más amplio es organizativo. La calidad del agente pasa a formar parte de la definición de un cambio que puede fusionarse, en lugar de una revisión opcional realizada cuando alguien tiene suficiente tiempo.
OAuth hace que las pruebas integrales sean más difíciles que la puntuación
La parte difícil no es solicitar una puntuación de evaluación. Es reproducir la ruta completa de herramientas de un agente protegido dentro de un ejecutor de CI sin interfaz gráfica.
La arquitectura de referencia coloca tanto al agente como al servidor MCP detrás de Cognito. Los usuarios interactivos se autentican mediante un flujo de código de autorización y reciben tokens que contienen ámbitos y declaraciones de roles personalizados.
Esos roles determinan a qué herramientas MCP puede acceder un usuario. Un usuario de finanzas y uno de RR. HH. no deberían recibir automáticamente las mismas capacidades empresariales.
GitHub Actions no tiene un usuario interactivo. No puede abrir una pantalla de consentimiento, completar un inicio de sesión en el navegador y trasladar el contexto de rol de una persona a través de la prueba.
AWS presenta tres formas de abordar ese desajuste. Cada una valida una parte distinta del sistema.
El primer enfoque evalúa trazas almacenadas. Un proceso de staging invoca el agente de antemano, captura telemetría representativa y guarda esas trazas como elementos de prueba.
Los trabajos de solicitudes de extracción evalúan los elementos de prueba sin llamar a un agente activo ni a un servidor MCP. Este enfoque es predecible y evita el problema de autenticación en CI.
También tiene una limitación importante. Las puntuaciones describen un comportamiento capturado previamente, no necesariamente el código del agente de la solicitud de extracción actual.
Las trazas almacenadas pueden validar cambios en los evaluadores o preservar una referencia histórica. No pueden demostrar que el código de ejecución recién modificado siga produciendo la trayectoria esperada.
El segundo enfoque utiliza una cuenta de servicio dedicada. Un operador completa una autorización interactiva una vez y almacena su token de actualización en un gestor de secretos.
De este modo, CI puede actuar como un usuario conocido con roles definidos. Hace posible probar los límites de autorización y el acceso a herramientas para una identidad específica.
Los tokens de actualización caducan o dejan de ser válidos. Los equipos necesitan rotación, reautorización y un control cuidadoso sobre los privilegios de la cuenta.
La implementación de AWS elige una tercera ruta: autenticación de máquina a máquina. Cognito emite un token mediante la concesión OAuth client_credentials.
El script de evaluación envía el ID de cliente, el secreto de cliente y el ámbito solicitado al punto de conexión de tokens de Cognito. Después invoca AgentCore Runtime mediante HTTPS con el token bearer devuelto.
El middleware MCP distingue estos tokens de los tokens de usuario. Los tokens de máquina tienen ámbitos, pero no declaraciones de roles personalizados, por lo que el ejemplo les permite acceder a todas las herramientas.
Los tokens interactivos siguen incluyendo roles, y el servidor MCP aplica restricciones a nivel de herramienta para esos usuarios. Por tanto, el mismo grupo de Cognito admite tanto el acceso de CI como la autorización humana.
Este diseño permite pruebas activas e integrales del código de la solicitud de extracción. El agente puede llamar al servidor MCP desplegado y producir nuevas trazas para la evaluación.
Sin embargo, no prueba la aplicación de roles. La identidad de CI omite esas comprobaciones de roles por diseño.
Ese límite es la salvedad más importante de la arquitectura. Un pipeline aprobado demuestra que la identidad de máquina puede completar las tareas evaluadas. No demuestra que FinanceUser y HRUser reciban resultados autorizados diferentes.
Los equipos que necesitan ambas formas de garantía deben añadir pruebas de autorización independientes. Pueden usar cuentas de servicio con roles específicos o pruebas directas contra el middleware MCP.
La credencial de máquina también se convierte en un activo sensible. AWS afirma que solo el pipeline de CI y el entorno de ejecución del agente deberían poder obtenerla.
Esa afirmación depende de los detalles de implementación. Los permisos del repositorio, las aprobaciones de flujos de trabajo, las políticas de IAM, la exposición de secretos, el comportamiento de los forks y la redacción de registros influyen en el límite de seguridad real.
La conexión OIDC de GitHub protege el lado de AWS frente a credenciales de repositorio de larga duración. No elimina todos los secretos, porque el cliente OAuth sigue utilizando un secreto de cliente.
El rol de IAM también debe seguir el principio de privilegio mínimo. Un acceso amplio de despliegue a Cognito, ECR, recursos de CDK, Bedrock y AgentCore puede otorgar más autoridad de la que necesita un trabajo rutinario de pull request.
Las protecciones de entorno pueden reducir el riesgo. Los equipos pueden restringir qué ramas y flujos de trabajo asumen el rol, exigir aprobación para cambios no confiables y separar los roles de despliegue de las identidades de evaluación.
Por tanto, la arquitectura prueba conjuntamente el comportamiento del agente y la integración de CI. La corrección de la autorización sigue siendo un objetivo de aceptación independiente.
La puerta de calidad puntúa trazas, no solo respuestas
La evaluación de Amazon Bedrock AgentCore es importante porque puede juzgar la ruta del agente a través de una tarea, no solo su texto final.
El script de evaluación utiliza el kit de inicio de AgentCore para recopilar las trazas relevantes de CloudWatch. Luego aplica evaluadores a la sesión seleccionada.
La API Evaluate sin procesar acepta sessionSpans, una colección de intervalos de telemetría pertenecientes a una sesión. AWS advierte que mezclar intervalos de varias sesiones produce un error de validación.
Este límite de sesión permite al evaluador reconstruir una interacción. Puede inspeccionar la entrada del usuario, la salida del modelo, las herramientas seleccionadas, los parámetros de las herramientas y la respuesta resultante.
GoalSuccessRate opera a nivel de sesión. Determina si la interacción completa logró lo que solicitó el usuario.
Correctness examina la respuesta a nivel de traza. Puede usar una respuesta esperada cuando la prueba proporciona una.
ToolSelectionAccuracy y ToolParameterAccuracy operan a nivel de llamada de herramienta. Distinguen entre elegir la operación correcta y llamar correctamente a esa operación.
Esta separación produjo un resultado ilustrativo en la prueba de regresión deliberada de AWS. Los autores modificaron el prompt del sistema para que el agente siempre devolviera una negativa poco útil.
GoalSuccessRate cayó a 0.0. Correctness también obtuvo 0.0, y ToolParameterAccuracy obtuvo 0.0.
ToolSelectionAccuracy aun así obtuvo 1.0. Al parecer, el agente podía identificar una herramienta adecuada incluso mientras no lograba completar la solicitud general.
Por eso una sola medida agregada puede ocultar problemas. Los distintos evaluadores capturan dimensiones independientes, y una puntuación aprobatoria no puede compensar todos los comportamientos fallidos.
Después de que los autores restauraran el prompt de sistema previsto, GoalSuccessRate volvió a 1.0. Correctness alcanzó 0.9, mientras que ambas métricas de herramientas alcanzaron 1.0.
Las cuatro superaron entonces el umbral de muestra de 0.8. GitHub desbloqueó el pull request.
AgentCore también acepta entradas de referencia para pruebas que requieren un comportamiento esperado. Estas entradas pueden incluir una respuesta esperada, aserciones en lenguaje natural o una trayectoria de herramientas esperada.
Una trayectoria describe la secuencia de herramientas que un agente debe llamar. AWS ofrece evaluadores de orden exacto, en orden y en cualquier orden para diferentes restricciones de flujo de trabajo.
Una prueba de orden exacto se ajusta a un proceso en el que cada paso depende del anterior. Una prueba en cualquier orden se ajusta a operaciones de recuperación independientes cuya secuencia no afecta a la corrección.
El servicio también admite evaluadores personalizados. Los equipos pueden definir sus propias instrucciones, modelo juez y escala de puntuación para requisitos específicos del dominio.
Los evaluadores basados en código ofrecen una opción más determinista. Invocan una función de AWS Lambda que puede comprobar esquemas, patrones, palabras clave o reglas de negocio.
Esta combinación importa porque no todos los requisitos necesitan un juez basado en modelos. La validez de JSON, los campos prohibidos, los límites máximos de llamadas y los identificadores exactos a menudo pueden comprobarse con código convencional.
Según la guía de evaluadores personalizados, los evaluadores pueden operar a nivel de sesión, traza o llamada de herramienta. La lógica personalizada puede usar un modelo o una función Lambda.
Una puerta práctica debe ajustar el tipo de evaluador al requisito. La puntuación basada en modelos se adapta a cualidades semánticas como relevancia, éxito de la tarea o fidelidad.
El código determinista se adapta a restricciones binarias. Las comprobaciones de trayectoria de herramientas se adaptan a la estructura esperada del flujo de trabajo.
La mejor señal proviene de combinar estos métodos. Una respuesta puede ser semánticamente correcta mientras incumple un esquema, y un esquema válido aún puede contener una respuesta irrelevante.
La verdad fundamental también merece un uso cuidadoso. No todas las respuestas aceptables tienen una redacción exacta, especialmente en resúmenes o análisis abiertos.
Las aserciones pueden expresar los hechos o comportamientos que deben aparecer sin imponer una única respuesta. Las trayectorias esperadas pueden especificar el comportamiento de las herramientas independientemente del estilo de redacción.
Esto convierte el conjunto de pruebas en algo más que una colección de prompts. Cada escenario puede indicar qué significa el éxito a nivel de respuesta, tarea y herramienta.
Una puntuación aprobatoria aún tiene puntos ciegos
La puerta detecta regresiones definidas, pero su fiabilidad depende de la cobertura de pruebas, la estabilidad de las puntuaciones, el diseño de identidad y el tiempo operativo.
AWS afirma que el pipeline completo tarda unos 10 minutos. El despliegue, el inicio del entorno de ejecución, la propagación de trazas y la evaluación basada en modelos explican esa duración.
Ese tiempo es aceptable para muchos pull requests. Es demasiado lento para una comprobación local previa al commit y puede resultar costoso en repositorios con actualizaciones frecuentes.
La disponibilidad de trazas añade incertidumbre. AWS observó retrasos de propagación de 30 a 90 segundos después de la invocación del agente.
El script de referencia vuelve a intentarlo cada 30 segundos durante un máximo de 10 minutos. Por tanto, consultar CloudWatch inmediatamente puede producir un fallo aparente antes de que exista la traza.
La arquitectura de ejecución crea otro obstáculo de implementación. AgentCore Runtime requiere imágenes de contenedor ARM64, mientras que los runners estándar alojados por GitHub usan procesadores x86-64.
El flujo de trabajo utiliza QEMU y Docker Buildx para la construcción de imágenes multiplataforma. Ese requisito aumenta el tiempo de compilación e introduce otro posible punto de fallo no relacionado con la calidad del agente.
La limitación más importante proviene del juicio basado en modelos. Un evaluador LLM puede asignar puntuaciones ligeramente distintas al evaluar la misma traza más de una vez.
Por tanto, un límite estricto puede generar pull requests inestables cerca del umbral. Una ejecución puede aprobar con 0.81, mientras otra falla con 0.79 sin una diferencia significativa en el código.
AWS recomienda dejar margen entre el umbral de aceptación y el objetivo de fiabilidad deseado. Los equipos también deben medir la varianza del evaluador antes de hacer obligatoria una comprobación.
Las ejecuciones repetidas pueden estimar esa varianza, pero también aumentan el uso de evaluación. El ejemplo de referencia utiliza cuatro evaluadores en cinco prompts, lo que genera 20 llamadas al modelo juez para un pull request.
La fuente no asigna un precio a esas llamadas. Sí recomienda a los equipos supervisar el uso de Bedrock a medida que crecen los repositorios y los conjuntos de datos.
La cobertura de pruebas plantea un problema conocido, pero más agudo. Una puerta de calidad solo mide los escenarios incluidos en su conjunto de datos.
Cuatro o cinco prompts convenientes no pueden representar cada solicitud de producción, estado de autorización, modo de fallo, idioma o entrada adversarial.
El token de máquina del ejemplo puede acceder a todas las herramientas. Como resultado, la ejecución integral no demuestra que las herramientas restringidas por roles sigan protegidas frente a usuarios normales.
Una puntuación amplia también puede ocultar un rendimiento desigual. Un promedio general puede aprobar mientras falla un escenario crítico.
Las tareas de alto riesgo deben tener requisitos a nivel de escenario. Una acción de nómina, eliminación de cuenta o consulta de datos personales no debería obtener éxito prestado de varios prompts aritméticos sencillos.
Las métricas también necesitan responsables. Los desarrolladores deben saber quién aprueba los cambios de umbral, añade nuevos escenarios e investiga los desacuerdos entre evaluadores.
De lo contrario, una puerta fallida puede generar presión para bajar el umbral. La organización preserva entonces la velocidad de entrega debilitando la medición.
La falsa confianza es otro riesgo. Una comprobación verde demuestra que la versión probada cumplió los criterios especificados en un momento determinado.
No certifica todas las respuestas, no elimina la inyección de prompts ni valida infraestructura fuera de la pila de pruebas desplegada. Tampoco sustituye una revisión de seguridad.
La telemetría de producción sigue siendo esencial porque los usuarios encontrarán combinaciones que un conjunto de datos seleccionado no detectó. La evaluación en línea de AgentCore puede muestrear sesiones en vivo y publicar resultados en CloudWatch.
La documentación de resultados indica que las puntuaciones en línea aparecen como métricas de CloudWatch. Los eventos detallados de evaluación se almacenan en grupos de registros dedicados.
La evaluación por lotes puede comparar ventanas más amplias antes y después de cambios en modelos, prompts o herramientas. Esa comparación proporciona una línea de base más sólida que una sola ejecución de pull request.
Un sistema maduro debe conectar estas etapas. Los fallos de producción deben convertirse en nuevos escenarios de evaluación, y los fallos repetidos de CI deben orientar el diseño del agente.
La puerta de calidad es más creíble cuando su conjunto de datos evoluciona con los incidentes. Un benchmark estático termina recompensando la familiaridad con la prueba en lugar de un comportamiento fiable.
Qué observar después de la primera puerta de GitHub Actions
La siguiente prueba es si los equipos pueden hacer que estas puertas sean lo bastante estables, conscientes de la seguridad y representativas como para convertirse en comprobaciones obligatorias.
La primera señal es la adopción de evaluaciones de verdad fundamental y deterministas en flujos de trabajo de pull request. Las cuatro métricas integradas proporcionan un punto de partida útil, pero no expresan todas las reglas de negocio.
Observe si los equipos añaden respuestas esperadas, aserciones y trayectorias de herramientas para escenarios de alto valor. Un mayor uso de comprobaciones basadas en Lambda demostraría que la evaluación de agentes se está convirtiendo en verificación de software ordinaria.
Este avance reforzaría el caso de la evaluación de Amazon Bedrock AgentCore. Reduciría la dependencia de un único modelo juez y haría que algunos fallos fueran más fáciles de reproducir.
La segunda señal es la cobertura de CI consciente de los roles. AWS identifica abiertamente la limitación del token de máquina, ya que el flujo elegido omite las comprobaciones de roles de usuario.
Los equipos deberían publicar patrones que prueben identidades de usuario distintas sin crear operaciones frágiles de actualización de tokens. Las cuentas de servicio, las pruebas directas de autorización y los tenants de prueba aislados son vías plausibles.
Si las comprobaciones específicas por rol se vuelven habituales, la arquitectura se acercará más a una garantía integral completa. Si siguen siendo independientes o inexistentes, una puntuación verde del agente dirá poco sobre la corrección de la autorización.
La tercera señal es la conexión entre las puertas de pull request y los resultados de producción. Un pequeño conjunto de datos de desarrollo no puede seguir siendo representativo sin retroalimentación de sesiones reales.
Observe flujos de trabajo que conviertan trazas de producción con puntuaciones bajas en casos de regresión revisados. La supervisión en línea debe descubrir fallos, mientras que las pruebas de CI seleccionadas deben impedir que esos fallos regresen.
La herramienta de evaluación de conjuntos de datos de AWS es otro avance relevante. Sus ejecutores de conjuntos de datos pueden invocar agentes, esperar la telemetría y evaluar escenarios mediante un proceso coordinado.
Una adopción más amplia reduciría la orquestación personalizada visible actualmente en el flujo de trabajo de referencia. También facilitaría el mantenimiento de conjuntos de evaluación más grandes y versionados.
Para los desarrolladores, la pregunta práctica ya no es si se deben probar las respuestas de los agentes. Es qué comportamientos deben bloquear una fusión, cuáles requieren supervisión y cuáles exigen una aplicación determinista.
Comience por los fallos que provocarían una reversión, un incidente de seguridad o la interrupción de un flujo de trabajo empresarial. Asigne a cada uno un escenario explícito y un método de evaluación adecuado a su riesgo.
Después, rompa deliberadamente el agente y confirme que la barrera falla por el motivo esperado. Una comprobación solo se vuelve fiable cuando detecta una regresión conocida.
Amazon ha proporcionado una vía creíble para pasar de las pruebas de prompts a comprobaciones obligatorias de estado en GitHub. El siguiente paso corresponde a los equipos de ingeniería: definir el comportamiento que se niegan a publicar, codificarlo y mantener esa definición actualizada.
