Concevoir des agents qui ne bouclent pas indéfiniment

Imaginez une défaillance coûteuse courante en production : un mardi à 3 heures du matin, un agent de support client entre dans une boucle infinie. Il appelle le même outil, reçoit la même erreur, modifie légèrement un paramètre, puis recommence des centaines de fois par minute. Au matin, l’équipe découvre une facture inattendue à quatre ou cinq chiffres, selon le modèle et la fréquence des appels.

Ce scénario n’est pas rare. Les boucles comptent parmi les défaillances les plus fréquentes et les plus lourdes de conséquences. Elles sont insidieuses, car l’agent semble fonctionner : il agit et ses appels réussissent, ou échouent de manière prévisible. Seule l’analyse de la trace révèle la répétition.

Concevoir des agents qui terminent exige des choix architecturaux délibérés. La plupart de leurs défaillances sont prévisibles et les schémas de prévention bien connus. Les équipes fiables les mettent en œuvre avec rigueur.

Cet article couvre ce qui fait boucler les agents, les modèles architecturaux qui empêchent cela, et les garde-fous opérationnels qui détectent les boucles lorsqu’elles passent à travers.

Pourquoi les agents bouclent

Quelques mécanismes derrière les boucles d’agents :

1. Confusion sur la progression

L’agent ne sait pas clairement s’il progresse. Il tente une action, observe le résultat et décide d’en essayer une autre. Sans suivi explicite, cette nouvelle tentative peut n’être qu’une variante minime de la précédente.

2. Absence de critères de terminaison

Le prompt de l’agent dit “aidez l’utilisateur”, mais ne dit pas “arrêtez quand X est vrai.” Sans critères de terminaison clairs, l’agent continue à “aider” — à chercher une autre information, à essayer un autre outil, à affiner davantage.

3. Réessais pathologiques

Lorsqu’une chose échoue, les agents réessaient naturellement. Sans budgets de réessai, le même échec peut être réessayé indéfiniment. L’agent perçoit “je n’ai pas encore réussi” et non “j’ai déjà essayé cela 10 fois.”

4. Amnésie d’état

La mémoire de travail de l’agent ne contient que les dernières étapes. Si une boucle a parcouru 20 tentatives, l’agent pourrait ne voir que les 5 dernières dans le contexte — perdant le motif qui est maintenant évident pour les observateurs extérieurs.

5. Incohérence des outils

Un outil renvoie des résultats confus ou contradictoires. L’agent réessaie. L’outil renvoie toujours des résultats confus. L’agent raisonne “peut-être mon interprétation précédente était erronée” et tente différemment. L’outil renvoie toujours des résultats confus. Boucle.

6. Optimisme excessif

L’entraînement de l’agent le rend persévérant — il continue d’essayer lorsqu’une meilleure stratégie serait d’arrêter et de demander de l’aide. Particulièrement mauvais dans les tâches à long terme où les petites confusions s’accumulent.

7. Dérive de l’objectif

L’agent perd progressivement de vue ce qu’il essayait d’accomplir. Il se branche sur des sous-tâches, puis des sous-sous-tâches, explore des domaines tangents sans revenir à l’objectif principal.

Les agents échouent de différentes manières. Les défenses se chevauchent.

Schéma 1 : budgets d’étapes stricts

La défense la plus simple et la plus importante consiste à fixer un nombre maximal d’étapes. Si l’agent dispose de 20 appels d’outils, il doit ensuite produire une réponse finale ou transmettre le problème.

Implémentation :

def agent_loop(query, max_steps=20):
    messages = [{"role": "user", "content": query}]
    for step in range(max_steps):
        response = call_llm(messages, tools=available_tools)
        if response.is_final_answer:
            return response.content
        result = execute_tool(response.tool_call)
        messages.append(response)
        messages.append({"role": "tool", "content": result})
    # Hit budget — force final answer
    return force_final_answer(messages)

Le budget doit être calibré en fonction de la tâche. Tâches simples : 5 à 10 pas. Tâches complexes multi-sources : 20 à 30. Recherche ouverte : 50+. Mais toujours borné.

Lorsque le budget est atteint, l’agent produit sa meilleure réponse avec ce qu’il sait. Ou escalade vers un humain.

