Observabilité de l'agent AI: Mesurer les progrès utiles, pas seulement l'activité

L'observabilité de l'agent AI est la capacité d'expliquer ce qu'un agent a fait à partir de preuves externes: traces, journaux, métriques, événements d'outil, appels de modèle, latence, jetons et coût. Cette preuve est nécessaire, mais ce n'est pas un verdict de santé. Une trace peut être complète pendant que le fichier demandé manque. Un appel à l'outil peut réussir tant que l'agent répète la même étape. Une course silencieuse peut bien attendre l'approbation. La réponse pratique est de conserver la télémétrie et d'ajouter une petite couche de décision au dessus. Pour chaque tâche, observez cinq choses ensemble: la disponibilité, le delta de progression utile, les dépendances déclarées, les contrôles déterministes des résultats et le coût sur la même fenêtre. Évaluez les dans cet ordre avant d'alerter ou de récupérer quoi que ce soit. Ce guide transforme cette règle en un fichier exécutable à cinq cas. Il est intentionnellement neutre en fonction du temps d'exécution: le même raisonnement peut être au dessus des intervalles d'OpenTelemetry, des événements Claude Code, un journal d'exécution OpenClaw ou un agent personnalisé. Une trace prouve ce qui a couru, pas ce qui a changé. Le Conventions sémantiques OpenTelemetry pour les champs d'action de GenAI actuel définit les opérations de création et d'invocation d'agents, d'invocation de flux de travail, de planification et d'exécution d'outils. Le document est marqué Development , ce qui est important lorsque vous concevez un schéma à long terme: utilisez les conventions là où elles conviennent, mais isolez les attributs sensibles à la version derrière votre propre couche de normalisation. La télémétrie en temps d'exécution devient déjà détaillée. La documentation de surveillance du code Claude décrit les mesures, les événements et les traces distribuées bêta. Son arbre de trace peut inclure une interaction, des demandes de modèle, des appels à l'outil, le temps bloqué sur une décision de l'utilisateur et l'exécution de l'outil. Les champs documentés comprennent la durée, les jetons, le coût estimé, la taille des résultats de l'outil et success . Ces champs répondent à de précieuses questions: Le temps d'exécution a t il répondu ? Quel modèle et quels outils fonctionnaient ? Un corps d'outil spécifique a t il rendu une erreur ? Combien de temps a t il fallu pour attendre l'autorisation et l'exécution ? Combien de jetons et de dollars a consommé la course ? Ils ne définissent pas le succès de votre tâche. Une commande de shell renvoyant le code de sortie 0 prouve que la commande a été effectuée en vertu de son propre contrat. Il ne prouve pas qu'un article est public, qu'une carte de site contient son URL, qu'une demande de retrait passe IC ou qu'un dossier client a atteint le système prévu. Les applications peuvent ajouter ces contrôles, mais un champ générique de réussite des outils ne peut pas les inventer. L'activité et le progrès peuvent donc se déplacer dans des directions opposées. Dix neuf appels d'outils réussis sans delta de sortie peuvent être une boucle. Deux appels d'outils suivis d'un silence peuvent être une attente saine pour un critique. Un dernier message disant done peut être un faux succès si l'artefact promis est absent. Construire une fenêtre de santé à partir de cinq signaux Choisissez une fenêtre d'observation spécifique à la tâche avant de regarder le résultat. Cinq minutes peuvent convenir à une petite modification de code; une heure peut être raisonnable pour un travail de recherche programmé. Évitez un seuil global qui étiquette chaque opération longue comme bloquée. Dans cette fenêtre, recueillez cinq signaux: Le signal Les preuves minimales Ce qui l'empêche Accès à l'information l'âge du battement cardiaque, la réponse au processus/à la séance, ou la réception de l'exécution du programmeur Traiter un temps de course inaccessible comme un échec de raisonnement Des progrès utiles un delta monotone spécifique à la tâche confondre l'activité répétée avec le mouvement La dépendance raison d'attente, propriétaire et heure d'échéance réessayer un travail qui nécessite légitimement une personne ou un système externe Le résultat prédicateur déterministe du résultat promis l'acceptation d'un message d'achèvement sans délivrable Le coût des jetons, des appels, du temps ou de l'argent dans la même fenêtre ignorant des tentatives coûteuses qui ne produisent aucun progrès Les progrès utiles doivent être concrets. Pour un agent de codage, il peut s'agir d'un résultat de test modifié, d'un nouvel engagement ou d'un nombre réduit d'échecs de test pas de lignes émises à un terminal. Pour un éditeur, il peut s'agir d'un ID de projet CMS, puis d'un API public, puis d'une URL en direct dans la carte du site. Pour un agent de soutien, il pourrait s'agir d'une transition validée de billet plutôt que d'un autre modèle de réponse. Préférer un prédicat déterministe de résultat quand il existe: Utilisez un évaluateur uniquement lorsque le résultat ne peut pas être vérifié mécaniquement, et conservez sa rubrique, sa version et son incertitude. Ne recueillez pas la chaîne de pensée cachée comme raccourci. Les sélections d'outils, les plans explicites, les sorties, les timestamps et les changements d'état fournissent des preuves opérationnelles sans avoir besoin de raisonnement privé. Le coût appartient à la fenêtre, mais le coût seul n'est pas la santé. On peut s'attendre à dix dollars qui produisent une migration vérifiée. Cinquante cents dépensés pour répéter une recherche inchangée peut être l'anomalie. Une mesure dérivée utile est: Le max évite la division par zéro; il ne rend pas le zéro progrès sain. Alerte séparément lorsque progress delta == 0 et le coût continuent d'augmenter. Classifier le travail, l'attente, le blocage, l'impossible et le faux succès Les décisions sont importantes. Vérifiez d'abord la facilité d'accès. Alors honorez une dépendance explicite qui est encore à son terme. Vérifiez une réalisation revendiquée par rapport à la prédication des résultats avant de l'accepter. Ce n'est qu'après que vous interpréterez les progrès et le temps écoulé. Voici un fichier NDJSON complet. Enregistrer comme health window fixture.ndjson : Exécutez ce classifiateur avec Node.js: Résultats attendus: La fixation rend la thèse falsifiable. Une règle naïve telle que tool calls 0 marque à la fois run stuck et run false success comme actifs. Une règle fondée uniquement sur le silence marque run waiting comme malsaine. La règle des cinq signaux les sépare parce qu'elle préserve la dépendance et les preuves des résultats. L'exemple est un squelette de décision, pas un modèle universel de notation. Le code de production a également besoin de fraîcheur, de confiance, d'identité source et d'un chemin uncertain lorsque les signaux ne sont pas d'accord. Cartographie de chaque état à une réponse limitée La classification existe pour prévenir la mauvaise action, pas pour décorer un tableau de bord. État Les preuves requises Réponse par défaut Travail récente accessibilité et progrès positifs delta laissez la tranquille; échantillonnez la à nouveau plus tard J'attends dépendance typée, propriétaire et délai d'expiration non expiré notifier une fois la personne responsable; ne réessayez pas l'étape bloquée Je suis coincé. accessible, au delà de sa fenêtre, aucune dépendance, aucun delta de progression inspecter l'étape répétée; préparer une nouvelle tentative réversible ou une poussée dans les limites Faux succès l'achèvement déclaré, le résultat déterministique échoué réouvrir la tâche et signaler le prédicat manquant; ne l'appelle pas complète Il est inaccessible battements cardiaques stagnants ou échec du contact en temps de course vérifier la disponibilité de l'hôte/de l'heure d'exécution avant de modifier les instructions Un peu incertain des preuves manquantes ou contradictoires recueillir le signal absent ou demander; ne pas automatiser la récupération Cette séparation a un précédent utile en dehors des systèmes AI. Kubernetes distingue les sondes de démarrage, de vitalité et de préparation parce que le processus existe et le service doit recevoir du trafic sont des décisions différentes. Ses documents mettent également en garde contre le fait que les sondes de vie mal conçues peuvent provoquer des pannes en cascade en redémarrant inutilement. L'analogie a une limite: un agent AI n'est pas un Pod, et le progrès utile dépend de la tâche. La leçon transférable est plus étroite: ne laissez pas un signal vert ou rouge ambigu autoriser chaque intervention. Pour une récupération active, fixez des limites à l'action: une nouvelle tentative, pas une boucle de nouvelle tentative illimitée; un délai et un coût maximaux écoulés; une étape réversible; une limite d'approbation explicite pour les actions destructrices ou externes; une vérification post action des progrès ou des résultats. L'achèvement du commandement n'est pas la récupération. Nettoyez l'incident seulement après les changements d'état attendus. L'instrument du contrat, pas chaque pensée Un dossier médical standardisé peut être placé à côté de vos données de traces existantes: Gardez les références de preuves contrôlées par l'accès et éditez les secrets, les instructions, les charges d'outils bruts et les itinéraires locaux absolus, sauf si cela est strictement requis. Le dossier médical devrait indiquer ce qui a été vérifié et où les opérateurs autorisés peuvent l'inspecter; il ne devrait pas devenir une deuxième copie de télémétrie sensible. Quatre choses explicitement: 1. l'adaptateur d'exécution qui a normalisé les données probantes; 2. la définition des progrès réalisés; 3. le prédicat de résultat; 4. les règles et les seuils du classifiant. Sans ces versions, une commande de test modifiée ou un produit renommé peut ressembler à une régression soudaine d'un agent. Savoir où s'arrête la méthode Le plus difficile, c'est de ne pas recueillir une autre coupe. Il définit honnêtement les progrès utiles et les résultats promis. Certaines tâches n'ont pas de mesure monotone de progression. Un agent de recherche peut rejeter une hypothèse faible et revenir à une étape antérieure; cela peut être un travail précieux même si un contrefacteur tombe. Certaines dépendances n'exposent pas un délai de prescription fiable. Certains résultats nécessitent un jugement plutôt qu'une somme d'argent. Dans ces cas, conservez les éléments de preuve et signalez uncertain . Ne fabriquez pas de précision avec un score de santé universel. Il est également nécessaire de séparer les contrôles de santé en ligne de l'évaluation hors ligne. Les ensembles de données hors ligne peuvent révéler si une nouvelle version d'agent est plus précise dans les cas connus. La fenêtre de santé en direct répond à une autre question: cette course particulière est elle accessible, en mouvement, en attente légitime, ou manque t elle de son résultat maintenant? Vous avez généralement besoin des deux. Commencez par un flux de travail conséquent. Définir un delta de progression et un prédicat de résultats déterministes. Reprise des cas connus de travail, d'attente, de blocage, de non atteinte et de faux succès. Ce n'est que lorsque les classifications correspondent à la réalité qu'une alerte ou une action de récupération limitée doivent en dépendre. Sidewisp est actuellement en préversion privée. Son site public et son système d'articles sont en direct, mais la collecte des agents de production, les adaptateurs de temps d'exécution et la récupération ne sont généralement pas expédiées. La direction du produit est une couche de santé qui facilite l'action des limites de preuve, de fraîcheur, de confiance et d'approbation sans remplacer le temps d'exécution de l'agent. Références principales OpenTelemetry: Conventions sémantiques pour l'agent et le cadre de GenAI récupéré le 24 juillet 2026; statut du document: Développement. Code Claude: surveillance champs et configuration officiels de télémétrie, récupéré le 24 juillet 2026. Les Kubernètes: vitalité, préparation et démarrage des sondes fins officielles de l'enquête et des avertissements de récupération, récupéré le 24 juillet 2026.