Seguimiento de los agentes después de una corrección: prueba de recuperación en cinco pasos

Un agente AI no se recupera simplemente porque un reinicio, retiro o empuje regresó con éxito. El defecto práctico para el monitoreo de agent es verificar la recuperación en cinco pasos: registrar la intervención autorizada, confirmar la accesibilidad y preparación, observar el progreso específico de la tarea, verificar el resultado prometido de forma independiente y observar una ventana de estabilidad para la recaída. Hasta que pase el control más fuerte aplicable, mantenga el estado como recovering , uncertain o needs human no saludable. Esta distinción es importante porque el comando de reparación y el trabajo del usuario viven en diferentes capas. Un proceso puede reiniciarse mientras su credencial siga expirando. Un latido cardíaco puede reanudarse mientras el agente repite la misma llamada de la herramienta. Un agente puede declarar que se ha completado mientras el archivo, el boleto, el mensaje o la implementación aún están ausentes. La recuperación es una afirmación de evidencia, no un evento de actividad. Despejar un incidente con una escalera de verificación Usa una escalera en lugar de un estado verde. Cada paso responde a una pregunta diferente y debe conservar su propio sello de tiempo, fuente y confianza. Paso a paso Pregunta de la Comisión Evidencias mínimas Indique si no funciona Intervención ¿Fue autorizada y ejecutada la acción limitada exacta? referencia de aprobación, tipo de acción, ID de intento, resultado de salida o API needs human o intervention failed Accesividad ¿Es el tiempo de ejecución contactable y listo para su tarea? ritmo cardíaco fresco más un control de preparación para la tarea relevante unreachable o alive only El progreso ¿Ha cambiado el trabajo útil desde la intervención? artefacto monótono, unidad completa, cursor, delta de ensayo o cambio de destino alive only o recovering El resultado ¿Existe el resultado prometido y satisface su verificación determinista? búsqueda, digestión, prueba, revisión o recepción en el país de destino false recovery , recovering , o uncertain Estabilidad ¿El fallo diagnosticado se mantuvo ausente lo suficiente como para que se repitiera? una ventana de observación específica de la carga de trabajo sin síntomas repetidos relapsed o recovered El defecto razonable es conservador: un agente que es accesible pero no ha movido trabajo útil es alive only ; uno que ha reanudado el trabajo medible pero no ha alcanzado su resultado es recovering ; sólo la evidencia de resultados frescos que sobrevive a la ventana de estabilidad gana recovered . Kubernetes utiliza una separación relacionada para los contenedores. Su documentación de la sonda proporciona diferentes tareas de arranque, vitalidad y preparación: la vitalidad puede desencadenar un reinicio, mientras que la preparación controla si un contenedor debe recibir tráfico. También advierte de que las sondas de vida incorrectas pueden causar fallos en cascada. La analogía tiene un límite una tarea de agente no es un Podpero la lección de operación transfiere: el proceso debe reiniciar y el trabajo está listo no debe ser la misma prueba. Una ventana de estabilidad no es un sueño arbitrario de cinco minutos. Elige el intervalo más corto en el que el fracaso original tuviera una oportunidad justa de regresar. Para un bucle que repite cada dos llamadas de herramientas, observe al menos dos oportunidades limpias de llamadas de herramientas. Para un editor programado, espere hasta la fecha límite de su próximo resultado. En caso de incumplimiento de la credencial, ejerza el permiso afectado una vez con un chequeo no destructivo. La ventana debe ser lo suficientemente larga como para falsificar la reparación, pero no tan larga que el incidente permanezca ambigüo después de que exista evidencia decisiva. Graba un intento de recuperación, no una secuencia suelta de comandos Enlace el diagnóstico, la autoridad, la intervención y la verificación a una identificación inmutable del intento. De lo contrario, el monitor puede unir un latido cardíaco de un posterior reinicio manual a un empuje automático anterior y reportar una recuperación que nadie puede explicar. Un evento limitado a la privacidad puede verse así: Este evento no necesita instrucciones, respuestas, secretos, cargas útiles de herramientas primas, o caminos absolutos. Necesita el límite de la acción y el límite de la evidencia. Almacenar action completed como un recibo, no como el veredicto de recuperación. Esa regla es especialmente importante para las APIs asincronas. Sección 15.3.3 de la RFC 9110 dice que una respuesta HTTP 202 Accepted significa que el procesamiento no se ha completado y puede que nunca ocurra; la respuesta debe describir el estado actual y apuntar a un monitor de estado. Si un adaptador de recuperación de un agente recibe 202 , siga ese monitor o consulta el destino. No traduzca acceptado en fixed. Las huellas tienen el mismo límite de alcance. OpenTelemetry define un extensión como una unidad de trabajo y su estado como el estado de la operación que realiza. Una duración limpia de restart agent demuestra que la operación no reportó un error. No define si se produjo un informe, un boleto llegó o un despliegue sirve para la revisión prevista. Enlazar el lapso de intervención con el progreso posterior y la evidencia de resultados; no sobrecargar su estado. La autoridad también pertenece al expediente. Si un reinicio, actualización de credenciales, envío de mensajes o retroceso requiere aprobación y no existe una aprobación válida, el monitor debe emitir needs human . No debe intentar la acción y luego pedir permiso retroactivo. La recuperación también necesita un nuevo intento y un presupuesto de tiempo. Una segunda intervención después del fracaso de la primera es una nueva decisión, no una extensión invisible del comando original. Reproduce el latido cardíaco falso positivo El dispositivo de acompañamiento contiene ocho casos sintéticos posteriores a la intervención: falta de autoridad, error de acción, actividad solo por latido cardíaco, reanudación del progreso, recuperación estable verificada, recaída, evidencia obsoleta del verificador y finalización declarada por el agente con un resultado de destino faltante. Ejecutar el clasificador desde el directorio de artefactos: El resultado decisivo es: La regla ingenuo acción completada y el ritmo cardíaco presente reporta seis recuperaciones. La escalera informa uno. Eso no es porque la escalera sea pesimista. Un caso es realmente recovering : se ha reanudado el progreso útil y el resultado aún está pendiente. Otro tiene evidencia de resultados nuevos pero luego repite el fallo diagnosticado, así que es relapsed . Un tercero tiene un resultado de aspecto verificado que es de diez minutos bajo un contrato de frescura de dos minutos, por lo que es uncertain , no fallido o saludable. El umbral de frescura de 120 segundo de la fijación es ilustrativo, no un defecto de producción. La actualidad de las pruebas pertenece al verificador. Una digestión de archivos en el almacenamiento local puede ser decisiva inmediatamente. Un índice de búsqueda consistente eventualmente puede necesitar un retraso documentado. Si el verificador en sí no está disponible, preserve uncertain y exponga la señal que falta. No reinicie el agente sólo para hacer que el tablero se vuelva verde. El capítulo Monitoreo de los sistemas distribuidos de Google separa los síntomas de las causas y la caja negra de la evidencia de la caja blanca. También trata una respuesta exitosa al protocolo con contenido incorrecto como un error que puede requerir pruebas de extremo a extremo. En esta escalera de recuperación, el recibo de intervención y la telemetría en tiempo de ejecución son pruebas de causa en caja blanca; la verificación de resultados nativos de destino es la prueba de síntomas en caja negra. Ambos son útiles, pero sólo este último resuelve lo que el usuario realmente perdió. Transformar la verificación de la recuperación en un contrato de explotación Para cada clase de tareas vigilada, define la escalera antes de un incidente: los estados de incumplimiento que permiten una intervención limitada; la persona o política autorizada para aprobar cada acción; la acción reversible y sus límites de esfuerzo, tiempo y costes; el control de preparación para la ejecución después de la acción; un campo de progreso útil con una dirección esperada; el verificador de resultados deterministas, su plazo y su límite de frescura; la oportunidad de recurrencia que cierra la ventana de estabilidad; el camino de retroceso o escalada cuando el intento falla. Mantenga el vocabulario del veredicto pequeño. Needs human significa que falta autoridad, un secreto o una decisión irreversible. Intervention failed significa que la acción aprobada no se completó. Alive only significa que el tiempo de ejecución está listo pero no hay progreso útil. Recovering significa que se ha reanudado el progreso mientras se mantiene abierta la verificación de resultados o de estabilidad. Uncertain significa que faltan o quedan obsoletas pruebas decisivas. False recovery significa que el plazo final del resultado pasó sin el resultado prometido. Relapsed significa que el síntoma original ha sido devuelto. Recovered significa que se verifica el resultado específico de la tarea y que la ventana de recurrencia se mantiene limpia. Hay límites honestos. Algunos resultados no se pueden comprobar de manera determinista. El cliente aceptó el análisis puede requerir una decisión humana; el resumen es bueno puede necesitar una rúbrica cuya fiabilidad se mide por sí misma. Un destino también puede cometer un efecto secundario antes de que terminen los tiempos de respuesta. Conciliar con una llave de impotencia o una búsqueda independiente antes de volver a intentarlo. Cuando la evidencia no resuelva el estado, mantenga la incertidumbre visible. Sidewisp se encuentra actualmente en versión preliminar privada. Sus adaptadores de monitoreo de producción, análisis de costos de tokens y ejecución de recuperación generalmente no se envían. La dirección prevista es una capa de salud junto con los tiempos de ejecución existentes que hace explícito el diagnóstico, la autoridad, la frescura de la evidencia, el progreso útil y la verificación de resultados. No debe convertirse en una puerta de entrada de modelo obligatoria ni en un dispositivo de fijación autónomo. Si ese modelo de operación se ajusta a sus agentes, Únete a la vista previa privada. Fuentes Kubernetes: vigilancia, preparación y pruebas de inicio Google SRE Book: Monitoreo de los sistemas distribuidos RFC 9110: Semántica HTTP, 202 Acceptado Telemetría abierta: rastros