Observabilité de l'agent AI pour les essais rétrospectifs: capture d'effets dupliqués

Un agent ne devrait pas réessayer un appel d'outil simplement parce que sa trace se termine dans un délai. La demande a peut être atteint le fournisseur, a changé d'état réel et n'a perdu que la réponse. Une deuxième tentative peut ensuite envoyer le message deux fois, créer deux billets ou fournir deux ressources alors que les deux traces semblent raisonnables individuellement. La règle de santé utile est plus stricte: une opération logique de one ne doit pas produire plus d'un effet vérifié . Donnez à l'opération une identité stable, gardez cette identité à travers les tentatives, enregistrez les reçus d'effets secondaires du fournisseur et bloquez la reprise automatique lorsque l'effet ne peut pas être recherché en toute sécurité. Le nombre de tentatives et le statut HTTP aident toujours au diagnostic, mais aucun ne prouve le résultat. Cet article construit cette règle dans un petit registre d'effets et le teste contre quatre opérations. Le dispositif contient huit tentatives et quatre observations du fournisseur. Une politique de tentative seulement mettrait fin à trois opérations et continuerait de les réessayer. L'audit conscient de l'effet trouve plutôt une répétition saine, un incident d'effet duplicé, un conflit clé d'idempotence et une opération honnêtement incertaine. Une pause n' est pas la preuve que rien ne s' est passé . La fenêtre dangereuse se situe entre l'exécution à distance et la reconnaissance locale. Un fournisseur peut commettre un effet et ensuite perdre la réponse sur le chemin du retour. Du côté de l'agent, ces deux histoires sont observationnellement similaires: 1. la demande n'a jamais atteint le fournisseur; 2. la demande a été remplie, mais la réponse n'a pas atteint l'agent. Seule la première histoire est sûre de se répéter sans autre garantie. Le second crée un duplicat lorsque l'opération n'est pas naturellement idempotente. La sémantique HTTP fournit une limite utile. RFC 9110 définit une méthode idempotente en tant qu'un serveur dont l'effet prévu est le même après plusieurs demandes identiques qu'après une seule demande. Il permet une répétition automatique après une défaillance de communication pour les méthodes idempotentes, mais dit qu'un client ne doit pas automatiquement réessayer une demande non idempotente à moins qu'il sache que l'opération est effectivement idempotente ou puisse détecter que l'original n'a jamais été appliqué. Cette distinction appartient à la santé des agents. Un PUT qui remplace un enregistrement connu et un POST qui envoie un e mail peuvent à la fois sortir, mais ils n'ont pas la même limite de réessayer. Une politique générique timeout → retry efface le fait sémantique qui compte le plus. L'aide du fournisseur aide, mais le contrat doit être lu avec précision. Documents de bande qu'il stocke le code d'état et le corps pour la première demande faite avec une clé d'idempotence, puis renvoie ce résultat à des demandes ultérieures avec la même clé. Il compare également les paramètres et rejette la réutilisation avec différents paramètres. La clé n'est donc pas une étiquette aléatoire attachée à chaque tentative. Il représente une opération logique stable. Documents EC2 d'Amazon un modèle client token similaire: une nouvelle tentative réussie avec le même jeton et les mêmes paramètres n'effectue aucune action supplémentaire, tandis que les paramètres modifiés peuvent produire IdempotentParameterMismatch . L'EC2 couvre également certaines garanties au niveau régional ou régional. Avoir un jeton ne suffit pas; le dossier de santé a besoin de la portée du jeton, de l'identité de la charge utile, de la fenêtre de rétention et du comportement du fournisseur. Le défaut raisonnable est: réutiliser une identité d'opération dans toutes les tentatives; réutiliser la clé d'idempotence du fournisseur uniquement pour la même charge utile canonique; après un résultat ambigu, une requête par cette identité avant de réessayer; si le fournisseur n'offre ni l'indemnité ni la recherche, exiger une décision humaine pour les effets conséquents. Le retrait réduit la pression sur un service en panne. Elle ne transforme pas une action non idempotente en une action idempotente. Des effets enregistrés, pas seulement des tentatives Une trace ordinaire répond à qu'a essayé l'agent? Un registre des effets répond à la question différente quels changements durables pouvons nous prouver? Gardez les deux enregistrements liés, car les tentatives restent des preuves utiles, mais ne traitez pas la durée terminale d'une tentative comme le résultat commercial. Un registre minimal a besoin de ces champs: champs Le but Les problèmes de santé qu'il révèle operationId Identification stable de l'exploitation prévue par l'utilisateur Une nouvelle pièce d'identité générée pour chaque nouvelle tentative attemptId Identification pour une tentative de transport Des tentatives manquantes ou se chevauchant idempotencyKey Identification déduplication du fournisseur, lorsqu'elle est prise en charge Changements clés au cours des essais répétitifs payloadHash Hash d'une charge utile canonique et modifiée La même clé réutilisée à des fins différentes effectRef Identification du fournisseur ou de la destination de l'effet réel Plus d'un effet durable result Observation des transports tels que timeout ou success Reconnaissance ambiguë observedAt Le moment où les preuves ont été recueillies Des preuves anciennes confondues avec l'état actuel Ne mettez pas de secrets, d'adresses électroniques, d'invitations complètes ou de charges utiles d'outils dans ces champs. Hash une représentation canonique après avoir supprimé les valeurs volatiles. Gardez la matière première sensible à l'origine lorsque l'enquête en a besoin. L'identité de l'opération doit être imprimée lorsque l'intention devient durable, et non à l'intérieur de la boucle de réessayer. Par exemple: L'extrait est incomplet par conception: saisir une exception et continuer n'est pas une preuve de sécurité. L'appelant doit également conserver l'identifiant objet retourné du fournisseur ou demander au fournisseur par la même identité d'entreprise après une réponse ambiguë. Comptez les effets uniques, pas les réponses réussies. Deux réponses réussies qui nomment toutes les deux ticket 908 décrivent un effet. Un délai suivi d'un succès nommé delivery a et delivery b décrit deux effets. À l'inverse, les reçus zéro ne prouvent pas que les effets zéro lorsque le canal de recherche n'est pas disponible. Cet état est uncertain , pas sain et pas automatiquement coincé. L'identité de la charge utile est une porte séparée. Si deux tentatives partagent une clé d'idempotence mais ont des hachages de charge utile canoniques différents, arrêtez avant d'interpréter le nombre d'effets. L'appelant peut avoir accidentellement réutilisé une clé après avoir modifié la région, le destinataire, la quantité ou la forme de la ressource demandée. Les erreurs de défaut de paramètre du fournisseur sont une preuve utile de cette erreur exacte. Effectuer une vérification des effets des quatre opérations Le dispositif inspectable utilisé pour cet article est NDJSON. Chaque ligne est soit une observation attempt , soit une observation effect . L'artefact local complet contient quatre opérations logiques: op ticket 42 : deux tentatives partagent une clé et une charge utile; les deux observations pointent vers ticket 908 ; op webhook 77 : deux tentatives n'ont pas de clé d'idempotence et révèlent delivery a plus delivery b ; op vm 5 : deux tentatives de réutilisation d'une clé avec des hachages de charge utile différents; op email 3 : deux tentatives de délai, aucun reçu d'effet n'est disponible et le fournisseur n'a pas de chemin de recherche. Les groupes d'audit enregistrent par operationId , rejettent la dérive de la charge utile avant de compter les effets et comptent des valeurs distinctes effectRef plutôt que des lignes d'observation des effets: Exécution de l' artefact du référentiel: produit: Trois observations modifient la décision opérationnelle. Tout d'abord, op ticket 42 a deux enregistrements de tentatives et deux observations d'effets, mais les deux observations se résolvent à un seul objet fournisseur. L'alerte sur les lignes d'effet 1 serait un faux positif. La référence du fournisseur stable est ce qui prouve la déduplication. Deuxièmement, op webhook 77 inclut une deuxième tentative réussie. Un tableau de bord uniquement destiné au transport pourrait fermer l'incident. Les deux références d'effet prouvent que la récupération a créé une deuxième livraison, donc l'état correct est dupliqué et la tâche suivante est la réconciliation, pas une nouvelle tentative. Troisièmement, le op vm 5 n'a pas d'effet dupliqué dans le dispositif, mais il est toujours dangereux. La clé réutilisée couvre deux hashes de charge utile différents. En attendant l'apparition d'une deuxième ressource, il serait trop tard pour détecter le problème; le principal conflit réside dans une insuffisance préventive en matière de santé. L'audit a une limite importante: il ne peut classer que les éléments de preuve fournis. Pour op email 3 , aucun reçu et aucun chemin de recherche ne laissent le résultat inconnu. Le registre ne peut pas fabriquer la certitude. Une nouvelle tentative pourrait compléter le travail manquant ou dupliquer le travail accompli, de sorte que la réponse limitée est de faire surface à l'ambiguïté et de demander l'autorité. Transformer le résultat en une limite de réessayer Utilisez la classification pour contrôler l'action suivante, pas seulement la couleur d'un tableau de bord: Classification Les preuves Par défaut sécurisé healthy Une identité de charge utile et exactement un effet unique Arrêter de réessayer; vérifier la livrabilité prévue duplicate Plus d'un effet unique pour une opération Reessais par groupe; concilier ou compenser avec l'approbation key conflict Une clé attachée à plusieurs hashes de charge utile Exécution par bloc; ne réaliser une nouvelle opération qu'après examen de l'intention uncertain Aucune preuve d'effet et aucune preuve d'absence fiable Encore une fois, attendez de nouvelles preuves, ou demandez à un humain Un délai est encore nécessaire. Les dossiers d'idempotence du fournisseur peuvent expirer, les indices de recherche peuvent être en retard et une destination peut être en dehors des limites de la transaction du fournisseur. Conservez la conservation et la portée documentées à côté de la clé. Après l'expiration de cette limite, la même demande peut ne plus être sécurisée même si le chemin du code d'origine n'a pas changé. La vérification de la récupération doit atteindre le résultat initial. Un seul objet fournisseur peut toujours être faux: un ticket peut exister avec le mauvais projet, ou une ressource peut être créée mais ne jamais être prête. L'invariable à effet unique empêche la duplication; un contrat de résultat séparé vérifie que l'effet de survie est celui prévu par l'utilisateur. Pour une vue de la santé opérationnelle, rappelez cinq faits: 1. l'exploitation logique et l'empreinte digitale de la charge utile; 2. les tentatives et les résultats de leur transport; 3. la portée et la fraîcheur de l'idempotence du fournisseur; 4. les différents effets durables observés; 5. la limite de l'autorité pour la réessayer, l'indemnisation ou la réconciliation. Ce qui fait de la réussite de la retraite une preuve plutôt que le verdict. Le verdict le plus sain est qu'un effet prévu existe et a été vérifié, ou, lorsque les preuves sont incomplètes, l'effet est incertain; une nouvelle tentative automatique est bloquée. Sidewisp est actuellement en préversion privée. Son système public d'articles et la démonstration interactive de produits sont en direct, mais la collecte de l'agent de production santé, les adaptateurs de temps d'exécution, la gestion du cron, l'analyse des coûts des jetons et la récupération ne sont généralement pas expédiés. Les exemples ci dessus constituent un modèle de fonctionnement, et non une affirmation selon laquelle Sidewisp inspecte ou répare actuellement des agents vivants. Le Sidewisp n'est pas un temps d'exécution de remplacement, une passerelle obligatoire, un produit de traçage brut, un plan de contrôle d'entreprise ou un fixateur autonome. Si une règle de santé du registre des effets vous aiderait à opérer des agents existants, envisagez de rejoindre l'aperçu privé. Gardez l'exécution là où elle se déroule déjà; faites en sorte que les tentatives de reprise gagnent leur sécurité grâce à des preuves.