SimpleMem: Langzeitgedächtnis für LLM-Agenten mit Text, Bild, Audio und Video

Welches Problem SimpleMem adressiert und für wen

Ein Agent, der über mehrere Sitzungen hinweg arbeiten soll, braucht einen Speicher, der nicht mit jeder Konversation wächst. Das README beschreibt SimpleMem als Langzeitgedächtnis, das Erinnerungen speichert, komprimiert und semantisch verlustfrei wieder abruft. Der Untertitel nennt Text und Multimodal, also Bild, Audio und Video. Zielgruppe sind Entwickler, die einem Agenten ein eigenes Gedächtnis geben wollen, statt sich auf den Kontext eines einzelnen Chats zu verlassen. Die README nennt ausdrücklich zwei Integrationswege: MCP für Textgedächtnis, Python für die volle Multimodalität. Wer nur Claude Desktop, Cursor, LM Studio oder Cherry Studio nutzt, bleibt beim Textpfad. Wer Bilder oder Videos ablegen will, kommt um Python-Code nicht herum. Das ist eine bewusste Aufteilung: Der MCP-Server ist der kleinere, breiter nutzbare Teil, das Python-Paket der vollständige.

Drei Generationen in einem Paket: Text, Omni, EvolveMem

Die Release-Historie zeigt, wie das Projekt gewachsen ist. v0.1.0 vom 10. März 2026 war ausdrücklich Text Only. v0.2.0 vom 3. April 2026 brachte unter dem Namen Omni-SimpleMem multimodales Gedächtnis. v0.3.0 vom 21. Mai 2026 führte die Teile zu einem einheitlichen Paket zusammen. Laut README wählt der Aufruf `from simplemem import SimpleMem` den Backend-Typ automatisch anhand der ersten aufgerufenen Methode aus, und `simplemem.optimize(...)` greift auf den Selbstoptimierungs-Loop von EvolveMem zu. Diese Zusammenführung ist praktisch relevant, weil sie die Wahl zwischen Text- und Multimodalpfad von einer Installationsentscheidung zu einer Aufrufentscheidung macht. Sie erzeugt aber auch eine unsichtbare Abhängigkeit: Wer die erste Methode falsch wählt, landet im anderen Backend, ohne dass die Installation das signalisiert. Die Dokumentation sollte man an dieser Stelle genau lesen, denn der Automatismus ist bequem, aber nicht selbsterklärend.

Wie der Selbstoptimierungs-Loop von EvolveMem arbeitet

Der interessanteste Teil ist EvolveMem. Die Release-Notiz zu v3.0 vom 14. Mai 2026 beschreibt ihn als Retrieval-Infrastruktur, die sich selbst weiterentwickelt, gesteuert durch einen LLM-getriebenen geschlossenen Diagnose-Loop. Das bedeutet: Das System bewertet seine eigenen Abrufergebnisse, diagnostiziert Schwächen und verändert die Abrufdimensionen. Laut Notiz entdeckt es dabei Dimensionen, die im ursprünglichen Design nicht vorgesehen waren. Genau hier liegt der Reiz und das Risiko. Ein Retrieval, das sich selbst umbaut, ist schwer zu reproduzieren, wenn sich die Bewertungsgrundlage ändert. Die genannten Verbesserungen von 25,7 Prozent relativ auf LoCoMo und 18,9 Prozent relativ auf MemBench stammen aus der Projektbeschreibung, nicht aus einer unabhängigen Messung. Wer diese Zahlen als Planungsgrundlage nimmt, sollte sie selbst nachfahren, zumal das README einen Abschnitt Reproduce Paper Results anbietet. Der Aufwand dafür ist real: Der Loop ruft ein LLM auf, und jeder Optimierungslauf kostet Tokens.

Installation und die Konfigurationsschritte, die tatsächlich nötig sind

Das README nennt `pip install -e .` als Installationsschritt für das Repository und verweist auf PyPI unter pypi.org/project/simplemem. Der zentrale Konfigurationsschlüssel ist `OPENAI_BASE_URL`. Er entscheidet, welcher Inferenz-Endpunkt Gedächtnisaufbau, Abruf und Bewertung übernimmt. Das README nennt als Beispiel Atlas Cloud, eine OpenAI-kompatible Plattform, über die sich Modelle wie DeepSeek, Qwen, GLM, Kimi und MiniMax über eine einzige API ansprechen lassen. Für den MCP-Pfad nennt das README den gehosteten Endpunkt mcp.simplemem.cloud sowie Unterstützung für Claude Skills. Damit stehen zwei Betriebsarten zur Wahl: ein gehosteter MCP-Endpunkt, bei dem die Speicherinfrastruktur nicht im eigenen Netz läuft, oder ein eigener Python-Prozess mit selbst gesetztem `OPENAI_BASE_URL`. Die zweite Variante ist die einzige, bei der der Speicher vollständig in der eigenen Umgebung bleibt. Wer den gehosteten Endpunkt nutzt, sollte vorher klären, wohin die Gesprächsinhalte gehen, denn das README macht dazu keine Angabe.

Kompression als Kernversprechen und ihre offene Flanke