Ce seul modèle empêche la plupart des boucles catastrophiques. Implémentez-le toujours.

Variantes

Budget de tokens. À la place du nombre d’étapes, ou en complément, limitez le nombre total de tokens. Vous éviterez ainsi qu’un petit nombre d’étapes contienne chacune une trace de raisonnement de 50 000 tokens.

Budget de coût. Traduit les budgets de pas/token en euros. Empêche les dépassements de budget d’être abstraits.

Budget de temps. Limitez le temps réel écoulé, notamment pour les parcours utilisateur qui exigent une réponse en 30 secondes.

La plupart des agents en production ont les quatre budgets sous une forme ou une autre. L’atteinte de l’un quelconque termine l’exécution.

Schéma 2 : suivi de la progression

Un budget seul ne dit pas à l’agent qu’il est bloqué — il ne l’arrête que finalement. Le suivi de progression aide l’agent à reconnaître une boucle et à s’en sortir.

Une implémentation simple consiste à tenir un journal explicite de progression. À chaque étape, l’agent indique les nouvelles informations obtenues ou les changements survenus.

Step 1: Searched for customer "Smith". Found 12 matches.
Step 2: Filtered to active accounts. 4 remain.
Step 3: Checked recent activity. Customer 234 had a recent ticket about pricing.
Step 4: Pulled the ticket details. The complaint was about a recent price change.
Step 5: Drafted response. Ready to send.

Chaque étape ajoute de nouvelles informations. Si l’agent fait l’étape 6 et que le journal de progression ne gagne rien — même recherche, mêmes résultats, même conclusion — il tourne en rond.

Le prompt peut inclure :

Before deciding the next action, summarize what you've learned in the last few steps. If you haven't gained new information in the last 3 steps, stop and either:
- Produce your best answer with current information.
- Escalate the issue: explain what you've tried and what's missing.

L’absence de progression devient ainsi visible pour l’agent, qui peut y réagir.

Schéma 3 : détection des répétitions

Parfois, les agents répètent exactement le même appel d’outil. C’est facile à détecter de manière programmée.

def detect_repeat(history):
    recent_calls = [c for c in history[-5:] if c.is_tool_call]
    if len(recent_calls) < 3:
        return False
    call_signatures = [(c.tool, json.dumps(c.args, sort_keys=True)) for c in recent_calls]
    return len(set(call_signatures)) < len(call_signatures) / 2

Si une répétition est détectée, intervenir :

• Insérer un message : “Vous avez appelé cet outil avec ces paramètres récemment. Les résultats n’ont pas changé. Essayez une approche différente ou terminez.”
• Ou forcer la terminaison.

Cela détecte automatiquement les boucles les plus évidentes.

Schéma 4 : détection des états bloqués

Au-delà des répétitions exactes, on peut détecter des états bloqués plus subtils :

Reconnaissance de schémas. Utilisez un appel LLM distinct pour évaluer si l’agent a progressé au cours des cinq dernières étapes. Dans le cas contraire, interrompez-le.

def is_stuck(history):
    recent = format_history(history[-5:])
    response = call_llm(
        system="You are evaluating whether an agent is making progress.",
        user=f"Recent agent steps:\n{recent}\n\nIs the agent making meaningful progress or stuck in a loop? Answer: progressing | stuck."
    )
    return response.content.strip() == "stuck"

Exécutez ce test toutes les quelques étapes. Si cela renvoie “bloqué”, intervenez.

Diversité des outils. Si l’agent a appelé un seul outil pendant 5 étapes ou plus, cela est suspect. Forcez-le à essayer autre chose ou à s’arrêter.

Modèles d’erreur. Si le même outil a renvoyé la même erreur 3 fois ou plus, arrêtez de l’utiliser. L’agent ne va pas découvrir l’entrée manquante par plus de réessais.

Schéma 5 : points de réflexion

À des points spécifiques de l’exécution de l’agent, forcez une réflexion explicite.

After every 5 steps, the agent must produce a reflection:

1. What was my original goal?
2. What have I learned so far?
3. What do I still need to know?
4. Am I making progress, or repeating?
5. Should I continue or stop?

