MemoryOS: ein Speicher-Stack für personalisierte Agenten, mit vier Modulen und einer Benchmark-Zahl
[EMNLP 2025 Oral] MemoryOS is designed to provide a memory operating system for personalized AI agents.
Auf einen Blick
- Was ist das?
- MemoryOS aus dem BAI-LAB ist ein Python-Framework, das kurzfristige, mittelfristige und langfristige Persona-Erinnerungen über vier Module verwaltet. Der Nutzen liegt in der Struktur, die Grenze in der Abhängigkeit von LLM-Aufrufen und Embeddings.
- Für wen ist es gedacht?
- Sinnvoll ist MemoryOS für Teams, die einem einzelnen Agenten ein persistentes, hierarchisch strukturiertes Persona-Gedächtnis geben wollen und bereit sind, LLM- und Embedding-Kosten pro Speichervorgang zu tragen. Wer lediglich Fakten für RAG ablegen will, nimmt ein Vektor-Backend und spart sich die Updating-Schicht.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 71 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 16. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem MemoryOS adressiert und für wen es gedacht ist
Ein Sprachmodell hat innerhalb einer Sitzung Kontext, danach nichts. Wer einen Assistenten baut, der einen Nutzer über Wochen begleitet, muss Erinnerungen außerhalb des Kontextfensters ablegen, sie bewerten, verdichten und bei Bedarf zurückholen. Genau diese Aufgabe nennt das Projekt ein Gedächtnis-Betriebssystem für personalisierte Agenten. Der Anspruch ist nicht, eine weitere Vektordatenbank zu sein, sondern die Verwaltungsschicht darüber: Was wird gespeichert, wann wird es aktualisiert, was wird vergessen, was wird beim nächsten Turn eingespeist.
Die Zielgruppe lässt sich aus dem Repository gut ableiten. Es gibt ein Python-Paket auf PyPI, einen MCP-Server für Agent-Clients, eine Docker-Variante und ein Playground-Frontend. Die README listet Claude Desktop in der Support-Tabelle als Agent-Client. Wer einen Agenten mit langfristigem Nutzerprofil betreibt, ist die naheliegende Zielgruppe. Wer dagegen nur Dokumente durchsuchbar machen will, braucht die Updating- und Generation-Module nicht und trägt deren Kosten ohne Gegenwert.
Bemerkenswert ist der Kontext: Das Projekt stammt aus einer Forschungslinie, die sich selbst Memory Family nennt und neben MemoryOS eine Übersichtsarbeit zu AI Memory sowie LightSearcher führt. Das erklärt den Aufbau. Die Architektur folgt einer Taxonomie, nicht einem Produkt-Backlog.
Vier Module und drei Zeithorizonte: die eigentliche Mechanik
Die README beschreibt eine hierarchische Speicherarchitektur mit vier Kernmodulen: Storage, Updating, Retrieval und Generation. Die Inspiration kommt laut Projektbeschreibung aus dem Speichermanagement von Betriebssystemen. Das ist mehr als eine Metapher, denn es legt nahe, dass Einträge nicht gleich behandelt werden, sondern nach Alter oder Wichtigkeit in unterschiedliche Ebenen wandern.
Die Ebenen sind kurzfristig, mittelfristig und langfristig, wobei die langfristige Ebene als Persona-Gedächtnis beschrieben wird. Dazu kommt ein automatisches Aktualisieren von Nutzerprofil und Wissen. Der Datenfluss lässt sich damit grob so skizzieren: Ein Dialogbeitrag kommt an, das Updating-Modul entscheidet, ob und wie er in die kurzfristige Ebene geschrieben wird. Aus kurzfristigen Einträgen entsteht verdichtetes mittelfristiges Material, und daraus wiederum langfristige Persona-Einträge. Beim nächsten Turn zieht das Retrieval-Modul passende Einträge, und die Generation-Schicht baut sie in den Prompt ein.
Was die README nicht zeigt, ist die konkrete Verdichtungsregel. Ob ein Übergang von kurz nach mittel durch Anzahl der Turns, durch eine LLM-Zusammenfassung oder durch ein Zeitintervall ausgelöst wird, geht aus dem vorliegenden Material nicht hervor. Das ist die wichtigste offene Stelle für jeden, der das Verhalten vorhersagen will. Die vier Module sind benannt, ihre Schwellenwerte nicht.
Installation, Konfiguration und der similarity_threshold
Das Paket liegt auf PyPI, daneben existieren ein MCP-Server und ein Docker-Weg. Die README verweist für Details auf die Dokumentationsseite unter bai-lab.github.io/MemoryOS/docs und nennt einen Abschnitt Docker getting started sowie einen Abschnitt zum ChromaDB-Backend. Konkrete Befehlszeilen sind im vorliegenden Auszug nicht enthalten, deshalb lässt sich hier kein Installationskommando zitieren, ohne es zu erfinden.
Ein Konfigurationsschlüssel ist dagegen namentlich bekannt: similarity_threshold. Er wurde am 8. Juli 2025 als neuer Parameter eingeführt und steuert offenbar, ab welcher Ähnlichkeit ein neuer Eintrag als Duplikat eines bestehenden gilt oder mit ihm zusammengeführt wird. Das ist der zentrale Hebel für die Qualität des Gedächtnisses. Zu niedrig angesetzt, verschmelzen unterschiedliche Sachverhalte zu einem Eintrag. Zu hoch angesetzt, wächst der Speicher mit Wiederholungen desselben Fakts. Die Dokumentation nennt den Parameter, die README nennt keinen Standardwert.
Als Modell-Backends nennt das Projekt OpenAI, Deepseek und Qwen, dazu Unterstützung für R1-Modelle wie Deepseek-r1 und Qwen3. Für Embeddings werden BGE-M3 und Qwen3 erwähnt. Das ist eine breite Auswahl, aber sie bedeutet auch: Retrieval-Qualität hängt an der Wahl des Embedding-Modells, und ein Wechsel des Embedding-Modells macht bestehende Vektoren unbrauchbar. Wer das Gedächtnis über Monate aufbaut, sollte das Embedding-Modell früh festlegen.
Die Benchmark-Zahl und was sie nicht sagt
Die README nennt für den LoCoMo-Benchmark durchschnittliche Verbesserungen von 49,11 Prozent im F1-Score und 46,18 Prozent in BLEU-1. Das sind die Zahlen, die das Projekt nach vorn stellt, und sie stammen aus der zugehörigen Arbeit, die als EMNLP-2025-Hauptkonferenzbeitrag angenommen wurde. Eine Reproduktionsanleitung ist laut News-Eintrag vom 9. Juli 2025 öffentlich verfügbar.
Trotzdem taugt die Zahl nur begrenzt als Auswahlkriterium. LoCoMo misst Langzeitgespräche mit einer bestimmten Struktur. Ob der eigene Agent Nutzeranfragen zu Produktdaten, zu Code oder zu Terminplanung verarbeitet, ist eine andere Verteilung. Die Verbesserung ist außerdem relativ zu einer Baseline angegeben, die im Auszug nicht benannt wird. Wer die Zahl zitieren will, sollte im Paper nachsehen, gegen was verglichen wurde.
Zweitens ist BLEU-1 eine Überlappungsmetrik auf Token-Ebene. Ein Gedächtnissystem, das Formulierungen aus früheren Turns wörtlich zurückholt, kann hier gut abschneiden, ohne dass die Antwort inhaltlich besser wird. F1 auf der anderen Seite misst, ob die richtigen Erinnerungsstücke gefunden wurden. Zusammen ergeben die beiden Werte ein plausibles Bild, aber keines, das sich direkt auf eine Produktionsanwendung überträgt.
Wo MemoryOS die falsche Wahl ist
Der Speicher wird nicht billig betrieben. Aktualisierung, Verdichtung und Zusammenfassung laufen über LLM-Aufrufe, und Retrieval läuft über Embeddings. Bei jedem Dialogbeitrag können also mehrere Modellaufrufe anfallen, bevor überhaupt eine Antwort entsteht. Die News nennen eine fünffache Latenzreduktion durch Parallelisierung im PyPI-Paket, was implizit bestätigt, dass Latenz vorher ein Problem war. Wer einen Agenten mit Subsekunden-Antwortzeit braucht, sollte die Updating-Pipeline messen, bevor er sie einschaltet.
Zweitens ist die Verdichtung verlustbehaftet. Wenn aus kurzfristigen Einträgen mittelfristige und daraus langfristige werden, entscheidet ein Modell, was wichtig genug ist, um zu überleben. Ein Modell, das eine beiläufige Präferenz des Nutzers für unwichtig hält, löscht sie faktisch. Das ist ein inhärentes Designmerkmal hierarchischer Speicherung, kein Bug, aber es macht das System ungeeignet für Anwendungen, bei denen jede Aussage des Nutzers erhalten bleiben muss, etwa bei dokumentationspflichtigen Vorgängen.
Drittens: Wer bereits eine Vektordatenbank für RAG betreibt und nur Chunks ablegen und wiederfinden will, bekommt mit MemoryOS drei zusätzliche Schichten, die er nicht braucht. Der Nutzen entsteht erst, wenn ein Nutzerprofil über Zeit entstehen soll.
Mem0 als Alternative und der Unterschied im Ansatz
Die naheliegende Alternative ist Mem0, ebenfalls ein Gedächtnis-Layer für Agenten, ebenfalls mit Speicherung und Abruf von Nutzerfakten. Der Unterschied liegt in der Struktur. Mem0 arbeitet primär mit einer flachen Menge extrahierter Fakten, die über Add- und Search-Operationen verwaltet werden. MemoryOS legt dagegen explizit drei Zeithorizonte übereinander und verschiebt Information zwischen ihnen. Wer wissen will, wie sich ein Nutzer über Monate verändert hat, findet in einem hierarchischen Modell eher eine Antwort als in einer flachen Faktenliste.
Der Preis dafür ist Steuerbarkeit. Bei einer flachen Faktenmenge lässt sich nachvollziehen, welcher Eintrag wann hinzugefügt wurde. Bei MemoryOS läuft die Verdichtung durch ein Modell, und der Ursprung eines langfristigen Eintrags ist nicht mehr ohne Weiteres rekonstruierbar. Für Debugging ist das ein realer Nachteil.
Ein zweiter Unterschied betrifft die Anbindung. MemoryOS liefert einen MCP-Server, über den Agent-Clients die Speicherwerkzeuge aufrufen. Das ist ein Integrationsweg, der ohne eigenen Code funktioniert, solange der Client MCP spricht. Projekte, die eine HTTP-API bevorzugen, müssen den Server selbst betreiben.
Wartung, Lizenz und was ein Upgrade kostet
Das Repository steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und Änderungen kenntlich gemacht werden. Bei einer modifizierten Weitergabe ist eine NOTICE-Datei zu führen, sofern das Projekt eine mitliefert. Das ist eine technische Beschreibung, keine Rechtsberatung; wer das Paket in ein Produkt einbettet, sollte die Apache-2.0-Bedingungen im eigenen Kontext prüfen lassen.
Die Release-Historie ist kurz und dicht. v1.0 erschien am 12. Juli 2025, V1.1 am 13. Juli, V1.2 am 18. Juli mit ChromaDB-Unterstützung und einer Korrektur an den fest verdrahteten LLM-Aufrufen. Drei Releases in sechs Tagen bedeuten, dass die API in dieser Phase instabil war. Wer damals integriert hat, hat vermutlich nachziehen müssen. Der letzte Push liegt laut Repository-Metadaten im Juli 2026, das Projekt ist also nicht archiviert und wird weiter bearbeitet.
Für die Wartung heißt das: die Updating-Strategie und das Embedding-Modell sind die beiden Stellen, an denen Änderungen bestehende Speicherbestände entwerten können. Ein Wechsel des Embedding-Modells erfordert eine Neuberechnung aller Vektoren. Ein Wechsel der Updating-Logik verändert, welche Einträge künftig entstehen, ohne die alten anzufassen. Wer das Gedächtnis langfristig hält, sollte beide Werte in der Konfiguration versionieren.
Redaktionelles Fazit
Sinnvoll ist MemoryOS für Teams, die einem einzelnen Agenten ein persistentes, hierarchisch strukturiertes Persona-Gedächtnis geben wollen und bereit sind, LLM- und Embedding-Kosten pro Speichervorgang zu tragen. Wer lediglich Fakten für RAG ablegen will, nimmt ein Vektor-Backend und spart sich die Updating-Schicht. Vor dem Einsatz zu prüfen: ob der eigene Anwendungsfall unter die LoCoMo-Messung fällt, welches Storage-Backend der Konfiguration entspricht, und ob der MCP-Server mit dem vorhandenen Agent-Client zusammenarbeitet.
Community-Notizen