Observabilité de l'agent AI: Arrêter le vert stagnant avec une preuve de fraîcheur

Le verdict de santé de l'agent AI doit expirer. Si un tableau de bord indique "santé" sans indiquer le moment où les preuves décisives ont été observées, il peut maintenir un écran vert déconnecté longtemps après que les faits aient changé. Le défaut pratique est un certificat de fraîcheur évalué à un moment explicite. Pour chaque signal requis, conservez le temps de l'événement source, le temps d'observation du collecteur, une séquence en augmentation monotone et un âge maximum spécifique à la tâche. Marquez la course en bonne santé seulement tant que chaque signal requis est présent, frais, non répété et conforme au résultat prétendu. Si les preuves requises expirent, le verdict devient unknown non sain et ne s'échoue pas automatiquement. Cet article rend cette règle vérifiable. Le fichier de cinq cas qui l'accompagne ne modifie pas le modèle, le fournisseur de traces ou l'agent. Il modifie uniquement l'âge, l'heure d'arrivée, la séquence ou la valeur de la sortie et montre pourquoi un statut vert caché ne peut pas être fiable par lui même. Un verdict de santé a besoin d'un délai d'expiration Les systèmes d'observabilité sont bons pour conserver la dernière valeur. La santé des agents exige de savoir si cette valeur est toujours admissible. Imaginez un agent de recherche planifié avec trois champs verts: le rythme cardiaque: ok ; progrès utiles: 3 sources accepted ; vérification des résultats: brief schema valid . Ces valeurs décrivent différentes promesses. Un battement cardiaque peut expirer après deux intervalles de collecte. Les progrès peuvent raisonnablement rester inchangés pendant une phase de lecture limitée. Un reçu de résultat peut rester valable pour la course spécifique à perpétuité, mais il doit toujours être joint à cette course plutôt que hérité d'hier. Un seul timestamp global last updated efface ces distinctions. Le certificat plus sûr contient un délai d'expiration pour chaque fait requis: Le minimum compte. Un nouveau reçu de résultat ne peut pas prouver que le temps d'exécution est actuellement atteignable; un nouveau battement de cœur ne peut pas prouver que l'artefact promis existe. Lorsque le premier signal requis expire, le verdict sain combiné expire avec lui. Il ne s'agit pas d'une exigence nouvelle inventée pour les LLM. Kubernetes utilise l'API Lease pour les battements cardiaques des nœuds: chaque kubelet met à jour un Leases spec.renewTime , et le plan de contrôle utilise ce timestamp pour déterminer la disponibilité des nœuds. Le Kubernetes Documentation de location à la révision de la source 9a8df52 officiel est utile ici parce qu'il considère la disponibilité comme une réclamation à durée déterminée et non comme une propriété permanente de la dernière mise à jour réussie. Prométhée fait une limite connexe explicite. Son documentation de requête à la révision ab225f6 décrit un regard en arrière par défaut de cinq minutes et un comportement de série périmée. Ce délai de cinq minutes est une règle de requête Prometheus, pas un délai universel approprié pour les agents. Le principe transférable est qu'un ancien échantillon doit finalement cesser de répondre à une question actuelle. Utilisez deux horloges et un temps d'évaluation Un événement peut avoir au moins deux moments pertinents: lorsque la source dit qu'il s'est produit et lorsque le système de collecte l'a observé. Gardez les deux. Le Modèle de données OpenTelemetry Logs à la révision f62b146 stable définit le Timestamp comme étant le temps mesuré par l'horloge d'origine et le ObservedTimestamp comme étant le temps que le système de collecte a observé l'événement. Il dit aussi que le timestamp source peut être absent. Cette séparation empêche un champ surchargé de prétendre répondre à la commande d'événements, de retarder le transport et de surveiller la fraîcheur à la fois. Pour un certificat de santé, évaluez l'âge dans un domaine de l'horloge: Utilisez source time pour commander les événements source uniquement lorsque vous connaissez la limite de synchronisation de l'horloge source. Soustraire une horloge hôte d'une horloge collectrice et appeler la latence réseau résultante est injustifiée sans cette limite. Si un ordinateur portable est à quatre minutes de vitesse, un battement cardiaque nouvellement recueilli peut sembler provenir du futur; s'il est lent, un agent en direct peut sembler obsolète. collector time a une signification plus étroite mais fiable: le moniteur avait cette preuve à ce moment là. Il ne peut pas prouver quand l'action sous jacente s'est réellement produite, mais il peut prouver si la vision du moniteur est récente. Retarder la collecte des dossiers séparément lorsque la source fournit des horloges fiables ou un reçu de transport. Un temps d'évaluation est tout aussi important. Sans evaluated at , un certificat ne peut être reproduit lors d'un essai ou d'un examen des incidents. Fresh now n'est pas une déclaration vérifiable. Fresh à 2026 07 26T00:42:00Z dans le cadre de la politique freshness v1 est. Construire un certificat, pas un cache de la dernière valeur Le plus petit enregistrement utile est délibérément simple: Chaque champ ferme une lacune spécifique: champs Ce qui l'empêche run id accepter le résultat d'une autre course evaluated at Un mouvement, irréductible maintenant collector time conservation des preuves après la fenêtre de fraîcheur du moniteur source time perdre l'ordre de l'événement source lorsque cette montre est digne de confiance sequence d'accepter un battement cardiaque répété ou hors ordre comme nouveau max age s d'appliquer un délai arbitraire à des signaux différents required le traitement silencieux des preuves décisives manquantes comme facultatives policy changement de seuils sans suivi d'audit Ne déduisez pas de progrès à partir de la séquence de battements cardiaques. Une boucle peut émettre des battements cardiaques parfaits sans produire de changement utile. Donnez leur le rythme cardiaque, les progrès, la dépendance à l'attente, et les résultats de leurs propres dossiers de preuve. Une approbation nommée peut être fraîche et valable pendant que les progrès sont intentionnellement arrêtés; le certificat doit classer les versions waiting , non collées. La priorité du verdict devrait préserver l'incertitude: 1. une nouvelle défaillance déterministique donne attention ; 2. un résultat de signal requis manquant, obsolète, à venir ou reproduit unknown ; 3. une dépendance nommée fraîchement donne waiting ; 4. Seules des preuves complètes, récentes et actuelles peuvent fournir healthy . Cette ordonnance ne cache pas l'échec de la télémétrie manquante. Un nouveau résultat échoué est une preuve plus forte qu'un battement cardiaque stérile. À l'inverse, les preuves périmées seules ne prouvent pas que l'agent a échoué; elles prouvent que le contrôleur ne peut actuellement pas appuyer une affirmation saine. Exécuter cinq contre exemples L'appareil qui accompagne cet article contient cinq courses évaluées simultanément: Le fresh run possède trois signaux frais, avancés et réussis; stale green est toujours porté heartbeat: ok , mais le collectionneur l'a vu pour la dernière fois il y a 240 secondes contre une limite de 120 secondes; delayed batch contient un enregistrement des progrès dont le temps de collecte est après le temps d'évaluation, de sorte que les preuves n'étaient pas encore disponibles; replayed sequence répète une séquence de résultats plutôt que de la faire avancer; failed outcome a de nouvelles preuves que la vérification requise des artefacts a échoué. Exécutez le classifiateur Node.js 20+: Sa sortie exacte est: La thèse falsifiable est étroite: la modification de la seule admissibilité des preuves doit être capable de révoquer un verdict vert. fresh run et stale green contiennent tous les deux heartbeat: ok ; seul l'âge du collectionneur diffère. Si un tableau de bord affiche à la fois la santé au moment de l'évaluation, il affiche une valeur en cache plutôt qu'une conclusion actuelle sur la santé. Le cas delayed batch traite d'une erreur plus subtile. La télémétrie reconditionnelle peut améliorer le diagnostic historique, mais elle ne doit pas réécrire ce que le moniteur savait au moment de la décision antérieure. Comparer collector time avec evaluated at garde le jeu d'incident honnête. Le contrôle de séquence bloque une autre fausse fraîcheur. Une reconnexion de file d'attente peut redonner le dernier battement cardiaque avec une nouvelle heure d'arrivée du transport. Si le moniteur renouvelle l'âge en utilisant l'arrivée seule, la répétition fait apparaître une source morte actuelle. Requérir une séquence source, un identifiant de démarrage ou un autre jeton monotone où le temps d'exécution peut en fournir un. Au travers des redémarrages, associez la séquence à un identifiant d'incarnation afin qu'un réinitialisation légitime ne soit pas confondu avec la répétition. L'appareil est un ensemble de contre exemples inspectibles et non une référence de production. Il n'estime pas les taux de faux positifs, ne tient pas compte de chaque file d'attente, ni ne prouve que les limites d'exemple correspondent à votre charge de travail. Sa valeur est que chaque verdict a une explication unique et peut être modifié en éditant un timestamp ou une séquence. Calibrer la fraîcheur autour des promesses Choisissez des limites à partir du comportement attendu du flux de travail, et non d'un tableau de bord universel par défaut. Pour un enquêteur attendu toutes les 60 secondes, une limite de battement cardiaque pourrait être deux intervalles manqués plus un frisson mesuré. Pour une phase de compilation qui devrait s'exécuter en silence pendant huit minutes, la progression peut utiliser une date limite de phase plutôt qu'une règle de changement de 60 secondes. Pour un reçu de résultat lié de manière immuable à une course et à un hash d'artefact, la fraîcheur peut signifier que appartient à cette course et a été vérifiée après son début, non a été créée dans les cinq dernières minutes. Testez ces limites avant d' alerter: le rythme normal du planificateur; le redémarrage du collecteur et le backlog de file d'attente; déviation de l'horloge hôte; la livraison en double et hors commande; réinitialisation de l'heure d'exécution avec une séquence de réinitialisation; une attente légitime d'approbation humaine; une commande terminée dont le contrôle de destination échoue; une panne de moniteur pendant que l'agent continue de travailler. Enregistrer la première violation séparément de la dernière observation. Faites preuve de persévérance lorsque les preuves sont bruyantes, mais ne laissez pas un nouveau rythme cardiaque réinitialiser une horloge de progression obsolète. Éliminer un incident uniquement avec de nouvelles preuves qui répondent à la condition qui l'a ouvert. Une reprise du processus n'est pas la preuve que le rapport manquant existe maintenant. Il y a un coût à cette rigueur: plus de champs, une politique par flux de travail et un état explicite de unknown . L'avantage est d'éviter une fiction plus coûteuse et un statut vert soutenu par des preuves que le moniteur n'a plus le droit d'utiliser. Commencez par les trois signaux qui peuvent modifier l'action: accessibilité, progrès utile ou dépendance, et vérification des résultats. Gardez le diagnostic et les allégations de produits limités Un certificat de fraîcheur se trouve au dessus des journaux, des traces, des mesures, des enregistrements des planificateurs et des contrôles de destination. Elle ne les remplace pas. Il enregistre les éléments de preuve admissibles pour une décision sanitaire et l'échéance de cette décision. Il ne devrait pas non plus entraîner une reprise irréversible par lui même. unknown appelle à la restauration des preuves ou à l'inspection humaine. attention peut justifier une recommandation limitée, mais les secrets, les changements destructeurs et les diagnostics incertains nécessitent toujours une autorité explicite. Le rétablissement n'est complet qu'après un nouveau progrès ou après l'observation du résultat prévu. Cela résout la question initiale: l'observabilité de l'agent AI ne devrait jamais préserver un état sain indéfiniment. Donnez à chaque signal décisif un timestamp du collecteur, l'âge maximum lié à la politique, l'identité de l'exploitant actuel et la garde de répétition; évaluez les à un moment donné; et expirez le verdict combiné au plus tôt à la limite requise. Sidewisp est actuellement en préversion privée. Son rôle prévu est une couche de santé à côté des temps d'exécution existants des agents, avec des preuves visibles et des limites d'approbation humaine. La collecte des agents de production, les adaptateurs de temps d'exécution, la récupération automatisée, la gestion du cron et l'analyse du coût des jetons ne sont généralement pas expédiés aujourd'hui. Si les preuves de fraîcheur correspondent aux défaillances que vous devez détecter, vous pouvez rejoindre la prévisualisation privée.