2026-08-01T19:16:18.766Z
Observabilidad del agente AI: detener el verde estable con una prueba de frescura
Un certificado ejecutable de cinco casos que expira los veredictos de salud almacenados en caché, separa el tiempo de la fuente y el tiempo de recolección, y rechaza la evidencia rellena o reproducida.
El veredicto de salud del agente AI debe expirar. Si un panel dice saludable sin mostrar cuándo se observó su evidencia decisiva, puede mantener un tiempo de ejecución desconectado mucho después de que los hechos hayan cambiado. El defecto práctico es un certificado de frescura evaluado en un momento explícito. Para cada señal requerida, mantenga el tiempo del evento fuente, el tiempo de observación del colector, una secuencia que aumenta monótona y una edad máxima específica de la tarea. Marque la carrera saludable sólo mientras todas las señales requeridas estén presentes, frescas, no reproducidas y consistentes con el resultado reclamado. Si la evidencia requerida expira, el veredicto se vuelve unknown no saludable y no falló automáticamente. Este artículo hace que esa regla sea comprobable. La fijación de cinco casos que acompaña no cambia el modelo, el proveedor de rastreo o el agente de solicitud. Sólo cambia la edad de la evidencia, la hora de llegada, la secuencia o el valor del resultado y muestra por qué no se puede confiar en un estado verde almacenado en caché por sí mismo. Un veredicto de salud necesita una fecha de vencimiento Los sistemas de observabilidad son buenos para conservar el valor más reciente. La salud del agente requiere saber si ese valor es todavía admisible. Imagínese un agente de investigación programado con tres campos verdes: la frecuencia cardíaca: ok ; progreso útil: 3 sources accepted ; control de resultados: brief schema valid . Esos valores describen diferentes promesas. Un latido cardíaco puede expirar después de dos intervalos de recogida. El progreso puede mantenerse razonablemente sin cambios durante una fase de lectura limitada. Un recibo de resultado puede permanecer válido para la carrera específica para siempre, pero aún debe unirse a esa carrera en lugar de heredar de ayer. Una sola marca de tiempo global last updated borra esas distinciones. El certificado más seguro almacena una caducidad para cada hecho requerido: El mínimo importa. Un recibo reciente del resultado no puede probar que el tiempo de ejecución es actualmente alcanzable; un nuevo latido del corazón no puede probar que el artefacto prometido existe. Cuando expira la primera señal requerida, el veredicto saludable combinado expira con él. Este no es un requisito nuevo inventado para LLM. Kubernetes utiliza la API Lease para los latidos cardíacos de los nodos: cada kubelet actualiza un Leases spec.renewTime , y el plano de control utiliza ese sello de tiempo para determinar la disponibilidad de los nodos. El Documentación de arrendamiento de Kubernetes en la versión de origen 9a8df52 oficial es útil aquí porque trata la disponibilidad como una reclamación limitada en el tiempo, no como una propiedad permanente de la última actualización exitosa. Prometeo hace explícito un límite relacionado. Su documentación de consulta en la revisión ab225f6 describe una retroalimentación predeterminada de cinco minutos y un comportamiento de serie obsoleta. Esa regla por defecto de cinco minutos es una regla de consulta de Prometheus, no un tiempo límite universal apropiado para los agentes. El principio transferible es que una muestra vieja eventualmente debe dejar de responder a una pregunta actual. Utilice dos relojes y un tiempo de evaluación Un evento puede tener al menos dos momentos relevantes: cuando la fuente dice que ocurrió y cuando el sistema de recogida lo observó. Quédate con ambos. El estable Modelo de datos de registros de OpenTelemetry en revisión f62b146 define a Timestamp como el tiempo medido por el reloj de origen y a ObservedTimestamp como el tiempo en que el sistema de recogida observó el evento. También dice que la timestamp fuente puede estar ausente. Esa separación impide que un campo sobrecargado pretenda responder al pedido de eventos, retrasar el transporte y controlar la frescura de una vez. Para un certificado de salud, evalúe la edad en un dominio de reloj: Utilice source time para ordenar eventos de origen sólo cuando sepa el reloj de origen s sincronización limitada. Sustraer un reloj de anfitrión de un reloj de colector y llamar a la latencia de la red resultante es injustificado sin ese límite. Si un reloj portátil es rápido cuatro minutos, un latido cardíaco recién recogido puede parecer venir del futuro; si es lento, un agente en vivo puede parecer obsoleto. collector time tiene un significado más estrecho pero confiable: el monitor tenía esta evidencia en ese momento. No puede probar cuándo ocurrió realmente la acción subyacente, pero puede probar si la propia visión del monitor es reciente. Retrasar la recogida de registros por separado cuando la fuente proporcione relojes confiables o un recibo de transporte. Un tiempo de evaluación es igualmente importante. Sin evaluated at , no se puede reproducir un certificado en una revisión de ensayos o incidentes. Fresh now no es una declaración inspectable. Fresco en 2026 07 26T00:42:00Z bajo la política freshness v1 es. Construir un certificado, no un caché de valor más reciente El registro más pequeño y útil es deliberadamente simple: Cada campo cierra una brecha específica: El campo Lo que impide run id aceptar el resultado de otra carrera evaluated at Un movimiento, irreproducible ahora collector time conservación de la evidencia después de la ventana de frescura del monitor source time pérdida de orden de origen evento cuando ese reloj es confiable sequence acepta un latido cardíaco repetido o fuera de orden como nuevo max age s Aplicación de un plazo de tiempo arbitrario para señales diferentes required Tratar en silencio como opcional la falta de pruebas decisivas. policy cambios en los umbrales sin rastro de auditoría No deduzca el progreso de la secuencia de la frecuencia cardíaca. Un bucle puede emitir perfectos latidos cardíacos sin producir ningún cambio útil. Dar el ritmo cardíaco, progresar, dependencia de la espera, y obtener sus propios registros de evidencia. Una homologación con nombre puede ser reciente y válida mientras el progreso se detiene intencionalmente; el certificado debe clasificar las ejecuciones como waiting , no pegadas. La precedencia del veredicto debe preservar la incertidumbre: 1. un nuevo fallo determinístico produce attention ; 2. un rendimiento de señal requerida unknown perdido, obsoleto, de llegada futura o reproducido; 3. un rendimiento de dependencia denominado de nuevo waiting ; 4. Sólo pruebas completas, frescas y corrientes pueden producir healthy . Esta orden no oculta el fracaso detrás de la falta de telemetría. Un nuevo resultado fallido es una prueba más fuerte que un latido cardíaco obsoleto. Por el contrario, las pruebas obsoletas por sí solas no demuestran que el agente haya fallado; demuestran que el monitor no puede apoyar actualmente una afirmación saludable. Ejecutar cinco contraejemplos El dispositivo que acompaña a este artículo contiene cinco carreras evaluadas al mismo tiempo: fresh run tiene tres señales nuevas, avanzadas y exitosas; stale green todavía lleva heartbeat: ok , pero el colector lo vio por última vez hace 240 segundos contra un límite de 120 segundos; El delayed batch contiene un registro de progreso cuyo tiempo de recogida es posterior al tiempo de evaluación, por lo que aún no había pruebas disponibles; replayed sequence repite una secuencia de resultados en lugar de avanzar en ella; failed outcome tiene nuevas pruebas de que la verificación requerida del artefacto falló. ejecuta el clasificador Node.js 20+: Su salida exacta es: La tesis falsificable es estrecha: cambiar sólo la admisibilidad de la evidencia debe ser capaz de revocar un veredicto verde. fresh run y stale green contienen ambos heartbeat: ok ; sólo la edad del colector difiere. Si un tablero de control sigue siendo tan saludable en el momento de la evaluación, muestra un valor almacenado en caché en lugar de una conclusión de salud actual. El caso delayed batch maneja un error más sutil. La telemetría de retroalimentación puede mejorar el diagnóstico histórico, pero no debe reescribir lo que el monitor sabía en un momento de decisión anterior. Comparar collector time con evaluated at mantiene la reproducción del incidente honesta. El control de secuencia bloquea una nueva falsedad. Una nueva conexión de cola puede volver a dar el último latido cardíaco con una nueva hora de llegada del transporte. Si el monitor actualiza la edad usando solo la llegada, la reproducción hace que una fuente muerta parezca actual. Requerir una secuencia de origen, identificador de arranque, u otro token monótono donde el tiempo de ejecución puede proporcionar uno. Al reiniciar, empareja la secuencia con un ID de encarnación para que un restablecimiento legítimo no se confunda con repetición. El dispositivo es un conjunto de contraejemplos inspectables, no un punto de referencia de producción. No estima las tasas falsas positivas, explica cada cola, ni prueba que los límites de ejemplo se ajustan a su carga de trabajo. Su valor es que cada veredicto tiene una explicación de un campo y se puede cambiar editando un sello de tiempo o secuencia. Calibra la frescura alrededor de las promesas Seleccione los límites del comportamiento esperado del flujo de trabajo, no de un tablero de control universal predeterminado. Para un encuestador esperado cada 60 segundos, un límite de la frecuencia cardíaca podría ser dos intervalos perdidos más el nerviosismo medido. Para una fase de compilador que se espera que se ejecute en silencio durante ocho minutos, el progreso puede utilizar un plazo de fase en lugar de una regla de cambio de 60 segundos. Para un recibo de resultado vinculado inmutablemente a una carrera y a un hash de artefacto, la frescura puede significar que pertenece a esta carrera y se verificó después de su inicio, no que se creó en los últimos cinco minutos. Prueba estos límites antes de alertar: el ritmo normal del programador; reinicio del colector y retraso de fila; la inclinación del reloj del anfitrión; la entrega duplicada y fuera de pedido; reiniciar el tiempo de ejecución con una secuencia de restablecimiento; una espera legítima de aprobación humana; un comando completado cuyo control de destino falla; un apagón del monitor mientras el agente sigue trabajando. Registrar la primera infracción por separado de la última observación. Requiere perseverancia cuando la evidencia es ruidosa, pero no dejes que un nuevo latido cardíaco restablezca un reloj de progreso obsoleto. Elimine un incidente sólo con pruebas nuevas que aborden la condición que lo abrió. Un proceso reiniciado no es prueba de que el informe desaparecido exista ahora. Hay un costo para este rigor: más campos, política por flujo de trabajo y un estado explícito de unknown . El beneficio es evitar un estado de ficción más costoso verde respaldado por pruebas de que el monitor ya no tiene derecho a usar. Comience con las tres señales que pueden cambiar la acción: accesibilidad, progreso útil o dependencia, y verificación de resultados. Mantenga el diagnóstico y las afirmaciones de productos limitados Un certificado de frescura está por encima de los registros, rastros, métricas, registros de programadores y controles de destino. No los reemplaza. Se registran las pruebas que fueron admisibles para una decisión sanitaria y cuándo expira dicha decisión. Tampoco debe desencadenar una recuperación irreversible por sí sola. unknown pide la restauración de la evidencia o la inspección humana. attention puede justificar una recomendación limitada, pero los secretos, los cambios destructivos y los diagnósticos inciertos aún requieren autoridad explícita. La recuperación sólo se completa después de que se haya realizado un nuevo progreso o se haya observado el resultado previsto. Eso resuelve la pregunta original: la observabilidad del agente AI nunca debe preservar el estado saludable indefinidamente. Dar a cada señal decisiva un sello de tiempo de recolección, la edad máxima vinculada a la política, la identidad actual y la guardia de reproducción; evaluarlos en un instante nombrado; y expirar el veredicto combinado en el límite más temprano requerido. Sidewisp se encuentra actualmente en versión preliminar privada. Su papel previsto es una capa de salud junto con los tiempos de funcionamiento de los agentes existentes, con evidencia visible y límites de aprobación humana. La recopilación de agentes de producción salud, adaptadores de tiempo de ejecución, recuperación automática, gestión cron y análisis de costos de tokens generalmente no se envían hoy en día. Si las pruebas de frescura coinciden con los fallos que necesitas detectar, puedes Únete a la vista previa privada.