Ingénierie du contexte pour les agents à exécution prolongée : bases de données vectorielles, cache KV, Claude Code

Beaucoup a été écrit sur ce qu’est l’ingénierie de contexte. Beaucoup moins aborde la question à laquelle se heurte un développeur en pratique : comment concevoir le pipeline de contexte pour un agent qui exécute 200 étapes ? Une fenêtre de un million de tokens semble généreuse, mais une étude de Chroma en 2025 portant sur 18 modèles de pointe aurait révélé que la qualité commence à décliner dès que la fenêtre est remplie de 50 à 70 pour cent. Ce qui suit est un plan d’action pour y faire face, destiné aux personnes qui déploient des agents en production. Il explique pourquoi les contextes longs se détériorent, un modèle de mémoire emprunté à l’architecture informatique, quatre patterns pour gérer le contexte, les aspects économiques du cache KV, les différences entre trois produits bien connus, ainsi qu’un processus de décision accompagné de métriques.

Un agent sans conception de mémoire souffre d’amnésie

Imaginez un agent qui exécute correctement les étapes 1 à 40. À l’étape 41, il semble oublier l’objectif et commence à répéter des décisions qu’il a déjà prises. Il s’agit rarement d’une erreur logique. C’est la détérioration du contexte, la baisse mesurable de la qualité des réponses à mesure que la longueur des entrées augmente. Plus le modèle reçoit d’informations, plus il perd en efficacité.

Des recherches publiées par Zylos AI en 2026 indiquent la même tendance : doubler la durée d’une tâche multiplierait par quatre les chances d’échec, et les agents semblent se dégrader après environ 35 minutes d’exécution équivalente. Les résultats de Chroma mentionnés précédemment montrent que chacun des 18 modèles a vu sa performance diminuer à mesure que le contexte s’aggravait. Le benchmark NoLiMa (ICML 2025) a montré des effets encore plus marqués. Avec seulement 32 K de tokens, 11 des 13 modèles auraient atteint une performance inférieure à la moitié de leurs valeurs de référence, bien qu’ils aient été annoncés comme capables de gérer 128 K ou plus de tokens ; GPT-4o, quant à lui, est passé de 99,3 % à 69,7 %.

Pourquoi la dégradation est inhérente

La mécanique d’attention compare chaque token avec tous les autres tokens. Doubler la longueur du texte entraîne donc environ quatre fois plus de calculs, et non deux fois. Avec 200 000 tokens, cela représente l’ordre de 40 milliards de paires d’attention par couche. Intégrer tout cela dans le contexte ne permet pas une adaptation efficace pour un agent qui doit effectuer des centaines d’étapes.

Un deuxième effet est celui du « oubli au milieu ». Les modèles gèrent le mieux le début et la fin d’un contexte long, mais perdent en précision au milieu, de sorte qu’un fait important caché là-bas peut devenir presque invisible. Curieusement, un texte cohérent et bien organisé mais irrelevant nuit davantage à la précision que les mêmes phrases mélangées au hasard. La similarité sémantique au sein de ce bruit rend le signal réel encore plus difficile à détecter.

La taille de la fenêtre annoncée est également trompeuse. Un modèle qui accepte un million de tokens ne dispose pas d’une capacité utile équivalente à un million de tokens.

Anxiété de contexte

Les utilisateurs ont observé, et Anthropic l’a reconnu, un autre défaut : Claude Sonnet 4.5 avait tendance à terminer les tâches trop tôt en approchant de la limite de contexte. Cela a été qualifié de anxiété de contexte. Le modèle se comporte comme s’il manquait de mémoire vive et recule avant même que ses ressources ne soient réellement épuisées.

Puisque la dégradation est inévitable, l’architecture de l’agent doit la gérer. L’ingénierie des systèmes propose une analogie ancienne qui aide à y faire face.

Le modèle est la CPU, le contexte est la mémoire vive, la base de données vectorielle est le disque

Au milieu de 2025, Andrej Karpathy a préféré l’« ingénierie de contexte » à l’« ingénierie de prompts », la décrivant comme l’art et la science délicats consistant à remplir la fenêtre de contexte uniquement des informations appropriées pour l’étape suivante. Il ne créait pas simplement un nouveau terme à la mode ; il soulignait plutôt un changement de perspective : le LLM est l’unité centrale de traitement, la fenêtre de contexte correspond à la mémoire vive, et l’ingénieur qui conçoit l’agent joue le rôle du système d’exploitation.

