Agents de longue durée : points de reprise, récupération et idempotence
Pour un agent qui travaille plusieurs heures, la difficulté est souvent de savoir ce qui s'est déjà produit après un redémarrage, un délai dépassé ou une compression du contexte. Un contexte plus grand et une boucle plus longue ne remplacent pas un état de tâche enregistré.
Les boucles d'agent expliquent observation, action et vérification. Cette page traite de la reprise entre processus et des effets externes.
Séparer état de tâche et conversation
La conversation conserve les échanges. L'état récupérable doit aussi préciser objectif, contraintes, actions en attente, résultats confirmés, échecs, budget restant et conditions d'arrêt. Un « terminé » rédigé par le modèle ne prouve rien : il faut un artefact consultable, un résultat d'outil ou une vérification.
Un point de reprise capture cet état à un instant donné. La persistance de LangGraph distingue les instantanés d'un fil d'exécution du stockage partagé entre fils ; elle rappelle que les points en mémoire disparaissent au redémarrage. Un résumé aide le prochain appel du modèle, mais ne doit pas être la seule preuve d'une action externe.
Pour une tâche documentaire fictive — lire, rédiger, enregistrer puis notifier — l'état peut conserver version du brouillon, identifiant de l'écriture et accusé de réception du service de notification. La reprise n'a plus à deviner la dernière étape réussie dans des milliers de lignes.
La faille : exécuté mais non enregistré
Supposons que le service de notification accepte une requête, mais que le client dépasse son délai avant la réponse. Réessayer faute de succès local peut envoyer deux notifications. Enregistrer le succès avant l'envoi crée la faille inverse : un plantage peut laisser une notification jamais envoyée marquée comme terminée.
Un point local et un service distant quelconque ne constituent pas automatiquement une transaction atomique. Le modèle d'exécution des activités Temporal sépare travail externe réessayable et progression du workflow ; l'application doit encore définir le sens d'une répétition. Une infrastructure persistante ne garantit pas, à elle seule, que tous les effets auront lieu exactement une fois.
Identifier l'action logique, pas la tentative
Répéter une opération idempotente n'ajoute pas d'effet supplémentaire. Fixer un fichier à une version donnée se réessaie plus facilement que lui ajouter un paragraphe. Si l'API accepte une clé d'idempotence, toutes les tentatives de la même action doivent la réutiliser, plutôt que créer un nouvel UUID.
Associer cette clé à la tâche, à l'étape et à l'empreinte du contenu. Modifier destinataire ou texte crée une nouvelle action logique ; réutiliser l'ancienne clé peut renvoyer l'ancien résultat. Le destinataire doit refuser une même clé avec des paramètres différents.
Ce pseudocode simplifié côté réception montre les opérations qui doivent partager une transaction :
begin transaction
if operation_key exists:
reject if stored_payload_hash differs
return stored_result
apply the local business change
store operation_key, payload_hash, result
commit transaction
Si l'effet métier se produit dans un autre service, cette transaction locale reste insuffisante. Il faut une idempotence distante, un identifiant métier interrogeable, ou un mécanisme de livraison tel qu'un outbox transactionnel. Un résultat non confirmé reste inconnu, plutôt qu'automatiquement considéré comme un échec.
Reprendre ne signifie pas tout rejouer
Lire le dernier état confirmé et les artefacts externes avant de choisir la suite. Réutiliser les résultats de génération conservés quand cela convient : rappeler le modèle peut changer le texte et les actions suivantes. Des modifications de code, de schéma d'outil ou d'entrée demandent aussi de décider si l'ancien point reste compatible. L'exécution des workflows Temporal décrit une récupération à partir de l'historique ; séparer calcul rejouable et entrées-sorties externes est essentiel.
Traiter chaque échec selon sa cause. Une erreur réseau transitoire peut justifier des reprises espacées et limitées ; des arguments invalides demandent une correction ; des permissions absentes ne se résolvent pas en réessayant ; une attente longue exige une échéance. Propager l'annulation aux outils actifs tout en conservant les effets déjà réalisés. Arrêter le travail futur n'annule pas le passé.
Relier reprise et compression du contexte
L'instantané garde une progression exploitable par la machine ; le résumé explique au modèle comment poursuivre. Ils peuvent être mis à jour ensemble. Le résumé conserve objectif, décisions acceptées, hypothèses non vérifiées et positions des artefacts. Les gros résultats d'outils restent stockés, tandis que seuls leurs passages utiles reviennent dans le contexte. Voir l'ingénierie du contexte.
La fin dépend de l'objectif. « Brouillon enregistré et citations vérifiées » diffère de « utilisateur notifié ». Réussir l'un ne doit pas masquer l'autre par un statut global. Budget épuisé, attente d'une entrée externe et objectif atteint demandent également des états distincts.
Un test utile interrompt avant l'écriture, après l'écriture mais avant son enregistrement, puis après celui-ci. Vérifier exactitude de l'artefact, absence de duplication et résolution des résultats inconnus. Des fichiers locaux et services simulés permettent ces essais sans envoyer plusieurs vrais messages.