En quoi cela diffère-t-il de l'ajout d'un bloc try/except et d'une boucle de tentative ?

Le bloc try/except gère une seule erreur ; une stratégie de récupération détermine le type de défaillance et choisit entre la tentative, la solution de secours, l'annulation et l'escalade sous des budgets stricts. C'est la logique de contrôle et l'idempotence qui en constituent l'essence, et non la gestion des exceptions.

Combien de tentatives dois-je autoriser ?

Peu — généralement une petite limite fixe avec un backoff exponentiel et du jitter, plus des plafonds de temps et de coût distincts. Le nombre exact dépend de la dépendance, mais la boucle doit toujours se terminer, et les défaillances permanentes ne doivent pas faire l'objet de tentatives.

Que se passe-t-il si une action ne peut pas être annulée ou rendue idempotente ?

Ne lancez pas de tentative automatique sur cette action. Créez un checkpoint avant l'étape irréversible et, en cas d'échec, escaladez vers un humain ou un agent superviseur plutôt que de deviner. L'irréversibilité est un signal pour ralentir, pas pour insister davantage.

FiabilitéMis à jour 2026-08-25 · Version 1.1

Stratégie de récupération

Donnez à l'agent un plan explicite en cas de panne. Détectez les défaillances en validant les sorties et en interceptant les erreurs des outils ; puis réessayez avec ajustement, basculez vers un chemin alternatif, annulez les actions partielles ou escaladez. Limitez les tentatives pour éviter les boucles infinies et les coûts, rendez les actions idempotentes et distinguez les défaillances transitoires des défaillances permanentes. L'objectif est une dégradation progressive plutôt que des plantages ou des résultats silencieusement erronés.

Preuve: ProductionConfiance: FaibleSource: Système de productionSource: Expérience personnelleSource: Observation du secteur

Lisible par machine: JSON

Problème

Les agents échouent constamment : les outils expirent, les API renvoient des erreurs, les modèles émettent des sorties malformées, les plans se retrouvent dans des impasses et les flux de travail multi-étapes laissent derrière eux des effets secondaires partiels. Sans chemin de récupération explicite, un agent soit plante à la première erreur, soit — pire encore — continue sur la base de données erronées et produit silencieusement des résultats faux avec assurance. Les boucles de tentative naïves aggravent la situation, pilonnant une dépendance défaillante, consommant des jetons et tournant indéfiniment. Le plus difficile n'est pas d'intercepter une erreur, mais de déterminer de quel type de défaillance il s'agit et quelle réponse est sûre.

Quand l'utiliser

Utilisez ce modèle dans tout agent qui appelle des outils externes, exécute des plans multi-étapes ou effectue des actions importantes où une exécution partielle est possible. Il est particulièrement crucial pour les flux de travail autonomes ou de longue durée qu'aucun humain ne surveille en temps réel, et pour les actions ayant des effets secondaires (paiements, écritures, e-mails) où une tentative aveugle pourrait dupliquer le travail. Il suppose que vous pouvez valider les sorties par rapport à un contrat et qu'au moins certaines opérations peuvent être rendues idempotentes ou compensées. Il est moins pertinent pour les prompts ponctuels, en lecture seule et à faibles enjeux.

Solution

