Reflexion Agent
Un reflexion agent est un agent IA basé sur le framework Reflexion (Shinn et al., NeurIPS 2023) qui apprend de ses erreurs non pas en modifiant les poids du modèle, mais en générant une réflexion verbale sur ses échecs, la stockant dans une mémoire épisodique, et l’utilisant comme contexte pour améliorer ses décisions lors des tentatives suivantes.
L’idée est élégante : plutôt que le reinforcement learning traditionnel (coûteux, nécessite des milliers d’exemples et un fine-tuning du modèle), on remplace le gradient numérique par un « gradient sémantique ». Le modèle écrit en langage naturel ce qu’il a mal fait et comment s’améliorer. Cette réflexion textuelle sert ensuite de guide pour la tentative suivante.
C’est exactement ainsi que les humains apprennent des tâches complexes : on essaie, on échoue, on réfléchit à ce qui n’a pas marché, et on ajuste son approche. Le reflexion agent reproduit ce cycle essai-erreur-réflexion-amélioration, mais en quelques secondes plutôt qu’en heures.
- Catégorie
- Architecture agentique / Apprentissage par feedback verbal
- Papier fondateur
- « Reflexion: Language Agents with Verbal Reinforcement Learning » (Shinn et al., NeurIPS 2023)
- Principe
- Essai → Évaluation → Réflexion verbale → Stockage en mémoire → Tentative améliorée
- Composants
- Actor (exécute), Evaluator (note), Self-Reflection (réfléchit), Memory (stocke)
- Tâches validées
- Prise de décision séquentielle (ALFWorld), raisonnement (HotPotQA), programmation (HumanEval, LeetCode Hard)
- Frameworks
- AutoGen (reflection_assistant), LangGraph (loops), implémentations custom
- Relation
- Sous-catégorie de reasoning agent, utilise la mémoire long-terme
Architecture du reflexion agent
Le framework Reflexion repose sur trois composants qui fonctionnent en boucle itérative.
L’Actor (l’exécutant)
L’Actor est le LLM qui exécute la tâche. Il génère des actions en interagissant avec l’environnement (écrire du code, naviguer dans un jeu, répondre à des questions). À chaque tentative, il produit une trajectoire : la séquence complète de ses actions et observations.
Au moment de l’inférence, l’Actor a accès à deux types de mémoire :
La mémoire à court terme contient la trajectoire en cours (les actions et observations de la tentative actuelle).
La mémoire à long terme contient les réflexions des tentatives précédentes. C’est la « sagesse acquise » de l’agent.
L’Evaluator (le correcteur)
L’Evaluator prend la trajectoire produite par l’Actor et génère un score de performance. Ce score peut être :
Binaire ou scalaire : pour les tâches de raisonnement, un score d’exact match (la réponse est-elle correcte ?). Pour les tâches de code, les tests passent-ils ?
Heuristique : pour les tâches de prise de décision (jeux, navigation), une fonction de récompense prédéfinie évalue la qualité de la trajectoire.
LLM-as-judge : un autre LLM (ou le même) évalue la qualité de la sortie en langage naturel.
Le Self-Reflection (le réflecteur)
C’est le cœur de l’innovation. Le modèle de Self-Reflection analyse la trajectoire et le score de l’Evaluator, puis produit un résumé textuel de ce qui a mal fonctionné et comment s’améliorer. Cette réflexion agit comme un « gradient sémantique » : elle donne à l’agent une direction concrète d’amélioration en langage naturel.
Par exemple, après un échec en programmation : « Ma solution a échoué sur les cas limites avec des listes vides. Je n’ai pas géré le cas où l’input est None. Au prochain essai, je dois ajouter une vérification en début de fonction pour les inputs null et les listes vides. »
Cette réflexion est stockée dans la mémoire épisodique et sera disponible comme contexte pour la tentative suivante.
La boucle complète
Le processus est formalisé comme une optimisation itérative :
Tentative 1 : l’Actor produit une trajectoire τ₀ en interagissant avec l’environnement. L’Evaluator calcule un score r₀. Le Self-Reflection analyse {τ₀, r₀} et produit un résumé sr₀ stocké en mémoire.
Tentative 2 : l’Actor reçoit en contexte la réflexion sr₀ (et optionnellement la trajectoire τ₀). Il ajuste sa stratégie en conséquence et produit une nouvelle trajectoire τ₁, évaluée par r₁.
Tentatives suivantes : le cycle se répète jusqu’à ce que l’Evaluator soit satisfait ou qu’un nombre maximum de tentatives soit atteint (typiquement 3 à 5).
Pour gérer la taille du contexte, Reflexion utilise une fenêtre glissante : seules les 1 à 3 réflexions les plus récentes sont conservées en mémoire. Les réflexions plus anciennes sont éliminées.
Résultats et performances
Le papier original démontre des améliorations significatives sur trois types de tâches :
Prise de décision séquentielle (ALFWorld)
ALFWorld est un environnement de jeu textuel où l’agent doit accomplir des tâches domestiques (trouver un objet, le déplacer, interagir avec l’environnement). Les agents Reflexion améliorent considérablement leurs performances par rapport aux agents sans réflexion, en évitant de répéter les mêmes erreurs de navigation.
Raisonnement multi-hop (HotPotQA)
HotPotQA demande de répondre à des questions nécessitant un raisonnement en plusieurs étapes à travers plusieurs documents. L’agent Reflexion apprend à affiner ses requêtes de recherche et à croiser les sources après avoir échoué sur une première tentative.
Programmation (HumanEval, MBPP, LeetCode Hard)
C’est le domaine où Reflexion brille le plus. L’agent génère du code, l’exécute contre une suite de tests, et quand des tests échouent, il réfléchit sur les erreurs et corrige. Sur les benchmarks de génération de code, Reflexion atteint des résultats state-of-the-art. Le papier introduit aussi LeetcodeHardGym, un environnement de 40 problèmes LeetCode de difficulté « hard » en 19 langages de programmation.
Le mécanisme est particulièrement efficace en programmation parce que le feedback est précis et exploitable : les messages d’erreur du compilateur et les résultats de tests indiquent exactement ce qui ne fonctionne pas, ce qui facilite la génération d’une réflexion utile.
Reflexion vs Self-Refine : quelle différence ?
Reflexion est souvent confondu avec Self-Refine (Madaan et al., 2023), un autre framework d’auto-amélioration. Les deux utilisent le feedback itératif, mais avec des différences architecturales importantes :
| Critère | Reflexion | Self-Refine |
|---|---|---|
| Portée | Multi-épisodes (l’agent apprend entre les tentatives) | Intra-épisode (refinement dans une seule génération) |
| Mémoire | Mémoire épisodique persistante entre les tentatives | Pas de mémoire entre les générations |
| Feedback | Externe (environnement, compilateur, tests) + réflexion | Auto-évaluation interne uniquement |
| Tâches | Décision séquentielle, code, raisonnement multi-étapes | Génération de texte, tâches single-shot |
| Interaction | Interaction avec un environnement (actions, observations) | Refinement d’un output unique |
En résumé : Self-Refine améliore un seul output par itérations successives. Reflexion améliore le comportement de l’agent au fil de multiples tentatives complètes, avec une mémoire qui persiste entre les essais.
Implémenter un reflexion agent
Avec AutoGen
Microsoft AutoGen facilite l’implémentation du pattern Reflexion avec trois agents :
Un writing_assistant (l’Actor) qui génère les solutions. Un reflection_assistant (le Self-Reflection) qui produit des critiques et recommandations. Un user_proxy qui orchestre le dialogue et exécute le code si nécessaire.
Le reflection_assistant reçoit la sortie du writing_assistant, génère une critique, et le writing_assistant produit une version révisée en tenant compte du feedback. Le cycle se répète jusqu’à satisfaction ou limite de tours.
Avec LangGraph
LangGraph (de LangChain) est particulièrement adapté grâce à ses boucles natives. Vous définissez un graphe avec les nœuds Actor, Evaluator et Reflector, et des arêtes conditionnelles : si le score est insuffisant, on boucle vers le Reflector puis vers l’Actor ; sinon, on termine.
Implémentation custom
Le pattern est suffisamment simple pour être implémenté sans framework. La logique se résume à une boucle for trial in range(max_trials) où chaque itération exécute l’Actor (avec les réflexions précédentes en contexte), évalue le résultat, et génère une nouvelle réflexion si nécessaire.
Le choix de la stratégie de contexte est important : REFLEXION (seule la réflexion est donnée comme contexte), LAST_ATTEMPT_AND_REFLEXION (la trajectoire complète de la dernière tentative + la réflexion), ou LAST_ATTEMPT (seule la trajectoire, sans réflexion explicite, comme baseline).
Applications en production
Agents de code auto-correcteurs
Le cas d’usage le plus naturel. Claude Code, Codex et Cursor Agent Mode implémentent implicitement le pattern Reflexion quand ils écrivent du code, lancent les tests, analysent les erreurs, et corrigent. Le feedback du compilateur et des tests joue le rôle de l’Evaluator. La correction de l’agent après analyse des erreurs est la Self-Reflection.
Recherche itérative
Un agent de recherche qui formule une requête, évalue si les résultats répondent à la question, puis reformule une meilleure requête en réfléchissant sur ce qui manquait. C’est le fonctionnement implicite du Deep Research de Perplexity et ChatGPT.
Dialogue adaptatif
Un chatbot de service client qui, après un échange insatisfaisant (détecté par le feedback utilisateur ou un LLM-as-judge), réfléchit sur son approche et adopte une stratégie différente lors de la prochaine interaction similaire. Le framework DERA (Dialog-Enabled Resolving Agents) étend ce concept à la résolution de conversations médicales.
Limites et pièges
Optima locaux : l’agent peut converger vers une solution « assez bonne » sans atteindre l’optimum. Si les premières réflexions orientent dans une mauvaise direction, les tentatives suivantes s’améliorent marginalement dans cette direction plutôt que d’explorer des alternatives radicalement différentes.
Qualité de la réflexion : l’auto-réflexion est aussi fiable que le LLM sous-jacent. Si le modèle ne comprend pas pourquoi il a échoué (problème d’attribution de crédit), la réflexion sera vague ou incorrecte, et les tentatives suivantes ne s’amélioreront pas. Les tâches avec un feedback précis (code compilation, tests unitaires) fonctionnent mieux que celles avec un feedback ambigu (qualité d’un texte).
Coût cumulatif : chaque tentative supplémentaire consomme des tokens. Avec 5 tentatives incluant chacune trajectoire + réflexion + contexte des réflexions précédentes, le coût total peut être 10 à 20× supérieur à un appel unique. La limite de tentatives doit être calibrée en fonction de la valeur de la tâche.
Fenêtre de contexte : les réflexions et trajectoires passées consomment le contexte disponible. La fenêtre glissante (garder 1 à 3 réflexions) est un compromis nécessaire mais peut faire perdre des insights des réflexions plus anciennes.
Biais de récence : l’agent peut accorder trop d’importance aux réflexions récentes et ignorer des patterns plus anciens mais pertinents. Un système de mémoire plus sophistiqué (mémoire sémantique indexée plutôt que fenêtre glissante) pourrait atténuer ce biais.
Évolution du concept
Reflexion a inspiré une famille de travaux sur l’auto-amélioration des agents :
RISE (Recursive IntroSpEction, 2024) : fine-tune les LLM en les faisant introspecter leur propre comportement, raisonner sur leurs erreurs et les corriger avec du calcul supplémentaire.
SkillRL (2026) : va au-delà de la mémoire brute de trajectoires en distillant les expériences réussies en « skills » réutilisables et les échecs en « leçons ». La bibliothèque de skills évolue récursivement avec la politique de l’agent pendant l’entraînement RL. Les tests montrent une compression de 10 à 20% des tokens par rapport au stockage de trajectoires brutes, tout en améliorant la qualité du raisonnement.
Self-Improve for Web Agents (2024) : montre que les boucles d’auto-amélioration synthétiques peuvent matériellement améliorer les performances des agents web, confirmant que le principe de Reflexion se généralise au-delà des tâches de code.
RCI (Recursively Criticizes and Improves) : un schéma de prompting simplifié où le LLM critique récursivement sa propre sortie et l’améliore. Plus simple que Reflexion (pas de mémoire épisodique séparée) mais efficace pour les tâches d’automatisation informatique.
La tendance est à l’intégration du pattern réflexif directement dans les architectures agentiques de production. Les agents de code modernes ne font pas de « Reflexion » formelle avec trois composants séparés, mais ils intègrent le même cycle : agir, observer le feedback, ajuster.
Bonnes pratiques d’implémentation
Maximisez la qualité du feedback. La réflexion est aussi bonne que le signal qu’elle analyse. Pour le code, utilisez des tests unitaires détaillés (pas juste pass/fail, mais les messages d’erreur complets). Pour le raisonnement, utilisez des réponses de référence avec exact match. Un feedback vague produit une réflexion vague.
Rendez les réflexions spécifiques et actionnables. Guidez le modèle de Self-Reflection pour qu’il produise des recommandations concrètes (« ajouter une vérification null en ligne 12 ») plutôt que des observations génériques (« le code pourrait être plus robuste »). Incluez des exemples de bonnes réflexions dans le prompt du réflecteur.
Limitez la fenêtre de mémoire. 1 à 3 réflexions en mémoire est généralement optimal. Plus de réflexions sature le contexte et peut créer des contradictions entre les différentes leçons. Si une réflexion plus ancienne est particulièrement pertinente, le modèle peut la reformuler et l’intégrer dans la réflexion courante.
Utilisez la stratégie LAST_ATTEMPT_AND_REFLEXION. Donner à l’Actor la trajectoire complète de la dernière tentative en plus de la réflexion est généralement plus efficace que la réflexion seule. L’Actor peut voir exactement ce qu’il a fait et où la réflexion suggère de changer.
Fixez un budget de tentatives strict. Sans limite, un agent peut boucler indéfiniment en s’améliorant marginalement à chaque tour. En pratique, si l’agent n’a pas résolu la tâche en 5 tentatives, il est peu probable qu’une 6e tentative change la donne. Escaladez vers un humain ou un modèle plus puissant.
Questions fréquentes
Quelle est la différence entre un reflexion agent et un reasoning agent ?
Un reasoning agent raisonne en profondeur avant d’agir (chain-of-thought, tree-of-thought). Un reflexion agent raisonne après avoir agi : il évalue le résultat de sa tentative, réfléchit sur ses erreurs, et utilise cette réflexion pour améliorer la tentative suivante. Le reasoning agent pense avant, le reflexion agent apprend après. Les deux sont complémentaires : un agent peut raisonner en profondeur (reasoning) ET apprendre de ses erreurs (reflexion).
Faut-il fine-tuner le modèle pour utiliser Reflexion ?
Non, c’est justement l’innovation de Reflexion. L’apprentissage se fait entièrement via le contexte (prompt), pas via les poids du modèle. Vous pouvez utiliser Reflexion avec n’importe quel LLM accessible par API : GPT-5.4, Claude Opus 4.6, Gemini 3.1 Pro, ou des modèles open source. Aucun accès aux poids ni infrastructure de fine-tuning n’est nécessaire.
Combien de tentatives sont nécessaires ?
Le papier original utilise typiquement 3 à 5 tentatives. En pratique, la majorité de l’amélioration se produit dans les 2 à 3 premières tentatives. Au-delà, les gains diminuent tandis que le coût en tokens augmente linéairement. Fixez un budget de tentatives proportionnel à la valeur de la tâche : 2 tentatives pour les tâches simples, 5 pour les problèmes de code complexes, rarement plus de 5.
Sur quels types de tâches Reflexion fonctionne-t-il le mieux ?
Les tâches avec un feedback précis et vérifiable : génération de code (les tests unitaires donnent un feedback binaire exact), raisonnement factuel (la réponse est correcte ou non), navigation dans un environnement (l’objectif est atteint ou non). Les tâches avec un feedback subjectif ou vague (qualité d’un texte, pertinence d’une recommandation) bénéficient moins de Reflexion car la réflexion manque d’ancrage concret.
Comment Reflexion se compare-t-il au fine-tuning par RL ?
Le fine-tuning par reinforcement learning modifie les poids du modèle pour améliorer ses performances de manière permanente. Reflexion n’améliore l’agent que dans le contexte de la session en cours (les réflexions ne survivent pas au-delà de la fenêtre de contexte). Le RL est plus puissant à long terme mais nécessite des milliers d’exemples et un accès aux poids du modèle. Reflexion est immédiatement utilisable, sans infrastructure de training, et fonctionne avec 3 à 5 exemples. En production, les deux approches peuvent se compléter : Reflexion pour l’adaptation rapide, RL pour l’amélioration permanente.