Speicherbetriebssystem des KI-Agenten: Überwachen Sie jeden Ebenenübergang

Ein Speicherbetriebssystem für einen KI Agenten ist nur dann fehlerfrei, wenn der Bediener eine Speicherversion durch Speichern, Aktualisieren, Abrufen und Generieren im gleichen Benutzer und Assistentenbereich verfolgen kann. Eine kohärente Antwort ist eine nützliche Ausgabe, aber kein Beweis dafür, dass jeder frühere Übergang durchgeführt wurde. Die praktische Vorgabe ist daher einfach: Fügen Sie jeder Grenze eine inhaltsfreie Abstammungsbestätigung hinzu. Behalten Sie den Speicherinhalt auf dem Host. Erfassen Sie nur stabile Kennungen, Umfang, Quellversion, Zielebene, Zeitstempel, Übergangsstatus und die für die Generierung verwendete Version. Wenn eine Grenze fehlt oder widersprüchlich ist, melden Sie waiting , at risk , stale oder uncertain anstelle von Grün. Diese Regel ist für die spezifische Architektur hinter der Suchabfrage Speicher Betriebssystem des KI Agenten wichtig. Das MemoryOS Papier definiert drei Speicherebenen und vier Funktionsmodule. Seine Implementierung weist außerdem ein enges Fehlerfenster auf, das ein Antwortqualitäts Benchmark nicht identifizieren kann. Was MemoryOS etabliert Das MemoryOS Papier beschreibt vier Module: 1. Speicher organisiert das Kurzzeitgedächtnis (STM), das Mittelzeitgedächtnis (MTM) und das persönliche Langzeitgedächtnis (LPM). 2. Aktualisierung verschiebt Dialogseiten von STM nach MTM und leitet dann langlebigeres Profil oder Wissensmaterial von MTM ab. 3. Abruf wählt relevantes Material aus den Ebenen aus. 4. Generierung erstellt eine Antwort aus dem aktuellen und abgerufenen Kontext. Das Papier geht ungewöhnlich konkret auf die Bewegung zwischen den Ebenen ein. Die STM zu MTM Aktualisierung verwendet einen Dialogketten FIFO Prozess. Bei der MTM zu LPM Aktualisierung werden segmentierte Seiten mit wärmebasierter Auswahl verwendet. Das ist genug Struktur, um beobachtbare Übergangsgrenzen zu definieren, anstatt den „Speicher“ als eine undurchsichtige Datenbank zu behandeln. Die Autoren berichten von durchschnittlichen Verbesserungen von 49,11 % in F1 und 46,18 % in BLEU 1 gegenüber ihren Ausgangswerten auf LoCoMo mit GPT 4o mini. Das sind die Benchmark Ergebnisse der Autoren; Ich habe LoCoMo für dieses Audit nicht erneut ausgeführt. Noch wichtiger ist, dass die Richtigkeit und Kohärenz der Antworten eine andere Frage beantworten als die betriebliche Integrität. Eine hohe Punktzahl beweist nicht, dass: ein STM Datensatz war vor der Räumung dauerhaft vorhanden; – ein MTM Ziel, das vor dem Verschwinden der Quelle festgeschrieben wurde; Derselbe Benutzer und Assistentenbereich hat jeden Übergang überstanden. Beim Abrufen wurde die neueste erwartete Version zurückgegeben. Die letzte Generation hing tatsächlich von dieser Version ab. Die Architektur des Papiers liefert die Grenzen. Dafür benötigt der Betreiber noch Belege. Das riskante Intervall erscheint vor dem Ziel Commit Ich habe das Projekt beim angehefteten Commit 587ed7755c7aed179965792830ff1b5ad9a6fa92 überprüft. Das Anheften ist wichtig: Das Repository ist aktiv und eine operative Schlussfolgerung ohne Quellversion wird nach der nächsten Änderung mehrdeutig. Der aktuelle add memory Pfad prüft, ob die Kurzzeit Deque voll ist und führt die Heraufstufung durch, bevor ein weiteres Element angehängt wird. Die Quelle bezeichnet dies ausdrücklich als Fix zur Verhinderung der automatischen Deque Eviction im Stillen ( memoryos.py , Zeilen 226–244). Das ist eine nützliche Schutzmaßnahme, macht Werbung jedoch nicht zu einer Transaktion. Die Promotion Reihenfolge ist wichtig: 1. process short term to mid term ruft pop oldest auf, während STM voll ist ( updater.py , Zeilen 100–105). 2. pop oldest entfernt den Datensatz und speichert sofort die kürzere STM Deque ( short term.py , Zeilen 33–37). 3. Der Updater ruft dann LLM gestützte Kontinuitäts und Zusammenfassungsfunktionen auf. 4. Das Einfügen des MTM und seine endgültige Speicherung erfolgen später ( updater.py , Zeilen 130–207). Dieser Kontrollfluss erstellt ein Intervall für gefährdete Quellen. Wenn der Prozess beendet wird oder ein nicht abgefangener Downstream Vorgang nach der STM Speicherung, aber vor dem MTM Commit fehlschlägt, verfügt der Bediener über keinen abgeschlossenen Hochstufungsnachweis. Hierbei handelt es sich um ein von der Quelle abgeleitetes Fehlerfenster und nicht um die Behauptung, dass bei jeder MemoryOS Bereitstellung Daten verloren gehen. Der korrekte Gesundheitszustand ist einfach nicht grün, bis der Zielbeleg vorhanden ist oder die Quelle als wiederherstellbar angezeigt wird. Es gibt eine zweite, engere Kontinuitätsgrenze. last evicted page for continuity beginnt als speicherinterner None Wert, wird in den nächsten Stapel übernommen und nach der Verarbeitung aktualisiert ( updater.py , Zeilen 35 und 115–158). Ein Prozessneustart setzt diesen bestimmten Verschleppungshinweis zurück. Andere MTM Ähnlichkeitslogiken verbinden möglicherweise immer noch Material erneut, sodass dies kein Beweis für einen vollständigen Kontinuitätsverlust ist. Dies ist ein Grund, die vorherige Seite oder Quellversion im Übergangsbeleg aufzuzeichnen, anstatt davon auszugehen, dass der Prozess sie gespeichert hat. Verwenden Sie für alle Ebenen einen inhaltsfreien Beleg Für die Quittung sind keine Eingabeaufforderungen, Antworten, Zusammenfassungen, Einbettungen oder persönlichen Angaben erforderlich. Ein minimales Event kann so aussehen: Führen Sie sechs Felder durch jede Stufe: – runId nimmt an einem Speicher zu Generation Versuch teil, ohne Inhalte preiszugeben. – userScope und assistantScope erkennen mandantenübergreifende oder gemeinsam genutzte Assistentenfehler. – version identifiziert den erwarteten Speicherstatus. – sourceVersion pinnt den Implementierungs oder Adaptervertrag. status trennt started , waiting , committed , verified und fehlgeschlagene Arbeit. – Mit atUtc lässt der Verifizierer veraltete Beweise verfallen. MemoryOS erstellt bereits benutzerspezifische Kurz , Mittel und Langzeitdateien sowie eine separate assistentenspezifische Langzeitdatei ( memoryos.py , Zeilen 71–78). Die Quittung sollte beide Dimensionen beibehalten, da „richtiger Benutzer, falscher gemeinsamer Assistent“ immer noch ein Bereichskonflikt ist. Fügen Sie zur Generierung dependsOnVersion und einen outcomeReceipt hinzu. dependsOnVersion gibt an, welche abgerufene Speicherversion in die letzte Eingabeaufforderung eingegeben wurde. outcomeReceipt sollte nach Möglichkeit eine deterministische Ergebnisprüfung angeben: einen Datei Hash, eine Zeilenkennung, ein Testergebnis, eine Zielsuche oder einen anderen Beweis dafür, dass die beabsichtigte Arbeit vorhanden ist. Es darf sich nicht um eine Aneinanderreihung sensibler Gesprächsinhalte handeln, nur um der Aufzeichnung ein strenges Aussehen zu verleihen. Unbequeme Zustände noch einmal abspielen, bevor man auf Grün vertraut Ich habe eine inhaltslose Vorrichtung mit acht Gehäusen gebaut und ausgeführt. Der Klassifikator hat alle acht erwarteten Zustände zurückgegeben: Fall Beweise Staat Vollständige Abstammung Umfang, Version, Aktualität, Tier Commits, Abruf und Generierungsempfang stimmen überein healthy Kapazitätsschwellenwert nicht erreicht STM ist dauerhaft und das deklarierte Wartefenster ist geöffnet waiting STM entfernt, MTM nicht festgeschrieben Quelle vor Zielnachweis verschwunden source at risk STM beibehalten, keine Werbeveranstaltung Der erwartete MTM Übergang ist nie erschienen promotion missing Benutzeränderungen während der Promotion Ein Ereignis gehört zu einem anderen Bereich scope conflict Der Abruf gibt v21 zurück, erwartet v22 Es gibt eine echte Erinnerung, aber sie ist veraltet stale retrieval Flüssige Antwort, kein Abhängigkeitsempfang Generation ohne verifizierte Abstammung abgeschlossen generation unverified Keine Implementierungsversion Die Beweise können nicht sicher interpretiert werden uncertain Der wichtige Unterschied besteht zwischen Warten und Vermissen . Ein STM Datensatz, der dauerhaft bleibt, solange ein dokumentierter Kapazitätsschwellenwert nicht erreicht wurde, bleibt nicht hängen. Eine entfernte Quelle ohne Ziel Commit wartet nicht; es ist gefährdet. Die Zeitstempel und Quellpräsenzfelder machen diesen Unterschied überprüfbar. Verwenden Sie explizite Priorität, damit ein späterer Erfolg einen früheren Konflikt nicht verdecken kann: Diese Reihenfolge ist bewusst konservativ. Der Umfangskonflikt ist wichtiger als eine erfolgreiche Reaktion. Das Quellenrisiko ist wichtiger als spätere Aktivitäten. Ein veralteter Abruf wird nicht durch fließende Generierung ersetzt. Fehlende Beweise bleiben ungewiss und werden nicht in gesunde Beweise umgewandelt. Verwandeln Sie die Quittung in ein Bedientor Beginnen Sie mit einer kanarischen Erinnerung, die keine persönlichen oder Produktionsinhalte enthält. Geben Sie ihm eine zufällige Kennung und die erwartete Version und üben Sie dann den tatsächlichen Speicher , Heraufstufungs , Abruf und Generierungspfad aus. Vor der Einführung oder nach einem Speichersystem Upgrade: 1. Implementierung anpinnen. Notieren Sie die Paketversion oder das Repository Commit sowie die Konfiguration, die Kapazität, Wärme, Ähnlichkeit oder Abrufgrenzen ändert. 2. Beweisen Sie die Bereichsisolation. Führen Sie zwei Benutzerbereiche und, falls zutreffend, zwei Assistentenbereiche aus. Kreuzen Sie jede Abfrage bewusst an und erfordern Sie keinen Abruf auf der falschen Spur. 3. Kapazitätsübergänge erzwingen. STM bis zur konfigurierten Grenze füllen. Stellen Sie sicher, dass für jede Quellenentfernung ein passender MTM Commit vorhanden ist. 4. Üben Sie den Fallback aus. Der Updater verfügt über einen allgemeinen Zusammenfassungs Fallback, wenn die Ausgabe mit mehreren Zusammenfassungen nicht verfügbar ist. Kennzeichnen Sie diesen Pfad als beeinträchtigt und überprüfen Sie den Abruf separat, anstatt den Fallback Abschluss als normale Qualität zu behandeln. 5. Neustart zwischen Stapeln. Überprüfen Sie die Kontinuität nach dem Neustart des Prozesses, da die Übertragung im Speicher kein dauerhafter Beweis ist. 6. Belege laufen ab. Eine Heraufstufung, die gestern fehlerfrei war, stellt nicht sicher, dass der aktuelle Prozess, Index oder die Dateien jetzt fehlerfrei sind. 7. Überprüfen Sie das Ergebnis. Ein erfolgreicher Abruf besagt, dass ein Speicher zurückgegeben wurde. Es heißt nicht, dass der Agent die richtige Version verwendet oder die beabsichtigte Aufgabe abgeschlossen hat. Versuchen Sie nicht automatisch, eine Heraufstufung einer gefährdeten Quelle erneut durchzuführen, wenn das Update möglicherweise bereits teilweise festgeschrieben wurde. Gleichen Sie zunächst Quelle und Ziel nach runId und Version ab. Blindes Wiederholen kann Unsicherheit in doppelte Seiten oder widersprüchliche langfristige Fakten verwandeln. Die Einschränkung ist ebenso wichtig: Diese Quittung beweist Übergangsherkunft, Umfang, Aktualität und deterministische Ergebnisprüfungen. Es beweist nicht, dass eine von LLM verfasste Zusammenfassung semantisch korrekt ist. Dies erfordert eine separate Bewertung, eine menschliche Überprüfung auf wichtige persönliche Fakten oder einen aufgabenspezifischen deterministischen Vergleich. Die Gesundheitsgrenze für Sidewisp Diese Prüfung passt zum Speicher und Kontextgesundheitsmodell von Sidewisp: Fehlende Lese oder Schreibvorgänge, fehlgeschlagene Persistenz, veraltete Synchronisierung, unerwartete Zurücksetzungen und verlorene Entscheidungen sollten sichtbar sein und nicht aus einem grünen Prozess abgeleitet werden. Sidewisp befindet sich derzeit in einer privaten Vorschauphase. Die öffentliche Website und das Artikelsystem sind live, während die Zustandserfassung des Produktions Agents, Laufzeitadapter und die Ausführung der Wiederherstellung im Allgemeinen nicht ausgeliefert werden. Die obige Quittung ist ein Operatormuster, das Sie jetzt implementieren können. Es wird nicht behauptet, dass Sidewisp derzeit MemoryOS überwacht. Die gelöste Regel ist streng, aber anwendbar: Vertrauen Sie dem Speichersystem nur, wenn die gleiche Version dauerhaft gespeichert, hochgestuft, abgerufen, verwendet und überprüft wird. Eine fließende Antwort kann ermutigend sein. Sie kann den fehlenden Beleg nicht ersetzen.