OpenClaw mémoire: vérifier l'écriture, l'indexation, la recherche et le redémarrage

La mémoire OpenClaw n'est saine que lorsque quatre affirmations différentes sont vraies: l'enregistrement prévu a été écrit pour un stockage durable, l'index actuel couvre l'écriture, la récupération renvoie l'ancre source correcte, et une nouvelle session applique toujours la décision correctement. Un fichier Markdown sur le disque ne prouve que la première réclamation. Une recherche réussie ne prouve qu'une partie indexée correspond. Utilisez une vérification de contenu réduite qui garde le texte de mémoire sur l'hôte. Enregistrez des identifiants opaques, des résultats de comparaison locaux, des timestamps et des ancrements de source; n'exportez pas les instructions, le contenu des notes, les chemins absolus ou les extraits de recherche bruts. L'opérateur doit être en mesure de distinguer une écriture manquante, un index obsolète, une mauvaise récupération et une décision perdue au lieu de s'effondrer les quatre en mémoire est cassée. Traiter la mémoire OpenClaw comme quatre preuves distinctes Le OpenClaw vue d'ensemble de la mémoire actuel décrit la mémoire comme Markdown simple dans l'espace de travail de l'agent. MEMORY.md est la couche à long terme curatée, tandis que les fichiers datés sous memory/ contiennent un contexte quotidien détaillé. Le modèle se souvient de ce qui atteint le disque; il n'y a pas d'état durable caché qui sauve une écriture omise. Cette conception crée des points d'inspection utiles: 1. Ecrivez preuve: le fichier attendu existe et son contenu local correspond à la version qui devait persister. 2. Index proof: l'arrière plan de mémoire a indexé l'instantané de la source actuelle plutôt qu'un précédent. 3. Retrieval proof: une requête renvoie le fichier et la plage de lignes attendues, pas simplement une phrase plausible provenant d'ailleurs. 4. Prouver de décision: après une limite de session réelle, l'agent suit la décision enregistrée et sa limite d'action. Ces preuves échouent indépendamment. Une note peut exister pendant que l'index reste sale. L'indice peut être actuel pendant qu'une requête tombe en dessous du score configuré. La récupération peut trouver le bon passage alors qu'une nouvelle session ignore son état d'expiration ou son propriétaire. À l'inverse, une session peut répondre correctement parce que le même fait existe toujours dans son contexte de conversation, même si l'écriture durable n'a jamais eu lieu. Le défaut raisonnable est donc un verdict par étapes. Arrêtez vous à la première couche ratée et réparez seulement cette couche. Ne réécrivez pas la mémoire lorsque l'index est obsolète, et ne rétablissez pas un index lorsque l'enregistrement n'a jamais été conservé. Prouver l'écriture sans exporter la mémoire Donner à chaque enregistrement sensible à l'action un identifiant opaque tel que decision 7f3b , plus les champs nécessaires pour agir en toute sécurité plus tard: propriétaire, état effectif, condition d'expiration ou de déverrouillage, et action interdite. L'identité n'est pas un secret et ne révèle pas la décision. À la source, calculez si l'enregistrement actuel correspond à la version locale attendue. Exporter uniquement la comparaison: N'envoyez pas un extrait brut d'une note courte ou sensible à un service de santé à distance. Le texte à faible entropie peut être deviné et hashé. Gardez la digestion sur l'hôte, utilisez un HMAC à clé lorsqu'une empreinte digitale stable doit quitter la limite du processus, ou signalez uniquement la comparaison booléenne et un identifiant d'enregistrement opaque. Un système de fichiers écrit rendant le succès n'est pas suffisant. Lisez l'enregistrement du fichier durable, puis comparez les octets qui ont été stockés. Si l'écriture est censée survivre à un redémarrage de l'hôte, confirmez que l'emplacement de stockage est persistant pour ce déploiement; un espace de travail local de conteneur peut disparaître même si l'appel d'écriture a réussi. La même règle s'applique à la tronçage de MEMORY.md . OpenClaw maintient un fichier surdimensionné intact tandis que la copie injectée dans le contexte du bootstrap peut être tronquée. La présence des fichiers passe toujours, mais la preuve de décision peut échouer parce que l'entrée requise n'a pas atteint la nouvelle session. La vue d'ensemble de la mémoire recommande de vérifier les détails du contexte ou la sortie du médecin lorsque des limites de démarrage sont impliquées. Prouver la fraîcheur de l'index avant de faire confiance à la récupération OpenClaws documentation de recherche de mémoire explique que le backend intégré peut combiner la similitude vectorielle avec la correspondance des mots clés BM25. Il documente également la synchronisation automatique au début de la session, lors de la recherche et par l'intermédiaire d'un observateur de fichiers. Ces mécanismes réduisent les fenêtres vieillissantes; ils ne rendent pas la fraîcheur inobservable. Commencez par le statut: La sonde deep vérifie le fournisseur d'intégration et le chemin de recherche sémantique, afin qu'elle puisse faire un appel au fournisseur. Inspectez au moins: si le magasin est sale; le nombre de fichiers indexés et de pièces; le fournisseur et le modèle sélectionnés; la disponibilité du FTS; la disponibilité de la recherche vectorielle et sémantique; les problèmes de scan et l'identité de l'index. Sur OpenClaw 2026.7.1 2 , une sonde en direct en lecture seule au cours de cette enquête a rapporté une identité d'index intégrée valide et des voies léxicales et sémantiques disponibles, mais aussi dirty: true . Cette combinaison est importante: une sonde d'intégration fonctionnelle ne prouve pas que la note la plus récente est indexée. Lorsque la source est correcte mais que le magasin est sale, procédez à une synchronisation progressive avec: Réservez une reconstruction forcée pour une identité invalide, une configuration modifiée de fragmentation ou d'intégration, une corruption ou une synchronisation incrémentielle qui ne peut pas converger: Le mémoire OpenClaw référence CLI distingue ces opérations: le status index réindique lorsqu'il est sale, tandis que le index force effectue une reconstruction complète. Traiter une panne de fournisseur comme search unavailable , pas une mémoire vide. Le comportement documenté est délibérément explicite lorsqu'un fournisseur d'intégration configuré échoue; il ne doit pas devenir silencieusement la preuve qu'aucun enregistrement pertinent n'existe. Traversez la limite de redémarrage avec une sonde de décision Rechercher une clé de récupération opaque unique au dossier d'essai, puis demander un résultat ancré: Une preuve de récupération passante contient le type de source attendu, la référence de fichier et la plage de lignes. Ne passez pas parce que le texte du résultat sonne correctement. La recherche hybride peut renvoyer des notes liées sémantiquement, et les entrées quotidiennes répétées peuvent placer une version plus ancienne au dessus de la décision actuelle. Maintenant, traversez une véritable limite de séance. Une deuxième demande dans la même conversation n'est pas un test de redémarrage parce que l'instruction originale peut encore être dans le contexte. Commencez une nouvelle session à travers le mécanisme de session normal du runtime, demandez une sonde de décision limitée et comparez le comportement avec le contrat enregistré. Par exemple, si la note durable stipule qu'une migration reste de conception uniquement jusqu'à l'approbation de A 42 , la sonde devrait demander si la mise en œuvre peut commencer maintenant. Le résultat attendu est un code de décision tel que WAIT FOR A 42 , et non une citation littérale de la note privée. Le dossier: Il teste la continuité utile plutôt que le théâtre de récolte. Un modèle peut paraphraser une note tout en abandonnant la limite d'autorité qui la rend sûre. Elle peut aussi produire la bonne décision par hasard. Gardez la sonde étroite, répétez la après des modifications de configuration pertinentes et incluez un cas négatif dont la condition de déverrouillage n'a pas été remplie. Répétez une vérification sans contenu de neuf cas L'appareil memory health cases.json qui l'accompagne ne contient pas de texte de mémoire. Il fournit neuf observations synthétiques à evaluate openclaw memory health.mjs , une pour chaque état terminal: Le résumé reproduit est le suivant: Le classifiateur utilise un ordre strict. Il vérifie l'existence durable et l'égalité locale avant l'état de l'indice; l'état de l'indice avant la disponibilité de la recherche; la disponibilité de la recherche avant la récupération; et la récupération avant une nouvelle décision de session. Cela empêche les réparations trompeuses. La réindexation ne peut pas créer un enregistrement manquant. La réécriture d'un enregistrement ne peut pas restaurer un fournisseur d'intégration raté. Un score élevé ne prouve pas la continuité du redémarrage. Adaptez le fichier avec des identifiants opaques réels et des booliens locaux. Ajoutez des cas pour un espace de travail uniquement lu, un index construit à partir d'un ancien digeste, un résultat de la mauvaise note datée, un fichier de démarrage tronqué, un fournisseur d'intégration indisponible, un back up uniquement pour les mots clés et une décision dont l'approbation a expiré. Gardez la note brute et le résultat de recherche brut hors de la télémétrie partagée. Utilisez un état inconnu explicite La règle de fonctionnement compacte est la suivante: La mémoire de marque OpenClaw est vérifiée uniquement lorsque l'enregistrement durable correspond localement, que l'indice actuel le couvre, que la récupération s'ancrera à la source attendue et qu'une nouvelle session produira la décision limitée attendue. Tout le reste devrait conserver un état non vert spécifique. Le search unavailable n'est pas le retrieval miss . Le restart unverified n'est pas le continuity failed . Un inconnu explicite est plus utile qu'un statut rouge générique car il identifie le prochain test sûr sans inviter l'agent à inventer le contexte manquant. Cette vérification a encore des limites. Une comparaison locale ne peut valider que les enregistrements inclus dans l'ensemble d'essai. Un hôte compromis peut falsifier la note et les preuves. Une sonde de récupération mesure une requête et une configuration de classement. Un code de décision correspondant ne prouve pas que toutes les nuances ont survécu, et les sondes répétées consomment le modèle et le budget d'intégration. Utilisez des contrôles déterministes pour le stockage et l'indexation, puis passez des appels de modèle uniquement sur le comportement qui ne peut pas être vérifié à partir des fichiers et de l'état de la base de données. Sidewisp est actuellement en préversion privée. Il est destiné à fournir une couche de santé autour des temps d'exécution existants des agents, mais les adaptateurs OpenClaw de production, la collecte en direct des agents de santé et la récupération automatisée ne sont pas expédiés dans le référentiel du site Web actuel. L'audit à quatre preuves est un modèle géré par l'opérateur que vous pouvez mettre en œuvre maintenant, pas une affirmation selon laquelle Sidewisp surveille ou répare actuellement la mémoire OpenClaw. Si cette séparation entre le stockage, la récupération et la prise de décision correspond à la façon dont vous souhaitez utiliser les agents, rejoignez l'aperçu privé Sidewisp. En attendant, gardez la comparaison locale, faites le redémarrage réel, et laissez les preuves manquantes rester inconnues.