Ingénierie du contexte pour agents IA de longue durée

Pris ensemble, l’analyse d’Arize, l’article arXiv sur le débordement de fenêtre de contexte, l’explication de production de Redis et la comparaison d’ingénierie de harness d’Atlan indiquent un changement pratique dans la conception des agents. Les agents de longue durée sont de moins en moins jugés à la taille de la fenêtre de contexte du modèle, et de plus en plus à la couche de contrôle qui l’entoure. Arize rend ce changement concret. L’analyse cite des outils d’agents et des systèmes de mémoire/harness déjà livrés, notamment Pi, OpenClaw, Claude Code et Letta, comme exemples d’ingénierie du contexte au niveau du harness, et décrit un simulateur interactif montrant une fenêtre de 200 000 tokens en train de se remplir.

Les détails publics disponibles dans les sources citées sont inégaux. Arize fournit des chiffres d’implémentation concrets pour Pi, OpenClaw, Claude Code et Letta. Un article de recherche sur la résolution du débordement de fenêtre de contexte dans les agents IA donne un mécanisme plus général pour gérer les sorties d’outils susceptibles de dépasser n’importe quelle fenêtre pratique. L’explication de Redis sur le débordement de fenêtre de contexte résume les symptômes en production : erreurs API bloquantes, dégradation silencieuse de la qualité, accumulation de sorties d’outils et latence accrue à mesure que les prompts grossissent. La comparaison d’Atlan entre ingénierie du prompt, du contexte et du harness fournit une métaphore de pile utile : l’ingénierie du prompt façonne le message, l’ingénierie du contexte façonne ce que le modèle voit, et l’ingénierie du harness façonne tout l’environnement de l’agent.

La nouvelle importante n’est pas que les fenêtres de contexte sont trop petites. Les équipes qui construisent des agents le savent déjà. Le point le plus utile est que les systèmes d’agents cités convergent vers quatre mécanismes de harness qui maintiennent le travail en vie lorsque la transcription cesse d’être une source de vérité fiable.

Un agent superficiel lit des fichiers, appelle des outils, ajoute le résultat et espère que le modèle saura s’en sortir. Un agent pensé d’abord par le harness bloque ou remodèle les entrées volumineuses avant qu’elles n’atteignent le modèle.

Une manière plus claire de lire le premier ensemble de limites est la suivante :

• Pi : les lectures de fichiers s’arrêtent à 2 000 lignes ou 50 Ko, selon la première limite atteinte. Le contenu renvoyé inclut une indication de continuation qui indique au modèle quelle plage de lignes a été affichée et comment continuer avec offset et limit. OpenClaw hérite de ce comportement, puis ajoute des plafonds séparés : les fichiers de bootstrap sont limités à 12 000 caractères par fichier et 60 000 caractères au total. Les résultats d’outils reçoivent un autre budget de 16 000 caractères ou 30 % de la fenêtre de contexte, selon la valeur la plus petite.

Claude Code utilise une conception à deux portes. Selon Arize, il vérifie un plafond de 256 Ko en octets avant d’ouvrir un fichier, puis compte les tokens du résultat par rapport à un budget de 25 000 tokens après la lecture. Même pour les fichiers sous le plafond, il renvoie par défaut 2 000 lignes depuis le début et tronque les lignes de plus de 2 000 caractères. Si le modèle relit la même plage de fichier et que le fichier n’a pas changé, Claude Code peut renvoyer un stub au lieu de répéter le contenu complet.

Ce n’est pas seulement de l’optimisation. Cela change le mode de défaillance. Au lieu de laisser une grosse lecture évincer la tâche, le harness transforme « tout lire » en « lire une tranche contrôlée ». Si le modèle a besoin de plus, il peut le demander. Pour les équipes qui conçoivent des harnesses d’agents à partir de zéro, c’est la première ligne de défense : ne laissez jamais les données externes brutes devenir la transcription par défaut.

Le motif suivant consiste à traiter le contexte comme une fenêtre d’affichage, et non comme du stockage.