Traisez la récupération comme une boucle de contrôle de premier ordre superposée à l'exécution normale de l'agent. Chaque appel d'outil et chaque sortie de modèle passe par une barrière de validation : interceptez les exceptions et les expirations de délai, et vérifiez les sorties par rapport à un schéma ou un contrat avant de leur faire confiance. En cas d'échec, classifiez-le. Les défaillances transitoires (expirations, limites de débit, 5xx) font l'objet d'une tentative limitée avec un backoff exponentiel et du jitter, idéalement sur une opération idempotente pour qu'une requête dupliquée soit sans danger. Les défaillances permanentes (arguments invalides, erreurs d'authentification, violations de contrat) ignorent les tentatives et passent directement à une alternative : un outil différent, un plan plus simple ou une réponse de secours. Lorsque la progression est importante, sauvegardez l'état (checkpoint) afin que l'agent puisse reprendre à partir de la dernière étape valide plutôt que de redémarrer. Lorsqu'une étape a déjà produit des effets secondaires et ne peut pas continuer, exécutez des actions de compensation pour annuler — annuler la commande, supprimer le brouillon, rembourser le débit. Enveloppez l'ensemble de la boucle dans des budgets stricts : nombre maximal de tentatives, temps d'exécution maximal et plafond de coût, plus un disjoncteur (circuit breaker) qui cesse d'appeler une dépendance qui échoue continuellement. Lorsque toutes les options de récupération sont épuisées, escaladez proprement — remontez la défaillance à un humain ou à un agent superviseur avec suffisamment de contexte pour agir, plutôt que de deviner.

Composants

Barrière de validationClassificateur de défaillancesTentative limitée avec backoffRouteur de secoursStockage de checkpointsGestionnaire de compensation

Avantages

L'agent produit un résultat partiel ou de secours et un statut clair au lieu de planter ou de renvoyer des données aberrantes avec assurance.
Les limites strictes de tentatives, de temps et de coût empêchent les boucles de tentative infinies de consommer le budget sur une dépendance défaillante.
Les actions de compensation et les checkpoints maintiennent la cohérence des systèmes externes et de l'état des tâches lorsqu'un flux de travail s'arrête à mi-parcours.
En cas d'échec de la récupération, l'agent passe la main avec suffisamment de contexte pour qu'un humain ou un superviseur puisse agir, plutôt que de deviner.

Risques

Des tentatives agressives contre une dépendance en difficulté augmentent la charge et peuvent transformer une brève anomalie en une panne en cascade.
Réessayer une action non idempotente peut entraîner une double facturation, un double envoi ou une double écriture si des clés de requête ne sont pas utilisées.
Des solutions de secours trop zélées peuvent masquer des défaillances systématiques, de sorte qu'un outil en panne semble sain tout en dégradant discrètement chaque résultat.
La logique d'annulation est souvent incomplète ou échoue elle-même, laissant les systèmes dans un état incohérent difficile à détecter.

Quand ne pas l'utiliser

Pour les prompts à faibles enjeux, sans effets secondaires et sans plan multi-étapes, une simple logique de tentative ou d'échec suffit ; un mécanisme complet de récupération est superflu.
Lorsqu'une défaillance signifie que la tâche est réellement impossible (autorisation manquante, API obsolète), les tentatives et les solutions de secours ne font que perdre du temps — échouez rapidement et escaladez.
Si un effet secondaire est irréversible et ne peut pas être rendu idempotent, ne lancez pas de tentative automatique ; exigez plutôt une confirmation ou une approbation humaine.

Technologies

Retries with backoffCircuit breakersCheckpointingCompensating actions

Exemples

L'outil de recherche d'un agent de recherche renvoie une erreur 503 ; l'agent réessaie avec un backoff, réussit à la troisième tentative et continue sans faire planter l'exécution.
Un agent de code génère du JSON qui échoue à la validation du schéma ; la barrière de validation le rejette et relance le prompt avec l'erreur, au lieu de transmettre des données malformées en aval.
Un agent de réservation réserve un vol mais l'étape de l'hôtel échoue définitivement ; le gestionnaire de compensation annule la réservation et escalade plutôt que de laisser un voyage à moitié réservé.

Preuves de production

