La Gestion du Contexte d'OpenClaw Critiquée pour sa Consommation de Tokens et ses Défauts Architecturaux

Un utilisateur de Reddit a publié une critique détaillée de l'architecture d'OpenClaw, ciblant spécifiquement son approche de gestion du contexte. Le post soutient que le framework gère l'état de manière inefficace en traitant la fenêtre de contexte du LLM comme une "décharge" via des vidages de contexte paresseux et tout-ou-rien.

Comment OpenClaw gère le contexte

Selon la source, OpenClaw manque d'une gestion d'état appropriée et d'un isolement de l'état éphémère. Chaque fois que l'agent effectue une étape, la nouvelle action est aveuglément ajoutée à l'historique global. En trois tours, le prompt devient gonflé avec :

• Le prompt système global
• Le fichier de mémoire à long terme complet de l'utilisateur
• Une liste de tous les outils disponibles
• La sortie brute de la dernière commande
• Toutes les actions précédentes

Le problème avec les modèles plus petits

Le post décrit ce qui se passe lors de l'exécution d'OpenClaw sur des modèles plus rapides et moins chers comme les variantes Flash ou Mini :

• Les modèles plus petits souffrent du syndrome "perdu au milieu" lorsqu'ils sont noyés dans 50 000+ tokens d'anciennes sorties de terminal, de journaux d'outils et de prompts de personnage global
• Ces modèles oublient littéralement l'objectif original
• Ils hallucinent soit que la tâche est déjà terminée
• Soit ils restent piégés dans une boucle infinie appelant exactement le même outil avec exactement les mêmes arguments

La dépendance à Claude Opus

La critique s'étend à la dépendance d'OpenClaw aux modèles frontaliers :

• OpenClaw prétend que ses agents sont "hautement capables", mais cette capacité vient du fait qu'ils s'appuient sur des modèles frontaliers massifs comme Claude Opus
• Claude Opus peut regarder un "incendie de décharge" de 80 000 tokens et ignorer avec succès 79 500 tokens d'encombrement historique inutile pour déduire l'étape suivante
• Cela crée l'illusion que le framework est bien construit alors qu'en réalité, Opus masque une incompétence architecturale
• Les utilisateurs finissent par payer des prix d'API de niveau Opus pour qu'un LLM de pointe agisse comme un "filtre à ordures glorifié" pour un contexte mal conçu

Recommandations architecturales

Le post plaide pour une meilleure ingénierie plutôt que la force brute :

• Une simple tâche de navigation ou de terminal en plusieurs étapes ne devrait pas nécessiter un modèle à mille milliards de paramètres
• Si elle est correctement conçue, la boucle devrait forcer le modèle à observer l'environnement et lui fournir exactement ce qu'il doit voir maintenant et absolument rien d'autre
• Cette approche pourrait atteindre le même taux de réussite en utilisant une fraction de la puissance de calcul sur des modèles moins chers et plus rapides