De l’ingénierie des prompts à l’ingénierie de contexte : écrire, sélectionner, compresser, isoler
Un cours d’ingénierie de contexte pour les agents d’IA : pourquoi l’ingénierie des prompts est insuffisante, comment se remplit la fenêtre de contexte, quatre stratégies, RAG pour les outils, Claude Code.
Tout ceux qui ont développé un agent ont probablement observé le même schéma. Au début, il se comporte bien : il choisit des outils appropriés, raisonne de manière claire et reste concentré sur la tâche. Vers l’étape 15 ou 20, il devient négligent. Il oublie ce qui lui a été demandé, utilise des outils inadaptés ou commence à produire des résultats de faible qualité.
La première suspicion habituelle porte sur le modèle. Mais le plus souvent, la cause réside dans ce qui est présenté au modèle. Déterminer ce qui est affiché au modèle, sous quelle forme et à quel moment, s’appelle l’ingénierie de contexte, et pour ceux qui conçoivent des agents, c’est devenu l’une des compétences les plus précieuses qui soient.
Les sections suivantes traitent de ce qu’est l’ingénierie du contexte et pourquoi les agents en ont besoin, des quatre stratégies qui organisent presque toutes les techniques, des quatre manières dont le contexte peut mal fonctionner, de conseils concrets pour les prompts de système et les définitions d’outils, d’un flux de travail en phases qui met en œuvre ces stratégies, ainsi que de la manière dont Claude Code, Manus, ChatGPT Agent et le Google Agent Development Kit gèrent chacun ce problème.
De l’ingénierie des prompts à l’ingénierie du contexte dans la fenêtre de contexte
L’ingénierie des prompts consiste à rédiger de bonnes instructions pour un modèle de langage : formuler les choses clairement, fournir des exemples, attribuer un rôle. Pour une conversation avec une seule question et réponse, cela suffit souvent.
Les agents changent la donne. Un agent ne répond pas d’un seul coup : il explore, appelle des API, écrit du code et exécute des commandes, étape par étape, parfois des dizaines d’étapes, sans intervention humaine. Chaque étape produit des résultats, qui sont tous intégrés dans le contexte du modèle, dont la taille est fixe.
L’ingénierie du contexte consiste donc à concevoir l’ensemble du système d’information autour du modèle. Cela inclut le prompt du système, les définitions des outils, les résultats des appels aux outils précédents, l’historique des conversations et bien d’autres éléments, à chaque étape. L’équipe d’ingénierie d’Anthropic définit le contexte comme l’ensemble des tokens pris en compte lors de l’échantillonnage d’un modèle, et l’ingénierie du contexte comme l’optimisation de l’utilité de ces tokens pour atteindre le résultat souhaité. En termes simples, l’agent doit disposer des informations appropriées, au bon format, au bon moment.
Anthropic le présente également comme l’étape naturelle suivante après l’ingénierie des prompts. Tout ce qui concerne l’élaboration des prompts reste applicable (instructions claires, bons exemples, formatage structuré), mais un niveau supplémentaire s’ajoute : des outils, des données externes, un historique des messages, de la mémoire et un état dynamique. L’ingénierie des prompts devient ainsi un sous-ensemble de cette approche.
Le moment est crucial. Gartner prévoit que 40 % des applications d’entreprise intégreront des agents IA spécifiques à certaines tâches d’ici la fin de 2026, contre moins de 5 % en 2025. Ces agents remplacent les prompts statiques et les pipelines de récupération fixes par un système dynamique dans lequel chaque appel à un outil, chaque document récupéré et chaque décision est intégré dans une fenêtre qui se remplit de contenus que l’utilisateur n’a jamais demandés directement. Les équipes qui apprennent à gérer cela parviennent généralement à créer des agents fiables, car elles cessent de blâmer le modèle pour les problèmes provenant de ses entrées.
La fenêtre de contexte en tant que mémoire de travail
LangChain propose une analogie utile. Considérez le LLM comme un nouveau type de système d’exploitation : le modèle est l’CPU qui effectue le raisonnement, tandis que la fenêtre de contexte correspond à la RAM, la mémoire de travail qui stocke tout ce que le modèle peut voir actuellement. Tout comme un ordinateur ralentit lorsque la RAM est pleine, le raisonnement d’un agent se détériore à mesure que sa fenêtre de contexte se remplit.
Cet effet a un nom : la dégradation du contexte. Chroma a testé dix-huit modèles de pointe, parmi lesquels GPT-4.1, Claude 4, Gemini 2.5 et Qwen3, et a constaté que chacun d’eux performe moins bien à mesure que la longueur des entrées augmente, même bien en deçà de la limite annoncée. Un modèle disposant d’une fenêtre de 200 000 tokens peut déjà montrer une dégradation réelle à 50 000 tokens. Il n’y a pas de chute brutale, seulement une pente progressive. Les documents techniques d’Anthropic aboutissent à la même conclusion et considèrent cette dégradation comme un gradient.
La raison réside dans le fonctionnement des transformateurs. Chaque token prête attention à tous les autres tokens, ce qui génère n² de relations binaires. À mesure que la fenêtre s’agrandit, la capacité du modèle à en tenir compte diminue, un peu comme demander à quelqu’un de garder en tête un nombre croissant d’éléments. À un certain moment, certains éléments sont oubliés.
Un autre effet bien étudié est celui du « oubli au milieu ». Un groupe de recherche dirigé par Liu a découvert que l’attention suit une forme en U : le matériel situé au début du contexte est bien mémorisé, celui situé à la fin également, tandis que le matériel du milieu est négligé, avec une précision qui diminue de plus de trente points de pourcentage lorsque le passage pertinent passe du début au milieu. Imaginez un agent dont les instructions initiales se trouvent sous cinquante mille tokens de résultats générés par des outils ; ces instructions ont en fait disparu.
Les praticiens ont élaboré des règles empiriques. Les utilisateurs de Claude Code indiquent que la qualité du résultat commence à décliner vers 40 à 60 pour cent de la durée totale, bien avant toute limite stricte.
Qu’est-ce qui concurrence l’espace disponible ?
Sept types d’informations se disputent l’espace dans le contexte d’un agent :
- Le prompt du système, qui représente l’identité de l’agent : règles de comportement, flux de contrôle et directives pour différents types de tâches. Chez un agent, il s’agit de bien plus qu’une simple phrase type « assistant utile » et peut définir le fonctionnement global.
- Les définitions des outils. Chaque outil que l’agent pourrait utiliser nécessite un schéma décrivant ce qu’il fait, quels paramètres il prend et quand il doit être utilisé.
- Les résultats des outils. Chaque appel ajoute son propre résultat. Une page web téléchargée peut contenir de cinq à dix mille tokens, et il en va de même pour un fichier lu.
Les quatre stratégies fondamentales, avec des exemples RAG et Claude Code
Avec une fenêtre de temps finie et en déclin, les questions portent sur ce qui entre, ce qui reste à l’extérieur et ce qui est compressé. Le cadre largement cité de LangChain classe chaque technique d’ingénierie de contexte en quatre catégories : écrire, sélectionner, compresser et isoler. Une fois ces catégories maîtrisées, presque toute technique rencontrée se retrouvera dans l’une d’elles.
Écrire
Les agents oublient. Lorsqu’un contexte complet est compressé, les informations disparaissent, et si l’agent ne les a pas enregistrées ailleurs, elles sont perdues. Écrire signifie fournir à l’agent des moyens de conserver des informations en dehors de cette fenêtre de temps. Cela prend trois formes courantes.
Scratchpads sont un outil de prise de notes que l’agent peut utiliser en cours de tâche pour enregistrer des résultats provisoires, des décisions et des éléments dont il aura besoin plus tard. Anthropic a développé un outil « think » qui offre à Claude un espace dédié pour résoudre un problème, et sur le benchmark tau-bench, il a amélioré les performances de jusqu’à 54 % pour certaines tâches.
Fichiers de règles agissent comme une mémoire procédurale persistante. Les utilisateurs de Claude Code connaissent CLAUDE.md. Ces fichiers s’chargent au début de chaque session en tant qu’instructions permanentes, couvrant l’architecture du projet, les conventions, la manière de lancer des tests et les points à surveiller, afin que les bases ne soient jamais oubliées.
Extraction de la mémoire permet à l’agent de stocker des faits, des préférences et des schémas appris dans un système basé sur des fichiers et de les consulter lors de sessions ultérieures, complètement en dehors de la fenêtre de dialogue.
Sélectionner
Les notes ne sont utiles que si les bonnes reviennent au bon moment. La sélection consiste à fournir à l’agent ce dont il a besoin pour cette étape, et non tout ce qu’il pourrait utiliser. Un agent disposant de dizaines d’outils, d’une vaste base de connaissances et de plusieurs sessions d’historique ne peut pas tout charger en même temps ; il faut donc que quelque chose décide de ce qui est pertinent, et la vraie question est de savoir qui prend cette décision.
Dans le RAG classique, c’est le système qui décide. Une question arrive, des documents sont récupérés et intégrés dans le prompt, sans que le modèle n’ait voix au chapitre. Dans le RAG agent, c’est l’agent lui-même qui choisit ce à rechercher, quels outils utiliser, comment affiner les requêtes et quand il en a assez. La récupération devient alors un processus itératif, ce qui est adapté car la pertinence change à chaque étape d’une tâche longue, et seul l’agent sait de quoi il a besoin ensuite.
LangChain et Pinecone distinguent trois types de mémoire auxquels on peut recourir. La mémoire épisodique correspond essentiellement à des exemples de quelques cas où une situation similaire a été gérée précédemment. La mémoire sémantique est un stock de faits que l’agent a appris ou auxquels on l’a informé. La mémoire procédurale représente les instructions comportementales permanentes, telles que les fichiers de règles mentionnés ci-dessus. Un agent bien conçu fait appel aux trois types de mémoire en fonction de l’étape à suivre.
Les outils causent les plus gros problèmes de sélection. Avec un peu plus de quarante outils, environ dix mille tokens de définitions peuvent se trouver dans le contexte avant même que le travail ne commence. Comme le montre la section sur les échecs ci-dessous, trop d’outils non seulement gaspillent de l’espace, mais confondent également activement le modèle.
La solution consiste à appliquer RAG aux descriptions des outils eux-mêmes, en effectuant une recherche sémantique qui ne met en évidence que les quelques outils que l’étape actuelle peut utiliser. Une étude intitulée RAG-MCP a testé cette approche et a constaté que la précision du choix des outils est passée d’environ 14 % à 43 %, soit plus du triple, tandis que le nombre de tokens de prompt a diminué d’environ la moitié.
Le conseil général d’Anthropic est d’adopter une approche hybride : charger à l’avance une petite quantité de matériel essentiel pour accélérer les choses, comme le fichier CLAUDE.md, et laisser l’agent récupérer le reste au moment opportun. En pratique, cela signifie que l’agent conserve des références légères telles que des chemins de fichiers, des requêtes et des liens, puis ouvre le contenu volumineux uniquement lorsque c’est nécessaire. En chargeant d’abord les éléments de base et en récupérant le reste sur demande, on maintient une structure légère sans priver l’agent d’informations importantes.
Compressez
Même avec une bonne sélection, la fenêtre continue de se remplir. Imaginez un agent qui reçoit vingt appels d’outils. Il transporte quatre-vingt mille tokens de résultats, d’historique et de traces de raisonnement, dont la plupart ont déjà été pris en compte. Ces données anciennes occupent encore de l’espace, détournent l’attention et augmentent les coûts ainsi que les délais. Il s’agit à nouveau du problème de la dégradation du contexte, que la compression résout en réduisant le nombre de tokens tout en conservant les informations importantes. Cela peut être fait en trois étapes.
Avant que les informations n’entrent dans le contexte. Le découpage en blocs permet de diviser de grands documents en parties plus petites et cohérentes, et le ré classement ne laisse passer que les meilleurs blocs dans la fenêtre. Les résultats des outils peuvent également être résumés en temps réel, avant qu’ils ne rejoignent le contexte principal.
Pendant que l’agent travaille. La technique la plus courante consiste à résumer la conversation : un résumé mis à jour après chaque échange permet de conserver un enregistrement compact de tout ce qui a été dit jusqu’à présent. Une méthode hybride populaire conserve mot pour mot les dix derniers messages, car des détails précis peuvent encore être nécessaires, et résume tous les messages plus anciens. Une autre option consiste à supprimer simplement les messages anciens dès que le seuil de taille est atteint, en utilisant des règles prédéfinies. Claude Code intègre une fonction d’auto-compaction qui résume l’ensemble de l’historique lorsque la capacité de la fenêtre atteint 95 %. Il s’agit d’une mesure de sécurité. Idéalement, la compression se fait à l’avance et non en cas de situation d’urgence.
Après que l’agent ait utilisé quelque chose. La solution la plus simple consiste à effacer les résultats des outils. Si un outil a exécuté quinze étapes en arrière et que l’agent a déjà agi sur les résultats, le texte brut peut être supprimé. Une page web complète chargée il y a longtemps peut être remplacée par un résumé en une seule ligne ou supprimée directement.
Isoler
L’isolation est ce qui rend les systèmes multi-agents fonctionnels. Supposons qu’un agent s’occupe de la recherche, de la planification, de la programmation, des tests et du débogage au cours d’une seule longue conversation. Son contexte se remplira, mais le problème plus grave est la contamination. Les recherches de fichiers effectuées lors de la phase de recherche restent présentes lorsque commence l’implémentation, et ce matériel ancien devient alors du bruit, distrayant le modèle au moment précis où il doit écrire du code propre.
La solution consiste à attribuer à chaque partie du travail des fenêtres de contexte distinctes.
La méthode évidente consiste à utiliser des sous-agents. Un agent principal confie une tâche précise, par exemple trouver tous les fichiers liés à l’authentification, à un sous-agent qui travaille dans sa propre fenêtre indépendante. Une fois la tâche terminée, ce dernier ne renvoie qu’un résumé condensé, tandis que toute la recherche complexe reste confinée au sous-agent sans affecter l’agent principal.
Une autre variante est l’isolation des schémas d’état, telle qu’implémentée dans LangGraph. L’état de l’agent est conçu de manière à ce que différents champs contiennent des types de contexte distincts, et le modèle ne voit que les champs pertinents pour l’étape actuelle. Les résultats des outils peuvent être stockés dans un champ réservé que le modèle ne consulte jamais, sauf si quelque chose les fait apparaître délibérément. Cela permet un contrôle fin sans avoir à créer des agents supplémentaires.
En bref, les stratégies sont l’écriture, la sélection, la compression et l’isolation, et tout ce qui suit applique l’une ou plusieurs d’entre elles.
Comment les agents échouent
Les modes de défaillance nous apprennent ce qu’il faut éviter. Au milieu de 2025, Drew Breunig a écrit une série en deux parties très influente dans laquelle il a identifié quatre manières distinctes par lesquelles les agents échouent à mesure que leur contexte s’élargit.
Empoisonnement du contexte. Une hallucination ou une erreur pénètre dans le contexte et y est ensuite référencée à maintes reprises. Peut-être qu’un outil a renvoyé des données erronées, ou que l’agent a tiré une inférence fausse il y a cinq étapes. L’erreur reste alors présente dans le contexte, et l’agent continue de s’appuyer sur elle ; comme les agents itèrent sur leurs propres sorties, chaque erreur se cumule. La solution réside dans le tri : supprimer activement les informations obsolètes ou contradictoires à mesure que de nouveaux détails apparaissent, valider les résultats des outils (en particulier ceux provenant de sources externes) avant qu’ils ne soient intégrés au contexte, et, une fois que l’agent a surmonté une erreur, compresser les tentatives infructueuses afin que dix étapes d’analyse sans issue ne persistent pas, alors que seule la résolution compte. Laisser ces tentatives en l’état continue de pousser le modèle à reprendre des approches qui ont déjà échoué.
Distraction due au contexte. Lorsque le contexte est très long, le modèle commence à s’appuyer excessivement sur les événements récents et trop peu sur ce qu’il a appris pendant l’entraînement. Il cesse de synthétiser quelque chose de nouveau et répète les schémas qu’il a vus récemment, se contentant de reproduire des actions passées au lieu d’élaborer un plan original. La solution reste le même conseil général : résumer et éliminer de manière sévère, même si la fenêtre de contexte est très large.
Confusion du contexte. Le modèle intègre du contenu superflu, ce qui diminue la qualité des réponses. Le cas classique est la confusion des outils. Une étude de référence a testé un modèle Llama 3.1 8B quantifié sur l’outil de benchmark GeoEngine. Avec les quarante-six outils disponibles, le modèle a échoué, bien que le contexte soit resté largement dans ses limites. Avec seulement dix-neuf outils, il a fonctionné. Les outils entraient bien dans les limites prévues, mais leur nombre était trop élevé pour que le modèle puisse raisonner de manière claire. La solution réside dans une gestion dynamique des outils : il faut réduire le nombre d’outils disponibles à ceux qui correspondent à la phase actuelle de l’agent, en utilisant un système de récupération de type RAG-MCP pour sélectionner ceux qui sont pertinents à chaque étape.
Conflit de contexte. Les nouvelles informations recueillies au cours d’une mission contredisent des éléments déjà présents dans le contexte. L’instruction système peut indiquer une chose tandis qu’un document récupéré en dit une autre. L’agent ne parvient pas à les concilier et se comporte de manière incohérente, suivant parfois une source, parfois l’autre, et parfois agissant de manière qui ne correspond à aucune d’elles. La solution réside dans une hiérarchie claire des sources : l’instruction système avant les faits récupérés, et ces derniers avant l’historique de la conversation. Il faut valider les nouvelles informations par rapport à ce qui existe déjà avant de les intégrer, et utiliser des sections structurées telles que des balises XML ou des en-têtes clairs afin que le modèle puisse déterminer d’où provient chaque élément et jusqu’à quel point il peut lui faire confiance.
La bonne nouvelle, c’est que nommer un échec indique généralement une stratégie. Le problème de « contamination » est géré par la compression et le tri, celui de la « distraction » par la compression, celui de la « confusion » par la sélection, et celui des « conflits » par une rédaction structurée et une sélection rigoureuse. Tout revient finalement à écrire, sélectionner, compresser et isoler.
Indications système pour les agents
Indiquer des instructions à un agent diffère fortement de celles données à un chatbot. Les instructions pour un chatbot visent principalement à fixer un ton : être amical, rester bref. Les instructions pour un agent définissent son architecture. Elles précisent le flux de contrôle, c’est-à-dire comment gérer différents types de tâches, quels outils conviennent à quelles situations, que faire en cas d’erreur et quels limites de sécurité s’appliquent. Cela ressemble davantage à une description de poste pour un employé autonome.
Anthropic parle de l’importance d’écrire à la bonne altitude, il existe une zone Goldilocks. Être trop prescriptif rend le système fragile. Imaginez une règle exigeant d’utiliser l’outil X chaque fois que l’utilisateur mentionne la facturation, demande un remboursement et que le montant dépasse cent dollars : elle échoue face à chaque cas limite non prévu. Être trop vague est tout aussi problématique. L’instruction « Soyez utile et utilisez les outils appropriés » ne donne rien à l’agent, car il ne sait pas quels outils sont adaptés à quoi et ne peut pas prendre de décisions sans des indications concrètes. Le point idéal est d’être suffisamment spécifique pour guider le comportement autonome, tout en étant suffisamment souple pour permettre au modèle d’utiliser son jugement dans de nouvelles situations. Pensez à des heuristiques solides, pas à des règles rigides.
Quelques habitudes pratiques aident :
- Donnez une structure à la demande, avec des balises XML ou des en-têtes Markdown qui séparent les informations générales, les instructions et les indications relatives aux outils.
- Commencez avec le minimum nécessaire et itérez en fonction des échecs. Exécutez l’agent sur des tâches réelles, identifiez où il échoue et ajoutez des instructions ciblant ces échecs spécifiques, plutôt que de tenter de prédire à l’avance tous les cas limites.
- Le minimum n’est pas synonyme de court. Une instruction pour un flux de travail complexe peut compter des milliers de tokens, ce qui est acceptable tant que chaque token a une raison d’être.
- Utilisez des exemples de type few-shot. Montrer des cas variés et exemplaires de choix de outil correct, de raisonnement solide et d’exécution en plusieurs étapes vaut mieux que de décrire chaque règle par des mots.
Définitions des outils
Chaque outil appelable nécessite un schéma décrivant son objectif, ses paramètres et les situations où il doit être utilisé. Une bonne définition est autonome, tolérante aux erreurs et claire quant aux instructions à suivre, au prix d’un espace de contexte accru.
Dans la production, les outils sont de plus en plus connectés via MCP, le Model Context Protocol, une méthode standard permettant aux agents d’accéder à des outils et des données externes. Un serveur MCP pour GitHub, un autre pour la base de données, un troisième pour le système de fichiers, tous exposant des outils à travers une interface uniforme. Le problème, c’est que l’intégration d’outils devient si facile qu’on en fait trop. Avec quatre ou cinq serveurs connectés, les définitions peuvent consommer des milliers de tokens avant même d’effectuer la première action.
Le conseil par défaut est de sélectionner un ensemble minimal viable. Lorsqu’un agent a réellement besoin de nombreux outils, deux approches s’avèrent efficaces.
Le premier exemple provient de Manus, une plateforme d’agents de production. Ils déconseillent d’ajouter ou de supprimer des outils au milieu d’une conversation, pour une raison que de nombreux développeurs ignorent : le cache KV. Lorsque des tokens sont envoyés à un LLM, le modèle calcule des représentations clé-valeur pour chacun d’eux, ce qui est coûteux, c’est pourquoi les fournisseurs les mettent en cache. Si le début du contexte (le préfixe) est identique entre les appels, le fournisseur réutilise le travail en cache et ne traite que les nouveaux tokens à la fin, ce qui est plus rapide et moins cher.
Si l’on réorganise ou modifie la partie initiale du contexte entre les appels, le cache devient invalide, ce qui oblige à recalculer tout le contenu. Avec Claude Sonnet, les tokens d’entrée en cache coûtent trente cents par million, contre trois dollars par million pour ceux qui ne sont pas en cache, soit une différence de dix fois. Un agent effectuant trente ou quarante appels par tâche le ressent rapidement.
C’est pourquoi Manus préfère le masquage des outils à leur suppression. Chaque définition reste en place dans le préfixe mémorisé, mais certains outils sont marqués comme indisponibles pour la phase actuelle. Les définitions restent en place pour assurer la stabilité du cache, tandis que l’agent sait à ne pas les utiliser ; de plus, des préfixes de nommage cohérents l’aident à raisonner sur les catégories d’outils.
La deuxième approche est la sélection basée sur RAG déjà mentionnée : il s’agit de récupérer uniquement les outils pertinents pour l’étape actuelle, ce qui, comme l’ont montré les travaux RAG-MCP, a permis d’augmenter la précision de plus de trois fois tout en réduisant d’un facteur deux l’utilisation de tokens. Ces deux méthodes se complètent mutuellement : le masquage convient à un ensemble d’outils modéré, tandis que la récupération convient à un ensemble très large.
Un principe fondamental régit les deux cas. Le contenu stable se trouve en haut du contexte : l’instruction système, les définitions des outils et tout ce qui ne change pas entre les tours. Le contenu dynamique (l’historique, l’étape actuelle, l’état de l’agent) se trouve en bas.
Un flux de travail en phases qui combine tout
Ces principes s’appliquent aussi bien à un assistant de codage prêt à l’emploi qu’à un agent développé sur mesure. La seule différence réside dans le fait de structurer soi-même le flux de travail ou de créer l’agent pour cela.
Dex Horthy, PDG de HumanLayer, a donné une conférence au AI Engineer Code Summit pour présenter une méthode qui illustre tout cela de manière claire. Son équipe l’aurait utilisée pour intégrer environ trente-cinq mille lignes de code dans une grande base de code Rust en une seule session de sept heures. Il l’appelle « Frequent Intentional Compaction ». Le travail est délibérément divisé en phases ; chaque phase produit un artefact compact, comme un résumé structuré en markdown, et chaque nouvelle phase commence dans une fenêtre vierge contenant uniquement cet artefact. L’objectif est de maintenir délibérément l’espace utilisé entre 40 et 60 pour cent environ.
Première phase : recherche. Avant même que du code ne soit écrit, l’agent explore la base de code : il lit les fichiers, suit les flux de données et cartographie l’architecture pertinente pour la tâche. Les sous-agents effectuent les recherches et analyses brutes, de sorte que tous les résultats de grep ainsi que le contenu des fichiers restent dans leurs fenêtres sans jamais toucher celles du parent. C’est cela l’isolation. Le résultat de cette phase est un fichier de recherche, un document Markdown compact contenant des chemins de fichiers, des signatures de fonctions, des modèles existants et des pièges potentiels. C’est déjà une forme d’écriture, puisque les découvertes sont mémorisées en dehors de la fenêtre. Ensuite, le contexte est réinitialisé. La recherche brute peut occuper de 60 à 80 pour cent de l’espace de la fenêtre, tandis que le fichier de résultat réduit cette occupation à environ 15 à 20 pour cent. C’est cela la compression.
Deuxième phase : la planification. Une nouvelle fenêtre s’ouvre, ne contenant que le fichier de recherche et la description du problème, et l’agent utilise cette page vierge pour rédiger un plan d’implémentation détaillé. C’est également le meilleur endroit pour une révision par un humain. Une erreur logique détectée ici est facile à corriger, c’est pourquoi toute personne développant son propre agent devrait intégrer un point de contrôle impliquant un humain à ce stade.
Troisième phase : l’implémentation. Une autre fenêtre vierge ne contient que le plan, et l’agent le suit étape par étape. Pour les tâches nécessitant plusieurs cycles de compression, un fichier progress.md enregistre ce qui a été terminé et ce qui reste, ce qui représente une nouvelle opération d’écriture.
Une version de ce processus se retrouve dans la plupart des systèmes en production.
Comment les produits réels gèrent le contexte
Claude Code. L’agent de codage en ligne de commande d’Anthropic fait partie des cas le mieux documentés. Il utilise une récupération hybride : les fichiers CLAUDE.md sont chargés au début de chaque session pour fournir un contexte de base, tandis que des outils tels que glob et grep permettent une exploration en temps réel du codebase. Il ne crée pas d’index préalable de tout le contenu, mais explore sur demande. L’auto-compaction s’active à 95 % d’utilisation et conserve les décisions architecturales ainsi que les cinq fichiers consultés récemment. Il peut générer des sous-agents avec des environnements propres pour des sous-tâches complexes, et un outil de mémoire permet de conserver les informations entre les sessions. La philosophie directrice est de faire la chose la plus simple qui fonctionne, en faisant confiance au modèle pour savoir ce dont il a besoin et en lui fournissant les outils nécessaires pour le trouver.
Manus. Il s’agit de l’approche nécessitant davantage d’infrastructures, ce qui est logique pour un agent polyvalent servant des centaines de milliers d’utilisateurs, où l’efficacité à grande échelle est cruciale. Sa caractéristique principale est un ordonnancement tenant compte du cache KV, qui maintient le préfixe stable d’une partie à l’autre pour une réutilisation maximale du cache, ainsi que l’utilisation de masques plutôt que la suppression des outils. Un pipeline de compression des observations traite toutes les sorties d’outil avant qu’elles n’atteignent le contexte de l’agent. Une liste de tâches persistante suit l’état, et le système de fichiers sert de mémoire de secours pour le contexte évincé.
ChatGPT Agent. L’agent d’OpenAI, issu d’Operator, diffère architecturalement des deux autres. Équipé d’un modèle Computer-Using Agent, il adopte une approche centrée sur l’interface graphique. Au lieu d’appels d’outils basés sur du texte, il utilise un navigateur visuel, et les captures d’écran entrent dans le contexte sous forme de snapshots que le modèle analyse en conjonction avec son historique de captures précédentes et d’actions. La difficulté du problème change en conséquence. Les tokens visuels étant coûteux, l’agent doit être sélectif quant au nombre de captures d’écran qu’il conserve. OpenAI utilise l’apprentissage par renforcement pour découvrir de bonnes stratégies d’utilisation des outils, en s’entraînant sur des milliers de machines virtuelles plutôt que de définir par code fixe quand utiliser tel ou tel outil. Deep Research et Operator partagent leur état, ce qui permet des transitions fluides entre la navigation, l’analyse de texte et l’exécution de code. Par rapport à Claude Code, axé sur le code, utilisant des outils de texte et des fenêtres larges, celui-ci est visuel et polyvalent. Les deux exigent une gestion du contexte, mais avec des problématiques et des solutions différentes.
Google's Agent Development Kit. ADK adopte la position architecturale la plus fondée, avec trois principes de conception pour le contexte des agents. Séparer le stockage de la présentation, car un état durable n’est pas identique à ce qui apparaît dans une requête API donnée. Utiliser des transformations explicites, c’est-à-dire des processeurs nommés et ordonnés qui restructurent le contexte en étapes testables et composables, plutôt que des concaténations de chaînes de caractères ad hoc. Limiter le contexte par défaut, de sorte que chaque appel au modèle ne voie que le minimum nécessaire, et rien ne soit ajouté au contexte sauf s’il est explicitement inclus. Le résultat considère l’assemblage du contexte comme un pipeline à étapes bien définies, et non comme une requête à laquelle on continue d’ajouter des éléments.
Le pipeline de contexte commun
En examinant ces plateformes, on observe toujours la même séquence à chaque tour de l’agent :
- Récolter des candidats : entrées de l’utilisateur, historique, résultats des outils, documents récupérés et état de l’agent.
- Sélectionner ce qui est pertinent pour cette étape dans le budget de tokens restant.
- Compresser en résumant, en tronquant ou en restructurant la sélection pour qu’elle tienne dans les limites.
- Organiser tout cela pour une réutilisation dans le cache KV, en plaçant d’abord le contenu stable et en dernier le contenu dynamique.
- Assembler le contexte final et effectuer l’appel.
Le domaine évolue rapidement et il reste beaucoup à apprendre ; par conséquent, la meilleure façon d’améliorer ses compétences est de faire des expériences : créer quelque chose, observer où cela échoue et ajuster en conséquence.
Lectures complémentaires
- Ingénierie du contexte pour les applications LLM : Sorties structurées, outils et limites des agents : Comment concevoir délibérément les entrées des modèles : sélection du contexte, modèles de prompts, schémas JSON, décodage contraint, appels d’outils, boucles d’agents et autonomie limitée.
- Stratégies de chiffrement pour RAG en production : Taille fixe, sémantique et parent-enfant : Une présentation pratique du chiffrement RAG, allant du découpage par taille fixe et de la séparation récursive au système parent-enfant, aux propositions, au chiffrement tardif, à RAPTOR, aux tableaux, au code et aux tests de performance.