Cette analogie s’applique très naturellement dans la pratique. La compression ressemble à la collecte de déchets, l’injection d’état évoque une séquence de démarrage, les sous-agents correspondent à l’isolation des processus, et un fichier comme CLAUDE.md représente la configuration chargée au démarrage. Ce qui change, c’est l’accent mis : on consacre moins d’efforts à la formulation du prompt et davantage à ce qui est chargé en mémoire et quand.

Une hiérarchie de mémoire pour les agents

Un agent possède une hiérarchie tout comme un ordinateur, et chaque niveau compromet la vitesse au profit de la capacité :

• Mémoire de travail dans le contexte. Aucune latence supplémentaire, de 200 K à 1 M de tokens. Elle correspond aux registres et au cache L1 : la plus rapide, la plus coûteuse et la plus limitée.
• Cache KV. Moins de 10 ms. Comparable au cache L2 ou L3, il stocke des matrices d’attention précalculées pour des tokens antérieurs et conservées entre les requêtes.
• Base de données vectorielle ou recherche sémantique. Environ 5 à 50 ms et des millions d’entrées, l’équivalent de la RAM. Les valeurs citées incluent environ 0,34 ms par requête pour FAISS exécuté localement et 7 ms p99 pour Pinecone.
• Système de fichiers ou notes. Plus de 100 ms sans véritable limite de taille, comme un disque.
• Stockage d’archivage. Secondes pour la lecture, comparable au stockage réseau ou de sauvegarde.

Chaque décision concernant l’endroit où se trouve une information représente un compromis entre coût, latence et capacité. Choisir le mauvais niveau de stockage entraîne soit des factures élevées, soit des agents qui oublient. Le travail de MemGPT de 2023, largement cité, a formalisé cette idée sous le nom de « gestion de contexte virtuel », en s’inspirant de la manière dont les systèmes d’exploitation gèrent la mémoire hiérarchisée. Ce concept se poursuit aujourd’hui sous le nom de framework Letta.

Si le contexte correspond à la RAM de l’agent, quels schémas le gèrent dans un système réel, et comment s’articulent-ils entre eux ?

Quatre schémas : écrire, sélectionner, compresser, isoler

La conception du contexte repose sur quatre schémas de base. Ce ne sont pas des alternatives à choisir entre elles ; ce sont plutôt des couches complémentaires d’un même design global, et chaque agent en production finit par utiliser les quatre.

Écrire : placer l’état en dehors de la fenêtre de contexte

Écrire signifie externaliser l’état. L’agent conserve des notes dans un fichier tel que todo.md, NOTES.md ou progress.md et les lit à nouveau lors des étapes suivantes. Manus est connu pour la « récitation de la liste de tâches » : l’agent réécrit constamment sa liste de tâches tout en bas du contexte afin d’attirer l’attention du modèle vers le plan global. Il s’agit d’une orientation délibérée de l’attention, qui counterbalance l’effet de perte dans le milieu du processus.

Claude Opus 4, dans une expérience de jeu Pokémon, aurait conservé des notes précises au cours de milliers d’étapes de jeu, couvrant les niveaux des personnages, les cartes et les stratégies, sans aucune instruction explicite concernant la manière de structurer sa mémoire.

Sélection : récupérer juste à temps

Le choix de cette méthode consiste à récupérer le contexte au moment où il est nécessaire plutôt que de le charger à l’avance. CLAUDE.md agit comme un chargement préalable statique, un peu comme un document d’intégration remis à un nouvel employé dès le premier jour. Par la suite, l’agent explore le codebase à l’aide de grep et glob et ne récupère que ce dont il a besoin pour l’étape en cours.

Claude Code aurait testé des bases de données vectorielles avant de les abandonner, car le code peut devenir désynchronisé et les permissions deviennent complexes. Cursor a choisi une approche différente, en misant sur une découverte dynamique grâce à l’indexation sémantique. Un test A/B aurait montré une réduction de 46,9 % des tokens lorsque l’agent chargeait les outils MCP sur demande.

Compressez : réduisez le volume

La compression consiste à réduire le volume en résumant ou en tronquant le contenu. La compactation demande à un LLM de résumer la conversation jusqu’à présent, libérant ainsi de l’espace tout en conservant l’essentiel.

