Agentique AI Observabilité pour le fan-out: prouver le quorum de finalisation

Dans une course d'agents fan out, un parent terminé n'est pas la preuve que le travail est terminé. Le parent a peut être recueilli la branche la plus rapide, ignoré un examen requis, fusionné un résultat obsolète ou compté la même branche deux fois. L'observabilité de l'agent AI a besoin d'un quorum d'achèvement: une liste gelée des succursales attendues plus des reçus frais, uniques et vérifiés par les résultats pour chaque succursale requise et le nombre déclaré de succursales facultatives. Le défaut pratique est strict. Avant d'envoyer le manifeste de la succursale, identifiez les travaux requis et facultatifs, fixez une date limite, et laissez seulement les reçus vérifiés satisfaire le quorum. Avant la date limite, la couverture manquante peut être waiting . Après la date limite, c'est incomplete . Si le parent rapporte un succès sans couverture, étiquettez le false complete au lieu de mettre en vert un drapeau terminal pratique. Les traces montrent le ventilateur, mais elles ne définissent pas l'achèvement Le Documentation de suivi du SDK OpenAI Agents enregistre les générations, les appels à l'outil, les barreaux, les remises, les événements personnalisés, les identifiants parent et les timestamps. Le OpenTelemetry Conventions sur la durée de l'action de l'agent GenAI, actuellement marqué Développement, décrit les opérations comprenant l'invocation d'agents, la planification et l'exécution des outils. Ces enregistrements constituent une preuve utile de l'activité. Ils ne savent pas quelles branches l'exploitant a exigées ou quel résultat observable chaque branche devait. Une trace peut contenir quatre branches de l'enfant réussie alors que la cinquième branche non épiée, l'examen de la sécurité, la vérification de la destination ou la source de données régionale, ne s'affiche jamais. En regardant uniquement les sphères émises, on crée un problème de sélection: les travaux manquants ne laissent aucune sphère à inspecter. Les systèmes généraux de lots rendent explicite l'ensemble attendu. Le Kubernetes Documentation d'emploi distingue le travail parallèle avec un nombre fixe d'achèvements des emplois en file d'attente. Pour les emplois indexés, l'achèvement nécessite un Pod réussi pour chaque indice; la documentation prévient également que plus d'un Pod peut commencer pour le même indice et que seule la première réussite compte. L'agent fan out n'est pas un emploi Kubernetes, mais le transfert d'une leçon opérationnelle: l'identité et la couverture attendue sont des questions, pas seulement un nombre total d'événements réussis. Pour le travail d'agent, le parent doit congeler un manifeste comme celui ci avant de déléguer: Le gel est important. Si le parent peut retirer silencieusement une branche lente après l'expédition, le dénominateur change pour s'adapter au résultat observé. Une révision manifeste peut être légitime, mais elle a besoin d'une nouvelle version, d'une raison et d'une limite d'approbation plutôt que d'une modification en place. Faites en sorte que chaque reçu soit un résultat. Un reçu de succursale nécessite plus de status: succeeded . Donnez lui l'identité de la branche gelée, le temps d'observation, un résumé des preuves et un résultat d'une vérification indépendante des résultats: Le résumé doit couvrir une projection canonique et non secrète du résultat promis. Pour une branche d'essai, cela pourrait inclure le commande de commande, l'état de sortie et le résumé de test normalisé. Pour la recherche, il pourrait couvrir les URL de source sélectionnées, les temps de récupération et le registre des demandes. Pour une branche de livraison, utilisez l'identité de l'objet de destination et un résultat de vérification du côté de lecture. N'accrochez pas les instructions, les informations d'identification ou les charges utiles sensibles simplement pour que le reçu paraisse rigoureux. Évaluer les reçus dans un ordre qui préserve l'incertitude: 1. Rejeter un manifeste invalide, un identifiant de succursale inconnu ou des reçus dupliqués contradictoires en tant que uncertain . 2. Retour incomplete lorsque une branche requise échoue explicitement. 3. Retour unverified lorsque le succès requis est obsolète, manque d'une analyse des preuves ou n'a pas de vérification des résultats indépendante. 4. La couverture du compte n'est assurée que lorsque chaque succursale requise a un nouveau succès vérifié et que les succès vérifiés facultatifs répondent au quorum déclaré. 5. Retour complete uniquement lorsque la couverture est remplie et que le parent est terminal; sinon, retour ready to finalize . 6. Si la couverture est manquante, retournez waiting seulement pendant que la date limite reste ouverte. 7. Retour false complete lorsque le parent termine plus tôt, ou incomplete lorsque le délai expire le premier. Les duplicates en conflit méritent un traitement spécial. Deux reçus pour la même branche avec des preuves différentes peuvent indiquer une nouvelle tentative, une fracture cérébrale ou une sortie non déterministe. L'acceptation arbitraire du dernier résultat cache le conflit. Gardez l'état uncertain jusqu'à ce qu'une politique spécifique à la branche identifie la tentative d'autorisation. Répétez sept états d'achèvement L'artefact d'accompagnement comporte un classifiateur déterministe sur sept cas de ventilation synthétique: La répétition produite: research 42 a vérifié les reçus pour les deux succursales requises et pour l'une des deux succursales facultatives, répondant exactement à son quorum facultatif. Parce que son parent est terminal, il est complete . merge 17 a une couverture complète requise mais reste ready to finalize parce que l'exécution principale est encore ouverte. Les cas d'échec par paires exposent pourquoi un seul champ running/completé est inadéquat. approval 09 manque un reçu requis, mais reste dans sa date limite, il s'agit donc de waiting . Le early parent 08 a la même couverture mais un parent terminal, il devient donc false complete immédiatement. Le classificateur n'attend pas le délai pour admettre que l'affirmation de réussite n'est pas appuyée. Le unchecked 24 comprend un reçu de vérification de destination réussi dont le champ outcomeVerified est faux. Il est unverified , pas complet. conflict 15 présente deux digests différents pour la même branche et reste donc uncertain . L'artefact traite les preuves manquantes et les preuves contradictoires comme des problèmes opérationnels différents. Il s'agit d'une règle de décision falsifiable et non d'une mesure de la fréquence des défaillances de production. Sept cas construits démontrent la couverture des succursales et les commandes de l'État; ils ne peuvent pas établir des délais universels ou montrer à quelle fréquence les agents réels perdent le travail de ventilateur. Calibrer le quorum sans le rendre cosmétique Commencez par la sémantique des branches. Un examen de la sécurité, une approbation de l'action destructrice ou une vérification de la destination sont généralement nécessaires même si plusieurs succursales d'enrichissement facultatives réussissent. Ne laissez jamais un quorum numérique facultatif prévaloir sur une branche requise nommée. Si deux des trois sources est acceptable, encodez les trois comme facultatives avec quorum deux et préservez leur identité. Définir la date limite à partir de la classe de tâches, pas d'un agent global. Une révision interactive du code et une recherche régionale au cours de la nuit ont des attentes différentes. Enregistrer le temps du collecteur et le temps de source; rejeter les reçus observés avant le gel manifeste ou improbablement après le temps d'observation. Si vous ne pouvez pas faire confiance aux horloges, faites surface à uncertain plutôt que de deviner la fraîcheur. Persistez le manifeste et les reçus suffisamment durables pour survivre aux redémarrages des parents. Une liste reconstituée basée uniquement sur des enfants actuellement visibles peut omettre une branche qui a échoué avant la télémétrie. Conservez une version manifeste, l'identifiant de l'exécution parent, l'identité de la branche, l'identité de la tentative de réception et la raison finale de la classification. Si l'exécution dupliquée est possible, expliquez explicitement la règle de l'autorité au lieu de compter sur l'ordre d'arrivée. Enfin, séparer le diagnostic de l'intervention. Un reçu manquant peut justifier l'avis d'un propriétaire, la demande de preuves ou la préparation d'une nouvelle tentative limitée. Il n'autorise pas la dépense, la suppression, le changement de carte de crédit ou la chute silencieuse de la succursale. Après une nouvelle tentative approuvée, demandez un nouveau reçu et faites à nouveau la vérification du quorum. La limite est importante: un quorum d'achèvement prouve la couverture déclarée, pas que le manifeste a capturé toutes les exigences réelles. Un contrôle de branche faible peut également vérifier le mauvais artefact. Examiner la conception du manifeste et les vérifications des résultats aussi attentivement que le code du classifiateur. Sidewisp est actuellement en préversion privée. Son site public et sa bibliothèque d'articles sont en direct, mais la collecte de l'agent 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 destiné à aider à rendre visibles les limites de preuve, d'attente, d'achèvement faux et d'approbation aux côtés des délais d'exécution existants, et non à remplacer les délais d'exécution ou à agir comme un fixateur autonome. Si les quorums d'achèvement correspondent à un échec que vous devez inspecter, vous pouvez rejoindre l'accès anticipé sans considérer l'aperçu comme une revendication de surveillance déployée.