Memoria OpenClaw: Verifica la scrittura, l'indice, la ricerca e il riavvio

La memoria OpenClaw è sana solo quando quattro affermazioni diverse sono vere: il record previsto è stato scritto per un archiviazione duratura, l'indice corrente copre quello che scrive, il recupero restituisce l'ancora sorgente giusta e una nuova sessione applica ancora correttamente la decisione. Un file Markdown sul disco dimostra solo la prima affermazione. Una ricerca riuscita dimostra solo che alcuni pezzi indicizzati corrispondono. Utilizzare un audit ridotto al contenuto che conserva il testo in memoria sull'host. Registrare ID opaci, risultati di confronto locali, timestamp e ancoraggi di fonte; non esportare richieste, contenuti di note, percorsi assoluti o frammenti di ricerca grezzi. L'operatore dovrebbe essere in grado di distinguere una scrittura mancante, un indice obsoleto, un recupero errato e una decisione persa invece di crollare tutte e quattro in la memoria è rotta. Trattare la memoria OpenClaw come quattro prove separate L'attuale Presentazione generale della memoria OpenClaw descrive la memoria come semplice Markdown nello spazio di lavoro dell'agente. MEMORY.md è lo strato a lungo termine curato, mentre i file datati sotto memory/ contengono un contesto quotidiano dettagliato. Il modello ricorda ciò che raggiunge il disco; non c'è uno stato duraturo nascosto che salvi una scrittura omessa. Tale progettazione crea punti di ispezione utili: 1. Scrivere prova: l'archivio previsto esiste e il suo contenuto locale corrisponde alla versione che doveva persistere. 2. Index proof: il backend della memoria ha indicizzato lo snapshot di sorgente corrente piuttosto che uno precedente. 3. Retrieval proof: una query restituisce il file e la gamma di linee attese, non semplicemente una frase plausibile da un'altra parte. 4. Prova di decisione: dopo un limite di sessione reale, l'agente segue la decisione salvata e il suo limite di azione. Queste prove falliscono indipendentemente. Un biglietto può esistere mentre l'indice rimane sporco. L'indice può essere attuale mentre una query cade al di sotto del punteggio configurato. Il recupero può trovare il passaggio corretto mentre una nuova sessione ignora la sua condizione di scadenza o il suo proprietario. Al contrario, una sessione può rispondere correttamente perché lo stesso fatto esiste ancora nel contesto della conversazione, anche se la scrittura duratura non è mai avvenuta. Il risarcimento ragionevole è quindi un verdetto in fase. Fermati al primo strato fallito e ripara solo quel strato. Non riscrivere la memoria quando l'indice è obsoleto, e non ricostruire un indice quando il record non è mai stato mantenuto. Prova la scrittura senza esportare la memoria Indicare a ogni registro sensibile all'azione un ID opaco come decision 7f3b , oltre ai campi necessari per agire in modo sicuro in seguito: proprietario, condizione effettiva, condizione di scadenza o di sblocco e azione proibita. L'identità non è un segreto e non rivela la decisione. Nella fonte, calcolare se il record corrente corrisponde alla versione locale prevista. Esportare solo il confronto: Non inviare un testo grezzo di una nota breve o delicata a un servizio sanitario remoto. Il testo a bassa entropia può essere indovinato e hashato. Conservare la digestione sul host, utilizzare un HMAC con chiave quando un'impronta digitale stabile deve lasciare il confine del processo, o segnalare solo il confronto booleano e un ID di registrazione opaco. Un sistema di file di scrittura di ritorno di successo non è sufficiente. Leggi il record dal file duraturo, poi confronta i byte che sono stati effettivamente memorizzati. Se si prevede che la scrittura sopravviva a un riavvio dell'host, confermare che la posizione di archiviazione è persistente per quella distribuzione; uno spazio di lavoro locale contenitore può scomparire anche se la chiamata di scrittura ha avuto successo. La stessa regola si applica alla truncation MEMORY.md . OpenClaw mantiene intatto un file di dimensioni eccessive mentre la copia iniettata nel contesto di bootstrap può essere truncata. La presenza del file passa ancora, ma la prova della decisione potrebbe fallire perché l'entrata richiesta non è arrivata alla nuova sessione. La panoramica della memoria raccomanda di controllare i dettagli del contesto o l'output medico quando sono coinvolti i limiti di bootstrap. Prove la freschezza dell'indice prima di fidarsi del recupero OpenClaws documentazione di ricerca della memoria spiega che il backend integrato può combinare la somiglianza vettoriale con la corrispondenza delle parole chiave BM25. Documenta anche la sincronizzazione automatica all'inizio della sessione, durante la ricerca e attraverso un monitor di file. Questi meccanismi riducono le finestre obsolete; non rendono invisibile la freschezza. Inizia con lo stato: La sonda deep controlla il provider di inserimento e il percorso di ricerca semantica, in modo da poter effettuare una chiamata al provider. Controllare almeno: se il negozio è sporco; il numero di file indicizzati e di pezzi; fornitore e modello selezionati; Disponibilità di FTS; disponibilità di vector store e di ricerca semantica; problemi di scansione e identificazione dell'indice. In merito a OpenClaw 2026.7.1 2 , una sonda in diretta solo per lettura durante questa indagine ha riportato un'identità di indice integrata valida e percorsi lessicali e semantici disponibili, ma anche dirty: true . Questa combinazione è importante: una sonda di inserimento funzionante non dimostra che la nota più recente sia indicizzata. Quando la fonte è corretta ma il negozio è sporco, eseguire una sincronizzazione incrementale con: Riserva una ricostruzione forzata per un'identità invalida, una configurazione modificata, una corruzione o una sincronizzazione incrementale che non può convergere: Il Memoria OpenClaw CLI di riferimento distingue queste operazioni: status index riindica quando è sporco, mentre index force esegue una ricostruzione completa. Trattare un'interruzione del fornitore come search unavailable , non come una memoria vuota. Il comportamento documentato è deliberatamente esplicito quando un fornitore di inserimento configurato fallisce; non dovrebbe diventare silenziosamente la prova che non esiste alcun record rilevante. Attraversare il confine di riavvio con una sonda di decisione Cerca un tasto di recupero opaco che sia unico nel registro di prova, quindi richieda un risultato ancorato: Una prova di recupero di passaggio contiene il tipo di sorgente atteso, il riferimento del file e la gamma di linee. Non passare perché il testo del risultato suona giusto. La ricerca ibrida può restituire note semanticamente correlate e le voci giornaliere ripetute possono posizionare una versione più antica sopra la decisione corrente. Ora attraversate un limite di sessione reale. Un secondo suggerimento nella stessa conversazione non è un test di riavvio perché l'istruzione originale può essere ancora in contesto. Iniziare una nuova sessione attraverso il meccanismo di sessione normale del runtime, chiedere una sonda di decisione limitata e confrontare il comportamento con il contratto salvato. Ad esempio, se la nota duratura dice che una migrazione rimane progettuale solo fino all'approvazione di A 42 , la sonda dovrebbe chiedere se l'attuazione possa iniziare ora. Il risultato atteso è un codice di decisione come WAIT FOR A 42 , non una citazione letterale della nota privata. Registrazione: Questa prova la continuità utile piuttosto che il teatro di raccolta. Un modello può parafrasiare una nota, mentre lascia cadere il limite di autorita' che la rende sicura. Può anche produrre la decisione giusta per caso. Tenere la sonda stretta, ripeterla dopo le modifiche di configurazione pertinenti e includere un caso negativo la cui condizione di sblocco non è stata soddisfatta. Riproduci una revisione di nove casi senza contenuti L'apparecchio memory health cases.json di accompagnamento non contiene testo di memoria. Esso fornisce a evaluate openclaw memory health.mjs nove osservazioni sintetiche, una per ogni stato terminale: Il riassunto riprodotto è il seguente: Il classificatore utilizza un ordine rigoroso. Controlla l'esistenza duratura e l'uguaglianza locale prima dello stato dell'indice; lo stato dell'indice prima della disponibilità della ricerca; la disponibilità della ricerca prima del recupero; e il recupero prima di una decisione di nuova sessione. Ciò impedisce le riparazioni fuorvianti. La riindicazione non può creare un record mancante. Riscrivere un record non può ripristinare un fornitore di inserimento fallito. Un colpo con un punteggio elevato non può dimostrare la continuità di riavvio. Adattare il dispositivo con veri ID opachi e booleani locali. Aggiungi casi per uno spazio di lavoro solo per lettura, un indice costruito da un vecchio digest, un risultato della nota di data sbagliata, un file di bootstrap truncato, un fornitore di inserimento non disponibile, un fallback solo per parole chiave e una decisione la cui approvazione è scaduta. Mantenere la nota grezza e il risultato grezzo della ricerca fuori dalla telemetria condivisa. Utilizzare uno stato sconosciuto esplicito La regola di funzionamento compatta è: La memoria Mark OpenClaw viene verificata solo quando il record duraturo corrisponde localmente, l'indice corrente lo copre, l'ancoraggio del recupero alla fonte attesa e una nuova sessione produce la decisione limitata attesa. Tutto il resto dovrebbe mantenere uno specifico stato non verde. search unavailable non è retrieval miss . restart unverified non è continuity failed . Un sconosciuto esplicito è più utile di uno status rosso generico perché identifica il prossimo test sicuro senza invitare l'agente a inventare il contesto mancante. Questa revisione ha ancora dei limiti. Un confronto locale può convalidare solo le registrazioni incluse nel set di prova. Un ospite compromesso puo' falsificare sia il biglietto che le prove. Una sonda di recupero misura una query e una configurazione di ranking. Un codice di decisione corrispondente non dimostra che ogni sfumatura sia sopravvissuta, e le ripetute sonde consumano il modello e il budget di inserimento. Utilizzare i controlli deterministici per la memorizzazione e l'indicizzazione, quindi spendere le chiamate di modello solo sul comportamento che non può essere verificato da file e stato di database. Sidewisp è attualmente in anteprima privata. È destinato a fornire uno strato di salute intorno ai tempi di esecuzione degli agenti esistenti, ma gli adattatori di produzione OpenClaw, la raccolta di agenti di salute in diretta e il recupero automatico non vengono spediti nel repository attuale del sito web. L'audit a quattro prove è un modello gestito dall'operatore che puoi implementare ora, non una affermazione che Sidewisp attualmente monitora o ripara la memoria OpenClaw. Se questa separazione tra memorizzazione, recupero e salute della decisione corrisponde al modo in cui si desidera operare gli agenti, unisciti alla visualizzazione privata di Sidewisp. Fino a quel momento, mantenete il confronto locale, fate riavviare il processo e lasciate che le prove mancanti rimangano sconosciute.