Le contexte est plein, apprends à couper

Pourquoi compacter ?

Si l'agent fonctionne pendant une longue période, les messages[] se développeront : chaque read_file renverra des milliers de jetons, chaque bash en renverra des centaines et chaque cycle de dialogue renverra également le texte de réflexion du modèle. Après 50 tours, le contexte peut être rempli à 100K+. Deux conséquences :

• Rencontrer la limite supérieure du modèle : il s'effondre lorsque la taille de la fenêtre est atteinte, ou le prix augmente linéairement à chaque appel d'API.
• Dilution de l'attention : Maintenant que la tâche à accomplir est noyée dans des résultats d'outils non pertinents d'il y a 30 tours, le modèle commence à perdre sa concentration.

L'idée de s06 : laisser l'agent oublier activement le contenu sans importance mais conserver les états clés. Mécanisme à trois couches, du léger au lourd.

Couche 1 · micro_compact (fonctionne silencieusement à chaque tour)

Le niveau le moins cher. Exécutez-le avant chaque appel LLM et remplacez plus de 3 anciens tool_results par des espaces réservés :

# À partir du 10ème tour, la plupart des résultats d'outils deviennent :
{
  "type" : "tool_result",
  "tool_use_id" : "tolu_01A",
  "content" : "[Précédent : utilisé bash]" # Réduit de milliers de caractères à des dizaines

Il existe un cas particulier : le résultat de read_file n'est pas compressé. Pourquoi? Étant donné que la sortie de lecture est un document de référence, si vous appuyez sur le modèle, vous devez le relire, ce qui coûte plus cher.

PRESERVE_RESULT_TOOLS = {"read_file"} # Ne jamais compresser

Regardez micro_compact et appuyez sur Turn pour manger les anciens résultats

Les étapes suivantes simulent 10 cycles d'interaction et permettent à micro_compact de s'exécuter une fois avant chaque cycle. Voyez que l'ancien tool_result dans messages[] devient [Previous: ...], mais les 3 derniers restent les mêmes.

Couche 2 · auto_compact (déclenché lorsque le seuil est dépassé)

Même si le micro continue de fonctionner, il explosera quand même lorsqu'il sera fatigué jusqu'à une certaine taille. s06 définit un seuil (50 000 jetons par défaut) :

1. Estimer le nombre de jetons len(str(messages)) // 4 (approximatif mais utile).
2. Dépasse le seuil → Écrivez la transcription complète dans .transcripts/transcript_TIMESTAMP.jsonl (laissez le bas).
3. Demandez au LLM de rédiger un résumé de l'intégralité de la conversation.
4. Remplacez l'intégralité des messages par un seul "[compressé] RÉSUMÉ...".

Le coût est évident : le résultat spécifique de l'outil et le ton de la conversation sont perdus, et seul le plan est laissé. Mais l'agent peut continuer à faire, ce qui constitue le principal avantage.

Couche 3 · Ajustez le modèle vous-même, outil compact

auto_compact est automatiquement déclenché par le harnais et n'est pas connu du modèle. La couche 3 fait le contraire : donnez au modèle un outil compact et laissez-le demander activement la compression - par exemple, s'il estime que l'exploration précédente est inutile et qu'une nouvelle étape doit être démarrée.

Appel de modèle :

tool_use("compact", focus="conserver les décisions de conception de l'API")

Le déclenchement est identique à l'auto, mais peut prendre un paramètre focus pour indiquer sur quoi se concentrer lors du résumé. C'est très pratique en combat réel : le modèle sait quelles sont les « petites tâches terminées », ce qui est plus précis que l'heuristique du harnais.

Quelle couche est appropriée ? question vraie ou fausse

Les scénarios suivants déterminent quel déclencheur micro/auto/manuel est le plus raisonnable.