Pi et Claude Code exposent la pagination via offset et limit. OpenClaw ajoute à certains endroits une troncature tête/queue, en conservant le début et la fin lorsque le milieu a moins de chances d’être important. Arize indique qu’OpenClaw utilise une répartition 75 % tête / 25 % queue pour les fichiers de bootstrap surdimensionnés, et peut conserver à la fois la tête et la queue pour les résultats d’outils lorsque la queue semble importante, par exemple en présence d’erreurs, d’accolades JSON fermantes ou de mots-clés ressemblant à un résumé.

Letta va plus loin en faisant vivre les fichiers en dehors du prompt. Les fichiers téléversés sont analysés, découpés en chunks et intégrés dans un magasin vectoriel, ce qui donne à l’agent une consultation directe, une recherche exacte et une recherche sémantique. Lorsqu’un fichier est ouvert en contexte, Letta affiche une vue gérée dont la taille s’adapte au contexte du modèle : 5 000 caractères pour un contexte 8K, 15 000 pour 32K, 25 000 pour 128K et 40 000 pour 200K+. Le nombre de fichiers ouverts simultanément s’adapte lui aussi, de 3 pour les petits modèles jusqu’à 15 pour les très grands, avec une politique LRU qui évince les fichiers les moins récemment consultés.

C’est la même idée de conception que derrière le RAG en production : ne mettez pas tout le corpus dans le prompt ; récupérez la partie qui compte. La différence est que les harnesses d’agents doivent le faire en continu, à travers les fichiers, les sorties d’outils, la mémoire et les plans intermédiaires. La même contrainte s’applique aux systèmes RAG : la récupération ne concerne pas seulement la pertinence, mais aussi la préservation d’un budget de contexte suffisant pour l’étape de raisonnement réelle.

Redis fait un point connexe : des fenêtres de contexte plus grandes ne suppriment pas le besoin de gestion du contexte. Les prompts système, les documents récupérés, l’historique de conversation et les sorties d’outils se disputent tous le même espace. Même avant d’atteindre une limite stricte, les modèles peuvent se dégrader lorsque l’information pertinente est enfouie dans de longues entrées.

Le débordement est l’échec évident. La perte d’objectif est plus discrète. L’agent a encore de la place pour répondre, mais il oublie l’objectif initial, manque une contrainte ou commence à optimiser une sous-tâche locale.

C’est là que le compactage compte. Mal faite, la synthèse remplace un historique désordonné mais fidèle par un récit propre mais avec pertes. Bien faite, elle préserve l’état de la tâche, les travaux récents, les éléments en attente et l’intégrité des appels d’outils.

Arize rapporte que Pi déclenche le compactage lorsque le nombre estimé de tokens de contexte dépasse la fenêtre de contexte moins les tokens de réserve, avec une réserve par défaut de 16 384 tokens. Il conserve environ les 20 000 tokens les plus récents et résume le contenu plus ancien dans un message utilisateur synthétique ajouté en préambule à la queue conservée. Il évite aussi de couper au milieu des paires appel d’outil/résultat d’outil.

OpenClaw ajoute une politique d’historique plus agressive. Lorsque l’historique dépasse 50 % de la fenêtre de contexte, il divise les messages en chunks de masse équivalente en tokens, supprime le chunk le plus ancien, résume le contenu supprimé via une synthèse multi-passe par étapes, et répare l’appariement appel d’outil/résultat. Il effectue également un flush pré-compactage : un tour agentique silencieux donne à l’agent l’occasion de persister l’état dans des fichiers mémoire avant que l’historique ne disparaisse. Séparément, il élague les résultats d’outils en mémoire avec un comportement de soft-trim et de hard-clear sur un TTL de cache de 5 minutes.

Claude Code compacte près de la fin de la fenêtre. Arize indique que son déclencheur est la fenêtre de contexte effective moins un tampon de 13 000 tokens, ce qui place le compactage autour de 167K tokens pour un modèle à contexte 200K. Son prompt de synthèse demande des sections structurées couvrant la demande principale, les concepts techniques, les fichiers et le code, les erreurs et corrections, la résolution de problèmes, les messages utilisateur, les tâches en attente, le travail en cours et l’étape suivante. Après compactage, il peut rattacher jusqu’à 5 fichiers récemment lus dans la limite d’un budget de tokens.

