Un agent de 30 étapes avec 1% de pannes échoue sur une tâche sur quatre : comment le mener en production

En démo, l'agent se comporte à la perfection : 10 étapes sur 10, tout le monde est content. En production, il exécute des milliers de tâches, et tout apparaît d'un coup : le modèle confond les outils, le contexte est saturé de déchets, la recherche ne trouve pas ce qu'il faut, le processus plante en pleine tâche. La deuxième partie de la série publiée sur Habr est consacrée aux remèdes. Voici l'essentiel.

L'arithmétique qui sépare la démo de la production

Imaginez une tâche de 30 étapes, où chaque étape échoue une fois sur cent : un blip réseau, une API qui répond « surchargée ». La tâche n'ira alors au bout que dans 74% des cas. Une sur quatre échouera. Avec 3% de pannes par étape, seules 40% des tâches arriveront au bout. L'auteur précise honnêtement qu'il s'agit d'un calcul théorique : il suppose des pannes temporaires indépendantes. Si le fournisseur est totalement hors service, trois relances rapides n'y changeront rien : il faut une longue pause ou un fournisseur de secours.

Outils et contexte : moins, mais plus précis

Le modèle ne connaît d'un outil que son nom, sa description, le schéma de ses paramètres et ce qu'il a renvoyé. On écrit donc un outil pour un agent autrement qu'une API pour un développeur. Ne créez pas un outil par endpoint : au lieu de list_users, list_events et create_event, mieux vaut un seul schedule_event, qui trouve lui-même un créneau et crée la réunion.

Gardez des réponses courtes, avec des noms explicites plutôt que des uuid. Dans l'exemple d'Anthropic, le mode concis d'un outil Slack a renvoyé 72 tokens au lieu de 206. Rédigez les erreurs pour le modèle : avec le message « la date doit être au format 2026-11-09, reçu 09.

11 », l'agent se corrigera tout seul au tour suivant, alors qu'un code 400 nu ne lui dira rien.

Le même principe vaut pour le contexte : conserver le plus petit ensemble de tokens qui aide à résoudre la tâche. Chargez les données au fil de l'eau, en ne laissant dans le prompt que des références. Compressez l'historique en conservant les décisions et les bugs ouverts. Confiez les morceaux lourds à des sous-agents, qui renverront une synthèse de 1 000 à 2 000 tokens.

RAG : commencez par décider si vous en avez besoin

Si la base de connaissances fait moins de 200 000 tokens (environ 500 pages), on peut la placer entièrement dans le prompt et la mettre en cache. La recherche devient alors inutile. Si la base est plus grande, les mesures d'Anthropic montrent qu'une combinaison fonctionne : recherche sémantique plus recherche lexicale (BM25), 50–100 tokens de contexte ajoutés à chaque fragment avant l'indexation, et reranking.

Le taux d'échec, c'est-à-dire les cas où le bon fragment ne figure pas parmi les 20 meilleurs résultats, est passé de 5,7% à 1,9%. Évaluez la recherche séparément de la réponse : constituez des questions dont l'emplacement de la réponse est connu et mesurez à quelle fréquence le fragment remonte dans les résultats. Sinon, impossible de savoir si la faute revient à la recherche ou au modèle.

Une boucle sous contrôle : tours, argent, relances

Commencez par une chaîne de traitement, pas par un agent : l'agent fait payer sa liberté en latence et en argent. Si vous en avez malgré tout besoin, fixez trois garde-fous : une limite de tours, un budget en dollars et un timeout sur l'ensemble de la tâche. Le coût augmente plus vite que le nombre de tours, car chaque tour relit l'historique depuis le début. D'après le calcul de l'auteur, une tâche de 30 tours coûte $0,51, tandis qu'un agent bloqué à 100 tours revient à $2,68 : 3,3 fois plus de tours, mais 5,3 fois plus d'argent. Décidez à l'avance où part la tâche quand les tentatives sont épuisées : modèle de secours, chaîne simple ou humain.

Il ne faut relancer que les pannes temporaires comme 429, 500, 504 et 529, avec un délai croissant. Subtilité : un 429 peut aussi survenir lorsque le plafond mensuel de dépenses est atteint (code enforced_spend_limit_reached). La relance est alors inutile, et un retry sans distinction martèlera l'API pendant des heures.

Le danger, ce n'est pas la panne, c'est la répétition

Imaginez un outil send_email : l'e-mail est parti, mais la réponse s'est perdue, le code d'orchestration a rejoué l'appel, et le client a reçu deux e-mails. Avec charge_card, l'argent serait de même débité deux fois. La solution est connue depuis Stripe : la clé d'idempotence.

Le serveur mémorise la réponse à la première requête portant cette clé et, en cas de répétition, renvoie la réponse enregistrée. L'agent dispose déjà d'une telle clé : l'id de l'appel d'outil, qui ne change pas lors d'une relance. Transmettez-la au système externe.

Mais si le processus plante entre l'envoi et l'enregistrement du résultat, une vérification locale ne détectera pas le doublon. Les actions dont le système externe ne gère pas les clés, ainsi que l'envoi, le paiement et la suppression, doivent être soumises à la confirmation d'un humain.

Si c'est le processus lui-même qui plante, il n'y a rien à relancer : l'historique et les résultats étaient en mémoire. Il faut alors une exécution durable, par exemple Temporal. La boucle de l'agent vit dans un workflow, les appels au modèle et aux outils deviennent des activities, les événements sont écrits dans un journal, et un autre worker reprend à l'endroit de la panne. Condition : le code du workflow est déterministe et les activities sont idempotentes. Le prix à payer : une panne au 25e tour avec redémarrage à zéro coûte $0,93 au lieu de $0,51, soit +81%.

Que faire en pratique

Réduisez le jeu d'outils et regroupez-les en outils plus larges. Fixez une limite de tours, un budget et un plan B. Vérifiez que chaque action à conséquences est idempotente ou passe par une confirmation. Calculez le coût d'une tâche réussie, et non d'un seul appel, et lancez les vérifications à chaque modification du prompt.

Limites : tous les calculs de coût sont théoriques et liés au scénario de la première partie de la série, et une partie des chiffres sur les limites et les erreurs dépend de la documentation à une date donnée. Dans le texte disponible, le passage sur l'observabilité et la sécurité est tronqué, mais le conseil général est clair : ne pas donner à l'agent, en même temps, des données privées, du contenu non fiable et un accès vers l'extérieur.