OpenClaw met en œuvre la Compression de l'Historique des Agents pour réduire l'utilisation du contexte.

Problème de gestion du contexte

Lors de l'exécution d'OpenClaw dans Docker, l'écriture directe de code par l'agent remplit le contexte de bruit : lecture de fichiers (5 000 tokens), écriture de modifications (500 tokens), exécution de tests (200 tokens) et réception de traces d'erreurs (3 000 tokens). Un seul cycle de débogage consomme 10 000 à 15 000 tokens, principalement issus des sorties console et des traces d'erreurs qui deviennent inutiles après les corrections de bugs. Avec 20 à 30 cycles de débogage par session, la fenêtre de contexte entière est consommée par du bruit.

Architecture Cerveau/Ouvrier

La solution implique de séparer les responsabilités : OpenClawd (dans Docker) agit comme le cerveau pour la planification, la décomposition du travail en sous-tâches, la délégation et la coordination. Un ouvrier local sur l'hôte macOS, alimenté par Qwen3.5-27B fonctionnant sur Apple Silicon via MLX sans coût, sert de mains pour lire les fichiers, écrire le code, exécuter les tests et déboguer. Cela maintient les échanges bruyants dans le contexte de l'ouvrier, le cerveau ne voyant que les résultats finaux comme "tâche terminée, voici les fichiers modifiés".

Stratégie de compression

Même avec la séparation cerveau/ouvrier, le contexte de l'orchestrateur se remplit encore de documents opérationnels : AGENTS (~6 600 tokens), SOUL (~1 500 tokens), LESSONS (~10 000 tokens) et plans/guides (~13 000 tokens sur disque), totalisant 20 000 à 30 000 tokens avant même que le travail ne commence. Les sessions peuvent atteindre 100 000 à 200 000 tokens.

L'idée clé : le travail terminé n'a pas besoin de détails bruts. Une fois qu'une sous-tâche est achevée, son historique brut devient du poids mort. L'agent a seulement besoin de savoir : quelle était la tâche, a-t-elle réussi, quels fichiers ont changé, et y a-t-il eu des erreurs.

Détails d'implémentation

Étape 1 : Détecter les limites du cycle de vie - L'orchestrateur décompose le travail en sous-tâches avec des cycles de vie : Lancement (l'agent appelle sessions_spawn ou delegate_task), Exécution (appels d'outils, raisonnement) et Achèvement (Message système "sous-agent 'nom_tâche' terminé"). Un scanner à 4 passes parcourt le JSONL de la session :

• Passe 1 : Trouver les événements de lancement
• Passe 2 : Trouver les erreurs de lancement
• Passe 3 : Trouver les marqueurs d'achèvement
• Passe 4 : Calculer le nombre de tokens et la durée par cycle de vie

Cela identifie les plages de messages appartenant aux sous-tâches terminées.

Étape 2 : Résumer en "langage agent" (masquage) - Les résumés sont générés pour ressembler à une sortie normale d'agent afin de maintenir la compatibilité avec le format de message attendu par l'orchestrateur (rôles, blocs de contenu, structures d'appel d'outils, chaînes d'ID parent-enfant). Ces résumés masqués remplacent l'historique brut des tâches.

Exemple de résumé de tâche compacté :

── TÂCHE COMPACTÉE ──
origine : agent
tâche : Implémenter un délai d'inactivité pour le serveur MLX
résultat : succès
résultat : Ajout d'un minuteur d'inactivité de 5 min à MlxServerManager.
Le serveur se décharge automatiquement lorsqu'aucune requête n'est reçue.
fichiers+ : src/services/mlx_idle_monitor.py
fichiers~ : src/services/mlx_server.py, config.json
erreurs : aucune
essais_et_échecs : threading.Timer — condition de concurrence
à_retenir : Le serveur MLX ne doit se recharger que sur demande explicite de l'ouvrier, pas sur n'importe quel appel d'outil
─────────────────

Ce résumé d'environ 100 tokens remplace 5 000 tokens d'appels d'outils bruts et de raisonnement (réduction de 99,2 %). Les résumés sont générés par un LLM peu coûteux (Gemini Flash Lite ou MLX local), avec des mécanismes de secours en cas d'échec de génération.