Supervisión de agentes AI: una política de alerta silenciosa para fallas reales

El monitoreo del agente AI debe interrumpir a una persona solo cuando pueda nombrar una falla en curso, mostrar la evidencia y señalar una próxima acción limitada. Una llamada de herramientas, un punto de señal o un largo rastro pueden ayudar a explicar un problema; ninguno de ellos prueba que el agente haya dejado de entregar un trabajo útil. Para una primera política práctica, monitorear tres cosas por separado: 1. Freshtime: comenzó la carrera programada, y ¿su latido cardíaco sigue corriendo? 2. Progreso útil: ¿ cambió la evidencia específica de la tarea dentro de la ventana esperada? 3. O Verificación de resultados: ¿Existe el producto entregado prometido y ha pasado la verificación de aceptación? Entonces envía el resultado. Página para un fallo persistente, relevante para el usuario. Crear un boleto o notificación del propietario para una espera legítima o una investigación lenta. Elimina una sola muestra mala y un trabajo saludable. Este artículo convierte esa regla en un contrato de eventos pequeños y un fijo ejecutable de ocho casos. La página debe nombrar la promesa quebrantada Un agente puede estar en línea mientras su trabajo está mal. También puede estar en silencio porque está correctamente esperando una aprobación. Es por eso que la ejecución de procesos es demasiado débil para el seguimiento de agentes y ninguna llamada reciente de herramientas es demasiado ruidosa para la paging. El capítulo Monitoreo de los sistemas distribuidos de Google traza una línea útil entre la evidencia de la caja blanca y los síntomas de la caja negra. La telemetría interna es esencial para el diagnóstico, pero una página debe representar una falla clara que afecte al servicio. El capítulo también señala que una respuesta exitosa al protocolo puede seguir siendo un error cuando el contenido devuelto es incorrecto. Para un agente, el fallo correspondiente es una carrera que dice completed mientras que el artefacto requerido está ausente o inválido. Comience escribiendo un contrato de monitoreo por flujo de trabajo: Campo del contrato Ejemplo para un agente de depósito Por qué existe Inicio esperado Los días laborables a las 09:00 UTC, gracia de cinco minutos Detectar un horario perdido La frecuencia cardíaca Observación del tiempo de ejecución no superior a diez minutos Detectar una corriente inaccesible o muerta Prueba de progreso Nuevo compromiso, resultado de prueba modificado o bloqueador registrado Movimiento separado de la actividad repetida Esperar legítimo Identificación de aprobación más propietario responsable Sigue esperando trabajo fuera de la página de puestos Reclamo de finalización El estado de tiempo de ejecución es completed Registra lo que declaró el agente. El predicado de resultados La rama objetivo contiene el pase de control de compromiso y requerido Verificar el resultado prometido de forma independiente La última fila debe ser deliberadamente específica. Generar una respuesta puede ser suficiente para una tarea de chat. Creó un archivo no es suficiente para una tarea de liberación si el archivo es inválido, no publicado o adjunto al destino equivocado. El monitor no puede inferir este contrato a partir de un lapso de tiempo; el propietario del flujo de trabajo tiene que definirlo. Instrumento de la carrera sin tratar las extensiones como la finalización Las convenciones semánticas generales de AI ahora definen las operaciones de agente y flujo de trabajo como invoke agent , invoke workflow , plan y execute tool . El documento de alcance de los agentes actual también proporciona campos como gen ai.agent.id , gen ai.agent.name , gen ai.agent.version y error.type . Estos son campos de correlación y diagnóstico útiles. No son un esquema de resultados. El documento está marcado Development , por lo que fijar una versión importa. También advierte que los mensajes de entrada y salida capturados pueden contener información sensible. Puede implementar la política de alerta a continuación sin almacenar instrucciones, respuestas, secretos o cargas útiles de herramientas completas. Un evento compacto puede verse así: Mantenga runId estable a través del programador, la telemetría de tiempo de ejecución y el verificador de resultados. Almacenar un agente de baja cardinalidad o un nombre de flujo de trabajo para la agregación. Pon identificadores de rastro de diagnóstico detrás de la alerta en lugar de dentro de su identidad. De lo contrario, cada nuevo intento puede crear un nuevo incidente por la misma promesa quebrantada. La vía superior de la ilustración está ocupada pero circular. La pista inferior cambia de estado y produce un resultado inspectable. Esa distinción es el centro de la política: la actividad es evidencia de descomposición; el progreso y los resultados deciden la salud. Prueba la póliza con ocho casos incómodos El artefacto que acompaña a este artículo utiliza un registro NDJSON por ejecución observada. Abarca la realización verificada, el falso éxito, un horario perdido, un tiempo de ejecución inalcanzable, una espera legítima de aprobación, una carrera persistente sin progreso, una mala muestra transitoria y un trabajo activo saludable. Ejecutarlo desde el directorio de artefactos: Producción esperada: El evaluador utiliza una prioridad fija. Un resultado falso con éxito gana sobre la telemetría obsoleta porque el resultado roto ya es conocido. Un horario perdido gana cuando la carrera nunca comenzó. Un tiempo de ejecución inaccesible gana sobre un diagnóstico de no progreso porque el monitor carece de pruebas de ejecución frescas. Una espera explícita gana sobre la regla de los puestos. Sólo entonces se convierte en stuck un sello de tiempo de progreso obsoleto. Esto evita que un registro abra tres incidentes. También hace que cada decisión sea explicable: la salida puede nombrar la condición, el sello de tiempo de la evidencia y el umbral que se cruzó. Los umbrales incluidos son ejemplos, no imprevistos universales: cinco minutos después del inicio previsto; diez minutos sin latido cardíaco; quince minutos sin avances útiles; dos muestras malas consecutivas para las condiciones de la página; tres muestras de malos resultados consecutivos por un boleto sin progreso. Un agente de codificación que corre una corrección de dos minutos y un agente de investigación que lee artículos durante una hora no deben compartir esos números. La parte importante es la secuencia y el requisito de persistencia, no la duración particular. Añadir persistencia antes de la escalada Las reglas de alerta de Prometheus proporcionan dos mecánicas relevantes. La cláusula documentada for mantiene pendiente una nueva condición activa hasta que haya permanecido activa durante un período. keep firing for puede mantener abierta una alerta después de la última muestra de coincidencia para reducir los flaps o la resolución falsa causada por los datos faltantes. Las mismas ideas se aplican incluso si no utiliza Prometheus: Requerir repetidas observaciones antes de solicitar el silencio; registrar el primer tiempo de incumplimiento por separado de la muestra más reciente; las alertas de grupo por flujo de trabajo y promesas incumplidas, no por retrocesión o rastreo; mantener abierto el incidente hasta que se confirmen nuevas pruebas de recuperación; re página sólo cuando la gravedad o los resultados afectados cambian. No pongas todas las condiciones detrás del mismo retraso. Una afirmación de finalización cuyo artefacto requerido falla en una verificación determinista es una evidencia más fuerte que un latido cardíaco perdido. Por el contrario, una puntuación de calidad LLM cerca de un umbral es una evidencia más débil y puede pertenecer a una cola de revisión en lugar de un pager. Una tabla de enrutamiento tranquila es más útil que un largo inventario métrico: Condición observada Ruta por defecto Condición clara Se solicita la finalización; el control de resultados requerido falla después de su gracia de verificación Página cuando sea relevante para el usuario, por lo demás billete Se corrige el resultado del predicado o de la reclamación La carrera esperada no ha comenzado después de Grace y dos cheques Página cuando la ejecución tiene una obligación actual Se cambia explícitamente el inicio de ejecución o la expectativa del programador El ritmo cardíaco en el tiempo de ejecución está obsoleto durante dos comprobaciones Página cuando el trabajo activo se ve afectado La frecuencia cardíaca fresca más una nueva muestra de salud La aprobación de nombre, la decisión secreta o irreversible está pendiente Notificar al propietario responsable o crear un boleto Se proporciona dependencia o se cancela el trabajo La actividad continúa pero la evidencia de la tarea no ha cambiado durante tres controles Entrada para la investigación Se registran cambios en la evidencia de progreso o una espera legítima Una muestra obsoleta o ausente No hay notificación humana Reevaluar en la siguiente muestra Trabajar los casos de borde antes de elegir una herramienta Los errores de política de alerta suelen aparecer en los límites, no en el camino feliz. Verificación tardía: un editor puede informar de la finalización segundos antes de una actualización de CDN o índice de búsqueda. Dar el resultado predicado un período de gracia documentado, luego verificar de nuevo. No trate un sueño arbitrario como prueba; el segundo control debe inspeccionar el destino real. Human espera: almacena tanto la dependencia como su propietario. waitingOn: "approval" sin una persona responsable simplemente esconde el puesto. Una espera puede permanecer saludable para el agente mientras aún crea una tarea humana atrasada. Longo trabajo silencioso: un paso de investigación o compilación puede ser saludable sin eventos de herramientas frecuentes. Elige pruebas de progreso que el tiempo de ejecución puede emitir de forma segura: un fragmento completado, un hash de contenido cambiado, una nueva fase de prueba o un plazo de fase limitado explícito. Retries: retries pueden ocultar las fallas del proveedor mientras se infla la actividad y el costo. Los agrupamos bajo el mismo ejecutivo y el intento de registro se cuenta como contexto de diagnóstico. Un nuevo ensayo no debe restablecer el tiempo de la primera infracción a menos que produzca un progreso útil. Signales desconocidos: la telemetría faltante no es verde. Informarlo como no disponible y evitar la recuperación automática cuando el monitor no pueda distinguir entre bloqueado y desconectado. Un diagnóstico incierto debe pedir una inspección, no ejecutar una reparación destructiva. Recuperar: cerrar un incidente porque un comando de reinicio devuelve cero repite el problema de falso éxito. Utilice el mismo resultado o predicado de progreso que abrió el incidente. La recuperación es completa sólo cuando hay nuevas pruebas que muestran que el trabajo se está moviendo o que existe el resultado prometido. Lo que este experimento demuestra y lo que no La fijación hace falsificable una tesis estrecha: con la precedencia documentada y los umbrales, los ocho casos suministrados producen exactamente tres páginas, dos boletos y tres notificaciones suprimidas. Puedes editar una timestamp o el recuento de violaciones y ver el cambio de ruta. No demuestra que los umbrales se ajusten a su carga de trabajo. Los casos son sintéticos, y el evaluador lee registros ya normalizados. Las integraciones reales deben manejar el sesgo del reloj, la entrega duplicada, las muestras tardías, la política del programador, las zonas horarias y las interrupciones del colector. También necesitan un límite de privacidad para cualquier cosa derivada de las instrucciones o llamadas de herramientas. La política no sustituye los rastreos, evaluaciones o registros de tiempo de ejecución. Esas señales explican por qué un resultado fracasó. Tampoco garantiza que un predicado específico de la tarea capture todos los problemas de calidad. Algunos resultados son deterministas, como un hash de archivo o resultado de prueba; otros necesitan muestreo, revisión o un proceso de evaluación con un nivel de incertidumbre explícito. Lo más importante es que la política no debe autorizar una recuperación autónoma. Un monitor puede recomendar un retiro limitado o preparar un paso de reparación, pero las acciones irreversibles, el acceso secreto y los diagnósticos inciertos aún requieren autoridad humana. Convertir el dispositivo en una prueba de aceptación Antes de conectar un destino de alerta real, reemplace los casos sintéticos con ejemplos recientes de un flujo de trabajo: 1. Definir el inicio esperado y la demora aceptable. 2. Elige un latido producido fuera de la respuesta modelo. 3. Nombre la menor evidencia de progreso útil. 4. Registra las razones legítimas de espera y los propietarios. 5. Implementar el predicado de resultados en el destino real. 6. Repite los casos conocidos sanos, esperando, atrapados, perdidos, inaccesibles y falsos. 7. Ejecutar la póliza en silencio el tiempo suficiente para revisar páginas falsas e incidentes perdidos. Sólo después de esa revisión debe activarse una ruta de página. Mantenga la evidencia en bruto, la decisión, la versión del umbral y la verificación de la resolución inspectables para que el operador pueda entender por qué habló el monitor. Sidewisp está diseñado alrededor de este límite de salud: detectar, explicar, pedir autoridad cuando sea necesario y verificar el resultado. Sidewisp se encuentra actualmente en versión preliminar privada. Los adaptadores de monitoreo de producción y el motor de recuperación no se envían generalmente hoy en día. Si este enfoque coincide con la forma en que operas a los agentes, puedes describir Únete a la vista previa privada y los casos de tiempo de ejecución y fallas que necesitas cubrir.