Das README wirbt mit semantisch verlustfreier Kompression. Der Begriff ist stark, und die Dokumentation bleibt an der Stelle dünn: Es wird nicht erklärt, welches Verfahren die Kompression durchführt, wie die Kompressionsrate gemessen wird und woran man erkennt, dass eine Information verloren ging. Wer einen Agenten betreibt, der sich an Zusagen, Namen oder Zahlen erinnern muss, hat hier ein konkretes Risiko. Eine Kompression, die eine Verhandlungsposition auf einen Satz eindampft, kann im Abruf plausibel klingen und trotzdem falsch sein. Der EvolveMem-Loop bewertet Abrufqualität, aber die Bewertung selbst läuft über ein LLM, also über dasselbe Modell, das die Antwort später formuliert. Das ist kein Ausschlusskriterium, aber ein Grund, vor dem Produktiveinsatz eine eigene Abfrageliste mit erwarteten Antworten anzulegen und gegen den Speicher laufen zu lassen. Ohne diese Liste bleibt die Qualitätsaussage eine Behauptung aus der Projektbeschreibung.

Wann SimpleMem das falsche Werkzeug ist

SimpleMem ist kein Ersatz für eine Vektordatenbank mit festen Embeddings. Der Unterschied liegt im Betriebsmodell. Eine klassische Vektordatenbank indiziert einmal und liefert deterministisch dieselben Nachbarn für dieselbe Anfrage. SimpleMem baut Gedächtnis, Abruf und Bewertung auf LLM-Aufrufen auf, wie das README an mehreren Stellen zeigt. Das bringt zwei Konsequenzen mit sich. Erstens ist der Betrieb nicht offline möglich, solange kein lokales Modell hinter `OPENAI_BASE_URL` steht. Zweitens sind Ergebnisse nicht bitgenau reproduzierbar, weil das Modell hinter dem Endpunkt sich ändern kann. Für regulierte Umgebungen, in denen jede Abfrage auditierbar und wiederholbar sein muss, ist das ein Problem. Ebenso ungeeignet ist SimpleMem für sehr kleine Agenten mit wenigen hundert Erinnerungen: Der Aufwand für einen selbst optimierenden Loop lohnt sich erst, wenn die schiere Menge an Erinnerungen den einfachen Kontextabruf sprengt.

Alternative: Mem0 und der Unterschied im Ansatz

Als Vergleichsgröße bietet sich Mem0 an, ein verbreitetes Gedächtnissystem für LLM-Anwendungen, das ebenfalls Speichern und Abrufen über eine API kapselt. Der Unterschied liegt weniger im Ziel als im Verfahren. Mem0 arbeitet mit einem festen Satz von Operationen zum Hinzufügen, Aktualisieren und Löschen von Erinnerungen und überlässt die Abruflogik dem Entwickler. SimpleMem geht weiter und verändert laut Release-Notiz die Abrufdimensionen selbst, gesteuert durch den Diagnose-Loop. Das ist mehr Automatik und weniger Kontrolle. Wer nachvollziehen muss, warum eine bestimmte Erinnerung geliefert wurde, ist bei einem festen Operationsmodell besser aufgehoben. Wer viele heterogene Erinnerungen hat und die Abrufgüte durch das System verbessern lassen will, hat bei SimpleMem mehr Hebel. Ein zweiter Unterschied ist die Modalität: Mem0 ist primär textorientiert, SimpleMem deckt laut README Bild, Audio und Video ab. Für einen Agenten, der Screenshots oder Transkripte ablegt, ist das der ausschlaggebende Punkt.

Wartung, Lizenz und was vor dem Einsatz zu klären ist

SimpleMem steht unter der MIT-Lizenz. Das ist die permissivste gängige Variante: Nutzung, Änderung und Weitergabe sind erlaubt, solange der Lizenztext und der Urheberrechtshinweis beibehalten werden. Wer das Paket in ein Produkt einbettet, muss den Hinweis also mitführen. Eine rechtliche Prüfung ersetzt das nicht, insbesondere wenn das Paket zusammen mit gehosteten Endpunkten Dritter betrieben wird. Die Wartungslage sieht aktiv aus: drei Releases zwischen März und Mai 2026, der letzte Push stammt vom 24. Juli 2026. Der Sprung von v0.1.0 auf v0.3.0 in gut zwei Monaten bedeutet aber auch, dass sich Schnittstellen bewegen. Wer auf v0.3.0 aufsetzt, sollte die eigene Anbindung gegen die nächste Version testen, bevor er sie übernimmt. Konkret zu prüfen sind drei Dinge: ob `from simplemem import SimpleMem` im eigenen Fall das erwartete Backend wählt, ob der gesetzte `OPENAI_BASE_URL` die im README genannten Modalitäten tatsächlich bedient, und ob die eigene Abfrageliste nach einem `simplemem.optimize(...)`-Lauf noch dieselben Antworten liefert. Diese drei Punkte lassen sich vor dem Produktiveinsatz klären, alles andere ist Vermutung.

Redaktionelles Fazit

SimpleMem passt zu Teams, die einem Agenten ein eigenes, lokal kontrolliertes Gedächtnis geben wollen und Python sowie einen OpenAI-kompatiblen Endpunkt betreiben können. Untauglich ist es, wenn ein Agent ohne externen Modellaufruf arbeiten soll, weil Speicherkonstruktion, Retrieval und Bewertung laut README über LLMs laufen. Wer nur Textgedächtnis in einem MCP-Client braucht, kann den gehosteten Endpunkt mcp.simplemem.cloud testen und die Kompressionsrate dort zuerst gegen die eigene Abfrageliste prüfen, bevor eigene Infrastruktur entsteht.

Offizielle Quellen

1. aiming-lab/SimpleMem on GitHub
2. Issues
3. License: MIT
4. README
5. Releases