🤖 AI

Context as an Environment: Programmatic Context Management for Long-Horizon Agents

Le document présente Scroll, un système de gestion de contexte programmatique qui traite les sessions d'agents comme des environnements exécutables dotés d'un journal d'événements en ajout uniquement et d'un noyau Python persistant, permettant aux LLM de gérer dynamiquement l'état à long horizon par le code tout en atteignant des performances de pointe sur les benchmarks de contexte long.

Auteurs originaux : Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

Publié 2026-08-25

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Yin Lin, Elaine Ang, Erkang Zhu, Bolin Ding, Jingren Zhou

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez une conversation qui ne s'arrête jamais. Vous discutez avec un programme informatique très intelligent, capable de vous aider à écrire du code, à planifier des voyages complexes ou à effectuer des recherches sur des sujets profonds. Au début, la conversation est facile. Le programme se souvient de tout ce que vous avez dit au cours des dernières minutes. Mais à mesure que la conversation s'étire sur des heures ou des jours, la quantité d'informations augmente. Finalement, cela devient trop important pour que le programme puisse le conserver dans sa mémoire immédiate. Dans le monde de l'intelligence artificielle, cette mémoire immédiate est appelée fenêtre de contexte. Elle a une taille fixe, comme un bureau qui ne peut contenir qu'un certain nombre de papiers. Lorsque la pile de papiers devient trop haute, le programme doit en jeter certains pour faire de la place aux nouveaux.

Le problème est que le programme ne sait pas quels papiers sont importants avant qu'il ne soit trop tard. Si vous posez une question sur quelque chose que vous avez mentionné il y a trois jours, le programme pourrait déjà avoir jeté ce papier. Les solutions traditionnelles tentent de résoudre cela en résumant les vieux papiers sous forme de notes courtes ou en extrayant quelques faits pour les garder dans un carnet séparé. Mais ces méthodes sont risquées. Si le programme jette un détail spécifique, comme une date ou un nombre, ce détail est perdu à jamais. Il ne peut pas être récupéré. Pour les tâches qui nécessitent de consulter un historique long pour trouver des faits précis ou pour suivre l'évolution d'une situation, perdre ne serait-ce qu'un seul détail peut faire échouer le programme.

Une équipe de chercheurs a proposé une autre façon de gérer cette conversation croissante. Ils appellent leur système Scroll. Au lieu d'essayer de faire tenir tout l'historique dans la mémoire immédiate du programme, ils traitent l'historique comme un environnement distinct et permanent que le programme peut visiter dès qu'il en a besoin. Imaginez cela comme une vaste archive organisée qui se trouve juste à l'extérieur du bureau du programme. Le programme ne lit pas toute l'archive à la fois. Au lieu de cela, il écrit une petite instruction, comme une requête de recherche ou une commande, pour aller dans l'archive, trouver la page spécifique dont il a besoin et rapporter juste cette page sur le bureau.

Le cœur de ce système est un enregistrement permanent de chaque interaction, appelé Journal d'Événements (Event Log). Ce journal est comme un magnétophone qui ne s'arrête jamais, capturant chaque message, chaque résultat d'outil et chaque décision dans les moindres détails. Il est stocké en toute sécurité en dehors de la mémoire immédiate du programme, de sorte que rien n'est jamais perdu. À côté de ce journal se trouve un espace de travail persistant, une sorte de bac à sable numérique où le programme peut conserver ses pensées et calculs actuels. Lorsque le programme a besoin de se souvenir de quelque chose du passé, il ne compte pas sur un résumé. Il écrit un morceau de code pour chercher dans le Journal d'Événements, trouver le moment exact qu'il recherche, et charger cette information dans son espace de travail.