Claude Code avertit apparemment lorsque la capacité atteint environ 80 % et compresse automatiquement à près de 95 %, tout en respectant les décisions architecturales. Une compression trop agressive élimine des éléments contextuels subtils mais essentiels, ce qui pousse l’agent à reconsulter des zones déjà examinées. En pratique, un taux de compression de 3 à 6 fois semble être l’optimum pour les travaux en production. Les benchmarks académiques indiquent des ratios bien plus élevés (LLMLingua cite 20 fois avec une perte de précision de seulement 1,5 point sur GSM8K), mais l’utilisation en production exige une plus grande fidélité.

Isoler : séparer par des sous-agents

L’isolation consiste à maintenir les contextes séparés. Un agent enfant spécialisé travaille dans sa propre fenêtre de contexte et renvoie un résultat condensé à son parent. Il peut explorer 10 000 tokens ou plus, mais ne restitue qu’un résumé de 1 000 à 2 000 tokens, ce qui est bien moins que ce que pourrait accumuler un contexte partagé. Manus applique un principe emprunté à Go : ne pas communiquer en partageant de la mémoire, mais partager de la mémoire en communiquant.

Il ne s’agit pas de choisir le bon modèle, mais de savoir comment les combiner et quand chacun doit être activé. L’écriture combinée à la sélection constitue la première ligne de défense, tandis que la compression associée à l’isolation permet à un système de s’échelonner.

Une partie de la gestion du contexte a un impact considérable sur les coûts de production et est souvent négligée lors de la conception.

Taux de réussite du cache KV, le chiffre qui compte

Le cache KV stocke les matrices d’attention déjà calculées pour des tokens précédents, de sorte que le modèle n’a pas besoin de les recalculer pour chaque nouveau token. Imaginez une base de données qui calcule à l’avance les jointures pour les préfixes de requêtes fréquents. Lors d’une mesure sur GPT-2, la génération de 200 tokens a nécessité 11,9 secondes avec le cache et 56,2 sans, soit une accélération d’environ 4,7 fois.

Pourquoi cela change l’économie des agents

Un agent de production typique présente un rapport entrée/sortie d’environ 100 à 1, contre environ 1 à 1 pour un chatbot. La recalculation de toute l’entrée, appelée préremplissage, domine chaque appel. Le cache de prompts est un mécanisme du côté du fournisseur qui stocke les tokens calculés pour des préfixes identiques entre les requêtes, ce qui rend les lectures environ dix fois moins coûteuses. Pour Claude Sonnet, les prix indiqués sont de 0,30 $ par million de tokens en cache contre 3,00 $ sans cache.

Ainsi, en repensant la conception du contexte autour du cache KV, il est possible de réduire considérablement une facture API mensuelle de 8 000 dollars à 800 dollars, ce qui correspond au rabais de dix fois appliqué par Anthropic pour le caching. Yichao “Peak” Ji, cofondateur de Manus, a déclaré que, pour un agent en production, rien n’est plus important que la fréquence à laquelle le cache KV est consulté.

Trois règles pour maintenir le cache actif

• Un préfixe stable. Une différence d’un seul token entraîne une erreur de cache. Une erreur souvent mentionnée par Manus consiste à placer une date et une heure en haut du message système : cela permet au modèle de lire l’heure et dégrade fortement le taux de réussite des consultations.
• Un contexte uniquement en appendice. Seule l’ajout de contenu au contexte est autorisé, sans jamais pouvoir le modifier a posteriori. L’historique reste immuable, car toute modification provoque une erreur de cache. La sérialisation JSON doit également être déterministe, car l’ordre des clés a de l’importance.

Points de rupture de cache explicites. Indiquez des points dans le contexte qui indiquent au fournisseur où stocker le préfixe.

Il existe également un problème lié à l’échelle, parfois appelé « taxe MCP ». Supposons que 10 à 15 outils contiennent chacun de 10K à 15K de tokens de définitions. Cela représente de 100K à 225K de tokens de surcharge avant même que l’utilisateur n’ait tapé quoi que ce soit. Pour 1 000 développeurs ayant cinq sessions par jour, une estimation approximative montre que cela coûte près de 1,2 million de dollars par an rien que pour les définitions des outils. La solution réside dans la divulgation progressive : charger les outils juste au moment nécessaire plutôt que tous en même temps.

