Le modèle d’utilisateur d’OpenClaw

Les préférences et les faits échouent différemment. Un fait simplement présent dans le contexte peut encore être rappelé ; une préférence simplement présente cesse d’être appliquée après quelques tours. Cette asymétrie explique pourquoi OpenClaw garde le modèle d’utilisateur dans son propre petit fichier avec ses propres règles de format, au lieu de le mélanger à la mémoire durable.

Le contrat de format

• Chaque entrée est un commentaire de métadonnées suivi d’une seule directive impérative : commencer par un impératif comme toujours, jamais ou préférer, consigner la date d’observation, n’utiliser que actif ou remplacé comme statut, garder une seule instruction de comportement par directive, et ne stocker que ce qui améliore l’assistance plutôt que de bâtir un dossier.
• Quand une préférence change, mettez à jour sa section existante et gardez l’entrée remplacée à côté de son remplacement pour que la directive courante soit sans ambiguïté ; n’ajoutez pas une seconde directive active ailleurs, parce qu’un historique contradictoire en ajout pur fait répondre les modèles avec la valeur périmée.
• Le fichier se charge à côté de la mémoire durable au début de la session avec un petit budget d’amorçage séparé, les modifications sont reprises aux tours suivants dans une session longue, et si le fichier est absent le démarrage continue simplement sans lui.
• Choisir le bon fichier tient dans un tableau : les préférences stables et les faits de relation ou de projet qui changent la façon de vous assister vont ici, les faits durables hors profil et les décisions vont en mémoire durable, les observations détaillées vont dans les notes quotidiennes datées, les actions futures conditionnées par un événement deviennent des intentions permanentes, et les actions à heure fixe ou récurrentes deviennent des tâches planifiées.

Quand une préférence change, mettez à jour sa section existante. N’ajoutez pas une seconde directive active ailleurs dans le fichier.

Le garder compact

Le fichier utilisateur a un plafond d’amorçage fixe de quatre mille caractères, plus petit que le budget général par fichier, et les clés de configuration qui dimensionnent les autres fichiers ne peuvent qu’abaisser ce plafond, jamais le relever. C’est délibéré : l’orientation de profil doit rester de la taille d’une directive pour ne pas chasser les règles de projet et les faits durables du budget d’invite partagé. Quand le fichier approche du plafond, l’ordre documenté est de retirer les entrées remplacées devenues inutiles en gardant chaque remplacement à côté de son prédécesseur, de déplacer vers la mémoire durable les faits et leçons qui ne changent pas la façon de vous assister, de déplacer les observations détaillées et le contexte de projet vers les fichiers datés, et de convertir les actions conditionnées en intentions permanentes pour que le déclencheur reste disponible sans tout le détail. La commande de diagnostic nomme le plafond et recommande de compacter quand c’est la limite fixe qui mord, et donne un autre conseil quand c’est le budget total partagé.

Le profil à côté du fichier

• Le profil de passerelle authentifié est distinct du fichier utilisateur : il porte le nom affiché et l’avatar que voient les autres, une passerelle mono-utilisateur donne aux connexions d’opérateur non identifiées un profil propriétaire local durable partagé entre appareils, et ce profil n’a pas d’email, ne change aucune permission et ne peut pas être fusionné avec un profil personnel.
• L’identité vérifiée peut venir d’un proxy conscient de l’identité ou d’une connexion de tailnet adossée au même fournisseur de compte, en enregistrant l’identifiant numérique immuable à côté du nom de connexion courant pour que les renommages restent attachés à une seule personne, et la ligne du compte reste en lecture seule parce que les connexions par jeton, mot de passe ou non authentifiées ne peuvent pas la revendiquer.
• Le crédit public sur les commits est un choix distinct, actif par défaut pour les comptes vérifiés : il ajoute l’adresse publique sans réponse du compte vérifié comme ligne de co-auteur aux commits créés depuis des sessions partagées, l’invite système liste une fois les lignes exactes que l’agent doit appliquer, et le désactiver arrête l’attribution future sans réécrire les commits qui la portent déjà.

La mémoire OpenClaw en bref couvre la famille de fichiers à laquelle celui-ci appartient et L’architecture mémoire d’OpenClaw pourquoi les préférences sont tenues à l’écart des faits.

Ce qu’il ne faut pas y mettre

La tentation, avec un fichier utilisateur, est d’écrire des observations : des notes sur ce que quelqu’un a dit, quand, et ce qu’il semblait vouloir. Le format y résiste exprès. Une observation doit être interprétée avant de changer un comportement, et l’interprétation est précisément ce qui se dégrade sur une longue conversation. Une directive n’a pas besoin d’être interprétée. La même logique explique les métadonnées de statut : une entrée remplacée posée à côté de son remplacement dit au modèle comme au lecteur humain laquelle est courante, tandis qu’un fichier de phrases non datées ne dit rien à personne. Les intentions permanentes d’OpenClaw est l’endroit des actions futures conditionnées et L’espace de travail de l’agent OpenClaw l’ensemble plus large de fichiers lus au démarrage.

Sur Diali

Sur Diali la personnalité saisie lors de l’intégration entre dans ces fichiers d’espace de travail, et l’espace de travail vit sur un volume persistant, avec des instantanés quotidiens et une restauration en un clic grâce à l’option Sauvegardes (incluse avec Max). OpenClaw hébergé sur Diali décrit l’assistant hébergé et Les tarifs Diali les offres dans lesquelles il est livré.

• Des directives, pas des observations ; une instruction par entrée.
• Remplacer sur place, en gardant l’ancienne entrée près de la neuve.
• Quatre mille caractères, un plafond que la configuration ne peut qu’abaisser.