Explication du compactage de contexte dans TrueForge : ce que l'agent oublie et ce que la session conserve

Conçu pour la vitesse : latence d'environ 10 ms, même en cas de charge
Une méthode incroyablement rapide pour créer, suivre et déployer vos modèles !
- Gère plus de 350 RPS sur un seul processeur virtuel, aucun réglage n'est nécessaire
- Prêt pour la production avec un support complet pour les entreprises
Le compactage permet à un agent à longue durée d'exécution de poursuivre son traitement en remplaçant l'historique de travail ancien par un résumé structuré. C'est utile précisément parce que le procédé comporte des pertes — et dangereux s'il est considéré comme une vérité d'archivage.
Le compactage modifie la mémoire de travail de l'agent, pas le registre historique de la session
Les longues conversations accumulent des messages d'utilisateurs, des messages d'assistants, des appels d'outils, des résultats d'outils et des sorties de sous-agents. À terme, conserver chaque élément devient coûteux, voire impossible. Le compactage de contexte de TrueForge résout ce problème d'exécution en résumant l'historique le plus ancien et en utilisant ce résumé à la place des messages d'origine pour les étapes de modélisation ultérieures.
La distinction cruciale réside entre deux visions. La session persistance conserve l'ensemble de son historique d'évènements. Le contexte actif du modèle après compactage contient une représentation structurée et avec perte des travaux antérieurs. Ces deux visions répondent à des questions différentes. Le journal d'évènements permet de reconstituer ce qui a été enregistré ; le contexte compacté permet de poursuivre le raisonnement dans la limite d'un budget de tokens fini.
Le compactage n'est donc ni une suppression, ni un archivage, ni une preuve. Il s'agit d'une transition d'état dans la représentation de travail de l'agent. Un détail peut rester présent dans les évènements persistants tout en n'étant plus saillant — ou même plus présent du tout — dans le résumé utilisé par le modèle.

Le schéma sépare le registre de session durable de la représentation utilisée pour les inférences ultérieures. Le débogage nécessite les deux, car la présence dans le journal d'évènements ne garantit pas la saillance dans le contexte de travail compacté.
Le modèle de déclenchement documenté
TrueForge indique que le compactage est activé par défaut. Il s'exécute lorsque le contexte d'entrée atteint 80 % de la longueur de contexte du modèle. Si cette longueur n'est pas disponible, le harness utilise une valeur de secours de 50 000 tokens d'entrée. Un agent peut également configurer un seuil explicite de tokens d'entrée.
Il s'agit là de semantiques de déclenchement, et non de garanties de qualité. Un seuil détermine le moment où le résumé s'exécute ; il ne prouve pas que le résumé obtenu préserve chaque fait nécessaire pour la suite. Les équipes doivent choisir des seuils explicites lorsque les métadonnées du modèle sont incertaines, que les tâches nécessitent des réservations de sortie inhabituellement élevées, ou que les schémas d'outils et les pièces jointes réduisent le budget effectif par rapport à la fenêtre nominale du modèle.
Conservez de la marge pour la prochaine réponse du modèle, les arguments des outils, les charges utiles d'approbation et tout matériel système injecté par le harness. Un déclenchement au tout dernier token disponible est fragile sur le plan opérationnel, car la requête de compactage elle-même et l'étape de raisonnement suivante consomment également du contexte.

Le déclencheur est représenté sous la forme d'une décision d'allocation de ressources avec une marge réservée. Les valeurs par défaut documentées déterminent le timing ; les équipes restent responsables des seuils spécifiques aux charges de travail et de la validation de la qualité.
Ce que le résumé est censé préserver
TrueForge décrit un résumé structuré couvrant l'intention initiale, les décisions clés, les fichiers et artefacts, les erreurs et correctifs, ainsi que les étapes suivantes. Cette structure est précieuse car elle demande au compacteur de préserver l'état de la tâche plutôt que de produire un synopsis conversationnel générique.
Les agents en production doivent faciliter le résumé des états critiques. Les identifiants stables, les champs d'état typés, les registres de décision explicites et les empreintes d'artefacts survivent mieux au compactage que les faits enfouis dans de la prose conversationnelle. Si une action irréversible dépend d'une valeur, stockez cette valeur dans un système faisant autorité ou dans un point de contrôle typé au lieu de compter sur sa présence exacte dans un résumé généré.
La perte d'information est une fonctionnalité assortie d'un budget d'erreur
Un résumé utile supprime délibérément des détails. S'il conservait tout, il ne résoudrait pas le problème de contexte. Le travail d'ingénierie consiste à décider quelles pertes sont acceptables. Les formulations répétées, les charges utiles brutes des outils et les explorations abandonnées peuvent généralement être éliminées sans risque. Le périmètre d'approbation, les seuils numériques, les contraintes de sécurité et les incertitudes non résolues ne le peuvent pas.
Le compactage peut introduire des omissions, des compressions ou des réinterprétations. Un nombre peut perdre son unité ; une observation temporaire peut devenir une décision ; deux fichiers aux noms similaires peuvent être confondus ; une erreur non résolue peut disparaître derrière la solution de contournement finale. Il ne s'agit pas d'affirmations sur un défaut spécifique dans TrueForge. Ce sont des modes de défaillance inhérents aux résumés générés par des modèles avec perte d'information, et ils doivent guider vos tests.
Considérez chaque limite de compactage comme un point de contrôle pouvant être évalué. L'application peut comparer le résumé généré avec des invariants typés : l'objectif actif, les approbations requises, les opérations ouvertes, les empreintes d'artefacts, les contraintes de sécurité et la prochaine transition autorisée. Si un invariant est manquant ou contredit, ne poursuivez pas silencieusement.

