AI agent Observabilité: empreinte digitale à chaque course

La réponse la plus courte et utile est: attacher une empreinte digitale run manifest à chaque course d'agent, puis comparer la santé seulement après avoir su si le temps d'exécution, l'instantané du modèle, le prompt, la politique, le schéma d'outil et l'image de déploiement étaient les mêmes. Une trace vous indique ce qu'a fait une course. Le manifeste vous indique quelle version du système l'a fait. Cette empreinte digitale n'est pas un score de santé et elle ne prouve pas pourquoi une course a échoué. C'est une clé branche. Si une régression apparaît sous une nouvelle empreinte digitale, inspectez d'abord la dérive de configuration. S'il apparaît sous l'empreinte digitale ancienne, recherchez des changements d'environnement non enregistrés, de dépendance, de fournisseur, de données ou d'autorisation. Un nom d'agent stable peut cacher un système différent Supposons que support triage remplisse deux billets correctement vendredi et manque une escalade requise lundi. Les deux courses ont le même nom d'agent. Les deux émettent des battements cardiaques. Les deux outils d'appel. Les regrouper ensemble semble naturel et peut être faux. Entre ces courses, l'une d'entre elles a peut être changé: Componente manifeste Enregistrement Évitez d'enregistrer Temps d'exécution nom et version exacte ou engagement parcours hôte, jeton d'accès Modèle le fournisseur et l'instantané fiché lorsqu'il est disponible clé API, réponse complète Rapidement SHA 256 du paquet d'interrogatoire examiné client brut ou système prompt Politique révision hash ou immuable valeurs secrètes intégrées à la politique Les outils hash du schéma canonique les informations d'identification, les charges utiles des outils Déploiement digestion d'image ou commande de source mot de passe du registre Cela suit une idée d'observabilité établie plutôt que d'inventer un deuxième format de trace. Le SDK des ressources OpenTelemetry décrit une ressource comme une représentation immuable de l'entité produisant la télémétrie. Pour une exécution d'agent, la configuration d'exécution fait partie de cette identité. Gardez l'identifiant de trace pour une exécution et l'empreinte digitale manifeste pour la version qui l'a produite; aucun ne remplace l'autre. Un manifeste utile est délibérément ennuyeux. Il contient des identifiants stables, et non des observations telles que la latence, le nombre de jetons, l'état de sortie ou le résultat. Ceux là appartiennent à l'évidence. Les mélanger dans le hash créerait une nouvelle empreinte digitale pour chaque course et détruirait la comparaison. Il y a aussi une limite de confidentialité: hash un prompt ou une politique localement, mais ne téléchargez pas l'original simplement pour expliquer son identité. Les hashtags peuvent toujours fuir des informations lorsque l'entrée provient d'un petit ensemble deviniable, alors utilisez des identifiants de sortie opaques ou un digeste local à clé lorsque cette menace est importante. Ne mettez jamais les identifiants dans le manifeste, même avant d'aspirer l'objet entier. Canoniser avant le hachage Hashing JSON est un piège car l'ordre des clés d'objet et les choix de sérialisation insignifiants peuvent différer tandis que la configuration représentée reste la même. Le Schéma de canonisation JSON dans la RFC 8785 définit la sérialisation déterministe, y compris le tri des propriétés récursives. Le code de production devrait utiliser une mise en œuvre révisée du SCS lorsque l'interopérabilité est importante. Pour une expérience locale compacte, la fonction Node.js suivante est suffisante pour les valeurs finites ordinaires JSON: L'expérience a utilisé Node.js v22.23.1 . Il est intentionnellement plus étroit que la RFC 8785: il trient les clés d'objet de manière récursive et rejette les nombres non finis, mais il ne s'agit pas d'une revendication de conformité complète aux JCS multilingues. Cette limitation appartient à côté du code, pas dans une note de bas de page après qu'un lecteur l'a copié. Le manifeste lui même peut rester petit: Les valeurs de détenteur de place ci dessus sont des identifiants d'appareil, et non des revendications de fournisseur. Dans un véritable collectionneur, déduisez les sur l'hôte à partir de sorties fichées. Le principe plus large ressemble à celui de provenance de la SLSA: conserver des informations vérifiables sur le lieu, le moment et la façon dont quelque chose a été produit. Un manifeste de course emprunte ce principe pour le diagnostic; il ne s'agit pas automatiquement d'une attestation SLSA. Une répétition de six tours expose à la fois la valeur et la limite J'ai testé la règle contre six enregistrements synthétiques NDJSON pour un agent. Les courbes 101 et 102 contiennent les mêmes valeurs manifestes dans différents ordres de clés JSON. Exécuter 103 ne modifie que le hash prompt, 104 ne modifie que l'instantané du modèle et 105 ne modifie que le hash du schéma d'outil. L'exécution 106 échoue en raison d'une panne de dépendance que le manifeste de fixation ne représente pas. Le commandement d'audit était: Le résultat déterministe: Deux observations comptent plus que les chiffres. Tout d'abord, un nom de l'agent cachait quatre configurations enregistrées. Deuxièmement, les deux objets de base d'ordre différent ont produit la même empreinte digitale SHA 256, de sorte que l'ordre de sérialisation n'a pas créé une fausse dérive. Le contre exemple est la partie importante: run 106 a échoué avec l'empreinte digitale de base. Une empreinte digitale inchangée n'a pas rendu la course saine, et elle n'a pas prouvé que l'environnement était inchangé. Il a seulement montré que les champs de configuration enregistrés étaient inchangés. L'enquête suivante devrait examiner les éléments de preuve en dehors de la disponibilité du fournisseur, des données d'entrée, de l'itinéraire du réseau, de l'état des autorisations et de la fraîcheur de la dépendance. L'appareil est synthétique, il démontre donc la mécanique et falsifie une réclamation excessive; il n'estime pas la fréquence avec laquelle la dérive de configuration provoque des incidents réels. Cela nécessiterait des données de production avec des émissions contrôlées et des résultats vérifiés. Transformer l'empreinte digitale en décision de triage Utilisez l'empreinte digitale seulement après que la course ait un résultat observable. L'activité seule les jetons émis, les outils appelés ou un processus encore en vie n'établit pas de progrès utiles. Les preuves des résultats Comparaison des empreintes digitales Première branche Passé Le même que la ligne de départ Garder comme référence saine comparable Échoué Modifié Différer les champs de manifeste édités; envisager un retour limité ou une répétition Échoué C' est la même chose. Inspecter les dépendances, les autorisations, les entrées, l'état du fournisseur et la couverture manifeste manquante Je ne sais pas. Ou bien Récolter ou définir le produit attendu avant de diagnostiquer la dérive Trois règles de fonctionnement permettent d'être honnête: 1. Frixer le point de comparaison. Choisissez une course réussie vérifiée pour la même classe de tâches, pas seulement le statut vert le plus récent. 2. Tiens une carte de niveau de champ édité. Le hash intégral manifest dit different. Les digestes individuelles des composants indiquent où inspecter sans révéler le contenu. 3. Vérifier le résultat après l'intervention. Une commande de rétroaction réussie est l'activité. La récupération signifie que le produit prévu apparaît, que l'essai est passé ou qu'un autre contrôle déterministique d'acceptation est passé. N' annulez pas automatiquement toutes les empreintes digitales modifiées. Une libération peut être intentionnelle et une défaillance peut provenir de l'entrée plutôt que de la libération. Utilisez le changement comme preuve pour une révision, préservez l'approbation humaine pour les actions qui en découlent et enregistrez ce qui s'est passé après l'action. Lorsque cela s'inscrit dans la surveillance de la santé de l'agent L'empreinte digitale de l'expérience connecte trois questions de santé que les traces seules ne peuvent résoudre de manière claire: a t elle changé une politique de décision, un contrat d'outil a t il changé et la qualité des résultats a t elle régressé dans le même système enregistré? Il améliore également les remises d'incidents parce qu'un autre opérateur peut comparer l'identité exacte de la libération sans recevoir d'injonctions, de secrets ou de charges utiles d'outils bruts. Le modèle de santé prévu par Sidewisp comprend l'exécution, la mémoire et le contexte, les outils, les résultats, la disponibilité et le coût. Un futur adaptateur côté hôte pourrait utiliser un manifeste édité comme preuve à l'appui de ces diagnostics, mais ce n'est pas une revendication de surveillance expédiée. Sidewisp est actuellement en préversion privée. Le site public et le système d'articles sont en direct; la collecte des agents de production et de la santé, les adaptateurs de temps d'exécution et la récupération automatisée ne sont généralement pas disponibles. Si ce modèle de preuve correspond à un défaut que vous exploitez aujourd'hui, la prochaine étape restreinte est de rejoindre la liste d'attente d'aperçu privé et de décrire la vérification du temps d'exécution et du résultat dont vous avez besoinne pas supposer que Sidewisp le recueille déjà.