Le motif est clair : le compactage ne consiste pas à « résumer le chat ». C’est du checkpointing. Un agent de longue durée a besoin de l’équivalent d’un fichier de sauvegarde : objectif, contraintes, décisions, handles ouverts, preuves récentes et prochaine action.

Certaines sorties ne devraient jamais être placées dans la fenêtre de contexte.

L’article arXiv rend cela concret avec un workflow de science des matériaux. Un outil génère une structure de grille électronique pour une molécule : une matrice 3D de dimensions 128 × 128 × 128, totalisant 2 097 152 éléments float32. Cette sortie dépasse largement la fenêtre de contexte des LLM couramment utilisés. Mais l’outil suivant a besoin de la grille en entrée.

La solution proposée consiste à stocker les grandes valeurs en dehors du contexte du modèle et à renvoyer de courts identifiants, ou pointeurs. Les wrappers d’outils inspectent les entrées pour déterminer s’il s’agit de valeurs brutes ou de chemins mémoire. Les sorties trop volumineuses sont stockées dans la mémoire d’exécution sous un chemin, et les outils suivants peuvent recevoir le pointeur et le résoudre en interne. Le modèle manipule des références, tandis que le harness préserve les données complètes. Dans une expérience comparative où les deux méthodes ont réussi, l’approche fondée sur les pointeurs a utilisé environ sept fois moins de tokens que le workflow traditionnel, selon l’article.

C’est la séparation la plus nette entre raisonnement et transport des données. Le modèle n’a pas besoin de « voir » une matrice de 2 millions d’éléments pour la transmettre à un autre outil. Il doit savoir que la matrice existe, ce qu’elle représente et quelle opération doit la consommer ensuite.

La même logique s’applique au-delà des tableaux scientifiques. Les grandes réponses JSON, les PDF, les logs, les embeddings, les fichiers médias et les exports de bases de données ont souvent leur place dans le stockage, pas dans le prompt. Pour les systèmes construits autour d’outils MCP ou de connecteurs API personnalisés, le passage par pointeurs devrait être un choix de conception de premier ordre, pas un correctif après le premier débordement.

Une fenêtre de contexte de 200K tokens paraît grande jusqu’à ce qu’un agent commence à agir. Un prompt système, des définitions d’outils, quelques documents récupérés, des lectures de fichiers, des logs, des traces d’erreur et des résumés peuvent la consommer plus vite que prévu. Le cadre pratique n’est pas la taille de la fenêtre sur le papier, mais la vitesse à laquelle les agents la dépensent à l’exécution. Les recommandations de Redis sur la mémoire d’agent pointent vers une mémoire externe et durable pour l’état qui doit survivre entre les appels, tandis que le cadrage d’Atlan sur l’ingénierie du contexte distingue de meilleurs prompts d’un meilleur assemblage du contexte. Ensemble, ils traitent la fenêtre de contexte moins comme un entrepôt que comme un ensemble de travail contraint.

La leçon plus profonde est qu’une fenêtre de contexte est une ressource d’exécution rare. La traiter comme de la « mémoire » est utile, mais seulement si le harness se comporte comme un système d’exploitation : allouer, évincer, paginer, compacter, dédupliquer et persister. La distinction en couches d’Atlan est utile ici. L’ingénierie du prompt ne peut pas corriger un lecteur de fichiers qui déverse 80 000 tokens non pertinents dans l’appel suivant. L’ingénierie du contexte peut améliorer l’ensemble de travail. L’ingénierie du harness décide si cet ensemble de travail est protégé dès le départ.