Contexte: Déploiement OpenClaw mono-opérateur, local-first, observé sur 57 jours (161 sessions / 2 776 tours), agrégé à partir des traces de trajectoire de l'agent lui-même.
Scénario: Les erreurs, les abandons et les expirations de délai pendant les tours autonomes sont absorbés par des tentatives/backoffs et une chaîne de secours de modèles (model-fallback) afin que l'agent continue de fonctionner.
Technologie: retryAsync avec backoff exponentiel et jitter, runWithModelFallback, propagation d'abandon et autoprotection cron contre les boucles de redéclenchement.
Charge: 2 942 tours terminaux ; 52 erreurs, 126 abandons, 120 expirations de délai et 31 erreurs de prompt observées.
Résultats: Un taux d'erreur terminale de 1,77 % sur 2 942 tours ; les primitives de récupération ont absorbé les défaillances transitoires et le déploiement a maintenu un taux de réussite de session de 98,8 %. Déploiement mono-opérateur local-first.

KPI

Taux de réussite de la récupération: Part des défaillances résolues automatiquement par tentative ou secours sans intervention humaine ; une valeur saine est élevée et stable, sans dérive descendante silencieuse.
Nombre moyen de tentatives par tâche réussie: Nombre de tentatives nécessaires pour réussir ; surveillez toute augmentation progressive, qui signale une dégradation de dépendance plutôt qu'une véritable récupération.
Taux de boucle infinie / dépassement de budget: Fréquence à laquelle les exécutions atteignent les plafonds de tentative, de temps ou de coût ; cela devrait être rare, et les pics signifient que les limites ou la classification doivent être ajustées.
Complétude de la compensation: Fraction des flux de travail multi-étapes échoués qui se terminent dans un état cohérent ; l'objectif est une annulation complète sans effets secondaires orphelins.

Modes de défaillance observés

Des limites de tentatives manquantes ou trop élevées permettent à l'agent de réessayer indéfiniment une défaillance permanente, ce qui engendre des coûts sans jamais progresser.
Traiter une erreur permanente comme transitoire gaspille des tentatives ; traiter une erreur transitoire comme permanente conduit à abandonner trop tôt et déclenche des solutions de secours inutiles.
Un chemin de secours renvoie une réponse plausible mais erronée sans signaler qu'une récupération a eu lieu, de sorte que les consommateurs en aval font confiance à une mauvaise sortie.
L'agent échoue après une écriture ou une action externe mais avant l'exécution de la compensation, laissant des enregistrements en double ou orphelins.

Leçons apprises

La décision de tenter, de basculer ou d'escalader repose sur la distinction entre transitoire et permanent ; investissez dans une classification claire avant d'ajuster les courbes de backoff.
Les clés d'idempotence transforment une tentative risquée en une tentative sûre ; concevez-les dès le départ plutôt que d'ajouter une déduplication après coup.
Les limites strictes sur les tentatives, le temps et le coût sont non négociables ; un agent qui en est dépourvu finira par trouver un moyen de s'exécuter indéfiniment.
Enregistrez chaque tentative, solution de secours et compensation afin qu'une dégradation silencieuse apparaisse sous forme de métrique plutôt que comme un incident surprise.

FAQ

En quoi cela diffère-t-il de l'ajout d'un bloc try/except et d'une boucle de tentative ?: Le bloc try/except gère une seule erreur ; une stratégie de récupération détermine le type de défaillance et choisit entre la tentative, la solution de secours, l'annulation et l'escalade sous des budgets stricts. C'est la logique de contrôle et l'idempotence qui en constituent l'essence, et non la gestion des exceptions.
Combien de tentatives dois-je autoriser ?: Peu — généralement une petite limite fixe avec un backoff exponentiel et du jitter, plus des plafonds de temps et de coût distincts. Le nombre exact dépend de la dépendance, mais la boucle doit toujours se terminer, et les défaillances permanentes ne doivent pas faire l'objet de tentatives.
Que se passe-t-il si une action ne peut pas être annulée ou rendue idempotente ?: Ne lancez pas de tentative automatique sur cette action. Créez un checkpoint avant l'étape irréversible et, en cas d'échec, escaladez vers un humain ou un agent superviseur plutôt que de deviner. L'irréversibilité est un signal pour ralentir, pas pour insister davantage.