La réflexion force l’agent à s’éloigner de la pensée immédiate de l’action suivante et à évaluer l’ensemble.

Cela est particulièrement efficace pour les tâches à long terme. Sans réflexion forcée, les agents dérivent ; avec, ils détectent leur propre dérive.

Schéma 6 : ancrage de l’objectif

Dans les longues exécutions d’agents, l’objectif initial est perdu. La fenêtre de contexte de l’agent est remplie d’étapes intermédiaires ; la question originale devient une petite partie d’un grand contexte.

Contrez cela en ancrant l’objectif de manière répétée :

• Incluez l’objectif initial en tête de chaque message système.
• Faites que l’agent reformule l’objectif toutes les N étapes.
• Utilisez un “suivi d’objectif” séparé qui confirme que chaque étape est alignée sur l’objectif.

Exemple d’ajout de prompt :

Original goal: [verbatim user request]

Before each action, confirm:
- Is this action helping me toward the original goal?
- If yes, proceed.
- If no, return to the goal directly.

Schéma 7 : délimitation des sous-tâches

Les agents longs se divisent naturellement en sous-tâches. Sans structure, les sous-tâches peuvent engendrer des sous-sous-tâches de manière récursive jusqu’à ce que l’agent soit perdu.

Donnez une structure :

• L’agent identifie explicitement les sous-tâches.
• Chaque sous-tâche a son propre budget.
• Après avoir terminé (ou échoué) une sous-tâche, l’agent retourne à la tâche principale.
• Les sous-tâches ne peuvent pas engendrer des sous-sous-tâches non bornées.

C’est ce que tentent de formaliser des cadres comme LangGraph — une machine d’états où chaque nœud est une étape claire, avec des transitions explicites.

Pour les agents complexes, cette structure est essentielle. Pour les simples, c’est trop lourd.

Schéma 8 : sorties de secours

Lorsqu’un agent est bloqué, il a besoin de moyens explicites pour s’arrêter :

Escalade. “Je ne peux pas terminer cette tâche. Voici ce que j’ai essayé et ce qui manque.” L’agent s’arrête et soulève le problème.

Complétion partielle. “J’ai terminé les parties A et B. C est bloqué par X.” L’agent n’a pas besoin de réussir entièrement ; il peut produire une sortie partielle utile.

Clarification. “J’ai besoin d’informations supplémentaires de l’utilisateur : …” L’agent s’arrête et demande.

Ces options doivent être des options de premier plan pour l’agent, pas des recours ultimes. Le prompt de l’agent doit les mentionner et les encourager lorsqu’il est bloqué.

Une addition utile au prompt :

If you encounter any of these situations, stop trying and respond appropriately:
- A tool consistently returns the same error.
- You've tried 3 different approaches without progress.
- You need information only the user can provide.
- The task is more complex than your tools support.

In these cases:
- For tool errors: explain the issue, suggest the user contacts support.
- For lack of progress: report what you've tried and ask for guidance.
- For missing information: ask the user a specific question.
- For complexity: escalate to human assistance with a summary.

Schéma 9 : actions tenant compte de la confiance

L’agent doit savoir quand il est confiant et quand il ne l’est pas. Agir avec une faible confiance est comment les boucles commencent.

Un schéma consiste à exiger un niveau de confiance explicite avant toute action lourde de conséquences.

Before calling delete_record, state your confidence on a 1-5 scale that this is the right action. If <4, do not call. Instead, ask for human confirmation.

Cela fonctionne particulièrement bien pour les actions destructrices ou coûteuses. L’agent doit s’engager à une forte confiance avant de les prendre.

Combiné à la réflexion, cela détecte les cas où l’agent “essaie des choses” plutôt que “exécute un plan.”

Schéma 10 : garde-fous au niveau des outils

Au-delà des modèles au niveau de l’agent, les outils eux-mêmes peuvent avoir des garde-fous :

Limitation de taux par session. Un outil ne peut être appelé qu’un nombre N de fois par session. Après N, renvoie “limite de taux.” Force l’agent à faire autre chose.

Idempotence. Les appels identiques répétés renvoient le résultat mis en cache sans réexécuter. Empêche les boucles qui frappent un outil.