Cette approche change la façon dont le programme perçoit sa propre mémoire. Au lieu de deviner ce qu'il faut garder, le programme décide de ce qu'il doit rechercher au moment où cela est nécessaire. Si le programme planifie un voyage et doit se souvenir d'une préférence mentionnée par l'utilisateur il y a plusieurs semaines, il écrit une commande pour rechercher cette préférence spécifique. Il charge ensuite les mots exacts utilisés par l'utilisateur et les utilise pour prendre une décision. Le programme ne ramène dans sa vue immédiate que l'information nécessaire. Le reste de l'historique de la conversation demeure stocké en toute sécurité dans l'archive, attendant d'être récupéré si le programme en a besoin plus tard.

Pour éviter que la vue immédiate ne soit trop encombrée, le système dispose d'un moyen de vider les anciennes informations qui ne sont pas actuellement utilisées. Lorsque l'espace de travail devient trop chargé, le système déplace les parties les plus anciennes de la conversation vers l'archive. Cependant, contrairement à d'autres systèmes qui pourraient supprimer ou résumer ces anciennes parties, Scroll les conserve exactement telles quelles. Il crée une petite carte, un index, qui indique au programme l'endroit exact où ces anciennes parties sont stockées. Si le programme réalise plus tard qu'il doit vérifier une ancienne conversation, il peut utiliser cette carte pour sauter directement au bon endroit et récupérer le texte original. Cela garantit que le programme peut toujours revenir à la source, même si l'information n'est plus dans sa vue immédiate.

Les chercheurs ont testé ce système sur plusieurs défis difficiles conçus pour voir comment une intelligence artificielle peut gérer de longues conversations. Dans un test, le système devait répondre à des questions basées sur un historique de plus d'un million de mots de conversation. Dans un autre, il devait agir en tant qu'agent prenant des décisions sur une longue période, utilisant des outils pour recueillir des informations et résoudre des problèmes. Les résultats ont montré que cette nouvelle méthode était hautement efficace. Sur un test mesurant la capacité du système à se souvenir et à raisonner sur de longs historiques, il a obtenu un score de 94,8 %. Sur un autre test impliquant dix millions de mots d'historique, il a obtenu 73,1 %, ce qui est supérieur à tout autre système publié précédemment. Dans un test où le système devait gérer un environnement croissant tout en résolvant des tâches complexes, il a atteint 86,7 %, dépassant largement les meilleurs résultats précédents.

Le succès de ce système provient de sa capacité à traiter la mémoire comme une tâche de programmation. En permettant au programme d'écrire ses propres instructions pour trouver et utiliser l'information, le système tire parti de la capacité croissante du programme à écrire du code. Il ne force pas le programme à compresser son historique en un résumé qui pourrait perdre des détails importants. Au lieu de cela, il donne au programme les outils pour accéder à l'historique complet et non édité dès qu'il en a besoin. Les chercheurs ont constaté que cette méthode fonctionne bien avec différents types de programmes puissants, suggérant que la capacité de gérer la mémoire à long terme par le code est une compétence générale qui peut être apprise par divers systèmes.

Ce travail suggère un changement dans la manière dont nous construisons les agents intelligents. Plutôt que d'essayer de rendre la mémoire immédiate du programme plus grande ou plus performante dans la synthèse, nous pouvons lui donner accès à un enregistrement permanent et consultable de sa propre vie. Le programme apprend à naviguer dans cet enregistrement, décidant de ce qu'il doit faire avancer et de ce qu'il doit laisser derrière lui. Cela permet de garder la vue immédiate claire et concentrée, tout en garantissant que la vérité entière du passé est toujours disponible. Les chercheurs pensent que cette approche pourrait aider l'intelligence artificielle à gérer des tâches encore plus longues et complexes à l'avenir, lui permettant d'apprendre d'un historique beaucoup plus profond sans perdre les détails qui comptent.

Résumé technique : Scroll – Gestion programmatique du contexte pour les agents à long horizon

1. Formulation du problème

