AI Agent Observabilité pour les circuits à cerveau divisé: travailleurs de la clôture

L'observabilité de l'agent AI a besoin d'un signal de propriété, pas seulement de plus de traces, quand un travailleur échoué peut reprendre. Donner à chaque acquisition d'un flux de travail durable un owner epoch en augmentation monotone. Mettez cette époque sur les événements de progrès et les tentatives d'effets externes. À la destination, acceptez un effet seulement lorsque son époque est encore en vigueur. Cela sépare trois faits qui sont faciles à confondre: un travailleur est en vie; un travailleur effectue une activité; Un travailleur est toujours autorisé à changer le monde extérieur. Un battement cardiaque confirme la première affirmation. Un point de contrôle peut soutenir le second. Aucun ne prouve le troisième après qu'un autre travailleur ait pris le relais. Deux exécutions peuvent chacune paraître cohérente au niveau local tout en écrivant un index de sortie, en envoyant un message à un client, en mettant à jour un billet ou en publiant le même artefact. Le défaut raisonnable est un bail pour acquisition plus une clôture à chaque destination irréversible. Utilisez le bail pour décider quand un autre travailleur peut devenir propriétaire. Utilisez la clôture pour arrêter le travailleur déplacé s'il se réveille tard. Observez les deux chemins, car le service de location peut être sain alors qu'une destination ignore le jeton de propriété. Un bail courant n'est pas une barrière d'effet Documentation du bail Kubernetes fournit un modèle de béton utile. Les objets de location soutiennent les battements cardiaques des nœuds et l'élection du leader des composants. Un kubelet met à jour spec.renewTime , et le plan de contrôle utilise ce timestamp pour décider de la disponibilité du nœud. L'API du bail expose également l'identité du titulaire, la durée du bail et les informations de transition. Ces champs répondent aux questions de fraîcheur et d'élection. Ils ne font pas disparaître un vieux processus. Un travailleur peut s'arrêter pendant un problème de réseau, la suspension de la machine à sous, un long arrêt de collecte de déchets ou un appel à l'outil bloqué. Le bail peut expirer, un remplaçant peut acquérir la propriété, et l'ancien processus peut ensuite reprendre à partir de l'État local. La limite n'est pas une formule hypothétique. Le Package Kubernetes pour l'élection des dirigeants par client affirme explicitement que sa mise en œuvre ne garantit pas qu'un seul client joue le rôle de leader, également appelé clôture. Le paquet est conçu autour d'une élection coordonnée et d'une tolérance à l'horloge, pas une garantie universelle que chaque système en aval rejette l'ancien leader. Les preuves Ce qu'elle soutient Ce qu'il ne prouve pas récent battement cardiaque le processus ou l'observateur a été récemment accessible le processus possède toujours le flux de travail détenteur actuel du bail le magasin de coordination a sélectionné ce propriétaire le propriétaire précédent ne peut pas atteindre un outil trace avec des débits réussis un chemin d'exécution a terminé les étapes enregistrées aucune exécution concurrente n'a produit le même effet augmentation des points de contrôle Ce travailleur a changé d'état. ses modifications sont autorisées ou utiles l'acceptation de la cuvette avec l'époque actuelle cette destination a accepté le propriétaire actuel toutes les autres destinations ont appliqué la même règle Appeler la condition "exécution par séparation de cerveau" uniquement lorsque les preuves de propriété sont en conflit: une époque supérieure a été acquise, mais une époque inférieure rapporte encore une activité ou tente d'avoir un effet. N'étiquettez pas une livraison ordinaire comme un incident. L'ancien travailleur a peut être cessé de travailler et le nouveau travailleur est peut être le seul acteur après la prise de contrôle. Cette distinction empêche deux mauvaises alertes. Il y avait deux travailleurs est trop large; le remplacement de roulement peut être sain. Les journaux émis par les deux travailleurs sont également trop larges; les preuves tamponnées peuvent arriver tard. La question utile est de savoir si un événement s'est produit après que l'époque supérieure soit devenue autoritaire, en utilisant la transition ordonnée du magasin de coordination ou une autre séquence autoritaire, quelle que soit la nouvelle apparence de l'horloge de machine. Mettez l' époque du propriétaire sur l' effet Un dossier de propriété observable peut rester compact. Il devrait identifier le flux de travail durable, l'acquisition, le travailleur, l'effet et l'ordre d'observation: workflow key est l'unité qui doit avoir un propriétaire d'effet unique. Il ne s'agit pas nécessairement d'un identifiant de trace ou d'un identifiant de processus. Une exportation programmée pourrait utiliser tenant/export/date ; un agent de boîte de réception pourrait utiliser l'ID du message source; un flux de travail de publication pourrait utiliser locale plus article slug. owner epoch est un jeton monotoniquement croissant alloué par le magasin de coordination autorisé. Un timestamp du travailleur n'est pas un substitut sûr. Les horloges peuvent bouger, et deux hôtes peuvent être en désaccord. Un identifiant de course aléatoire est utile pour joindre des preuves mais n'a aucune relation d'ordre. L'audit doit savoir que l'époque 18 a remplacé l'époque 17. effect key nomme le résultat visible de manière suffisamment proche pour détecter deux propriétaires ciblant le même résultat. L'appel à l'outil 44 est faible parce que deux courses choisiront des identifiants d'appel différents. Index de libération pour le 26 juillet ou réponse au message source 8f2... décrit la chose qui ne doit pas se produire deux fois. Enregistrer au moins ces types d'événements: lease acquired : transition autoritaire vers une époque supérieure; progress : un point de contrôle significatif, toujours séparé de l'autorité; effect attempted : le travailleur est sur le point de franchir une limite des effets secondaires; effect committed : la destination confirme l'effet; outcome verified : un prédicat indépendant confirme le résultat prévu. L'état du détecteur est simple. Pour chaque workflow key , conservez l'époque la plus élevée acquise. Les preuves d'une époque inférieure après cette acquisition sont obsolètes. Un événement progress obsolète est diagnostique: un ancien processus est toujours actif. Un événement effect attempted périmé est un événement à risque si la destination le rejette. Un événement effect committed périmé est un incident de précision parce que la clôture a échoué ou n'existait pas. Ne pas améliorer directement l'activité périmée en une réclamation de dommages survenus. L'activité et l'effet sont différents. Le vieil ouvrier pourrait terminer un calcul local, écrire un cache jetable ou s'arrêter. La gravité devrait augmenter lorsque l'époque obsolète atteint une destination, et augmenter à nouveau lorsque deux époques commettent le même effect key . Retournez une prise de contrôle dangereuse et une transfert propre Le dispositif d'accompagnement comporte seize événements ordonnés sur trois flux de travail. export ledger commence par worker alpha à l'époque 17. worker beta acquiert alors l'époque 18. Alpha reprend, émet un point de contrôle des progrès, tente l'effet de l'indice de libération partagé et l'engage en représentant une destination non sûre. La bêta a le même effet à l'époque 18. report index fournit le dossier de contrôle. L'époque 5 commet une fragmentation, l'époque 6 prend plus tard en charge et commet une autre fragmentation, et aucun événement de l'époque inférieure ne se produit après la transition. checkout sync reste sur un seul propriétaire. Exécuter l'audit: Le résultat déterministe est: PASS signifie que le test d'acceptation a trouvé toutes les conditions de plantation. Cela ne signifie pas que le flux de travail dangereux de export ledger était sain. La séquence 6 est une activité stérile de l'époque 17 après l'époque 18. La séquence 7 est la tentative obsolète. La séquence 8 est le compromis dangereux. Lorsque la séquence 9 exerce le même effet à partir de l'époque 18, l'audit peut montrer à la fois les propriétaires et les deux événements de source au lieu de simplement signaler un nombre dupliqué. L'expérience donne quatre observations pratiques. Premièrement, le nombre d'acquisitions n'est pas une mesure d'erreur. Les deux export ledger et report index changent de propriétaire. Seule la première possède des preuves de l'époque inférieure après la prise de contrôle. Deuxièmement, un point de contrôle peut prouver qu'un processus fait du travail tout en prouvant que le travail n'est pas autorisé. Les rangées traitées augmentées de 400 à 600 est une activité, pas une autorisation. Troisièmement, la détection dupliquée devient explicative lorsqu'elle conserve l'ordre des époques et de la transition. L'opérateur peut voir si le double provient d'un client réessayé par un propriétaire ou de deux propriétaires agissant en cas de défaillance. Quatrièmement, c'est une vérification des preuves, pas une preuve de verrouillage distribué. L'appareil utilise une séquence d'authentification afin que la règle de décision soit vérifiable. Les systèmes réels doivent définir où les époques sont allouées, comment cette allouement est rendu durable, et quelles destinations l'appliquent à titre atomique. Appliquer la clôture à chaque destination L'enregistrement de owner epoch ne diagnostique qu'un écrivain obsolète après le fait. La prévention doit vivre dans le système qui en a l'effet. Dans les travaux basés sur des bases de données, il peut s'agir d'une seule transaction: verrouiller ou comparer l'époque actuelle du flux de travail, rejeter une valeur inférieure, puis écrire l'effet et sa clé d'idempotence avant de s'engager. La comparaison et l'effet doivent partager une frontière atomique. La vérification de l'époque, la libération du verrou, puis l'appel d'une API externe laisse une course entre le contrôle et l'effet. Kafka a documenté une version concrète de l'idée. ProducteurFundedException indique qu'un autre producteur avec le même transactional.id a démarré; l'instance la plus récente clôture les instances précédentes afin qu'ils ne puissent plus faire de demandes de transaction. Cela ne transforme pas le mécanisme de Kafka en un protocole d'agent universel. Il démontre la propriété à demander à une destination: un nouveau propriétaire peut il invalider une propriété plus ancienne au moment de l'engagement? Beaucoup d'outils d'agents ne peuvent comparer une époque. Les API de courrier électronique, les systèmes de billets, les commandes shell et les mutations SaaS acceptent souvent une demande sans consulter votre magasin de location. Utilisez la limite la plus forte que la destination supporte: 1. Passez un jeton de clôture et demandez une comparaison atomique lorsque vous contrôlez l'évier. 2. Utilisez une clé d'idempotence imposée par la destination lorsque les effets dupliqués sont équivalents. 3. La production de phase sous l'époque, puis laissez une transaction actuelle propriétaire de promouvoir. 4. Mettez une boîte de réception transactionnelle entre l'agent et l'API externe. 5. Lorsque cela n'est pas possible, concilier par effect key , exposer l'incertitude et exiger l'examen humain pour des répétitions coûteuses ou irréversibles. L'idempotence et la clôture résolvent des problèmes liés mais différents. Une clé d'idempotence peut annuler les demandes répétées pour le même effet. Une clôture rejette toutes les demandes ultérieures d'un ancien propriétaire, y compris une clé d'effet différente que l'ancien plan ne devrait plus produire. Pour les flux de travail critiques, utilisez les deux. La disponibilité est le compromis. Si le magasin de coordination ne peut pas allouer ou confirmer une époque actuelle, les effets de rejet peuvent interrompre les travaux utiles. C'est préférable pour les mouvements d'argent, les publications, les changements destructeurs ou la communication avec les clients. Une tâche de recherche de lecture uniquement peut plutôt se poursuivre localement et ne retarder que l'engagement. Fixez la limite par le risque, pas par un désir général de garder chaque agent occupé. Transformer le conflit en problème de santé opérationnelle Une constatation du propriétaire d'une usure devrait inclure le flux de travail, les travailleurs déplacés et les travailleurs actuels, les deux époques, la transition autoritaire, le dernier événement d'une usure, les clés d'effet affectées, la fraîcheur des preuves et si l'évier a rejeté ou engagé la demande. La confiance n'est élevée que lorsque l'ordre d'acquisition et la confirmation de l'effet proviennent de sources faisant autorité. La réponse la plus sûre dépend de ce qui s'est passé: activité ininterrompue sans tentative d'effet: arrêter ou mettre en quarantaine l'ancien travailleur si cette action est autorisée, puis vérifier qu'il n'émet pas d'autres événements; tentative de mise à jour rejetée: conserver le reçu de rejet, vérifier pourquoi le travailleur a manqué la perte de location et vérifier que le propriétaire actuel continue de progresser; l'engagement permanent sans engagement concurrentiel: congeler les effets ultérieurs, inspecter le résultat et décider si la compensation est sûre; deux époques engagées pour un effet: traiter le résultat comme incertain jusqu'à ce qu'un prédicat externe ou humain vérifie le résultat durable. Ne réparez pas automatiquement une condition de fracture cérébrale en réessayant le propriétaire actuel. Cela peut créer un troisième effet. Il suffit d'éliminer le problème après que le travailleur dépassé ait été clôturé et que l'issue prévue soit vérifiée, pas seulement une sortie de commande. La direction du produit de Sidewisp est une couche de santé autour des délais d'exécution des agents existants, axée sur les preuves, les progrès utiles, les résultats et les limites explicites d'approbation. Il ne s'agit pas d'un temps de fonctionnement de remplacement, d'une passerelle obligatoire, d'un produit de traçage brut, d'un avion de contrôle d'entreprise ou d'un fixateur autonome. Sidewisp est actuellement en préversion privée. Le site public et le système d'articles sont en direct, tandis que 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. Si la preuve de propriétaire de l'arrêt est l'un des modes d'échec dont vous avez besoin pour fonctionner, vous pouvez vous joindre à l'aperçu privé et décrire les limites d'exécution et d'effet impliquées. Références principales Kubernetes: Locations fraîcheur du rythme cardiaque des nœuds, élection des dirigeants et objets de location; examiné le 26 juillet 2026. Kubernetes client go: élection du leader portée de la mise en œuvre et l'absence explicite d'une garantie de clôture pour un client actif unique; examiné le 26 juillet 2026. Apache Kafka: Producteur fondéException les derniers cas de production transactionnelle de clôtures précédentes; examiné le 26 juillet 2026.