Utiliser un modèle plus petit comme couche d'hygiène d'exécution améliore la fiabilité de l'agent OpenClaw.

Problème : Les sorties négligées dégradent les agents à long terme

Lors de l'exécution d'OpenClaw localement sur un Mac Studio M4 (36 Go) avec Qwen 3.5 27B (4 bits, oMLX) comme agent domestique, le modèle n'a pas perdu en capacité au fil du temps — il est devenu négligé. Les problèmes spécifiques incluaient :

• Les appels d'outils qui fuient sous forme de texte brut au lieu d'une utilisation structurée des outils
• Les pensées de planification qui s'infiltrent dans les réponses finales
• La répétition des résultats des outils et du texte de politique à l'utilisateur
• Les sorties mal formées qui empoisonnent le contexte, provoquant une dégradation à chaque tour suivant

Le problème central n'était pas la capacité mais l'hygiène d'exécution : le modèle savait quoi faire mais échouait à adopter un comportement approprié dans l'environnement d'exécution d'OpenClaw.

Solution : Architecture à quatre couches pour l'hygiène d'exécution

Le développeur a mis en œuvre une approche à quatre couches qui s'est avérée plus efficace que simplement utiliser un modèle plus grand :

• Résumé : Compaction du contexte via lossless-claw (basé sur DAG, freshTailCount=12, contextThreshold=0.60). Cela a fourni la plus grande amélioration.
• Sheriff : Vérifications par expressions régulières et heuristiques qui capturent les réponses mal formées avant qu'elles n'entrent dans OpenClaw. Cela empêche le balisage d'outil divulgué, les divagations du planificateur et le JSON brut de devenir un contexte durable.
• Juge : Un modèle plus petit et moins coûteux qui classe les sorties limites comme « réponse finale valide » contre « déchet ». Ce modèle n'est pas pour l'intelligence mais pour l'hygiène d'exécution — c'est un système immunitaire plutôt qu'un second cerveau. Il gère également tous les résumés pour lossless-claw.
• Ozempic (nom interne) : Nettoyage agressif de la mémoire qui garantit que le modèle relit uniquement les demandes de l'utilisateur, les réponses finales et les faits compacts dérivés des outils lors des tours futurs — pas les divagations du planificateur, le JSON brut des outils, les artefacts de nouvelle tentative ou les monologues de politique.

Pourquoi cela surpasse l'utilisation d'un modèle plus grand

Un seul modèle doit simultanément résoudre des tâches, maintenir une discipline de formatage, gérer la cohérence du contexte, éviter de s'empoisonner avec ses propres sorties et se remettre des mauvaises sorties — particulièrement difficile aux niveaux de quantification locaux. Diviser les responsabilités pour que le modèle principal fasse le travail tandis qu'un modèle plus petit maintient l'hygiène d'exécution s'est avéré plus efficace que d'ajouter plus de paramètres.

Résultat : Fonctionnement soutenu sans réinitialisations

Cette approche est passée de la nécessité de réinitialisations /new toutes les 20 à 30 minutes à un fonctionnement soutenu en session unique sur un Mac Studio M4 avec 36 Go de RAM, entièrement local sans appels API.