La limite de compactage devient testable lorsque l'état critique est exprimé sous forme d'invariants. Un invariant manquant peut interrompre la poursuite du traitement avant qu'un résumé avec perte ne conduise à une action non sécurisée.
Le compactage et la recherche documentaire (retrieval) sont des outils différents
Le compactage crée un récit de travail synthétique. La recherche documentaire (retrieval) sélectionne le matériel source pertinent au moment où il est nécessaire. Les systèmes à longue durée d'exécution ont souvent besoin des deux. Un résumé peut indiquer qu'un plan de migration existe et donner son empreinte ; la recherche peut charger le plan exact juste avant son exécution. L'agent ne doit pas transporter un artefact de 20 pages à chaque tour de parole, mais il ne doit pas non plus exécuter une action à partir d'une paraphrase lorsque le contenu exact importe.
Ce modèle réduit la pression sur le résumé pour qu'il devienne une archive parfaite. Il doit seulement préserver les pointeurs, l'état et les limites de décision. Les éléments de preuve exacts restent dans les fichiers, les bases de données ou les évènements de session et sont rechargés pour les étapes à fortes implications.
Le compactage et les évènements persistants répondent à des questions de débogage différentes
Lorsqu'une réponse post-compactage est erronée, les enquêteurs ont besoin à la fois du registre pré-compactage et de la représentation compactée. L'historique des évènements permet de voir quelles informations existaient. Le résumé permet de voir quelles informations le modèle a réellement conservées. Leur comparaison permet d'identifier si la défaillance s'est produite avant le compactage, pendant le résumé ou après l'utilisation du résumé.
Enregistrez le déclencheur de compactage, le modèle et la configuration utilisés, la plage d'évènements d'entrée, l'évènement de résumé, le nombre de tokens avant et après, ainsi que le résultat de la validation. Versionnez toutes les invites de compactage au niveau applicatif ou le vérificateur d'invariants. Sans cette provenance, un résumé est difficile à reproduire et les régressions sont difficiles à attribuer.
Le compactage répété peut accumuler les pertes
Une longue session peut être compactée plusieurs fois. Si un résumé ultérieur est produit à partir d'un résumé antérieur plutôt qu'à partir de l'intégralité du registre pertinent, les omissions peuvent devenir permanentes dans le contexte de travail. Une ambiguïté mineure peut se retrouver compressée sous forme d'affirmation catégorique, puis transmise comme s'il s'agissait d'une preuve d'origine.
Suivez les générations de compactage et la plage d'évènements que chaque résumé représente. Lors d'étapes charnières importantes, construisez le prochain état de travail à partir de points de contrôle typés et durables associés à une sélection d'évènements sources, plutôt que de résumer uniquement le résumé précédent. Cela est particulièrement utile après des approbations, des mutations externes, des passages de relai lors d'incidents ou une modification substantielle de l'intention de l'utilisateur.
Définissez une durée de vie maximale pour la session ou un nombre maximal de compactages pour les workflows où le risque d'accumulation d'erreurs d'interprétation est critique. Démarrer une nouvelle session n'est pas un échec ; cela peut être une réinitialisation délibérée qui n'importe que des états vérifiés. Le passage de relais doit mentionner la session précédente, les artefacts approuvés, les opérations non résolues et le motif de la réinitialisation.
Le compactage n'est pas un contrôle de rétention ou de confidentialité
Supprimer des détails du contexte de travail du modèle ne signifie pas que l'historique des évènements sous-jacent a été supprimé. TrueForge distingue explicitement le contexte compacté des évènements de session persistants. Les politiques de rétention de données, de suppression, de conservation légale, d'accès et d'exportation doivent donc s'appliquer aux bases de stockage persistantes et aux artefacts associés — et non à ce que le modèle voit actuellement.
L'inverse est également vrai. Un résumé compacté peut conserver des informations sensibles même lorsque le détail d'origine n'est plus nécessaire à la tâche. Appliquez la minimisation des données au résumé lui-même, contrôlez qui peut lire l'état de la session et évitez de copier des secrets ou des données personnelles brutes dans des champs narratifs durables. La caviardage et la rétention doivent être conçus sur l'ensemble des copies : entrée du modèle, résumé, registre d'évènements, fichier, trace et systèmes en aval.
Les corrections humaines doivent survivre à la limite de compactage
Si un utilisateur corrige un fait antérieur, l'état compacté doit préserver la correction et retirer la valeur remplacée. Représentez les corrections sous forme de transitions d'état explicites au lieu de vous reposer sur le principe selon lequel "le texte le plus récent l'emporte". Vérifiez par des tests que le résumé conserve la valeur actuelle, enregistre la provenance du matériel si nécessaire et ne réintroduit pas l'ancienne valeur après un autre compactage.
Pour les décisions contestées ou réglementées, conservez la déclaration d'origine, la correction, le responsable de la décision et l'heure d'effet dans un registre faisant autorité. Le résumé de travail peut transmettre l'instruction actuelle, tandis que le registre durable conserve l'historique nécessaire aux audits et aux recours.
Ne supposez pas une poursuite strictement unique ou déterministe
L'état persistant et le résumé compacté aident un agent à poursuivre son exécution. Ils ne rendent pas pour autant les effets secondaires externes déterministes. Si un appel d'outil a expiré lors d'une mutation de base de données, le résumé peut indiquer à juste titre "état inconnu", mais l'application doit tout de même interroger le système faisant autorité avant de réessayer. Le compactage doit préserver l'identifiant d'opération et l'ambiguïté ; la réconciliation se charge de la résoudre.
De même, un résumé ne doit pas transmettre silencieusement une ancienne décision d'autorisation dans un nouvel état. Les approbations et autorisations métier peuvent expirer ou devenir obsolètes après la modification d'une ressource. Réévaluez-les au moment de l'exécution.
Comment tester le compactage
- Placez les faits critiques au début d'une longue session et vérifiez qu'ils restent explicites après le compactage.
- Intégrez des noms de fichiers, des unités et des identifiants similaires ; testez l'absence de fusion accidentelle.
- Compactez lorsqu'une approbation, une opération externe ou une erreur reste non résolue.
- Vérifiez que les hypothèses abandonnées ne sont pas transformées en décisions.
- Comparez les actions post-compactage avec une exécution témoin qui conserve l'historique complet.
- Rejouez des sessions représentatives après des modifications du modèle ou de la configuration de compactage.
- Confirmez que l'historique des évènements persistants reste disponible bien que le contexte de travail soit plus court.
Un modèle opérationnel pour les sessions longues
Utilisez le contexte de travail pour l'intention actuelle, les décisions, les pointeurs et les étapes suivantes. Utilisez les évènements de session pour le registre chronologique d'exécution. Utilisez les fichiers et les registres pour les artefacts versionnés. Utilisez les systèmes de référence pour l'état métier validé. Le compactage peut alors réduire le volume conversationnel sans devenir le seul endroit où l'application se souvient des faits importants.
Surveillez la fréquence de compactage, le taux de compression, le taux d'erreur post-compactage, les échecs d'invariants, les questions réouvertes et les appels d'outils répétés. Une session qui se compacte de manière répétée peut nécessiter une meilleure externalisation des résultats d'outils, un périmètre de tâche plus étroit ou une nouvelle session délibérée plutôt que des résumés de plus en plus denses.
La règle opérationnelle
Le compactage de contexte dans TrueForge prolonge la durée d'utilisation d'une session d'agent en échangeant les détails historiques contre un résumé de travail structuré. Le modèle mental sécurisé est une "poursuite avec perte au-dessus d'un registre durable", et non une "mémoire parfaite".
Préservez des pointeurs stables et des invariants typés, rechargez les preuves exactes lorsque cela importe, réconciliez les effets externes avec les systèmes faisant autorité et testez explicitement la limite de compactage. Le compactage devient fiable lorsque le système sait quels faits un résumé peut compacter — et quels faits il ne doit jamais être autorisé à inventer ou à oublier.
Références
Mention éditoriale. Cet article reflète l'interprétation technique par TrueFoundry des documents publics cités à la date du 19 septembre 2026. Les fonctionnalités du produit se limitent à ce qui est décrit dans la documentation liée. Les exemples et les paramètres par défaut sont fournis à titre d'illustration ; ils ne constituent pas un conseil juridique, un avis d'audit, un benchmark indépendant ou une garantie de sécurité, de sûreté ou de conformité.
TrueFoundry AI Gateway offre une latence d'environ 3 à 4 ms, gère plus de 350 RPS sur 1 processeur virtuel, évolue horizontalement facilement et est prête pour la production, tandis que LiteLM souffre d'une latence élevée, peine à dépasser un RPS modéré, ne dispose pas d'une mise à l'échelle intégrée et convient parfaitement aux charges de travail légères ou aux prototypes.












.png)
.png)
.png)
.png)

.webp)
.webp)
.png)

.png)
.png)
.png)
.png)
.webp)
.webp)

.png)
.png)