Plafonds de coût. Les outils coûteux (requêtes lourdes de base de données, API tiers avec des coûts d’utilisation) ont des limites par session.

Disjoncteurs. Désactivez un outil qui a échoué trois fois pendant la session. L’agent ne peut alors plus l’appeler.

Ces garde-fous complètent les modèles au niveau de l’agent. L’agent pourrait tenter de boucler, mais l’outil l’empêche.

Schéma 11 : surveillance externe

Pour tous les modèles internes à l’agent, une surveillance externe attrape ce qui passe à travers.

Un processus de surveillance surveille tous les agents en cours d’exécution. Il vérifie :

• Nombre d’étapes par agent.
• Utilisation de tokens par agent.
• Coût par agent.
• Temps par agent.
• Modèles d’appel d’outils.

Lorsqu’un agent dépasse les seuils, interrompez-le et envoyez une alerte.

C’est la dernière ligne de défense. Même si l’agent lui-même est cassé, la surveillance l’attrape avant qu’il n’endommage le portefeuille.

En implémentation :

• Une base de données en temps réel suit les métriques des agents.
• Des règles déclenchent des interruptions, par exemple lorsque l’agent fonctionne depuis plus de cinq minutes.
• Un petit service surveille et applique.

Pour les systèmes qui exécutent simultanément de nombreux agents, c’est essentiel.

Schéma 12 : points de contrôle humains

Pour les agents à haut risque, intégrez des points de vérification humains. L’agent fonctionne jusqu’à un point de vérification, puis attend l’approbation humaine.

Points de vérification typiques :

• Avant les actions destructrices.
• Après une décision que l’agent ne peut pas inverser.
• À des jalons majeurs dans une tâche longue.
• Lorsque la confiance diminue.

Il ne s’agit pas de méfiance, mais de détecter les erreurs tant que leur correction reste peu coûteuse.

Un workflow pratique : l’agent fait des préparations autonomes, présente un résumé et des actions proposées, l’humain approuve, l’agent exécute. L’humain est dans la boucle pour les décisions, pas pour chaque étape.

Exemple concret : un agent de recherche longue durée

Pour illustrer, les modèles appliqués à un agent réel :

Tâche : Rechercher un concurrent et produire un résumé.

Travail estimé : 10 à 30 recherches web, 20 à 50 pages lues et une synthèse de 1 000 mots.

Modèles appliqués :

1. Budget de pas : 60 pas au total.

2. Budget de tokens : 300 000 tokens pour le contexte et les actions. En cas de dépassement, résumer les résultats actuels et poursuivre.

3. Budget de coût : 2 € par exécution. Si dépassé, arrêter et retourner un résumé partiel.

4. Budget de temps : 5 minutes de temps réel.

5. Suivi de progression : À chaque étape, l’agent met à jour un “journal des découvertes” avec de nouvelles informations. Si 3 étapes passent sans nouvelles découvertes, sortir.

6. Détection des répétitions : Si la même requête de recherche est exécutée deux fois avec des résultats similaires, forcer une approche différente.

7. Points de réflexion : Toutes les 10 étapes, l’agent réfléchit à la progression et au travail restant.

8. Ancrage de l’objectif : L’objectif initial du résumé en tête de chaque message système.

9. Sorties de secours : “J’ai assez d’informations” ou “Je ne peux pas trouver suffisamment d’informations” terminent l’agent de manière gracieuse.

10. Surveillance externe : Un observateur indépendant tue les agents dépassant les budgets.

Résultat : Durée moyenne d’exécution 3 minutes. Coût moyen 0,40 €. Taux d’échec (boucles ou dépassements de temps) < 1 %. Les résumés produits sont de 700 à 1200 mots, ancrés dans les faits, points de départ utiles.

Sans ces modèles : quelques exécutions de 30 minutes, quelques coûts de 20 € ou plus, quelques sessions bloquées. Les modèles réduisent considérablement la queue.

Détection en production

Même avec des modèles, quelques problèmes passent à travers. Les détecter :

Alertes sur les agents longs. Tout agent > 2x la durée médiane déclenche une alerte.

Alertes sur les pics de coût. Coût par agent ou agrégé au-dessus du seuil.

