Tableau de bord de l'agent AI: six signaux qui révèlent la santé opérationnelle

Un tableau de bord agent AI doit répondre à une question opérationnelle avant de tracer un graphique de jeton: Autrait il une attention à cette course maintenant? La plus petite rangée utile combine six signauxfreshness collector, timeliness de calendrier, activité cardiaque, progrès utile, une dépendance explicite d'attente et vérification des résultats. Appliquez les dans un ordre fixe afin qu'une attente d'approbation silencieuse ne soit pas confondue avec un stand et qu'une boucle de réessayer occupée ne soit pas confondue avec un travail sain. Gardez la latence, les appels de modèle, les appels à l'outil, les jetons, le coût et les traces. Ce sont des preuves diagnostiques précieuses. Ils ne prouvent pas par eux mêmes qu'une course prévue a commencé, qu'un rapport a été modifié, qu'une approbation est en attente ou que le produit promis existe. Commencez par une ligne d'état, pas un mur de graphiques Le paramètre par défaut raisonnable pour un tableau de bord des applications LLM est la télémétrie de service. Le tableau de bord officiel AI Agents de Sentry, par exemple, comprend les opérations d'agent, les appels LLM, la durée, l'utilisation du modèle, les jetons, les appels à l'outil, les erreurs et les détails de suivi. Ces panneaux aident à répondre à ce qui s'est passé à l'intérieur de cette exécution et à quelle dépendance est elle devenue lente ou coûteuse ? Un opérateur confronté à vingt circuits autonomes ou planifiés a une décision antérieure: lequel dois je ouvrir? Une ligne d'état compacte peut répondre: champs Exemple Décision qu'il soutient Agents et flux de travail researcher / weekly brief Quel travail est affecté? État waiting:human approval A t il besoin d'intervention, d'orientation ou de patience? L'âge des preuves collector 14s ago Le verdict est il basé sur de nouvelles données ? Derniers progrès utiles 3 sources added, 4m ago Est ce que le résultat se déplace, pas seulement le processus? Le prochain événement attendu approval by owner Qu'est ce qui va se passer ensuite ? Contrôle des résultats brief.md schema: pending Qu'est ce qui doit être vrai avant qu'un "complete" soit crédible? L'état est un verdict dérivé des preuves, pas une copie de la dernière chaîne d'état de la course. Mettez les preuves décisives à côté. Stuck sans fenêtre de progression est un avis; No change de source pendant 13 minutes pendant que les battements cardiaques sont restés frais est inspectable. Cette séparation a un précédent utile dans les systèmes d'agents externes. Kubernetes n'effondre pas le démarrage, la vitesse et la préparation en une seule sonde parce que la réponse correcte est différente: attendre le démarrage, redémarrer après une défaillance réelle de la vitesse ou arrêter le trafic de routage lorsqu'une charge de travail n'est pas prête. Sa documentation met également en garde contre le fait qu'une sonde de vie mal conçue peut créer des défaillances en cascade. Un tableau de bord d'agent a le même problème de contrôle: une étiquette n'est sûre que lorsqu'elle implique la bonne prochaine action. Ramasser six signaux avec une fraîcheur explicite Les six signaux ci dessous constituent un contrat de santé compact. Ils peuvent être stockés sous forme de champs sur un enregistrement de fonctionnement ou calculés à partir d'événements de fonctionnement. Chacun a besoin d'un timestamp, d'une source et d'un état indisponible. 1. Fraîcheur du collectionneur Enregistrer la dernière fois que le tableau de bord a atteint l'heure d'exécution ou qu'il a reçu un événement de confiance. Si le collecteur est obsolète, classez la course comme unreachable ou uncertain avant d'interpréter les battements cardiaques et les progrès plus âgés. Sinon, un hôte déconnecté peut paraître paisiblement inactif. Utilisez un seuil lié à la cadence de collecte. Une limite de fraîcheur de 120 secondes est raisonnable pour un enquêteur d'une minute dans un exemple; c'est un non sens pour un travail qui synchronise chaque heure. Afficher à la fois l'âge observé et la limite configurée. 2. Temps de planification Conservez le démarrage prévu, le démarrage réel, le fuseau horaire, la fenêtre de grâce et la politique du planificateur. Aucune course ne signifie rien sans ces champs. Un planificateur peut être suspendu, une politique de chevauchement peut intentionnellement sauter un démarrage ou une fenêtre de rattrapage peut reporter le travail manqué. La documentation Temporal's Schedule rend ces distinctions concrètes: les calendriers peuvent être suspendus; les politiques de chevauchement peuvent sauter, tamponner, annuler, mettre fin ou permettre des exécutions simultanées; les fenêtres de rattrapage décident quelles actions manquées s'exécutent après une panne. D'autres temps d'exécution utilisent des noms différents, mais le tableau de bord doit toujours préserver la politique qui explique l'écart. 3. Activité cardiaque Un battement cardiaque prouve un contact récent ou une activité d'exécution. Il est utile pour séparer un temps d'exécution inaccessible d'un processus en direct. Il ne devrait pas faire avancer l'horloge de progression. Faites étroiter l'événement: heartbeat at , source , et peut être une séquence monotone en augmentation. Ne dites pas que la course est saine simplement parce que cette séquence continue de changer. 4. Des progrès utiles Définir un delta spécifique à la tâche. Un agent de codage peut modifier la digestion du patch ou augmenter le nombre de tests réussis. Un agent de recherche peut ajouter une source primaire accessible ou déplacer un bref de schéma invalide à schéma valid. Un agent de soutien pourrait créer le ticket promis. Le dossier des progrès nécessite last progress at , une petite description du delta et une version de vérification. Évitez les compteurs vagues tels que étapes accomplies à moins que chaque étape n'indique le résultat. 5. La dépendance à l'attente Représenter explicitement une attente légitime: human approval , credential , rate limit , external job ou une autre dépendance nommée. Ajoutez un propriétaire, l'action demandée et la date limite si elle est connue. Ce champ modifie l'action. Une course en attente d'approbation doit être dirigée vers la personne autorisée, pas redémarrer. Une attente limitée peut nécessiter de la patience. Une carte d'identité manquante a besoin d'un humain qui peut la fournir sans exposer le secret au tableau de bord. 6. Vérification des résultats Écrivez la prédication de fin avant le début de la course. Les exemples sont les suivants: report exists, parses, and contains two reachable primary sources ; pull request exists and named checks pass ; ticket ID was returned and can be fetched ; scheduled export contains the expected date partition . Conserver séparément le declared complete du outcome verified . Le deuxième doit être true , false ou unavailable , avec le vérificateur et le temps de vérification. Un commandement réussi est l'activité. L'artefact prévu est le résultat. Appliquer un ordre de priorité Le tableau de bord ne doit pas mettre toutes les avertissements possibles sur la même rangée. Évaluez d'abord l'état le plus sûr et le plus explicatif: 1. le collecteur stérile → unreachable ; 2. démarrage attendu au delà de sa fenêtre de grâce → missed schedule ; 3. dépendance nommée → waiting:<dependency ; 4. déclaré complet sans résultat vérifié → false success ; 5. le rythme cardiaque frais plus l'ancienneté, zéro progression → stuck ; 6. résultat vérifié → complete ; 7. delta de progression positive → working ; 8. preuve insuffisante ou contradictoire → uncertain . Cette commande est une décision de produit, pas une loi de la nature. Il est encore préférable de laisser trois alertes indépendantes prétendre que la même course déconnectée est coincée, en retard et manque de son résultat. Conserver les signaux sous jacents pour enquête, mais donner à l'opérateur un état primaire et une action suivante. L'appareil d'accompagnement teste six cas contre des limites explicites d'exemple: fraîcheur du collecteur de 120 secondes, gracie du calendrier de 300 secondes, fraîcheur du rythme cardiaque de 60 secondes et un temps de progression de 600 secondes. L' exécuter avec Node.js 20 ou plus récent: La sortie exacte est: La paire la plus importante est approval wait contre retry loop . Les deux ont des battements de cœur frais, aucun delta de progression, et de vieux progrès. La dépendance nommée fait de la première une attente légitime; l'absence d'une dépendance fait de la seconde un candidat coincé après son délai. L'affaire false success présente des progrès récents et une demande d'achèvement, mais le vérificateur des résultats est faux, de sorte que la demande d'achèvement ne gagne pas de confiance. Mettez le diagnostic derrière le verdict. Une fois que la ligne d'état identifie une piste qui vaut la peine d'être ouverte, la vue détaillée peut expliquer pourquoi. Organisez le autour de la transition qui a échoué plutôt que autour de la source de télémétrie la plus facile à cartographier. Pour missed schedule , afficher l'expression du calendrier, la zone horaire, l'état activé, les démarrements attendus et réels, la politique de chevauchement et l'historique d'exécution récente. Pour waiting , indiquez la dépendance, le propriétaire, l'autorité requise, l'âge et une action de rappel limitée. Pour stuck , affichez la cadence cardiaque à côté des preuves de progrès et des signatures d'outils répétées. Pour false success , indiquez la demande d'achèvement à côté de la prédication ratée. Ensuite, ajoutez des panneaux de trace, de latence, de jeton, de coût, de modèle et d'outils. Un pic de jeton attaché à une course bloquée est actionable; le même pic attaché à un résultat vérifié peut être un élément d'examen des coûts plutôt qu'un incident. La répétition des appels à l'outil peut expliquer un ralentissement, mais les appels identiques ne sont pas la preuve d'une boucle jusqu'à ce que la preuve de la progression de la tâche cesse également de changer. Utilisez un calendrier pour la causalité: Ce point de vue rend les périodes de silence compréhensibles. Il donne aussi à chaque alerte un âge des preuves. Si un adaptateur cesse de faire des rapports après 12:03, le tableau de bord doit passer à unreachable ou uncertain au lieu de conserver un état vert pour toujours. Traiter les seuils et la collecte de données comme des limites du produit L'appareil est un ensemble de contre exemples, et non une référence de production. Dix minutes sans changement de dossier peuvent être normales pour une analyse approfondie et désastreuses pour un travailleur en file d'attente d'une minute. Calibrez les fenêtres par flux de travail, puis enregistrez la configuration à côté du verdict. Le progrès est le signal le plus difficile. Préférer des preuves déterministes telles qu'un digeste, le nombre de lignes, le code d'état, le résultat du test ou la vérification du schéma. Lorsque le résultat est qualitatif, un évaluateur versionné peut apporter des preuves, mais son score est incertain. Gardez unavailable en état réel; ne convertissez pas les preuves manquantes en preuves saines. Ramasser le minimum nécessaire pour établir la santé. Une ligne d'état n'a généralement pas besoin d'interrogations, de réponses, de secrets, de charges utiles d'outils bruts ou de chemins locaux absolus. Un identifiant d'exécution opaque, des timestamps, de petits compteurs, des résultats du vérificateur et des classes de dépendance éditées peuvent entraîner la première décision. Les traces plus riches peuvent avoir des règles de rétention et d'accès distinctes. Enfin, ne branchez pas directement l'état primaire à une automatisation irréversible. L'avertissement de vie de Kubernetes est pertinent ici: un test de santé trop sûr peut aggraver la récupération. Un tableau de bord peut recommander une reprise limitée, une pause ou un rappel, mais l'action doit respecter les limites d'autorité, de reprise, de temps et de coûtset le problème ne doit être résolu qu'après des progrès utiles ou après l'observation du résultat attendu. où correspond Sidewisp La direction du produit de Sidewisp est une vision de la santé autour des agents que les gens utilisent déjà: accessibilité, progrès utile, accès à la mémoire et aux outils, preuve des résultats, signaux de coûts et récupération contrôlée avec des limites d'approbation explicites. Il n'est pas destiné à remplacer le système d'exécution, le planificateur, le gateway modèle ou le système de traçage brut. Cette description est la direction du produit et non une affirmation de surveillance généralement disponible. Sidewisp est actuellement en préversion privée. Le site public, la démonstration interactive et le système d'articles sont en direct; la collecte de l'agent de production santé, les adaptateurs de temps d'exécution, la récupération automatisée, la gestion du cron et l'analyse des coûts des jetons ne sont généralement pas expédiés. Rejoignez l'aperçu privé si ce contrat de tableau de bord à six signaux correspond au problème opérationnel que vous devez résoudre. Sources primaires Tableaux de bord des agents de sentinelle AI champs officiels pour les courses, les appels LLM, la durée, les modèles, les jetons, les outils, les erreurs et les traces. Les sondes Kubernetes de vitalité, de préparation et de démarrage séparation officielle des contrôles de santé, des réactions, des seuils et des avertissements d'échec. Échéanciers temporaires l'horaire officiel, la pause, le chevauchement, le rattrapage et la sémantique de la politique d'échec.