Sistema operativo di memoria dell'agente AI: controlla ogni transizione di livello

Un sistema operativo di memoria per un agente AI è integro solo quando l'operatore può seguire una versione di memoria attraverso l'archiviazione, l'aggiornamento, il recupero e la generazione nello stesso ambito di utente e assistente. Una risposta coerente è un risultato utile, ma non è la prova che tutte le transizioni precedenti siano state eseguite. L'impostazione pratica è quindi semplice: allegare una ricevuta di derivazione priva di contenuto a ciascun confine. Conserva il contenuto della memoria sull'host. Registra solo identificatori stabili, ambito, versione di origine, livello di destinazione, timestamp, stato di transizione e versione utilizzata per la generazione. Se un confine manca o è contraddittorio, segnala waiting , at risk , stale o uncertain invece del verde. Questa regola è importante per l'architettura specifica dietro la query di ricerca memory os of ai agent . Il documento MemoryOS definisce tre livelli di archiviazione e quattro moduli funzionali. La sua implementazione espone anche una finestra di errore ristretta che un benchmark sulla qualità della risposta non è in grado di identificare. Cosa stabilisce MemoryOS Il Carta MemoryOS descrive quattro moduli: 1. Archiviazione organizza la memoria a breve termine (STM), la memoria a medio termine (MTM) e la memoria personale a lungo termine (LPM). 2. L' Aggiornamento sposta le pagine di dialogo da STM a MTM, quindi deriva il profilo o il materiale informativo più longevo da MTM. 3. Recupero seleziona il materiale pertinente dai livelli. 4. Generazione crea una risposta dal contesto corrente e recuperato. Il documento è insolitamente concreto riguardo al movimento tra i livelli. L'aggiornamento da STM a MTM utilizza un processo FIFO a catena di dialogo. L'aggiornamento da MTM a LPM utilizza pagine segmentate con selezione basata sul calore. Questa è una struttura sufficiente per definire confini di transizione osservabili invece di trattare la “memoria” come un database opaco. Gli autori riportano miglioramenti medi del 49,11% in F1 e del 46,18% in BLEU 1 rispetto ai valori di riferimento su LoCoMo con GPT 4o mini. Questi sono i risultati di riferimento degli autori; Non ho eseguito nuovamente LoCoMo per questo audit. Ancora più importante, la correttezza e la coerenza della risposta rispondono a una domanda diversa dall’integrità operativa. Un punteggio elevato non dimostra che: la registrazione STM era stabilmente presente prima dello sfratto; una destinazione MTM impegnata prima che la fonte scomparisse; lo stesso ambito utente e assistente è sopravvissuto a ogni transizione; il recupero ha restituito la versione prevista più recente; la generazione finale in realtà dipendeva da quella versione. L’architettura del documento fornisce i confini. L'operatore ha ancora bisogno delle ricevute. L'intervallo rischioso viene visualizzato prima del commit di destinazione Ho esaminato il progetto nel commit bloccato 587ed7755c7aed179965792830ff1b5ad9a6fa92 . Il blocco è importante: il repository è attivo e una conclusione operativa senza una versione sorgente diventerà ambigua dopo la modifica successiva. Il percorso add memory corrente controlla se la coda a breve termine è piena ed esegue la promozione prima di aggiungere un altro elemento. La fonte etichetta esplicitamente questo come una correzione per impedire l'eliminazione automatica della deque silenziosa ( memoryos.py , righe 226–244). Questa è una tutela utile, ma non rende transazionale la promozione. La sequenza della promozione è importante: 1. process short term to mid term chiama pop oldest mentre STM è pieno ( updater.py , righe 100–105). 2. pop oldest rimuove il record e salva immediatamente la deque STM più breve ( short term.py , righe 33–37). 3. Il programma di aggiornamento richiama quindi le funzioni di continuità e di riepilogo supportate da LLM. 4. L'inserimento della MTM e il suo salvataggio finale avvengono successivamente ( updater.py , righe 130–207). Questo flusso di controllo crea un intervallo di origine a rischio. Se il processo termina o un'operazione downstream non rilevata fallisce dopo il salvataggio STM ma prima del commit MTM, l'operatore non ha una prova di promozione completata. Si tratta di una finestra di errore derivata dall'origine, non di un'affermazione secondo cui ogni distribuzione di MemoryOS perde dati. Lo stato di salute corretto è semplicemente non verde finché non esiste la ricevuta di destinazione o finché non viene dimostrato che la fonte rimane recuperabile. Esiste un secondo confine di continuità più stretto. last evicted page for continuity inizia come valore None in memoria, viene portato nel batch successivo e aggiornato dopo l'elaborazione ( updater.py , righe 35 e 115–158). Un riavvio del processo reimposta quel particolare suggerimento di riporto. Altre logiche di somiglianza MTM potrebbero comunque ricollegare il materiale, quindi questa non è una prova di perdita totale di continuità. È un motivo per registrare la pagina precedente o la versione sorgente nella ricevuta di transizione invece di dare per scontato che il processo la ricordi. Utilizza una ricevuta senza contenuto per tutti i livelli La ricevuta non necessita di suggerimenti, risposte, riassunti, incorporamenti o fatti personali. Un evento minimo può assomigliare a questo: Trasporta sei campi attraverso ogni fase: runId si unisce a un tentativo di archiviazione in generazione senza rivelare il contenuto. userScope e assistantScope rilevano errori tra tenant o assistente condiviso. version identifica lo stato di memoria previsto. sourceVersion blocca l'implementazione o il contratto dell'adattatore. status separa started , waiting , committed , verified e il lavoro non riuscito. atUtc consente al verificatore di scadere le prove obsolete. MemoryOS crea già file a breve, medio e lungo termine specifici dell'utente e un file a lungo termine separato specifico per l'assistente ( memoryos.py , righe 71–78). La ricevuta dovrebbe preservare entrambe le dimensioni perché "utente corretto, assistente condiviso sbagliato" è ancora un conflitto di ambito. Per la generazione, aggiungere dependsOnVersion e outcomeReceipt . dependsOnVersion indica quale versione della memoria recuperata è stata inserita nel prompt finale. outcomeReceipt dovrebbe identificare un controllo deterministico dei risultati ove possibile: un hash di file, un identificatore di riga, un risultato del test, una ricerca di destinazione o altra prova dell'esistenza del lavoro previsto. Non deve essere un hash di contenuti sensibili di conversazione solo per far sembrare rigoroso il record. Riproduci gli stati scomodi prima di fidarti del verde Ho costruito ed eseguito un dispositivo a otto case privo di contenuti. Il classificatore ha restituito tutti gli otto stati previsti: Caso Prove Stato Lignaggio completo Ambito, versione, aggiornamento, commit di livello, recupero e ricevuta di generazione concordano healthy Soglia di capacità non raggiunta STM è durevole e la finestra di attesa dichiarata è aperta waiting STM rimosso, MTM non impegnato La fonte è scomparsa prima della prova della destinazione source at risk STM mantenuto, nessun evento promozionale La transizione MTM prevista non è mai apparsa promotion missing Cambiamenti utente durante la promozione Un evento appartiene a un ambito diverso scope conflict Restituzioni di recupero v21 , previste v22 Esiste un ricordo reale, ma è stantio stale retrieval Risposta fluida, nessuna ricevuta di dipendenza Generazione completata senza discendenza verificata generation unverified Nessuna versione di implementazione Le prove non possono essere interpretate in modo sicuro uncertain La distinzione importante è tra in attesa e mancante . Un record STM che rimane durevole finché non è stata raggiunta una soglia di capacità documentata non è bloccato. Una fonte rimossa senza commit di destinazione non è in attesa; è a rischio. I campi timestamp e presenza origine rendono ispezionabile questa differenza. Utilizza la precedenza esplicita in modo che un successo successivo non possa nascondere un conflitto precedente: Questo ordine è deliberatamente conservatore. Il conflitto di ambito supera una risposta riuscita. Il rischio di origine supera l’attività successiva. Un recupero stantio non viene riscattato dalla generazione fluente. Le prove mancanti rimangono incerte piuttosto che essere convertite in salute. Trasforma lo scontrino in un varco operativo Inizia con un ricordo canarino che non contenga contenuti personali o di produzione. Assegnagli un identificatore casuale e la versione prevista, quindi esercita il percorso di archiviazione, promozione, recupero e generazione reale. Prima dell'adozione o dopo un aggiornamento del sistema di memoria: 1. Blocca l'implementazione. Registra la versione del pacchetto o il commit del repository e la configurazione che modifica i limiti di capacità, calore, somiglianza o recupero. 2. Dimostrare l'isolamento dell'ambito. Esegui due ambiti utente e, se applicabile, due ambiti assistente. Incrocia ogni query deliberatamente e non richiede il recupero dalla corsia sbagliata. 3. Forzare le transizioni di capacità. Riempire l'STM fino al limite configurato. Verifica che ogni rimozione dell'origine abbia un commit MTM corrispondente. 4. Esercitare il fallback. Il programma di aggiornamento dispone di un fallback di riepilogo generale quando l'output di riepilogo multiplo non è disponibile. Etichetta il percorso come danneggiato e verifica il recupero separatamente invece di considerare il completamento del fallback come di qualità normale. 5. Riavvio tra batch. Controllare la continuità dopo il riavvio del processo poiché il riporto in memoria non è una prova duratura. 6. Ricevute in scadenza. Una promozione integri ieri non stabilisce che il processo, l'indice o i file correnti siano integri adesso. 7. Verificare il risultato. Il recupero riuscito indica che è stato restituito un ricordo. Non dice che l'agente ha utilizzato la versione corretta o ha completato l'attività prevista. Non ritentare automaticamente una promozione dell'origine a rischio se è già stato eseguito il commit parziale dell'aggiornamento. Innanzitutto riconciliare origine e destinazione in base a runId e versione. La riproduzione cieca può trasformare l'incertezza in pagine duplicate o fatti contrastanti a lungo termine. La limitazione è altrettanto importante: questa ricevuta dimostra il lignaggio della transizione, la portata, l’aggiornamento e i controlli deterministici dei risultati. Non dimostra che un riassunto scritto da LLM sia semanticamente corretto. Ciò richiede una valutazione separata, una revisione umana per fatti personali di grande impatto o un confronto deterministico specifico per il compito. Il limite di salute per Sidewisp Questo controllo si adatta al modello di integrità della memoria e del contesto di Sidewisp: letture o scritture mancanti, persistenza non riuscita, sincronizzazione obsoleta, ripristini imprevisti e decisioni perse dovrebbero essere visibili anziché dedotti da un processo ecologico. Sidewisp è attualmente in anteprima privata. Il sito pubblico e il sistema degli articoli sono attivi, mentre la raccolta dell'integrità dell'agente di produzione, gli adattatori di runtime e l'esecuzione del ripristino in genere non vengono spediti. La ricevuta qui sopra è un modello di operatore che puoi implementare ora; non è un'affermazione che Sidewisp attualmente monitori MemoryOS. La regola risolta è rigorosa ma utilizzabile: fidarsi del sistema di memoria solo quando la stessa versione con ambito viene archiviata, promossa, recuperata, utilizzata e verificata in modo duraturo. Una risposta fluente può essere incoraggiante. Non può sostituire la ricevuta mancante.