Les tâches à long horizon pour les agents basés sur les modèles de langage (LLM) — telles que l'ingénierie logicielle au niveau du dépôt ou la recherche web approfondie — génèrent des historiques d'interaction qui dépassent largement la fenêtre de contexte d'un modèle unique. Les solutions existantes reposent principalement sur la compression de contexte (tronquage, résumé ou élimination des segments obsolètes) ou sur la mémoire externe (extraction de faits vers un magasin séparé). Ces deux approches sont fondamentalement perdues (lossy) : elles s'engagent sur ce qu'il faut préserver avant même de connaître les besoins futurs. Par conséquent, si un résumé ne parvient pas à capturer un détail spécifique ou si une extraction manque une nuance, cette information devient irrécupérable, même si le journal brut existe sur le disque. Cette limitation entrave la capacité des agents à effectuer des comparaisons historiques exactes ou des calculs non triviaux sur des événements passés où l'information requise n'est pas connue à l'avance.

2. Méthodologie : Le framework Scroll

Le document présente Scroll, un gestionnaire de contexte qui reformule l'historique de session non pas comme du texte à sérialiser dans des prompts, mais comme un Environnement de Session exécutable. Cet environnement permet à l'agent d'interagir de manière programmatique avec son propre historique.

Composants de base

Journal d'événements en mode ajout uniquement ( $L_t$ ) : Un enregistrement durable et de vérité terrain de toutes les interactions (messages utilisateur, réponses du modèle, appels d'outils, résultats). Chaque événement se voit attribuer une adresse de séquence immuable et strictement croissante (seq). Le journal est stocké dans SQLite, utilisant BM25 pour une recherche textuelle complète déterministe plutôt que des embeddings.
Stockage durable ( $P_t$ ) : Les charges utiles brutes (ex: sorties d'outils complètes, artefacts) sont stockées de manière externe (JSON, système de fichiers) et référencées par le Journal d'Événements via des handles différés. Cela garantit que le journal reste léger tout en préservant l'intégralité de la fidélité.
Noyau Python persistant ( $V_t$ ) : Un noyau Python sécurisé persiste entre les appels du modèle. Il maintient un espace de noms typé de variables résidentes (objets Python, DataFrames, handles différés). Crucialement, les calculs intermédiaires et les résultats d'outils restent dans ce noyau et ne sont pas sérialisés dans le prompt, sauf demande explicite.

Interface programmatique

Le modèle construit son contexte en écrivant du code exécuté au sein du noyau persistant. L'interface, exposée via un objet de capacité ms, décompose la construction du contexte en quatre opérations :

LOCALISER (LOCATE) : ms.search(query, k, ...) trouve des enregistrements candidats dans le Journal d'Événements via une recherche textuelle complète et des filtres structurés, retournant des adresses seq stables.
MATÉRIALISER (MATERIALIZE) : ms.expand(seq) récupère des tours ou des segments exacts et charge les charges utiles externalisées sous forme d'objets Python.
CALCULER (COMPUTE) : Le modèle effectue des filtrages, des jointures, des agrégations et des dérivations en utilisant du Python standard et des interfaces de base de données autorisées sur les variables résidentes.
EXPOSER (EXPOSE) : print(value) est le seul mécanisme qui franchit la frontière vers la vue de travail du modèle. Seules les projections explicitement imprimées entrent dans le prochain contexte du modèle.

Éviction et Navigation

À mesure que la vue de travail approche de la limite de tokens, Scroll emploie une procédure d'éviction qui supprime les segments obsolètes de la vue, mais jamais du Journal d'Événements.

Récupérabilité : Les événements évincés restent intacts dans le Journal d'Événements.
Index d'éviction : Pour éviter la nécessité de recherches dans l'intégralité du journal, Scroll maintient un index hiérarchique de "titres" (tâche, état, action suivante) pour les segments évincés. Cet index permet à l'agent de naviguer directement vers les régions évincées en utilisant des ancres d'adresse, en regroupant les entrées plus anciennes en plages plus larges pour maintenir une complexité en $O(k \log k n)$ .

3. Contributions clés

Le document apporte trois contributions principales :

Politique de sélection différée : Contrairement aux méthodes existantes qui fixent la carte du contexte avant que les besoins futurs ne soient connus, Scroll diffère la sélection de la vue de travail au moment de la requête. Le modèle écrit un programme $\pi_t$ à chaque étape pour décider de ce qu'il doit rappeler, calculer et exposer.
Substrat de contexte exécutable : L'implémentation d'un noyau Python persistant et sécurisé combiné à un Journal d'Événements en mode ajout uniquement. Cela déplace la gestion du contexte du traitement de texte vers la programmation, exploitant les capacités de codage du LLM pour rechercher, transformer et matérialiser l'état.
Algorithme de navigation sans perte : Un mécanisme d'éviction qui maintient la vue de travail limitée sans perdre l'historique. Les segments évincés restent intacts et sont indexés par des entrées compactes ancrées par des adresses, permettant à l'agent de naviguer directement vers les régions évincées plutôt que de chercher dans l'intégralité du journal.

4. Résultats expérimentaux

Les auteurs ont évalué Scroll en utilisant Qwen3.8-Max comme moteur de base à travers trois benchmarks :

LongMemEvalS (Récupération de mémoire à long terme) : Scroll a atteint une précision de 94,8 %, se montrant compétitif face aux systèmes de pointe.
BEAM10M (Historique de 10 millions de tokens) : Scroll a atteint 73,1 %, surpassant le meilleur système de mémoire publié de 5,1 points. Il a particulièrement excellé dans les catégories nécessitant des preuves historiques exactes, comme la mise à jour des connaissances (92,5 %) et la résolution de contradictions (88,1 %), là où la résumé perte (lossy) échoue typiquement.
LOCA256K (Action à long horizon) : Scroll a atteint 86,7 % de précision. En comparaison directe avec d'autres stratégies de gestion de contexte utilisant le même moteur, Scroll a démontré une stabilité supérieure à mesure que le contexte augmentait, avec une baisse de seulement 2,6 % de 128K à 256K tokens, contre des chutes d'environ 21 % pour les agents de résumé et de récupération.

Les études d'ablation ont confirmé que le Journal d'Événements sans perte est critique (sa suppression a provoqué une chute à environ 20 % sur BEAM10M), que le noyau persistant améliore les performances de 7,3 points en permettant l'agrégation en interne, et que l'index d'éviction apporte un gain de 1,8 point en facilitant la navigation dans les historiques éparpillés.

Efficacité des coûts : Scroll n'expose qu'une petite fraction du corpus au modèle. Sur BEAM10M, le nombre médian de tokens d'entrée était de ~105K (environ 1 % du corpus), avec des tokens de sortie un ordre de grandeur plus petits.

5. Signification et Revendications

Le document affirme que Scroll change fondamentalement la gestion du contexte, passant d'un problème de compression à une tâche de programmation. En traitant la session comme un environnement exécutable, l'agent hérite des capacités de codage croissantes des LLM pour gérer dynamiquement son propre contexte.

Les auteurs soulignent que Scroll ne dicte pas quel état conserver ni comment écrire le code de récupération ; ces décisions sont laissées au modèle. Cette flexibilité permet au système de passer à l'échelle avec les capacités du modèle. Le document suggère que les trajectoires réussies peuvent être distillées des modèles frontières vers des modèles plus petits via un apprentissage supervisé (SFT), tout en gardant les mécanismes de contexte sous-jacents fixes.

L'ouvrage postule que pour les tâches à long horizon nécessitant des preuves historiques exactes ou des calculs complexes sur des événements passés, la récupération sans perte via un accès programmatique est supérieure au résumé pré-calculé ou aux magasins de mémoire fixes, car elle évite la perte irréversible d'information inhérente aux paradigmes de compression actuels.