Observabilité de l'agent à travers les redémarrages: le modèle de réception de livraison

L'observabilité de l'agent répond généralement à ce qui s'est passé à l'intérieur d'une course. C'est utile, mais ce n'est pas suffisant quand un agent délègue le travail, quitte, redémarre ou attend un autre agent. La solution pratique est un reçu de remise durable : un petit enregistrement écrit en dehors de l'un ou l'autre processus qui indique qui a accepté le travail, quelles sont les conséquences attendues et quelles sont les preuves qui le feront clore. Gardez les traces pour débogage. Ajoutez des reçus pour la continuité. Une trace peut montrer qu'un outil de remise a été retourné avec succès; le reçu indique à l'opérateur si le destinataire a accepté la tâche et si l'artefact promis a été vérifié ultérieurement. La réponse courte: observez la limite, pas seulement la course Une remise en main n'est saine que si quatre événements différents peuvent être distingués: 1. l'expéditeur a délégué une tâche limitée; 2. le bénéficiaire a reconnu la même tâche; 3. des progrès utiles ou une attente légitime ont été enregistrés; 4. le résultat attendu a été vérifié. Ces événements peuvent se produire dans des processus et des traces différents. Ils peuvent être séparés par un retard de file d'attente, un redémarrage de l'hôte ou une approbation humaine. Les traiter comme une seule période de mémoire crée une dépendance fragile: le contexte qui explique le travail peut disparaître avec le processus. OpenTelemetry décrit la propagation du contexte en tant que mécanisme permettant d'assembler des spans de différents processus en une trace. Il fournit également des liaisons d'espace pour les opérations asynchrones causellement liées où le travail ultérieur ne peut pas être une simple étendue enfantine. Ça résout la corrélation. Il ne définit pas les règles de promesse, d'acceptation ou de vérification des résultats de votre demande. Le reçu comble ce vide. Il est délibérément plus petit qu'une transcription et plus explicite qu'une ligne de journaux. Là où une trace ordinaire cesse d' aider Prenons l'exemple d'un agent de recherche qui remet une tâche de vérification des sources à un autre employé. L'expéditeur enregistre un handoff réussie et des sorties. Dix minutes plus tard, le travailleur commence un nouveau processus, trouve une source inaccessible et attend l'approbation pour utiliser une alternative. Trois États peuvent maintenant sembler trompeusement similaires: la tâche est toujours en file d'attente et n'a jamais été acceptée; le travailleur l'a accepté et l'attend légitimement; le travailleur a effectué une commande mais n'a jamais présenté le dossier de preuve demandé. L'espace qui a enveloppé la livraison ne peut pas décider entre eux. Sa fin réussie signifie que l'opération de remise est retournée sans erreur. OpenTelemetry explique explicitement que le statut de span décrit l'opération suivie par cette span. Ce n'est pas la preuve qu'un résultat commercial ultérieur existe. Le SDK OpenAI Agents illustre la même frontière d'une autre direction. Il est enregistrements de suivi intégrés des courses, des appels à l'outil, des remises, des barreaux et des événements personnalisés. Un group id peut associer plusieurs traces, et un handoff span peut montrer la délégation. Le SDK note également que l'exportation de traces est en lot et peut exiger une mise en cache explicite lorsqu'il s'agit d'une livraison immédiate. Le suivi riche améliore les preuves disponibles pour le débogage; il a encore besoin d'une règle externe pour l'inspection réussie des livraisons. C'est pourquoi l'observabilité de l'agent ne devrait pas faire tomber la fin de commande en fin de résultat. Un contrat de réception de remise minimale Conservez un seul enregistrement en annexe par transition d'état. Le stockage peut être une table de base de données, un journal de file d'attente durable ou un fichier NDJSON sur un seul hôte. La propriété importante est qu'aucun processus participant ne possède la seule copie. Voici une forme compacte de l'événement: Six champs contiennent la plupart de la valeur: operation id est l'identité durable du travail visible à l'utilisateur. Il survit à des tentatives de redémarrage. handoff id identifie une tentative de délégation. Une nouvelle tentative obtient une nouvelle pièce d'identité au lieu de supprimer l'histoire. Le event est l'un des delegated , accepted , progress , waiting , completed ou outcome verified . expected artifact désigne une cible de vérification déterministe. Il peut également nommer un test, une condition API ou une décision de révision. trace id renvoie à la télémétrie détaillée sans faire dépendre le reçu de cette télémétrie. reason explique une attente, un refus ou une défaillance de vérification en termes opérationnels limités. Ne mettez pas d'instructions, de références, de modèles ou de charges utiles d'outils bruts dans cet enregistrement. Un reçu est un index et une machine d'état, pas un second backend de traçage. Le défaut raisonnable est les transitions à ajouter uniquement plus un statut courant dérivé. La mise à jour d'une ligne changeante est tentante, mais elle détruit les preuves nécessaires pour distinguer une reconnaissance retardée d'une ligne manquante. Reproduire les cas de défaillance avant de choisir les alertes L'appareil d'accompagnement de cet article contient quatre opérations: une remise vérifiée, une délégation non reconnue, une attente légitime d'approbation et une finition fausse sans objet vérifié. Le classifiant est intentionnellement déterministe. Faites le avec: Le résultat attendu est le suivant: Deux observations tombent à l'extérieur de ce petit test. Premièrement, la latence de la reconnaissance et la vérification des résultats sont indépendantes. Le op 101 peut être accepté rapidement et échouer plus tard; le op 102 est déjà malsain avant le début d'un appel de modèle ou d'une exécution d'outil. Un tableau de bord centré sur les traces qui commence à l'exécution du destinataire ne verra pas l'orphelin. Deuxièmement, l'attente a besoin d'une dépendance déclarée. op 103 n'a pas de progrès récent, mais le traiter comme bloqué serait faux parce que le reçu nomme l'approbation dont il a besoin. L'absence d'activité ne devient actionable que si elle est combinée à l'état et à l'attente. La limite de reconnaissance de 120 secondes dans le dispositif est un exemple et non un seuil universel. Définir la latence de livraison observée dans la file d'attente et l'urgence de la tâche. Le travail en série peut tolérer des minutes; une remise en main interactive peut tolérer des secondes. L'invariable est la transition, pas le nombre. Préserver la causalité sans transformer les métadonnées en fuite Utilisez l'identifiant de trace comme indicateur et propagez uniquement les identifiants dont les travailleurs en aval ont réellement besoin. OpenTelemetrys Guide des bagages prévient que le bagage est généralement envoyé dans des en têtes HTTP, peut atteindre des tiers non intentionnés et n'a pas de contrôles d'intégrité intégrés. Cela rend les objectifs bruts, le texte client, les itinéraires du système de fichiers et les informations d'identification des valeurs de propagation particulièrement médiocres. Une frontière plus sûre ressemble à ceci: propagent un operation id et un handoff id opaques; créer une liaison entre la trace de réception et la trace de délégation lorsque la durée de fonctionnement la supporte; conserver l'artéfact expected et l'état d'approbation dans un stockage durable fiable; résoudre les identifiants dans un contexte sensible uniquement à l'intérieur de la limite de l'hôte autorisé; authentifier les rédacteurs des reçus, car les métadonnées de corrélation ne sont pas une preuve d'identité. Il y a un compromis. Un reçu minimal ne peut expliquer pourquoi un modèle a choisi un outil ou reconstruire une conversation entière. C'est délibéré. Utilisez des traces et des journaux pour des enquêtes détaillées, sous réserve de vos règles de conservation et de confidentialité. Utilisez les reçus pour répondre de manière fiable à une petite question opérationnelle: la responsabilité a t elle évolué et le résultat promis a t il été observé? Transformer les reçus en état d'exploitant Évitez un seul statut rouge ou vert. L'historique des reçus soutient cinq états avec des réponses différentes: Working : accepté avec des progrès utiles récents. Ne l'interrompez pas. Waiting : une dépendance externe nommée ou une décision humaine est en suspens. Routez la demande au lieu de réessayer. Stuck : accepté, non attendu et aucun progrès utile dans la fenêtre de preuve de la tâche. Préparez une récupération limitée. Uncertain : les dossiers ne sont pas d'accord, l'auteur n'est pas digne de confiance ou les preuves requises ne sont pas disponibles. Demandez avant d'agir. Résultat raté : l'exécution a été terminée, mais la vérification de l'artefact a échoué ou n'a jamais eu lieu. Réouvrir le résultat, pas toute la trace. Les limites de récupération comptent. Une remise orpheline peut justifier une nouvelle livraison si l'action est impotente et que la limite de réessayer est connue. Une remise en attente ne doit pas être réessayée simplement parce que le chronomètre a expiré. Un état de faux succès devrait exécuter le vérificateur manquant ou demander l'artefact manquant; la reproduction de l'ensemble de l'agent peut dupliquer les effets secondaires. Pour chaque réponse automatisée, enregistrer l'autorité, les tentatives maximales, le coût ou la limite de temps, et les preuves qui marqueront la récupération comme réussie. La commande de retrait est sortie de zéro n'est pas suffisante lorsque la promesse initiale était un rapport publié, un changement fusionné ou un message livré. Ce que cela signifie pour Sidewisp Ce modèle de réception correspond aux questions opérationnelles que Sidewisp est conçu pour clarifier: un agent travaille, attend, est coincé, incertain ou manque de son résultat promis. Elle respecte également une limite de produit nécessaire: le diagnostic précède tout rétablissement et les actions qui en découlent nécessitent une autorité explicite. Sidewisp est actuellement en préversion privée. Son site public et son système d'articles sont en direct, tandis que la collecte des agents de production, les adaptateurs de temps d'exécution et la récupération automatisée ne sont généralement pas expédiées. Le modèle ci dessus est donc un design neutre en fonction du temps d'exécution que vous pouvez mettre en œuvre et tester aujourd'hui, et non une affirmation selon laquelle Sidewisp recueille déjà ces reçus. Si les envois croisés deviennent opaques, rejoignez l'aperçu privé et décrivez le temps d'exécution, le stockage des reçus et la limite d'approbation dont vous avez besoin. Cette preuve est plus utile qu'une demande générique de plus de traces.