Scripts de démarrage à froid et de fin de session : une meilleure mémoire d'agent pour OpenClaw
Un utilisateur d'OpenClaw, Competitive_Swan_755, a partagé sa configuration pour aider les agents à gérer les transitions de session et les problèmes récurrents. L'approche s'inspire de Hermes et implique deux composants clés : les scripts de démarrage à froid et de fin de session, ainsi qu'un répertoire /SOP.
Détails clés
- Script de démarrage à froid : Écrit avant le début d'une session, il donne à l'agent le contexte de ce à quoi s'attendre, y compris probablement l'état du projet, les objectifs et tout historique pertinent.
- Script de fin de session : Écrit avant la fin de la session, il capture ce qui a été accompli, ce qui reste à faire, et toutes les notes importantes pour la session suivante.
- Répertoire /SOP : Un dossier de procédures opérationnelles standard. L'agent peut s'y référer pour résoudre rapidement des problèmes courants ou inhabituels, évitant ainsi de devoir trouver la même solution à chaque fois.
L'idée est simple : imposer une discipline de documentation de l'état et des solutions afin que chaque session commence avec une image claire et se termine par un résumé mémorable. Cette pratique est particulièrement utile pour les développeurs qui gèrent plusieurs agents ou des projets à long terme où la perte de contexte est un problème fréquent.
Pourquoi c'est important
Les agents OpenClaw (et les assistants de codage IA similaires) fonctionnent souvent sans mémoire persistante. Les scripts de démarrage à froid leur donnent la piste nécessaire ; les scripts de fin de session assurent une transition propre. Le répertoire /SOP agit comme une base de connaissances légère, réduisant la résolution répétitive de problèmes et améliorant la cohérence entre les sessions.
Si vous atteignez les limites du contexte ou si vous constatez que votre agent redécouvre des solutions, ce modèle mérite d'être adopté. C'est une pratique à faible coût et à fort impact.
Cette astuce provient d'un post communautaire—consultez la discussion complète pour plus de détails et tout commentaire de suivi.
📖 Lire la source complète : r/openclaw
👀 See Also
Exécution d'OpenClaw sur un Raspberry Pi Model B avec des API gratuites
OpenClaw fonctionne de manière stable sur un Raspberry Pi Model B avec des API gratuites, notamment Google Gemma 4 31B IT (~20 RPM, contexte illimité) et Gemini Flash, où Firefox headless surpasse Chromium pour l'automatisation du navigateur.
OpenClaw API Budget Drain : Paramètres à modifier immédiatement
La fonction Heartbeat par défaut d'OpenClaw peut épuiser les budgets d'API en vérifiant les tâches toutes les 30 minutes et en chargeant à chaque fois les fichiers de contexte complets, la mémoire et l'historique des conversations. La source recommande de modifier les Heures d'Activité, d'utiliser des modèles de base moins chers, de passer manuellement aux modèles premium uniquement lorsque nécessaire et d'utiliser /new pour réinitialiser les sessions.
Correction du Dispositif de Vérification Résout le Problème d'Exécution du Plan de Claude
Un développeur a créé une couche de vérification en bash ou Python de 30 à 50 lignes qui vérifie si Claude exécute réellement chaque étape de ses propres plans en vérifiant des artefacts comme l'existence de fichiers, les réponses API et les changements de configuration.
Empêcher OpenClaw de générer plusieurs instances LLM locales sur LM Studio
Un utilisateur signale qu'OpenClaw lance plusieurs instances locales de LLM (Qwen 3.5 9B via LM Studio) sur un Mac Mini M1 de 16 Go, provoquant des dépassements de délai et une épuisement des ressources. Il cherche un moyen de forcer une file d'attente à instance unique.