Les taux de réussite du cache et les quatre modèles sont théoriques. À quoi ressemblent-ils dans des systèmes qui ont déjà rencontré ce problème en production ?

Claude Code et deux autres produits, trois philosophies

Claude Code, Cursor et Manus proposent trois réponses cohérentes mais différentes au même problème. Chacune découle de son propre contexte de travail plutôt que d’une ignorance des alternatives.

Claude Code : préchargement statique associé à des lectures just-in-time

Claude Code, développé par Anthropic, charge CLAUDE.md au début de la session en tant que document d’intégration, puis navigue dans le codebase à l’aide de glob et grep, sans base de données vectorielle. Il compresse automatiquement près de 95 % du contenu tout en préservant les décisions architecturales. La combinaison d’un outil de mémoire avec l’édition de contexte aurait permis une amélioration de 39 % par rapport au niveau de base.

Au niveau de Sonnet 4.5, l’anxiété liée au contexte obligeait le modèle à être réinitialisé avec des données externes. Anthropic aurait résolu ce problème dans les versions ultérieures du modèle sans modifier l’architecture de l’outil.

Cursor : deux niveaux et découverte dynamique

Cursor (développé par Anysphere) sépare le « contexte d’intention », c’est-à-dire ce que l’utilisateur demande, du « contexte d’état », qui représente l’état actuel des fichiers, des modifications et des erreurs. Par défaut, il ne lit que les 250 premières lignes de tout fichier, choix délibéré visant à économiser des tokens et de l’argent.

Un changement notable a eu lieu en janvier 2026. Cursor a indiqué que, à mesure que les modèles devenaient de meilleurs agents, il était plus efficace de fournir moins de détails au départ et de laisser l’agent récupérer lui-même le contexte pertinent. Le test A/B mentionné précédemment a montré une réduction de 46,9 % des tokens par rapport au chargement sur demande.

Manus : descente de gradient par essais et erreurs

Manus décrit son approche comme une « descente de gradient stochastique », le système de fichiers servant de contexte ultime. On rapporte qu’il a reconstruit son framework cinq fois depuis mars 2025. Selon Ji, l’ingénierie de contexte s’est avérée loin d’être simple et constitue une science expérimentale.

Six principes sont attribués à l’équipe :

• Placer le cache KV en premier.
• Utiliser des outils de masquage plutôt que de les supprimer, afin de préserver le cache.
• Considérer le système de fichiers comme une mémoire externe illimitée.
• Réciter la liste des tâches à accomplir pour orienter l’attention vers le plan global.
• Conserver les erreurs dans le contexte, car effacer une erreur élimine les preuves.
• Varier les modèles de sérialisation pour éviter le piège des quelques exemples.

Ce que la comparaison nous apprend

Aucune philosophie n’est absolument correcte. Claude Code est conçu pour de longues sessions de codage nécessitant stabilité. Cursor est destiné à de courtes sessions assistées qui réagissent dynamiquement au contexte de l’éditeur. Manus a été développé pour des agents web entièrement autonomes effectuant 50 appels d’outils ou plus par tâche. Cinq reconstitutions effectuées avec Manus montrent une chose fondamentale : l’ingénierie de contexte est une discipline empirique, et non un plan prêt à l’emploi une fois assemblé. Chaque système en production subira ses propres itérations.

Il est facile de penser que des fenêtres de traitement plus grandes résoudront le problème, puisqu’un million de tokens devrait suffire. Les données de NoLiMa et Chroma infirment rapidement cette hypothèse. Claude 4 Sonnet montre une résistance nettement meilleure à la dégradation du contexte que les modèles plus anciens, mais il s’agit d’une exception qui confirme la règle, et non d’une preuve que le problème a disparu.

Ces systèmes et modèles décrivent ce qui fonctionne. Il reste alors à les transformer en choix de conception concrets pour un agent donné, et à déterminer si la conception du contexte remplit bien sa fonction.

Un plan directeur : quoi utiliser et quoi mesurer

Une étude de mars 2026 sur l’architecture multi-agent au sein des entreprises (arXiv:2603.09619, portant sur le passage des prompts à l’ingénierie de contexte) propose cinq critères de qualité du contexte, et considère ce dernier comme le système d’exploitation de l’agent :

