Observabilité de l'agent: saisir le faux succès avec un contrat de résultat

L'observabilité de l'agent devrait répondre à une question plus difficile que a t il terminé la course?: : l'expérience attendue existe t elle, appartient elle à cette course et passe t elle la vérification d'acceptation? Le défaut pratique est de définir ce résultat avant l'exécution, de l'observer en dehors du message d'achèvement de l'agent, et d'enregistrer un reçu de résultats compact. Un événement terminal peut déclencher une vérification; il ne peut pas remplacer la vérification. Cette distinction atteint un faux succès sans nécessiter un deuxième modèle pour relire l'intégralité de la transcription. Il évite également l'erreur opposée: traiter une approbation légitime comme une course brisée. Le reçu décrit ci dessous enregistre un identifiant opaque de l'artefact, la fraîcheur, une digestion du contenu, le cas échéant, et un résultat de validation déterministe. Les preuves manquantes restent unverified ou un état de défaillance spécifique au lieu d'être rassemblées en bonne santé. Un événement terminal est une preuve d'exécution, pas de livraison. Les traces sont le bon endroit pour comprendre comment le travail a fonctionné. Ils ne sont pas automatiquement une preuve que l'état externe demandé existe maintenant. Le Conventions sémantiques OpenTelemetry pour les champs d'action de GenAI actuel décrit des opérations telles que invoke agent , plan et execute tool , ainsi que des attributs d'agent, de fournisseur, de modèle, de timing et d'erreur. Le document est explicitement marqué Développement. Ces signaux peuvent indiquer qu'une opération s'est produite et qu'elle a rapporté une erreur. Ils ne peuvent pas savoir que votre facture particulière a été stockée, que votre demande de retrait contient le changement demandé ou que votre rapport correspond à un schéma approuvé. Cette règle d'acceptation appartient à la demande. Le Références de suivi du SDK OpenAI Agents fait le même béton de bord. Sa trace par défaut peut inclure des générations de modèles, des appels à la fonction, des garde corps, des remises et des étendues personnalisées. C'est une riche preuve d'exécution. Le SDK prévient également que les intervalles de génération et de fonctionnement peuvent contenir des entrées et sorties sensibles et permet aux opérateurs de désactiver cette capture. Une réception de résultats peut donc être à la fois plus étroite et plus décisive: conserver la preuve nécessaire pour juger de la livrabilité, et non une deuxième copie de chaque charge utile de commande et d'outils. Un bon modèle opérationnel utilise les deux éléments suivants: la trace explique le parcours, les tentatives, les outils et l'emplacement de l'échec; la réception du résultat prouve le résultat envisagé ou nomme la preuve manquante; un signal d'attente enregistre une dépendance ou une approbation connue, plutôt que de prétendre que la tâche est terminée; un signal de progression montre un mouvement utile pendant que le travail est encore actif. La confusion de ces signaux crée de mauvaises alertes. L'activité n'est pas un progrès utile. Un événement terminal propre n'est pas un résultat vérifié. Une attente déclarée n'est pas une impasse. Écrire le contrat de résultat avant la course Un contrat de résultat est assez petit pour être examiné lors de la création de tâches et assez strict pour être évalué sans demander à l'agent ce que cela signifiait. Commencez par la vérification déterministique la moins chère qui correspond au résultat réel. champs Le but Exemple artifact id Nommer le résultat attendu sans exposer un chemin secret ou absolu monthly report run started at Établit la limite de fraîcheur 2026 07 25T14:00:00Z observed at Indique quand les preuves ont été recueillies 2026 07 25T14:08:12Z modified at Rejette un artefact laissé par une course antérieure 2026 07 25T14:07:55Z expected sha256 Pins octets exacts lorsque le octet est une question d'identité une digestion de 64 caractères validator Nom de la vérification d'acceptation report schema v3 validator exit code Il y a un verdict déterministe. 0 evidence source Dites d'où vient l'observation local file stat N'exigez pas tous les champs pour chaque emploi. Une migration de base de données peut nécessiter une requête de schéma plutôt qu'une digestion de fichiers. Une page déployée peut avoir besoin d'un statut HTTP, d'un contenu canonique et d'une affirmation de navigateur. Une tâche d'homologation humaine devrait rester waiting jusqu'à l'arrivée de l'événement d'autorité. Le contrat devrait représenter le résultat et non forcer chaque charge de travail à un modèle en forme de fichier. L'ordre de classification par défaut est important. Vérifiez d'abord l'absence de preuves, puis l'identité, la fraîcheur, la digestion et le résultat de validation. Cela produit des états actionnables: 1. missing aucun artefact n'a été observé; 2. wrong artifact l'observation appartient à une cible différente; 3. stale l'artefact est antérieur à la course; 4. hash mismatch des octets exacts ont été requis et diffèrent; 5. validator failed l'artefact existe mais ne répond pas aux critères d'acceptation; 6. unverified la vérification requise n'a pas été effectuée ou les preuves ne sont pas disponibles; 7. verified toutes les conditions requises ont été remplies. Gardez le reçu à un minimum de confidentialité. Les identifiants opaques sont plus sûrs que les noms de clients ou les chemins du système de fichiers. Un digeste peut prouver l'identité des octets, mais un hash simple ne cache pas un secret prévisible de l'énumération. Utilisez un HMAC à clé lorsque la valeur est sensible et à faible entropie, ou évitez de conserver la valeur entièrement. La collecte des preuves doit avoir lieu près de l'artefact afin que le contenu brut n'ait pas besoin de quitter l'hôte. Exécuter le test de faux succès en six cas J'ai testé la règle contre un dispositif synthétique à six tours. Chaque course porte le même état terminal de course: completed . Deux observations sont nouvelles et valables. Quatre représentent un mode de faux succès différent: aucun artefact, un artefact plus ancien que la course, un déséquilibre de contenu et une défaillance du validateur. Le classement est délibérément ennuyeux. Il évalue les faits dans un ordre fixe: L'exécution de l'appareil inclus produit: L'affirmation falsifiable est étroite: pour ce dispositif fourni, une règle de statut terminal accepte six courses, tandis que le contrat de résultat vérifie deux et rejette quatre avec des preuves spécifiques. Il ne s'agit pas d'un taux d'échec de production mesuré. Il s'agit d'un test de limite montrant que les mêmes états terminaux peuvent dissimuler des résultats matériellement différents. La métrique utile n'est pas pourcentage de courses qui ont été complétées. C'est verified outcomes / runs expected to deliver an outcome , rapporté à côté de la couverture des contrôles. Si seulement la moitié de vos types de tâches ont des validateurs déterministes, montrez cette limitation. Ne classifiez pas silencieusement la moitié non équipée comme saine. Accrocher la vérification à la limite de finalisation Le reçu fonctionne le mieux lorsque le délai d'exécution expose une limite d'achèvement mais que le chèque lui même reste indépendant. À cette limite, recueillir des preuves, exécuter le validateur, persister la réception, et seulement ensuite mettre à jour l'état opérationnel. Le Code Claude fournit un point de mise en œuvre concret. Son les crochets de référence actuel indique que TaskCompleted fonctionne lorsqu'une tâche est marquée comme complète. Un crochet de commande peut sortir avec le code 2 pour empêcher l'achèvement et retourner des commentaires lorsque les tests ou un autre contrôle d'acceptation échouent. Cela rend possible une porte déterministe sans faire confiance à une affirmation en prose. C'est un mécanisme spécifique au code Claude, pas une norme universelle d'agent, et un crochet qui a fonctionné avec succès doit encore tester le bon artefact. Pour les temps d'exécution sans crochet d'achèvement de blocage, utilisez une transition d'état en deux étapes: Ne réessayez pas automatiquement chaque état non vérifié. missing après un retard de téléchargement connu peut avoir besoin d'une fenêtre d'observation limitée courte. validator failed peut justifier une tentative de réparation réversible si l'utilisateur l'a déjà autorisée. unverified signifie que le canal de preuve a échoué; il ne prouve pas que le produit livré est mauvais. Une tâche en attente d'une décision irréversible appartient à waiting ou needs human , et non à une boucle de récupération. Il faut aussi séparer le succès du commandement du succès du résultat. Un processus de validation qui sort de 0 ne prouve que ce que ce validateur vérifie réellement. La version du nom du validateur, l'enregistrement de sa source de preuve et du temps d'observation, et l'examen du contrat lorsque le livrable change. Une règle d'acceptation périmée peut produire un faux positif parfaitement documenté. Éclairer l'incertitude; ne pas fabriquer le succès Un contrat de résultat n'est qu'à la hauteur de ses attentes déclarées. Il peut manquer un artefact non répertorié, accepter un validateur faible, ou lire à partir d'une source de preuves périmée. Ce sont des raisons d'exposer la couverture et la confiance, pas des raisons d'ajouter un juge modèle par défaut. Utilisez une évaluation LLM uniquement pour les critères qui ne peuvent être vérifiés de manière déterministe, gardez la rubrique et la version visibles et évitez de laisser le même agent produire et classer son propre travail de manière concluante. Lorsque les preuves sont en conflit, préférer uncertain et demander l'autorité avant de changer l'état externe. Sidewisp est actuellement en préversion privée. Le site public et la bibliothèque d'articles sont en direct; la collecte des agents de production santé, les adaptateurs de temps d'exécution et la récupération ne sont généralement pas expédiés. Le Sidewisp est conçu comme une couche de santé à côté des temps d'exécution existants, et non comme un temps d'exécution de remplacement ou un fixateur autonome. La règle d'exploitation est simple: laissez l'événement terminal d'exécution démarrer le contrôle, laissez les preuves externes décider du résultat, et laissez les preuves manquantes rester inconnues. Si ce modèle de santé correspond à la façon dont vous gérez les agents, l'inscription à l'avant première privée est la prochaine étape appropriée.