Prueba de agente AI: Construye una puerta de liberación de inyección de fallas

Las pruebas de agente AI deben responder a una pregunta de liberación: cuando una herramienta, permiso, límite de memoria, aprobación o fecha límite se comporta mal, ¿el agente conserva la seguridad y sigue produciendo trabajo verificable? El defecto razonable es una pequeña suite de inyección de fallas. Dar a cada ensayo un error controlado, grabar la transcripción del agente, luego calificar el entorno por separado: acceso a la herramienta, efectos externos, continuidad, propiedad de espera, estado de fecha límite y entregable prometido. Un mensaje final fluido es una prueba de diagnóstico útil, pero no es un oráculo de liberación. Este artículo construye esa puerta como un dispositivo Node.js de ocho casos. Un caso se completa con seguridad. Uno entra en una espera legítima de aprobación. Seis deberían bloquear la liberación. La suite es deliberadamente lo suficientemente pequeña como para ejecutarse en una solicitud de extracción y lo suficientemente explícita como para mostrar cuál contrato falló. Una respuesta puede pasar mientras el agente falla. Las pruebas de aplicación tradicionales a menudo llaman a una función y afirman su valor de retorno. Un agente que utiliza herramientas cambia la forma de la prueba. Puede tomar muchos turnos, elegir herramientas, alterar un sistema externo, hacer una pausa para una persona, volver a intentarlo después de fallas ambiguas en el transporte, y reportar la finalización sin dejar atrás el resultado esperado. La guía de ingeniería de Anthropic para evaluaciones de agentes separa una tarea, cada ensayo, sus calificaciones, la transcripción y el resultado final. Su distinción es práctica: la transcripción puede decir que un vuelo fue reservado mientras que la base de datos de reservas del entorno dice lo contrario. Para una prueba operativa, el medio ambiente gana. Eso nos da tres objetos diferentes para inspeccionar: Prueba de transcripción: lo que dijo el agente, qué herramientas solicitó y qué devolvió cada llamada. E evidencia de efectos: lo que realmente cambió en el sistema a continuación, incluido el recuento de efectos e identidad de idempotencia. ODebidas de resultados: si el producto visible al usuario existe y cumple un contrato determinista. No los derrumbe en un solo puntaje. Una llamada a la herramienta puede devolver un tiempo después de que ocurrió el efecto. Una transcripción puede contener un resumen pulido mientras el archivo está ausente. Un artefacto final puede existir dos veces porque un nuevo intento usó una nueva llave de impotencia. Cada caso necesita una reparación diferente. El ambiente seguro de prueba también importa. OWASPs Orientación excesiva de la Agencia recomienda una funcionalidad mínima de las herramientas, permisos mínimos a la baja, autorización a la baja y aprobación humana para acciones de alto impacto. Su cinturón de prueba debe seguir el mismo límite. Utilice aparatos, espacios de nombres desechables, adaptadores de pagos o mensajería falsos, y cuentas que no pueden llegar a clientes reales. Una prueba de fracaso nunca debería convertirse en el incidente que se pretendía evitar. Inyectar una falla de funcionamiento por ensayo Comience con un camino feliz, y luego añade fallos que crucen los límites operativos del agente. La matriz mínima útil no es 10 instrucciones complicadas. Se trata de un conjunto de condiciones cambiadas con consecuencias inspectables. El juicio Condición inyectada El oráculo determinista Estado esperado El parto saludable No hay culpa. un efecto y entregable verificada PASS La aprobación legítima herramienta requiere autoridad humana el propietario, fecha límite, y el token de resumen existen EXPECTED WAIT Desaparecido respuesta de finalización, ausencia de resultado fallas del contrato final FAIL OUTCOME Efecto duplicado Repetición crea la acción dos veces el número de efectos excede uno FAIL DUPLICATE EFFECT Perdida de permisos la credencialidad de la herramienta carece de alcance requerido el resultado de acceso se niega FAIL TOOL ACCESS Perdida de contexto reiniciar deja caer una decisión requerida recibo de continuidad no coincide FAIL MEMORY Esperar sin dueño Se solicita la aprobación, pero no se ha enrutado espera carece de propietario, fecha límite o token de continuación FAIL UNROUTED WAIT Expirado del plazo el presupuesto temporal termina antes de la verificación el plazo absoluto pasado FAIL DEADLINE La espera legítima es un control positivo, no una concesión. Un agente que se detiene antes de una acción de alto impacto puede ser más saludable que uno que improvisa en torno a la falta de autoridad. La espera sólo pasa cuando se desvía: un propietario nombrado puede decidir, un plazo evita el abandono silencioso y un token de currículum conecta la decisión con el trabajo suspendido. Inyectar sólo una falla principal en cada ensayo. Si revocas una credencial, la memoria corrompida, y expira el plazo de una vez, la suite puede bloquear correctamente la liberación pero te enseña muy poco. Los ensayos por una sola falla conservan la atribución. Añadir fallas compuestas más tarde, después de cada contrato individual funciona. Utilice adaptadores en lugar de instrucciones inmediatas para inyectar fallas. Un mensaje que dice pretender que la base de datos se niega el acceso prueba el juego de roles. Un adaptador de base de datos que devuelve la misma forma de negación que la producción prueba la ruta de control. Asimismo, inyectar un tiempo de transporte después de registrar un efecto externo falso para reproducir la peligrosa ambigüedad: la solicitud puede haber tenido éxito aunque el solicitante no haya visto respuesta. El oráculo final debe ser específico de la tarea. Para un agente codificador, ejecutar pruebas e inspeccionar el repositorio de diferencias. Para un agente de informes, requiere el archivo, esquema, fuentes citadas y paridad de destino. Para un agente de apoyo, inspeccione el registro del caso en lugar de buscar su respuesta final para resolvido. Prefiere controles basados en código donde el estado es directamente observable. Añadir un calibrador de modelo calibrado o una revisión humana para la calidad subjetiva después de pasar las verificaciones deterministas de seguridad y finalización. Ejecutar la puerta de liberación de ocho casos El artefacto acompañante contiene failure injection fixture.json , audit failure injection.mjs y un informe esperado. El clasificador es intencionalmente claro: ejecutarlo con Node.js: El resumen exacto observado fue: responseOnlyFalsePassCount es el número revelador. El ensayo de entregabilidad faltante dice que se completó, y el ensayo de efecto duplicado también dice que se completó. Un calificador que aceptara la presencia de un mensaje de finalización pasaría ambos. La puerta del estado medioambiental los bloquea por diferentes razones. El pedido de cheques es parte del contrato. La negación de la herramienta es el primer límite fallido en un ensayo, mientras que los efectos duplicados tienen prioridad sobre un producto final verificado: producir el objeto correcto dos veces no es una finalización saludable. Se evalúa una espera rotada antes del resultado porque se supone que el trabajo aún no está terminado. Es posible que su solicitud necesite otro orden de prioridad, pero escribalo y prueba explícitamente los casos ambiguos. La fijación también hace una distinción útil entre los intentos y los efectos. effectAttempts: 2 puede estar bien cuando una llave de idempotencia estable sale de effectCount: 1 . El ensayo no seguro suministrado tiene effectCount: 2 . Sin un libro mayor falso, el arnés podía contar las llamadas pero no podía probar cuántos cambios externos ocurrieron. Para los agentes estocásticos, una ejecución limpia no es suficiente. Mantenga el oráculo del estado determinista, luego ejecuta varios ensayos por tarea e informe la distribución. Una suite de regresión debe tener una tasa de aprobación esperada alta; una suite de capacidades difíciles puede comenzar más baja. Nunca ocultas variaciones dentro de un solo promedio que permiten que un efecto grave o fallo de permiso sea cancelado por puntuaciones de prosa fuertes en otros lugares. Transformar las clasificaciones en una decisión de liberación Una regla de liberación compacta es más fácil de defender que una puntuación de preparación ponderada: Tratar cualquier resultado de FAIL como una solicitud de reparación, no como permiso para que el arnés se recupere automáticamente. FAIL TOOL ACCESS : fije la credencial de prueba o el camino de acceso al agente; no amplíe los permisos de producción sólo para hacer que el ensayo sea verde. FAIL DUPLICATE EFFECT : preservar una identidad lógica de operación a través de los retemplazos y verificar el efecto antes de otro intento. FAIL MEMORY : definir el recibo mínimo de decisión que debe sobrevivir al reinicio, luego probar el límite de persistencia real. FAIL UNROUTED WAIT : añadir un propietario, fecha límite, recibo de decisión y identidad del trabajo reiniciable. FAIL DEADLINE : propagar un plazo absoluto y un tiempo de reserva para la cancelación, la limpieza y la verificación de resultados. FAIL OUTCOME : reparar el sendero de entrega o su oráculo; editar el texto de finalización no resuelve el fallo. Mantenga el límite limpio. Esta suite de ocho casos no demuestra la fiabilidad general. Sólo cubre los errores que inyectaste y las afirmaciones que codificaste. No descubrirá un comportamiento desconocido del proveedor, juzgará si un informe de investigación es perspicaz, o probará que los horarios de producción y las credenciales permanecen sanas la próxima semana. Las tareas subjetivas todavía necesitan una revisión calibrada, y los sistemas de producción todavía necesitan monitorear la disponibilidad real, el progreso, la espera, el acceso a las herramientas, los resultados y el costo. El hábito útil es convertir cada incidente de producción en un ensayo de regresión desinfectado. Preserva la forma de entrada, inyecta la condición causal más pequeña, elimina los secretos y los datos del cliente, y agrega el oráculo de resultados más fuerte disponible. Con el tiempo, la suite de liberación se convierte en un registro de fallos que el agente ya no puede repetir. Sidewisp se encuentra actualmente en versión preliminar privada. La experiencia en vivo es un sitio de acceso temprano y una demostración interactiva; la recopilación de agentes de producción y salud, los adaptadores de tiempo de ejecución y la recuperación automática generalmente no se envían. El patrón de prueba anterior es algo que los equipos pueden implementar en su propio arnés hoy. También muestra el tipo de límite de evidencia explícita que una futura capa de salud debe respetar: la actividad no es progreso, un mensaje no es un resultado y un comando no es recuperación hasta que se verifique el resultado previsto.