• Relevance. L’information est-elle pertinente pour l’étape de décision actuelle ? Un contexte irrélevant nuit directement.
• Suffisance. L’agent dispose-t-il de tout ce dont il a besoin, sans avoir à deviner ?
• Isolation. Les contextes des agents sont-ils correctement séparés, afin que les données du locataire A ne s’échappent jamais vers le locataire B ?
• Économie. Le contexte correspond-il à l’ensemble le plus réduit possible de tokens à forte signification ? Chaque token inutile épuise le budget d’attention.
• Provenance. Pouvez-vous retracer l’origine de chaque élément du contexte ? Cela est important pour le débogage.

Un chemin de décision

Pour une tâche courte, comptant environ 20 étapes sans dépendances à long terme, une fenêtre glissante suffit. Conservez les derniers N échanges ainsi que les instructions système de référence. Il n’y a pas de surcoût et l’implémentation est la plus simple.

Pour une tâche de longue durée, où une décision prise à l’étape 5 affecte l’étape 50, utilisez une compression qui préserve les décisions architecturales. Avertissez à environ 80 % de capacité et compressez automatiquement à environ 95 %.

Pour les tâches secondaires indépendantes utilisant plus de 10 outils, utilisez des sous-agents qui génèrent des résumés de 1 000 à 2 000 tokens chacun, travaillant dans une fenêtre propre.

Pour de nombreux outils mais des sessions courtes, chargez les outils au moment opportun plutôt que de tout précharger. La divulgation progressive élimine le fardeau lié à MCP.

Quoi mesurer

Sans ces métriques, une architecture contextuelle n’a aucune capacité d’observation :

• Taux de croissance des tokens. Une croissance monotone et constante indique l’absence de stratégie de compression. Un schéma en dents de scie de hausse, de réinitialisation et de nouvelle hausse montre que la compression fonctionne.
• Taux de réussite du cache KV. Un taux inférieur à 50 % suggère que quelque chose dans le préfixe du prompt système change constamment. Vérifiez d’abord les timestamps et les autres éléments dynamiques.
• L’heuristique des 35 minutes. Les agents semblent décliner après environ 35 minutes d’exécution d’une tâche équivalente, il convient donc de planifier des points de contrôle en tenant cela à l’esprit.
• L’amnésie post-compaction. Si l’agent reconsidère des zones déjà explorées, la compaction est probablement trop agressive.

Un problème majeur pour quiconque conçoit de tels systèmes est l’absence de métrique standard pour quantifier les informations perdues lors de la compaction. L’erreur apparaît plus tard, et non au moment même de la compaction. Le meilleur moment pour effectuer la compaction reste un problème non résolu, car la faire trop tôt gaspille du temps et la faire trop tard entraîne des dégradations.

SWE-ContextBench (arXiv:2602.08316) confirme cela, montrant que des expériences non filtrées ou mal sélectionnées apportent des bénéfices limités ou même négatifs. Plus de contexte n’est pas toujours mieux, et un mauvais contexte nuit activement.

Règles d’ingénierie du contexte pour les agents à long terme

Concevoir un pipeline de contexte est une question différente de celle de savoir ce qu’est l’ingénierie du contexte, et cela entraîne quelques conclusions.

• La dégradation du contexte est une propriété intrinsèque des transformateurs. Un meilleur modèle ne la résout pas ; c’est une architecture de mémoire qui la gère.
• Le modèle correspond à la CPU, le contexte à la RAM, et l’ingénierie du contexte représente le système d’exploitation de l’agent, ce qui déplace la discussion de la linguistique vers l’ingénierie des systèmes.
• Écrire, sélectionner, compresser et isoler sont des étapes complémentaires, non des alternatives, et tout agent de production utilise les quatre.
• Le taux de réussite de la cache KV est un indicateur important, et une date et heure erronée dans un prompt système peut ajouter des dizaines de milliers de dollars à la facture mensuelle.
• Il n’existe pas de philosophie unique et correcte, comme le montrent Claude Code, Cursor et Manus.
• Une bonne ingénierie du contexte signifie l’application des cinq critères de qualité ainsi que l’utilisation de métriques mesurables, et non de l’intuition.

Une première étape pratique consiste à accorder une place prioritaire au contexte lors de la prochaine revue de conception des agents : où le statut est stocké, comment le cache KV est géré, quel est le seuil de compactage, et quels sous-tâches sont confiés aux sous-agents. Il ne s’agit pas d’une simple optimisation des performances, mais des fondements d’un système qui fonctionne correctement.