Gestion de l’historique

Le runtime conserve l’historique de conversation pour chaque session d’agent et envoie au modèle un historique de travail destiné au fournisseur. Deux limites complémentaires opèrent sur des représentations différentes :

1. L’élagage du budget de jetons agit sur l’historique de travail ChatMessage exposé au fournisseur et supprime les tours complets les plus anciens jusqu’à ce que le contexte estimé tienne dans le budget de jetons.
2. Le rognage structuré par nombre de messages modifie Agent::history (ConversationMessage) utilisé par les tours Agent RPC, gateway et ACP lorsqu’il dépasse la limite effective de messages de l’agent structuré. Les boucles de canal du démon qui appellent le chemin hérité agent::run utilisent la limite de messages bruts distincte décrite ci-dessous.

Le rognage selon le budget de tokens et la limite structurée du nombre de messages conservent les tours de manière atomique. Un tour commence à un véritable message utilisateur et inclut la réponse de l’assistant ainsi que tous les appels d’outils et résultats d’outils avant le message utilisateur suivant. Le rognage ne sépare donc pas un appel d’outil de son résultat.

Rétention sur l’ensemble du tour

history_trim::trim_to_recent_turns applique le budget de tokens, tandis que history_trim::trim_conversation_to_recent_turns applique la limite structurée du nombre de messages. Chacun conserve le tour complet le plus récent, même si ce tour dépasse à lui seul la limite concernée. C’est intentionnel : préserver un tour courant complet est plus sûr que de satisfaire un seuil numérique en supprimant ses messages les plus récents ou en interrompant un échange d’outils.

Les messages système en tête sont conservés. Lorsqu’aucun rognage n’est nécessaire, l’ordre et la structure des messages restent inchangés.

Budget de jetons

Le budget de tokens provient de ResolvedRuntime::effective_context_budget() :

• Lorsque history_pruning.enabled est activé avec une valeur positive pour history_pruning.max_tokens, le budget correspond à la plus petite des deux valeurs entre celle-ci et max_context_tokens.
• Sinon, le budget est max_context_tokens.

Les comptages de tokens sont estimés par history::estimate_history_tokens : environ quatre caractères par token plus quatre tokens de cadrage par message. Il s’agit d’une heuristique, et non d’un tokeniseur de fournisseur.

Le rognage du budget de jetons s’exécute avant le premier appel au fournisseur d’un tour lorsque l’historique dépasse déjà le budget effectif, et aux limites d’appel au fournisseur entre les itérations de la boucle d’outils, y compris de manière réactive lorsqu’un fournisseur signale que la fenêtre de contexte a été dépassée. Il conserve des tours entiers, de sorte qu’il ne divise jamais un échange d’outils.

Limite structurée du nombre de messages

max_history_messages est la valeur configurée dans le profil d’exécution de l’agent. Une valeur explicitement configurée fait autorité pour le chemin brut hérité et l’historique d’agent structuré, y compris 0. Étant donné que l’élagage structuré conserve toujours le tour complet le plus récent, une valeur de 0 supprime les tours plus anciens mais n’efface pas le tour en cours.

Lorsque max_history_messages est omis, le plafond brut hérité reste 50. Le plafond effectif de l’agent structuré est dérivé de l’allocation de boucle d’outils :

max(50, 2 * max_tool_iterations + 2)

Chaque itération d’outil peut ajouter un appel d’outil et un résultat d’outil ; les deux emplacements supplémentaires couvrent le message de l’utilisateur et la réponse finale de l’assistant. Avec la valeur par défaut max_tool_iterations = 10, la limite dérivée reste 50.

Rognage visible

Chaque fois que la réduction du budget de jetons ou la limite structurée du nombre de messages supprime les tours plus anciens, le runtime :

1. Insère un fil d’Ariane avant le premier tour conservé afin que le modèle sache que le contexte antérieur a été omis.
2. Émet HistoryTrimmed avec le nombre de messages supprimés, les tours conservés et une raison indiquant le budget de jetons ou la limite de messages.

L’événement est exposé via le transport client actif et via le chemin d’observateur utilisé par les tableaux de bord et les abonnés aux événements. La suppression n’est donc pas limitée aux journaux et n’est pas silencieuse, ni pour le modèle ni pour les clients connectés.

Le chemin hérité agent::run dans loop_.rs constitue une exception inchangée. Sa limite brute de ChatMessage dans history::trim_history reste au niveau des messages et signale le rognage uniquement via les journaux, sans le fil d’Ariane ni l’événement HistoryTrimmed. Ce chemin sert à la fois à l’usage interactif ainsi qu’aux appelants one-shot et non interactifs de type daemon, cron, sous-agent et SOP.

Sécurité de l’appairage

La rétention par tour entier est la principale garantie d’appariement des outils : un appel d’outil et son résultat appartiennent au même tour et sont conservés ou supprimés ensemble. Le balayage des orphelins reste un filet de sécurité final pour les historiques déjà incohérents, tels que les sessions restaurées ou modifiées en externe.

Les limites de longueur des résultats d’outils sont distinctes. max_tool_result_chars borne un résultat individuel lors de son enregistrement ; cela n’élague pas l’historique de la conversation. L’application du contexte côté fournisseur est également distincte, bien qu’un débordement du fournisseur puisse déclencher l’élagage réactif du budget de tokens du runtime.