Alertes sur les motifs de répétition. Modèles d’appel d’outils suggérant des boucles.

Examen quotidien des longues traces. Une personne consulte chaque jour les 10 traces les plus longues afin de détecter les problèmes ignorés par les évaluations.

Métriques agrégées : taux de boucle au fil du temps. Détecte quand quelque chose change (mise à jour de modèle, changement de prompt) qui augmente la fréquence des boucles.

Un tableau de bord utile présente la distribution des durées d’exécution. Sa longue traîne révèle l’incidence des boucles.

Erreurs courantes

Voici quelques erreurs récurrentes :

Erreur 1 : aucun budget d’étapes. « Nous l’ajouterons si nécessaire. » Puis l’agent boucle à 3 heures du matin et vous regrettez cette décision. Ajoutez-le dès le départ.

Erreur 2 : Budgets trop élevés. “100 pas devraient suffire” — mais une boucle le remplit. Fixez les budgets à 2 à 3 fois la médiane, pas le cas le pire.

Erreur 3 : Aucune surveillance externe. Faire confiance à l’agent pour s’arrêter lui-même. Parfois, il ne le fait pas. La surveillance externe est essentielle en production.

Erreur 4 : détecter les boucles sans les analyser. La surveillance interrompt une boucle, puis l’équipe passe à autre chose. La même boucle réapparaît la semaine suivante. Analysez systématiquement sa cause, les changements intervenus et les moyens de prévenir cette classe de défaillance.

Erreur 5 : Réflexion agressive sur des tâches simples. Forcer une réflexion toutes les 5 étapes sur une tâche de 5 étapes est un surcoût sans bénéfice. Calibrez selon la complexité de la tâche.

Erreur 6 : Objectifs perdus dans des contextes longs. Un objectif mentionné une fois à l’étape 1 ne survit pas à l’étape 50. Ré-ancrage régulier.

Erreur 7 : Faire confiance aux rapports d’avancement de l’agent. Les agents diront qu’ils font de la progression lorsqu’ils ne le font pas. Vérifiez externement si possible.

Erreur 8 : laisser les agents s’appeler récursivement. « Décomposez cette tâche en sous-agents » peut provoquer une multiplication exponentielle des agents. Si vous l’autorisez, imposez un budget strict.

Quand les boucles sont acceptables

Toutes les boucles ne sont pas mauvaises. Certaines tâches exigent légitimement de nombreuses itérations :

• Raffinement itératif du code (écrire, tester, corriger, répéter).
• Recherche multi-étapes avec des branches.
• Tâches d’optimisation (essayer des variations, évaluer, raffiner).

Pour ces cas, les boucles sont le travail, pas un échec. Les modèles changent :

• Budgets de pas généreux (50 à 200 pas).
• Cadre explicite “itération”, pas “boucle”.
• Suivi de l’amélioration de la qualité — chaque itération doit améliorer une métrique.
• Arrêt dur lorsque l’amélioration se stabilise.

Le principe consiste à distinguer le travail itératif intentionnel de la boucle involontaire, puis à appliquer les schémas adaptés à chacun.

Liste de contrôle pour la production

Les agents qui bouclent indéfiniment sont prévisibles, courants et évitables. Les modèles sont bien connus : budgets de pas, suivi de progression, détection des répétitions, réflexion, ancrage des objectifs, sorties de secours, garde-fous des outils, surveillance externe.

Ce ne sont pas des polissages optionnels. Ils font la différence entre des agents qui sont déployés et des agents qui produisent des factures inattendues de quatre chiffres.

Pour tout agent en production, vérifiez les points suivants :

• Budget de pas maximum.
• Budget de tokens maximum.
• Budget de coût maximum.
• Budget de temps maximum.
• Détection des appels répétés.
• Suivi de progression.
• Réflexion périodique.
• Ancrage des objectifs.
• Plusieurs sorties de secours.
• Surveillance externe capable d’interrompre l’agent.

Chacun est simple à implémenter. Ensemble, ils font la différence entre “cet agent est dangereux à laisser fonctionner” et “cet agent est fiable en production.”

Mettez ces schémas en œuvre et testez-les. La réduction du risque dans la longue traîne justifie largement ce travail.