Surveillance des agents AI: une politique d'alerte silencieuse pour les échecs réels

La surveillance de l'agent AI ne devrait interrompre une personne que lorsqu'elle peut nommer une défaillance en cours, montrer les preuves et indiquer une prochaine action limitée. Un appel à l'outil, une pointe de marque ou une longue trace peuvent aider à expliquer un problème; aucun d'entre eux ne prouve que l'agent a cessé de fournir un travail utile. Pour une première politique pratique, surveillez trois choses séparément: 1. Freshtime: a commencé la course programmée, et son rythme cardiaque est il toujours en cours? 2. Utilisé: a t il changé les données probantes spécifiques à la tâche dans le délai prévu? 3. O vérification des résultats: L'offre promise existe t elle et passe t elle son contrôle d'acceptation? Puis envoyez le résultat. Page pour une défaillance persistante et pertinente pour l'utilisateur. Créer un ticket ou une notification au propriétaire pour une attente légitime ou une enquête lente. Supprimez un seul mauvais échantillon et un travail sain. Cet article transforme cette règle en un petit contrat d'événement et un fichier exécutable de huit cas. La page doit nommer la promesse rompue Un agent peut être en ligne alors que son travail est faux. Il peut aussi être silencieux parce qu'il attend correctement l'approbation. C'est pourquoi l'exécution du processus est trop faible pour la surveillance des agents et aucun appel d'outil récent est trop bruyant pour la page. Le chapitre Surveillance des systèmes distribués de Google trace une ligne utile entre les preuves de la boîte blanche et les symptômes de la boîte noire. La télémétrie interne est essentielle au diagnostic, mais une page doit représenter une défaillance évidente affectant le service. Le chapitre note également qu'une réponse réussie au protocole peut toujours être une erreur lorsque le contenu retourné est erroné. Pour un agent, l'échec correspondant est une course qui dit completed alors que l'artefact requis est absent ou non valide. Commencez par rédiger un contrat de surveillance par flux de travail: champ de contrat Exemple pour un agent de référentiel Pourquoi il existe Commencement attendu Les jours de la semaine à 09h00 UTC, grâce de cinq minutes Détecter un calendrier manqué La fréquence cardiaque Observation de l'heure d'exécution ne dépassant pas dix minutes Détecter une course inaccessible ou morte Des preuves de progrès Nouveau engagement, changement de résultat de test ou blocage enregistré Motion séparée de l'activité répétée Une attente légitime Identification d'homologation plus propriétaire responsable Continuez à attendre le travail à l'extérieur de la page de stand Demandes d'achèvement L'état de l'heure d'exécution est completed Enregistrer ce que l' agent a déclaré Prédicat de résultat La branche cible contient le passe des contrôles obligatoires et obligatoires Vérifiez indépendamment le résultat promis La dernière ligne doit être délibérément spécifique. Generé une réponse peut être suffisant pour une tâche de chat. Créé un fichier ne suffit pas pour une tâche de sortie si le fichier est invalide, non publié ou attaché à la destination incorrecte. Le moniteur ne peut pas déduire ce contrat à partir d'un intervalle; le propriétaire du flux de travail doit le définir. L'outil de course sans traiter les écarts comme une finition Les conventions sémantiques génératives AI définissent désormais les opérations d'agent et de flux de travail telles que invoke agent , invoke workflow , plan et execute tool . Le document de portée de l'agent actuel fournit également des champs tels que gen ai.agent.id , gen ai.agent.name , gen ai.agent.version et error.type . Ce sont des domaines de corrélation et de diagnostic utiles. Ils ne sont pas un schéma de résultats. Le document est marqué Development , il importe donc de fixer une version. Il prévient également que les messages d'entrée et de sortie capturés peuvent contenir des informations sensibles. Vous pouvez mettre en œuvre la politique d'alerte ci dessous sans stocker des instructions, des réponses, des secrets ou des charges utiles complètes d'outils. Un événement compact peut ressembler à ceci: Gardez le runId stable sur le programmeur, la télémétrie en temps d'exécution et le vérificateur de résultats. Conserver un agent à faible cardinalité ou un nom de flux de travail pour l'agrégation. Mettez des identifiants diagnostiques derrière l'alerte plutôt que dans son identité. Sinon, chaque nouvelle tentative peut créer un nouvel incident pour la même promesse rompue. La piste supérieure de l'illustration est occupée mais circulaire. La voie inférieure change d'état et produit un résultat inspectable. Cette distinction est au centre de la politique: l'activité est la preuve du débogage; les progrès et les résultats décident de la santé. Testez la politique avec huit cas d'inconvénient L'artefact qui accompagne cet article utilise un enregistrement NDJSON par course observée. Il couvre la réalisation vérifiée, le faux succès, un calendrier manqué, un temps de fonctionnement inaccessible, une attente légitime d'approbation, une course persistante sans progrès, un mauvais échantillon transitoire et un travail actif sain. Remplissez le dans le répertoire des objets: Résultats attendus: L'évaluateur utilise une priorité fixe. Un faux résultat de succès gagne sur la télémétrie obsolète parce que le résultat cassé est déjà connu. Un calendrier manqué gagne quand la course n'a jamais commencé. Un temps d'exécution inaccessible gagne sur un diagnostic sans progrès parce que le moniteur manque de preuves d'exécution fraîches. Une attente explicite gagne sur la règle des stands. Ce n'est qu'alors qu'un timestamp de progression périmé devient stuck . Cela empêche un enregistrement d'ouvrir trois incidents. Il rend également chaque décision expliquable: la sortie peut nommer la condition, le timestamp de preuve et le seuil qui a été franchi. Les seuils inclus sont des exemples et non des défauts universels: cinq minutes après le démarrage prévu; dix minutes sans battement cardiaque; quinze minutes sans progrès utile; deux mauvais échantillons consécutifs pour les conditions de page; trois échantillons négatifs consécutifs pour un ticket sans progrès. Un agent de codage qui fixe deux minutes et un agent de recherche qui lit des documents pendant une heure ne devraient pas partager ces chiffres. L'important est la séquence et l'exigence de persistance, pas la durée particulière. Ajouter de la persévérance avant l'escalade Les règles d'alerte Prometheus fournissent deux mécanismes pertinents. La clause for documentée maintient une condition nouvellement active en attente jusqu'à ce qu'elle soit restée active pendant une période. Le keep firing for peut maintenir une alerte ouverte après la dernière échantillon correspondant pour réduire les flaps ou la fausse résolution causée par les données manquantes. Les mêmes idées s' appliquent même si vous n' utilisez pas Prometheus: exigent des observations répétées avant de faire une demande de silence; enregistrer la première période de violation séparément de l'échantillon le plus récent; les alertes de groupe par flux de travail et promesses non respectées, et non par réessayer ou suivre; maintenir l'incident ouvert jusqu'à ce que de nouvelles preuves confirment la récupération; réinitialiser uniquement lorsque la gravité ou les résultats affectés changent. Ne mettez pas toutes les conditions derrière le même retard. Une réclamation d'achèvement dont l'artefact requis ne parvient pas à une vérification déterministe est une preuve plus forte qu'un battement cardiaque raté. À l'inverse, un score de qualité LLM près d'un seuil est une preuve plus faible et peut appartenir à une file d'attente plutôt qu'à un pager. Une table de routage silencieuse est plus utile qu'un long inventaire métrique: Condition observée Route par défaut Condition claire Complétation demandée; le contrôle des résultats requis échoue après sa grâce de vérification Page lorsque l'utilisateur est concerné, sinon billet Le résultat est corrigé par le prédicat ou la revendication. La course attendue n'a pas commencé après deux contrôles. Page lorsque la course a une obligation en cours Les débuts de course ou l'attente du planificateur sont explicitement modifiés Le rythme cardiaque est stérile pendant deux contrôles. Page lorsque le travail actif est affecté Un nouveau rythme cardiaque et un nouvel échantillon de santé L'approbation, la décision secrète ou irréversible est en suspens. En informer le propriétaire responsable ou créer un billet La dépendance est fournie ou le travail est annulé L'activité se poursuit mais les preuves de la tâche n'ont pas changé pour trois contrôles Billets d'enquête Des modifications de progrès ou une attente légitime sont enregistrées. Un échantillon périmé ou manquant Aucune notification humaine Réévaluer sur l'échantillon suivant Travailler les boîtes avant de choisir un outil Les erreurs de politique d'alerte apparaissent généralement aux frontières, pas sur le chemin heureux. Vérification lag: Un éditeur peut signaler la finition des secondes avant les mises à jour d'un CDN ou d'un index de recherche. Donnez à la prédication du résultat une période de grâce documentée, puis vérifiez à nouveau. Ne considérez pas un sommeil arbitraire comme une preuve; le deuxième contrôle doit inspecter la vraie destination. Human attends: stocke à la fois la dépendance et son propriétaire. waitingOn: "approval" sans personne responsable ne fait que cacher le stand. Une attente peut rester saine pour l'agent tout en créant une tâche humaine en retard. Long travail silencieux: une étape de recherche ou de compilation peut être saine sans événements fréquents avec des outils. Choisissez des preuves de progrès que le temps d'exécution peut émettre en toute sécurité: une fragmentation complète, un hash de contenu modifié, une nouvelle phase d'essai ou une date limite explicite de phase. Retries: Les retries peuvent masquer les défaillances des fournisseurs tout en gonflant l'activité et les coûts. Les regrouper sous le même cours et enregistrer les tentatives comptent comme contexte de diagnostic. Une nouvelle tentative ne doit pas réinitialiser le temps de la première rupture, sauf si elle produit des progrès utiles. Signals inconnus: la télémétrie manquante de n'est pas verte. Indiquer qu'il n'est pas disponible et éviter la récupération automatique lorsque le moniteur ne peut pas distinguer le blocage de la déconnexion. Un diagnostic incertain devrait demander l'inspection et non une correction destructrice. Récupération: fermant un incident parce qu'une commande de redémarrage renvoie à zéro répète le problème de faux succès. Utilisez la même prédication de résultat ou de progrès qui a ouvert l'incident. Le rétablissement n'est complet que lorsque de nouvelles preuves montrent que l'œuvre est en mouvement ou que le résultat promis existe. Ce que cette expérience prouve et ce qu'elle ne prouve pas Le dispositif permet de falsifier une thèse étroite: avec la priorité et les seuils documentés, les huit dossiers fournis produisent exactement trois pages, deux billets et trois notifications supprimées. Vous pouvez modifier un timestamp ou le nombre de violations et voir le changement de route. Cela ne prouve pas que les seuils correspondent à votre charge de travail. Les cas sont synthétiques, et l'évaluateur lit des dossiers déjà normalisés. Les intégrations réelles doivent gérer la déformation de l'horloge, la livraison en double, les échantillons tardifs, la politique du planificateur, les fuseaux horaires et les pannes du collecteur. Ils ont aussi besoin d'une limite de confidentialité pour tout ce qui découle des invites ou des appels à l'outil. La politique ne remplace pas les traces, les évaluations ou les journaux d'exécution. Ces signaux expliquent pourquoi un résultat a échoué. Il ne garantit pas non plus qu'un prédicat spécifique à la tâche couvre tous les problèmes de qualité. Certains résultats sont déterministes, comme un hash de fichier ou un résultat de test; d'autres nécessitent un processus d'échantillonnage, d'examen ou d'évaluation avec un niveau d'incertitude explicite. Le plus important, c'est que la politique ne devrait pas autoriser une reprise autonome. Un moniteur peut recommander une reprise limitée ou préparer une étape de réparation, mais des actions irréversibles, un accès secret et des diagnostics incertains nécessitent toujours l'autorité humaine. Transformer l'appareil en test d'acceptation Avant de connecter une destination d'alerte réelle, remplacer les cas synthétiques par des exemples récents d'un même flux de travail: 1. Définir le début attendu et la latence acceptable. 2. Choisissez un battement cardiaque produit en dehors de la réponse modèle. 3. Nombrez la moindre preuve d'un progrès utile. 4. Enregistrer les raisons légitimes d'attendre et les propriétaires. 5. Mettre en œuvre le prédicat de résultats à la destination réelle. 6. Reprise des cas connus sains, en attente, bloqués, manqués, inaccessibles et faussement réussis. 7. Exécutez la politique assez longtemps pour revoir les fausses pages et les incidents manqués. Ce n'est qu'après cette révision qu'un itinéraire de page doit être actif. Gardez les preuves brutes, la décision, la version du seuil et la vérification de la résolution inspectibles afin que l'opérateur puisse comprendre pourquoi le moniteur a parlé. Sidewisp est conçu autour de cette frontière de la santé: détecter, expliquer, demander l'autorité là où c'est nécessaire, et vérifier le résultat. Sidewisp est actuellement en préversion privée. Les adaptateurs de surveillance de la production et le moteur de récupération ne sont généralement pas expédiés aujourd'hui. Si cette approche correspond à la façon dont vous opérez avec des agents, vous pouvez rejoindre la prévisualisation privée et décrire les cas d'exécution et d'échec dont vous avez besoin.