Pourquoi les agents d’IA domestiques oublient-ils les actions terminées après le redémarrage d’un service ?
Les agents IA domestiques oublient les actions terminées après un redémarrage lorsque leur plan, les résultats des outils et les marqueurs d’achèvement n’existent que dans la mémoire volatile du processus.
Un agent peut mettre à jour un fichier, créer un événement, redémarrer un conteneur ou terminer une partie d’un traitement par lots, puis perdre cette information lorsque son service est redéployé ou tombe en panne. L’effet externe peut subsister, tandis que la conversation avec le modèle, le compteur de boucle, le plan en attente et l’objet contenant le résultat de l’outil disparaissent. Après son démarrage, l’agent peut répéter le travail ou supposer que rien ne s’est produit. Une récupération fiable nécessite d’enregistrer l’état d’exécution à des points de contrôle reliant l’intention, l’appel d’outil, le résultat observable et l’étape suivante non terminée.
L’historique des conversations n’est pas un état de workflow durable
Une transcription de discussion peut contenir la demande de l’utilisateur et le récit de l’agent, mais elle n’indique pas nécessairement quels effets de bord ont été validés, quels enregistrements ont été ignorés ou quelle branche doit reprendre.
Le guide d’Augment Code sur l’état persistant des workflows sépare l’exécution de longue durée d’un processus unique ou d’une requête synchrone.
L’agent a besoin d’un état structuré comprenant notamment l’ID de la tâche, l’étape actuelle, les opérations terminées, les hachages des résultats des outils, les approbations en attente et le nombre de nouvelles tentatives. Régénérer cet état à partir d’une conversation en langage naturel après un redémarrage est ambigu.
Les appels d’outils terminés nécessitent une limite de validation durable
Un outil peut réussir au niveau externe avant que l’agent n’écrive son marqueur local d’achèvement. Un redémarrage pendant cet intervalle laisse l’action effectivement réalisée, mais l’agent n’en a pas connaissance.
Zylos décrit des limites d’exécution durables qui préservent le travail terminé avant de poursuivre la récupération.
Une limite fiable enregistre l’ID de l’opération et son résultat dans un stockage durable, ou utilise un service transactionnel unique capable de valider simultanément l’effet de bord et l’enregistrement d’achèvement.
Lorsque la validation atomique est impossible, l’outil doit proposer une consultation d’état afin que l’agent redémarré puisse vérifier les résultats incertains.
Un instantané seul peut ne pas suffire à reconstruire une exécution sûre
Enregistrer les messages du modèle ou l’état sérialisé d’un graphe consigne ce que l’agent croyait à un moment donné. Cela ne garantit pas automatiquement que les appels externes ne seront pas dupliqués lors de la relecture.
Diagrid distingue les points de contrôle applicatifs des runtimes qui prennent en charge les nouvelles tentatives, l’historique des événements et l’achèvement des effets de bord.
La conception de la récupération doit définir quel code est déterministe, quels appels d’outils peuvent être rejoués et quels résultats doivent être lus dans l’historique plutôt que réexécutés.
Sinon, un point de contrôle correct peut tout de même reprendre sur un message dupliqué, un déplacement de fichier répété ou une seconde commande envoyée à un appareil.
Des identités stables pour les exécutions et les étapes évitent de démarrer accidentellement une nouvelle tâche
Après un redémarrage, un nouvel ID de conversation ou d’exécution peut faire passer le même objectif utilisateur pour une nouvelle tâche. L’agent ne dispose alors d’aucune clé pour retrouver son ancien état.
Inference.sh explique comment l’identité durable d’une exécution permet à un agent de reprendre depuis le dernier point de contrôle terminé.
Conservez l’ID du workflow en dehors du conteneur et associez-le à l’utilisateur, à la tâche, au périmètre des données et aux autorisations. La découverte de services et l’équilibrage de charge ne doivent pas créer une nouvelle exécution logique simplement parce qu’un autre worker reçoit la requête.
Les étapes terminées doivent être réutilisées plutôt que réinterprétées
Réexécuter les anciens appels au modèle peut produire un plan différent, des arguments d’outil différents ou une interprétation différente du travail déjà terminé.
L’article de Pydantic sur le runtime indique que les points de contrôle terminés restent terminés, tandis que la récupération ne réexécute que la limite en échec.
Cela réduit le coût en jetons et empêche un agent redémarré d’inventer un second parcours dans des systèmes domestiques déjà modifiés.
Les résultats stockés doivent contenir suffisamment d’éléments pour vérifier que la sortie de l’outil correspond toujours à l’état actuel de la cible.
L’idempotence et la réconciliation protègent la récupération contre les effets dupliqués
L’état durable peut tout de même avoir une étape de retard sur le système externe. Les ID d’opération, les clés d’idempotence, les vérifications d’état et les actions compensatoires permettent de gérer cette incertitude.
Le guide de Restate consacré aux boucles d’agents résilientes conserve l’état des itérations entre les redémarrages et permet une poursuite contrôlée.
L’article de ZimaSpace sur l’automatisation répétable sans risque montre pourquoi viser un état final souhaité est plus sûr que de rejouer aveuglément des commandes additives.
Lorsque l’action ne peut pas être rendue idempotente, l’agent redémarré doit vérifier l’état actuel ou s’arrêter pour demander une vérification, plutôt que de supposer qu’une entrée locale manquante signifie un échec.
Les tests de redémarrage doivent couvrir chaque fenêtre de défaillance
Arrêtez le service avant un appel d’outil, pendant l’appel, après l’effet externe, après le point de contrôle local et pendant l’attente d’une approbation. Chaque redémarrage doit produire une reprise prévisible.
DBOS décrit une exécution résistante aux pannes pour les workflows comprenant des API et des interactions humaines.
Vérifiez que les actions terminées sont réutilisées, que les actions incertaines sont réconciliées, que les actions en attente le restent et qu’aucune autorisation n’est régénérée silencieusement.
L’agent ne se souvient du travail terminé que lorsque la progression est enregistrée sous forme de preuves opérationnelles durables, et non simplement comme du texte conservé par l’ancien processus.
FAQ
L’enregistrement de la transcription de discussion suffit-il ?
Non. La transcription peut omettre les ID d’opération, les effets de bord validés, l’état des nouvelles tentatives, les approbations et la limite précise à partir de laquelle l’exécution doit reprendre.
L’agent doit-il rejouer chaque appel d’outil après un redémarrage ?
Non. Les appels terminés doivent être réutilisés depuis l’historique durable, tandis que les appels incertains nécessitent une idempotence ou une réconciliation avant toute nouvelle tentative.
Un point de contrôle dans une base de données peut-il empêcher toute action dupliquée ?
Non. Il doit être coordonné avec l’effet de bord externe. Une panne entre l’effet et le point de contrôle crée toujours un résultat incertain.
Produits recommandés
Centre Tech & IA
Plus à lire
Quelles fonctionnalités permettent de créer une frontière de confiance pour l’IA domestique autour des fichiers sensibles ?
Une frontière de confiance pour l’IA à domicile combine le chiffrement des données au repos, des autorisations selon le principe du moindre privilège, un...
Pourquoi les résultats de recherche privés privilégient-ils les fichiers fréquemment modifiés ?
Les fichiers fréquemment modifiés bénéficient d’un meilleur classement lorsque chaque mise à jour ajoute des signaux de fraîcheur, des segments, des versions ou des...
Qu’est-ce qui pousse les modèles de détection de présence pour maison intelligente à confondre les invités avec les résidents ?
Les invités peuvent être pris pour des résidents lorsque le système observe des habitudes d’activité du foyer, mais ne dispose d’aucun signal d’identité stable...
