Habr AI a Expliqué Comment Construire un Agent de Production avec Durable State, Étapes et Événements

Pour que les agents IA fonctionnent correctement en production, il ne suffit pas de garder tout en mémoire du processus : après un redémarrage, l'agent doit mémoriser exactement ce qu'a demandé l'utilisateur, quel plan a déjà été construit, quels outils ont été exécutés et où l'exécution s'est arrêtée. Dans la première partie d'une nouvelle analyse pratique sur Habr AI, l'auteur propose de construire cet état persistant autour de trois entités de base — tour, étape et événement — et explique pourquoi, sans elles, les longs scénarios d'agents se transforment rapidement en un pipeline opaque et fragile. Le point de départ est simple : si un agent ne stocke l'état qu'en mémoire, toute défaillance de service annule la tâche.

Pour une démo c'est acceptable, mais un agent de production peut analyser des documents, attendre la confirmation de l'utilisateur et exécuter une longue chaîne d'actions, donc après une défaillance il doit se rétablir à partir d'une base de données, non à partir de fragments d'un prompt. Comme ensemble minimal d'entités persistantes, l'auteur énumère AgentTurn, AgentPlanItem et AgentEvent, et note également que ApprovalGrant, SessionContext et BackgroundJob apparaissent presque inévitablement à proximité. L'idée est que l'état persistant décrit non seulement la réponse finale, mais le chemin entier vers elle : la demande originale, la commande normalisée, les drapeaux de confirmation, les statuts d'exécution et les erreurs possibles.

AgentTurn dans ce schéma est un enregistrement complet d'un tour utilisateur. Il stocke un identifiant de session et turn_id, le texte du message, la commande normalisée et le statut de traitement comme created, planned, awaiting_approval, running, completed ou failed. Il est important que le tour capture à la fois le output_text final et l'erreur, en cas d'échec de l'exécution.

Cela supprime la dépendance critique de la « mémoire » du modèle : le backend peut déterminer à tout moment ce qui s'est exactement passé avec la demande, même si le processus a été redémarré. Pour les tâches longues c'est particulièrement important car une seule demande aboutit rarement à un seul appel du modèle — plus souvent elle implique une chaîne de lectures de fichiers, d'invocations d'outils, de vérification et de préparation des résultats. La couche suivante est AgentPlanItem, c'est-à-dire une étape individuelle dans un tour.

Si un utilisateur demande d'analyser un projet et de préparer un rapport, l'agent peut décomposer la tâche en plusieurs actions : trouver des documents, lire les fichiers pertinents, vérifier les données et assembler la réponse finale. Pour chaque étape il est proposé de stocker son propre item_id, numéro d'ordre, nom de l'outil, arguments, mode de confirmation et statut. L'article souligne particulièrement que les modes safe_readonly, confirm_once et mutating sont nécessaires non pour l'apparence : ils permettent de pré-diviser les opérations de lecture sûres, les actions à confirmation unique et les mutations potentiellement dangereuses.

En résultat, le système sait non pas juste « l'agent fait quelque chose, » mais quel outil exact doit démarrer ensuite, ce qui est déjà terminé, ce qui peut être retryé et où l'exécution s'est bloquée. La troisième entité obligatoire est AgentEvent, c'est-à-dire une chronologie de ce qui se passe. Ce sont précisément les événements qui transforment un tour d'une boîte noire en un système observable.

Au lieu d'un seul état vague, le frontend peut lire turn_started, tool_started, tool_progress, tool_completed, approval_requested, tool_failed et turn_completed, puis afficher une progression claire. L'exemple du texte est concret et donc utile : l'agent exécute collect_documents, trouve 12 documents, puis lors de l'étape analyze_documents signale la progression 40 sur 100, et en cas d'échec écrit timeout du service externe et marque l'erreur comme retryable. Pour l'utilisateur cela signifie une UX normale au lieu d'un infini « l'agent réfléchit, » et pour l'équipe de développement — la capacité à déboguer le pipeline, mener des audits, analyser les incidents et récupérer les tâches après redémarrage sans reconstruction manuelle de l'historique.

La conclusion principale du matériel Habr AI est qu'un agent de production en 2026 n'est pas un prompt chanceux avec un wrapper, mais un système avec état et un journal d'exécution. Si un agent n'a pas d'état persistant au niveau du tour, de l'étape et de l'événement, il survit mal aux défaillances, est opaque pour l'interface et est presque impossible à maintenir. Ce qui signifie que le prochain stade de l'évolution des applications d'agents réside moins dans de nouveaux modèles que dans la discipline de l'architecture backend : dans comment nous capturons l'état, contrôlons les approbations et transformons le travail du modèle en un processus opérationnel reproductible.