Cela change aussi la manière dont les équipes devraient évaluer les agents. Un prompt de démonstration ne suffit pas. L’évaluation à horizon long devrait inclure des transcriptions qui grossissent, des lectures répétées de fichiers, de grandes sorties d’outils, des appels d’outils échoués, des reprises après compactage et des tâches où la bonne étape suivante dépend d’une contrainte précoce. Notre guide sur l’ingénierie du contexte pour les agents couvre la version côté modèle de ce problème ; la couche de harness est l’endroit où il devient opérationnel.

D’abord, mettez des budgets sur chaque source de contexte. Les fichiers, les sorties d’outils, les chunks récupérés, les insertions mémoire et l’historique de conversation devraient chacun avoir des limites explicites. Un seul nombre maximal global de tokens est trop grossier.

Ensuite, rendez la troncature actionnable. Si le harness coupe du contenu, le modèle devrait savoir quelle plage il a vue et comment demander davantage. Une troncature silencieuse est pire qu’un rejet, car elle crée un travail confiant sur des données manquantes.

Troisièmement, compactez autour de l’état, pas de la prose. Les résumés devraient préserver l’objectif de l’utilisateur, les contraintes, les décisions, les tâches en attente, les fichiers touchés, les résultats d’outils importants et l’étape suivante immédiate. Les paires d’appels d’outils devraient rester intactes.

Quatrièmement, déplacez les grandes valeurs hors du prompt. Stockez-les, nommez-les et transmettez des pointeurs à travers les outils. C’est particulièrement important pour les agents qui appellent des API, traitent des documents ou coordonnent des systèmes multi-agents.

Enfin, testez la perte d’objectif séparément du débordement. Un agent peut rester sous la fenêtre stricte et quand même dériver. La bonne question n’est pas seulement « l’API a-t-elle accepté le prompt ? ». C’est « la prochaine action sert-elle encore la tâche initiale ? »

Le résumé ci-dessous transforme ces motifs en checklist rapide avant la FAQ.

• Les agents à horizon long échouent à la fois par débordement de contexte et par perte d’objectif ; le harness doit donc gérer plus que la longueur du prompt.
• Les systèmes d’agents en production utilisent des budgets stricts sur les fichiers, les sorties d’outils et l’historique avant que les données brutes n’atteignent le modèle.
• La pagination, la recherche et les vues gérées traitent le contexte comme une fenêtre d’affichage limitée plutôt que comme un stockage permanent.
• Le compactage fonctionne mieux comme checkpointing : il préserve les objectifs, les contraintes, les décisions, le travail en attente et l’intégrité des appels d’outils.
• Les grandes sorties d’outils ont souvent leur place dans un stockage externe, avec de courts pointeurs transmis entre outils au lieu de valeurs complètes dans le prompt.

Cette section répond aux questions pratiques derrière l’ingénierie du contexte pour les agents à horizon long : ce qui déborde, comment les objectifs se perdent et quels motifs de harness maintiennent le travail sur les rails.

Le débordement de contexte se produit lorsque le prompt accumulé, l’historique, les données récupérées, les fichiers et les sorties d’outils d’un agent dépassent la fenêtre de contexte utilisable du modèle, ou dégradent la qualité avant que la limite stricte ne soit atteinte.

La perte d’objectif se produit lorsque la tâche initiale est encore présente quelque part dans la transcription, mais ne guide plus la prochaine action de l’agent, souvent après de longs historiques ou une mauvaise synthèse.

Ils définissent des budgets par source, paginent les lectures de fichiers, récupèrent uniquement les vues pertinentes, compactent l’historique autour de l’état, dédupliquent les lectures répétées et stockent les grandes sorties en dehors du prompt.

Les pointeurs permettent au modèle de faire référence à de grandes valeurs stockées dans la mémoire d’exécution, comme des matrices, des logs ou des PDF, tandis que les outils en aval résolvent les données complètes sans les placer dans la fenêtre de contexte.

Non. Des fenêtres plus grandes aident, mais les prompts système, les définitions d’outils, les documents récupérés, les logs et l’historique se disputent toujours l’espace, et les informations pertinentes peuvent être enfouies avant même qu’une limite stricte ne soit atteinte.