Agents temporaires AI: Exécution durable séparée de l'agent Santé

Temporal est une réponse solide à un problème d'agent dur: comment garder une exécution de longue date récupérable lorsque les travailleurs s'écrasent, les processus redémarrent ou une dépendance externe échoue? Il ne s'agit pas, en soi, d'une réponse à une autre question: L'agent est il sain et a t il produit le résultat demandé par l'utilisateur? Le défaut sécurisé est d'utiliser l'état Temporal Workflow comme preuve d'exécution, puis d'ajouter quatre reçus de demande avant d'attribuer un verdict de santé: 1. un reçu de progression montrant une étape importante ou un delta de sortie; 2. un reçu wait portant le nom du propriétaire, la date limite et la condition de représailles; 3. un reçu effect permettant de déterminer si une action du côté de l'outil s'est produite; 4. un reçu delivrable vérifiant l'artefact ou l'état requis. Cette distinction est importante car le Documentation d'exécution du flux de travail de Temporal définit Running comme étant capable de progresser tout en progressant activement ou en attendant quelque chose . Un flux de travail ouvert et vert ne peut donc pas distinguer un travail productif, une attente légitime d'approbation ou un arrêt silencieux. De même, un flux de travail Completed fermé prouve que son code a atteint un chemin d'achèvement; il ne prouve pas automatiquement qu'une facture a été envoyée une fois, qu'une demande de retrait contient les modifications prévues ou qu'un rapport existe à la destination promise. Ce que Temporal prouve et ce qu'il ne prouve pas Le modèle d'exécution durable de Temporal offre à un agent AI de précieuses garanties mécaniques. L'état du flux de travail persiste en cas d'échec. Les contrôles de répétition génèrent des commandes contre l'historique des événements. Les activités isolent les appels vulnérables à l'échec tels que les demandes LLM, l'utilisation d'outils et les API externes du code d'orchestration déterministe. L'explication officielle de les agents AI dynamiques sur Temporal rend cette limite explicite: l'orchestration du flux de travail doit être déterministe, tandis que les décisions et les résultats des outils de LLM peuvent rester non déterministes à l'intérieur des activités. Ces propriétés répondent à plusieurs questions opérationnelles: L'état d'orchestration enregistré peut il survivre à un redémarrage des travailleurs ? Le flux de travail peut il reprendre à partir de son historique enregistré au lieu de recalculer chaque décision LLM antérieure? Une activité est elle encore réessayée, terminée, échouée ou complète? Le flux de travail est il ouvert, interrompu, annulé, terminé, échoué, résilié ou terminé? Ils ne répondent pas à quatre questions spécifiques à l'agent: Le plan s'est il rapproché de l'objectif de l'utilisateur, ou la boucle est simplement active? Une pause est elle attendue, appropriée et réalisable? Y a t il eu un effet secondaire externe, en particulier après une pause ou un accident de travail? Le produit final existe t il et répond il à une vérification déterministe de l'acceptation? Ce n'est pas une critique de Temporal. C'est une limite de responsabilité. Le Implementation de l'agent AI de la communauté temporaire démontre une boucle d'agent, des appels à l'outil, une confirmation humaine, des signaux, une gestion de l'état et des tests à l'intérieur d'un flux de travail. Ses propres notes évoquent également une longue histoire de conversation, une nouvelle visibilité et des considérations de stockage de production. La sémantique des applications appartient toujours à l'application. Mettez quatre reçus au dessus de l' état du flux de travail Un reçu compact peut être beaucoup plus petit qu'une transcription. Il devrait exposer des preuves, de la fraîcheur et de l'identité sans télécharger des instructions, des charges utiles d'outils ou des secrets. Le reçu d'avancement doit décrire une étape importante de la demande, pas seulement un timestamp. Les documents temporaires Activité Les battements cardiaques sont un moyen pour un travailleur de signaler son état de santé et ses progrès, de conserver les détails des progrès pour une nouvelle tentative et de recevoir l'annulation. Ce transport est utile, mais la charge utile doit contenir un delta significatif: compte des enregistrements traités, ensemble de sources vérifiés, identifiants de branches complétés, digestion d'artefact ou autre invariant spécifique à la tâche. Un agent peut émettre un nouvel timestamp pour toujours tout en répétant le même appel raté. Le reçu d'attente empêche l'erreur opposéepaging une pause humaine saine dans la boucle comme un arrêt. Exigez trois champs: owner : la personne ou le système capable de résoudre la dépendance; deadline : lorsque l'attente devient tardive; resumeToken : le signal, la mise à jour, l'identifiant d'approbation ou une autre identité qui reprend le même travail. L'absence de l'un des trois rend l'attente opérationnellement incomplète. Attention à l'approbation sans propriétaire est un travail abandonné. Un propriétaire sans échéance peut disparaître indéfiniment. Un délai sans identité de CV invite à une continuation dupliquée ou déroutée. La réception de l'effet est nécessaire car les activités peuvent être retenues. Le Guide de gestion des erreurs Python de Temporal décrit les activités comme étant au moins une fois et recommande l'idempotence: un travailleur peut effectuer une action externe et s'écraser avant l'achèvement des dossiers de service. Pour un agent, les états critiques sont none , attempted , verified et unknown . Unknown n'est pas autorisé à réessayer. Concilier d'abord l'identifiant d'exploitation stable avec la destination. Le reçu de livraison ferme l'écart à l'autre bout. Il devrait lier le flux de travail et exécuter l'identité à un contrôle déterministe: digest de fichier, version de base de données, ID de ressource HTTP, engagement fusionné, résultat de test ou verdict d'acceptation structurée. Un message done en langage naturel est la preuve d'une affirmation, pas la preuve du résultat. Une expérience de six cas L'appareil inspectable utilisé pour cet article évalue six courses avec une règle déterministe: L'état du flux de travail seul réduirait les quatre premiers cas en RUNNING et les deux derniers en COMPLETED . Les reçus modifient la décision de l'exploitant: Le cas de l'accusé Des preuves décisives Action sûre Travail Récemment, une étape importante a été changée. Laissez le tranquille. J'attends propriétaire, échéance, jeton de résumé route ou attendre la date limite Je suis coincé. Aucun delta récent et aucune attente valide enquêter, puis préparer une récupération limitée Effets incertains l' identifiant d' opération stable n' a pas de verdict de destination réconcilier; ne réessayez pas Faux succès Flux de travail terminé mais manquant de livrables réouvrir l'incident Completement sain l'achèvement, l'effet et l'accord de livraison Fermez avec des preuves. La règle est intentionnellement conservatrice. Il n'utilise pas de juge LLM lorsqu'une vérification déterministique est disponible. Il préserve le uncertain lorsque les preuves ne sont pas d'accord. Il évite également de "fixer" chaque pause: une attente valide reste une attente, pas un échec. Réessayer d'exploiter et de longues histories sans faux vert Temporal gère la mécanique de retrait, mais l'application possède toujours le budget de retrait et la limite d'effet. Pour chaque activité externe, portez un identifiant d'exploitation stable à travers les tentatives. Enregistrez le verdict d'idempotence de la destination quand il sera disponible. Séparer la défaillance transitoire du transport de la défaillance permanente de l'entrée, et arrêter lorsque la date limite de conduite restante ne peut pas accueillir une autre tentative plus la réconciliation et la vérification des livraisons. Pour les activités longues, combinez trois signaux différents: Activité fraîcheur du cœur: le travailleur a t il communiqué récemment? fraîcheur de l'étape: l'état d'application utile a t il changé? budget de tentative et de délai: la nouvelle tentative actuelle est elle encore autorisée et en mesure d'être terminée? Un nouveau battement cardiaque avec un jalon inchangé peut être une boucle. Un battement cardiaque obsolète avec un reçu de destination récent peut être un échec de signalement incertain. Une attente exponentielle peut être saine si son temps de veille et son budget sont explicites. Aucun timestamp ne mérite un verdict vert. La croissance de l'histoire est une autre frontière. Le document Flux de travail Limits d'exécution dur d'historique d'événements actuel limite 51 200 événements ou 50 Mo, avec des avertissements à 10 240 événements ou 10 Mo. Ne convertissez pas ces valeurs datées en constantes universelles; vérifiez la documentation actuelle et votre déploiement. Le modèle durable consiste à conserver des données de conversation volumineuses en dehors de l'historique du flux de travail lorsque cela est approprié, à conserver des identités et des invariants minimisés par le contenu et à utiliser Continuer Comme Nouveau avant que la pression de l'historique ne devienne une panne. Cela crée une division pratique du travail: Temporal préserve et reprend l'état d'orchestration. La demande d'agent définit les étapes, l'attente de la propriété, la réconciliation des effets et les contrôles d'acceptation. Une couche de santé face à l'opérateur relie les deux ensembles de preuves et montre l'incertitude plutôt que d'inventer un verdict. Gardez la santé séparée de l'orchestration Pour un agent Temporal AI, l'exécution durable est la base, pas le score de santé final. La reproduction peut restaurer les décisions enregistrées après un accident. Les tentatives de réactivité peuvent récupérer les défaillances transitoires. Les signaux et les mises à jour peuvent porter des décisions humaines. Aucune de ces mécanismes ne devrait être étendue à une affirmation selon laquelle l'agent progresse, qu'un effet secondaire s'est produit exactement une fois, ou que le résultat de l'utilisateur est présent. Commencez par les quatre reçus. Faites les petits, frais et liés à workflowId , runId et à des identités d'exploitation stables. Testez les six états inconfortables avant la production. Si votre tableau de bord ne peut pas afficher séparément waiting , stuck , uncertain et false success , il cache les décisions qu'un opérateur doit réellement prendre. La limitation est sémantique: chaque flux de travail doit définir son propre jalon significatif et son propre contrôle de livrabilité. Un agent de vérification des sources et un agent de paiement ne peuvent pas partager le même prédicat d'acceptation. Quand il n'y a pas de vérification déterministe des résultats, étiquettez le jugement et sa confiance; ne le convertissez pas silencieusement en fait. Sidewisp est actuellement en préversion privée. Sa direction de produit est une couche de santé de l'agent AI, mais un adaptateur Temporal de production et la collection de santé de l'agent vivant ne sont pas présentés ici comme des capacités expédiées. L'avantage à court terme est indépendant de tout produit: conserver les preuves de durabilité de Temporal, ajouter les quatre reçus de demande et exiger qu'ils soient d'accord avant de qualifier un agent de sain.