Votre Agent atteint 80% de sa fenêtre de contexte. La compression se déclenche et supprime les échanges les plus anciens. Dix minutes plus tard, il relit un fichier déjà lu et repose une question à laquelle il a déjà répondu.
Le seuil savait que la place manquait. Il ne savait rien de ce qu’on pouvait perdre sans risque.
Voici la troisième note d’une série sur la conception des Agents à horizon long, suscitée par une lecture attentive de BEACON (université du Zhejiang, arXiv:2605.06078). La première portait sur la détection de stagnation, la deuxième sur la conception des jalons.
Commençons par notre propre implémentation
Orkas est un client de bureau multi-Agents. Les tâches longues y sont la norme, donc la compression intervient quotidiennement. Notre implémentation se déclenche à un seuil de tokens, lorsque le contexte atteint environ 80% de la fenêtre. Avant de rédiger cet article, aucun de nous n’y voyait de problème.
On rencontre environ trois limites courantes : un pourcentage de la fenêtre, un nombre de tours ou un résumé du contenu ancien rédigé par le modèle. La nôtre relève de la première catégorie.
Les deux premières ne regardent jamais le contenu. La troisième le regarde, mais confie entièrement au modèle la question de ce qui compte.
Toutes trois répondent à la question : « quand dois-je supprimer quelque chose ? ». La véritable question est : « que puis-je supprimer sans risque ? ». Couper au seuil supprime le contenu le plus ancien, pas le moins important.
La limite du jalon et l’hypothèse qui la sous-tend
Les jalons de la note précédente pourraient fournir une meilleure limite que les trois approches. Mais un piège se cache ici, et la note précédente l’avait un peu trop estompé.
BEACON contient une hypothèse appelée propriété de Markov des jalons. En termes simples : une fois un jalon atteint, la suite ne dépend que des sous-objectifs restants, pas du chemin parcouru. Une fois la clé en main, ce qui compte est la porte que vous ouvrez, pas la façon dont vous l’avez trouvée.
Cela ressemble à une autorisation de compresser : passé un jalon, on pourrait replier toute la portion précédente.
Mais c’est une hypothèse, pas un fait. L’article écrit ≈, pas =, et les auteurs expliquent où elle échoue.
Suffisante pour l’entraînement, insuffisante pour la compression
Même hypothèse, deux usages, un ordre de grandeur d’écart dans l’exigence.
Lors de l’entraînement, il suffit qu’elle soit vérifiée statistiquement. Si quelques dizaines de trajectoires sur quelques milliers la violent, le biais s’atténue en moyenne. L’entraînement dispose aussi d’un signal au niveau de la trajectoire comme filet de sécurité ; supprimez cette couche et ALFWorld passe de 91.4 à 23.4, bien en dessous du résultat obtenu sans rien faire.
Lors de la compression, elle doit être vérifiée dans chaque cas, pour l’exécution précise devant vous. Supprimez une seule fois le mauvais élément et cette tâche est perdue. Il n’y a aucune moyenne sur laquelle compter.
Le fait que l’article s’appuie sur cette hypothèse ne signifie donc pas qu’on puisse la transposer à la compression. Les deux usages n’exigent pas la même chose d’elle.
Quatre cas où elle échoue
Nous les utilisons comme liste de contrôle lorsque nous réfléchissons à une politique de compression.
1. Les connaissances implicites accumulées en chemin. Une étape initiale établit qu’une API donnée renvoie des horodatages en UTC. Cela n’appartient à aucun jalon, et toutes les étapes suivantes en ont besoin.
2. Les ressources déjà consommées. Budget de tokens, quota d’appels, temps restant. Un jalon ne consigne pas j’ai dépensé 60% du budget, mais ce chiffre détermine si une nouvelle tentative reste abordable.
3. Les effets de bord qui dépendent du chemin suivi. Le jalon indique refactorisation terminée. Dès que le débogage commence, vous devez savoir quels sont les cinq fichiers réellement modifiés.
4. Le jalon lui-même est insuffisamment défini. C’est le pire des quatre cas. Dans l’article, un jalon est un état complet de l’environnement — vous avez la clé ou non, sans ambiguïté. Une étape de plan est une phrase en langage naturel. « Terminer le nettoyage des données » est loin de couvrir tout ce qui s’est passé pendant cette phase.
Ce qu’il faut transmettre à la place
Ne gardez pas seulement un résumé. Un résumé est écrit par le modèle, qui décide intuitivement de ce qui comptait.
Gardez un ensemble fixe de champs choisis par un humain. Au minimum quatre :
- L’état actuel de l’espace de travail — quels fichiers ont été modifiés et dans quel état ils sont.
- Le budget restant — tokens, quota d’appels, temps.
- Ce qui a été établi — le fait concernant UTC, et tout ce qui influencera les décisions ultérieures.
- Ce qui reste ouvert — le problème qui a bloqué une fois, a été contourné et pourrait revenir.
Comparez-les aux quatre cas d’échec ci-dessus : ils correspondent un à un. Cette correspondance est le moyen le plus simple de juger si une politique de compression est suffisante.
La moitié est presque gratuite. Comme l’expliquait la note précédente, l’hôte enregistre déjà des faits déterministes après chaque appel d’outil : un fichier a-t-il réellement été réécrit, une commande a-t-elle vraiment été exécutée ? Ces données ont été recueillies pour vérifier les jalons, mais elles constituent l’instantané de l’espace de travail. La compression peut donc les transmettre directement, sans demander à un modèle de les résumer à nouveau.
La moitié difficile concerne les deux autres champs. Ce qui a été établi et ce qui reste ouvert n’existe actuellement que si le modèle le note, et c’est précisément pourquoi ces informations sont les premières victimes de la compression.
Cela se mesure, cela ne se débat pas
Après la compression, si l’Agent relit un fichier éliminé du contexte ou repose une question déjà résolue, l’hypothèse a échoué sur cette tâche et la preuve est là.
L’instrumentation est simple : calculez l’intersection entre les chemins des fichiers lus après le point de compression et ceux enregistrés avant.
Avec ce chiffre, « quels types de tâches peuvent être fortement compressés et lesquels ne le peuvent pas » devient une requête plutôt qu’un débat de conception. C’est la même approche que dans la première note de cette série : mesurer d’abord, puis changer quelque chose.
Où il faut relativiser cette proposition
Rien de cela n’est livré. Nous en sommes à la conception et à l’instrumentation.
Le choix des champs à conserver et de leur granularité doit venir des données sur ce qui est réellement récupéré à nouveau. Décider maintenant est un bon moyen de se tromper.
Et ce n’est qu’une approche parmi d’autres. La position de la limite et la définition des champs pourraient être complètement différentes dans un autre type de produit. La liste des quatre cas est transposable ; la réponse précise ne l’est pas.
La prochaine et dernière note de cette série portera sur l’autoréflexion : pourquoi les leçons synthétisées par un Agent restent aussi génériques que « être plus prudent », et un point réellement surprenant sur ce que ses entrées contiennent ou non.