AI Observabilité de l'agent pour les délais de l'outil: vérifier l'effet

Un délai d'outil vous indique que l'appelant a cessé d'attendre. Znot vous indique si l'outil a effectué son effet secondaire. Pour un agent AI qui peut envoyer un message, créer un billet, réserver une fente ou facturer un compte, traiter timeout comme failed peut transformer une erreur de réseau ordinaire en une action réelle dupliquée. Le défaut raisonnable est de congeler les tentatives de réinitialisation aveugles, de maintenir une identité opérationnelle stable et de concilier l'effet prévu. Acceptez l'une des trois réponses: vérifiée appliquée, vérifiée non appliquée ou indéterminée. Seule la deuxième réponse peut introduire une décision de réexamen, et même alors le contrat de fournisseur doit soutenir une réexamen avec la même identité et les mêmes paramètres inchangés. C'est un problème d'observabilité parce qu'un verdict sain dépend des preuves au delà de la durée de l'appel à l'outil. L'agent a besoin d'un reçu pour ce qu'il a prévu, quel transport a été retourné, et ce que le système externe contient maintenant. Un temps d'arrêt laisse trois faits différents Un agent enregistre généralement un fait pratique: l'appel à l'outil a suscité un délai. Le dossier opérationnel utile se compose de trois couches: 1. Intent l'opération logique exacte que l'agent s'est engagé à effectuer. 2. Transport si l'appelant a reçu une réponse, un refus ou aucune réponse. 3. Effect si le système cible contient le résultat prévu, ne contient pas de résultat ou ne peut pas être interrogé en toute confiance. Ces couches peuvent être en désaccord. Une demande peut atteindre le fournisseur, créer l'objet et perdre la réponse en retournant. Il peut échouer avant l'expédition. Il peut retourner le succès alors qu'un pas en aval asynchrone ne produit jamais le résultat promis. Aucun de ces cas n'est bien décrit par un seul champ success: true false . Le documentation avancée de traitement des erreurs de Stripe rend explicite l'ambiguïté: après une erreur de réseau, le client ne sait pas si le serveur a reçu la demande. Son chemin de réessayer recommandé réutilise la même clé d'idempotence et les mêmes paramètres jusqu'à ce que le client obtienne un résultat définitif. La même page traite une réponse 500 comme indéterminée car une demande peut toujours produire un effet secondaire visible à l'utilisateur. AWS documente une limite connexe dans son Conseils d'exécution durable. La répétition au moins une fois est sûre pour les opérations idempotentes; les effets secondaires externes nécessitent une manipulation au plus une fois ou un contrat d'idempotence du service. AWS prévient également qu'aucune sémantique par tentative ne signifie exactement une fois pour l'ensemble du flux de travail. La conclusion pratique est plus étroite que add retries. Déterminez d'abord si l'opération est sûre à répéter. Une lecture, un upsert avec un identifiant d'enregistrement stable et un appel du fournisseur avec une clé d'idempotence documentée sont différents de l'envoi d'une notification à un seul coup par l'intermédiaire d'une API qui n'a pas de contrat de déduplication. Enregistrer un reçu d'effet avant d'ajouter des répétitions Un reçu d'effet est un petit enregistrement local créé avant la livraison de . Ce n'est pas la seule réponse du fournisseur. Il corrélate l'intention engagée avec des preuves ultérieures: operation id identifie l'action logique à travers les redémarrages de processus. request hash empêche un agent de réutiliser cette identité pour les paramètres modifiés. La clé d'idempotence est séparée parce que tous les fournisseurs ne le prennent pas en charge, et les fournisseurs définissent différentes fenêtres de rétention et comportement de répétition. La sonde décrit comment l'effet a été vérifié; un point final de liste en cache est une preuve plus faible qu'une lecture directe par une référence externe unique. N'enregistrez pas de secrets, de corps rapides, de contenu de messages ou d'arguments complets sur les outils. Hach une intention canonique, édité et conserver uniquement les champs nécessaires pour concilier l'effet. Si le fournisseur accepte les métadonnées du client, y joindre l'identifiant d'exploitation stable afin qu'une connexion Web ou une lecture ultérieure puisse corréler un objet même lorsque la réponse initiale a disparu. Le verdict devrait utiliser des preuves explicites: Le verdict Les preuves L'action suivante verified applied Un effet de correspondance ou un reçu fiable du fournisseur reproduit Ne réessayez pas; continuez à vérifier les résultats verified not applied Une requête faisant autorité prouve zéro effet de correspondance Consulter le contrat de fournisseur avant une nouvelle tentative limitée indeterminate La réponse manque et aucune vérification d'effet autoritaire n'est disponible. Attendez, réconciliez vous ou demandez à un humain. Ne vous trompez pas de certitude. duplicate effect Il existe plus d'un effet de correspondance Arrêter les tentatives et entrer dans une voie de réparation compensatoire ou humaine false success Le transport a réussi mais l'effet promis est absent. Traiter la course comme malsaine même si la commande a été terminée unsafe retry La même intention a été réessayée sous une nouvelle clé ou un hash de requête modifié Arrêtez; la limite de déduplication a été rompue Ce tableau sépare l'activité des progrès utiles. Une autre tentative est l'activité. Un effet unique confirmé est le progrès. Une fenêtre de réconciliation légitime attend, alors que les clés fraîches répétées sans reçu stable sont une exécution dangereuse. Exécutez le classifiateur de six cas J'ai construit un dispositif NDJSON en six cas pour tester la règle. Il comprend une réponse perdue avec un reçu du fournisseur correspondant, un délai avec des preuves indisponibles, un fournisseur qui crée deux effets malgré une clé répétée, une réponse réussie sans objet résultant, un résultat autorisé à effet zéro et une nouvelle tentative de clé modifiée. Le classifiant de base est délibérément petit: La solution est un cas dans chaque État: Les six affirmations attendues passent. Le résultat le plus important est la deuxième ligne, et non le chemin heureux: un délai sans chemin de lecture autoritaire reste indeterminate . Une nouvelle tentative rendrait le tableau de bord plus occupé tout en rendant l'état du monde réel plus difficile à récupérer. L'appareil prend aussi un raccourci tentant. Un reçu du fournisseur n'est utile que lorsqu'il est lié au hash de la demande initiale. Un reçu pour une charge utile différente ne peut prouver que l'effet prévu s'est produit. De même, un transport 200 n'est pas une vérification des résultats; le cas ack without deliverable est false success parce que l'objet externe est absent. Dans la production, procéder à la réconciliation selon un calendrier limité. Demandez par la clé d'identité d'exploitation stable ou d'idempotence du fournisseur, enregistrez la fraîcheur des preuves et arrêtez après un délai fixe. Si le résultat reste indéterminé, envoyez la décision à quelqu'un qui a autorité sur le système affecté. Ne laissez pas une politique générique retry jusqu'à trois fois franchir une limite d'effets secondaires. Lorsque le contrat prend fin Un reçu d'effet réduit l'ambiguïté; il ne crée pas une garantie unique. Le fournisseur peut épuiser les clés d'idempotence, les ignorer sur certains terminaux, accepter une demande avant une défaillance asynchrone interne ou exposer un modèle de lecture qui est en retard sur l'écriture. Une sonde peut également être erronée en raison de la mise en cache, des autorisations partielles ou d'une recherche non unique. Mettez ces limites à côté du verdict: conserver la fenêtre et la portée de l'idempotence documentées du fournisseur; utiliser la même clé and la même requête canonique lors d'une nouvelle tentative autorisée; la fiabilité et la fraîcheur des sondes d'étiquette; distinguer un zéro autorisé de non visible encore; le temps de réconciliation maximal et le nombre de tentatives répétées; exigent l'approbation humaine pour des actions compensatoires ou irréversibles; vérifier le résultat prévu par l'utilisateur après confirmation de l'effet. Ce modèle est particulièrement précieux pour les agents de longue durée, car le processus de récupération perd souvent la réponse de transport alors que le travail extérieur se poursuit. La persistance de la réception avant l'expédition donne à un agent redémarré un lieu stable pour reprendre l'enquête. Il devrait reprendre à partir de indeterminate , pas de probablement échoué. Pour l'observabilité de l'agent AI, la règle d'exploitation est simple: un délai est une observation de transport, pas un verdict d'effet. Préserver l'identité d'une opération, corréler le fournisseur et les preuves de lecture et refuser d'appeler la course saine jusqu'à ce que le résultat externe prévu soit vérifié. L'orientation du produit de Sidewisp comprend la santé des résultats, les défaillances des outils, les essais répétés, les preuves et les limites d'approbation humaine. Cet article décrit un modèle de fonctionnement, pas un moniteur expédié. Sidewisp est actuellement en préversion privée. La collecte de l'agent de production en matière de santé, les adaptateurs de temps d'exécution, la surveillance de la réception des effets et la récupération ne sont généralement pas expédiées. Le site public et la bibliothèque d'articles sont en direct, et les lecteurs peuvent rejoindre l'accès anticipé sans accorder à Sidewisp l'autorité sur leurs agents.