Milvus
Zilliz
  • Home
  • Blog

  • Wir haben das Speichersystem von OpenClaw extrahiert und ins Internet gestellt (memsearch)

Wir haben das Speichersystem von OpenClaw extrahiert und ins Internet gestellt (memsearch)

  • Engineering
February 13, 2026
Cheney Zhang

OpenClaw (früher clawdbot und moltbot) geht viral - 189k+ GitHub-Sterne in weniger als zwei Wochen. Das ist Wahnsinn. Der meiste Wirbel dreht sich um seine autonomen, agentenbasierten Fähigkeiten in alltäglichen Chat-Kanälen wie iMessages, WhatsApp, Slack, Telegram und mehr.

Aber als Ingenieure, die an einem Vektor-Datenbanksystem arbeiten, hat uns vor allem der Ansatz von OpenClaw für das Langzeitgedächtnis beeindruckt. Anders als die meisten Speichersysteme auf dem Markt lässt OpenClaw seine KI automatisch tägliche Protokolle als Markdown-Dateien schreiben. Diese Dateien sind die Quelle der Wahrheit, und das Modell "merkt" sich nur, was auf die Festplatte geschrieben wird. Menschliche Entwickler können diese Markdown-Dateien öffnen, sie direkt bearbeiten, langfristige Prinzipien destillieren und genau sehen, woran sich die KI zu jedem Zeitpunkt erinnert. Keine Blackboxen. Ehrlich gesagt, ist dies eine der saubersten und entwicklerfreundlichsten Speicherarchitekturen, die wir je gesehen haben.

Wir hatten natürlich eine Frage: Warum sollte das nur in OpenClaw funktionieren? Was wäre, wenn jeder Agent so einen Speicher haben könnte? Wir haben die exakte Speicherarchitektur von OpenClaw genommen und memsearch entwickelt - eine eigenständige, Plug-and-Play-Langzeitspeicher-Bibliothek, die jedem Agenten einen persistenten, transparenten und von Menschen editierbaren Speicher bietet. Es besteht keine Abhängigkeit vom Rest von OpenClaw. Fügen Sie sie einfach ein und Ihr Agent erhält einen dauerhaften Speicher mit einer Suche, die von Milvus/Zilliz Cloud unterstützt wird, sowie Markdown-Logs als kanonische Quelle der Wahrheit.

Was den Speicher von OpenClaw auszeichnet

Bevor wir in die Speicherarchitektur von OpenClaw eintauchen, sollten wir zwei Begriffe klären: Kontext und Speicher. Sie klingen ähnlich, funktionieren aber in der Praxis sehr unterschiedlich.

  • Kontext ist alles, was der Agent in einer einzigen Anfrage sieht - Systemaufforderungen, Anleitungsdateien auf Projektebene wie AGENTS.md und SOUL.md, Gesprächsverlauf (Nachrichten, Toolaufrufe, komprimierte Zusammenfassungen) und die aktuelle Nachricht des Benutzers. Sie ist auf eine Sitzung beschränkt und relativ kompakt.

  • DerSpeicher ist das, was über Sitzungen hinweg bestehen bleibt. Er befindet sich auf der lokalen Festplatte - der gesamte Verlauf vergangener Unterhaltungen, Dateien, mit denen der Agent gearbeitet hat, und Benutzereinstellungen. Nicht zusammengefasst. Nicht komprimiert. Die Rohdaten.

Jetzt kommt die Designentscheidung, die den Ansatz von OpenClaw so besonders macht: Der gesamte Speicher wird als einfache Markdown-Dateien auf dem lokalen Dateisystem gespeichert. Nach jeder Sitzung schreibt die KI automatisch Updates in diese Markdown-Protokolle. Sie - und jeder andere Entwickler - können sie öffnen, bearbeiten, umorganisieren, löschen oder verfeinern. In der Zwischenzeit erstellt und pflegt die Vektordatenbank neben diesem System einen Index für den Abruf. Wann immer sich eine Markdown-Datei ändert, erkennt das System die Änderung und indiziert sie automatisch neu.

Wenn Sie Tools wie Mem0 oder Zep verwendet haben, werden Sie den Unterschied sofort bemerken. Diese Systeme speichern Erinnerungen als Einbettungen - das ist die einzige Kopie. Sie können nicht lesen, woran sich Ihr Agent erinnert. Sie können eine schlechte Erinnerung nicht durch Bearbeiten einer Zeile korrigieren. Der Ansatz von OpenClaw bietet Ihnen beides: die Transparenz von einfachen Dateien und die Abrufkraft einer Vektorsuche mit einer Vektordatenbank. Sie können sie lesen, git diff, grep - es sind einfach Dateien.

Der einzige Nachteil? Im Moment ist dieses Markdown-first Speichersystem eng mit dem gesamten OpenClaw-Ökosystem verwoben - dem Gateway-Prozess, den Plattformkonnektoren, der Workspace-Konfiguration und der Messaging-Infrastruktur. Wenn man nur das Speichermodell haben will, ist das eine Menge an Maschinerie, die man mitschleppen muss.

Das ist genau der Grund, warum wir memsearch entwickelt haben: dieselbe Philosophie - Markdown als Quelle der Wahrheit, automatische Vektorindizierung, vollständig von Menschen editierbar - aber als leichtgewichtige, eigenständige Bibliothek, die Sie in jede agenturische Architektur einfügen können.

Wie Memsearch funktioniert

Wie bereits erwähnt, ist memsearch eine völlig unabhängige Bibliothek für den Langzeitspeicher, die dieselbe Speicherarchitektur implementiert, die auch in OpenClaw verwendet wird - ohne den Rest des OpenClaw-Stacks mitzubringen. Sie können sie in jedes beliebige Agenten-Framework (Claude, GPT, Llama, benutzerdefinierte Agenten, Workflow-Engines) einbinden und Ihrem System sofort einen persistenten, transparenten und von Menschen editierbaren Speicher geben.

Der gesamte Agentenspeicher in memsearch wird in einem lokalen Verzeichnis als Klartext-Markdown gespeichert. Die Struktur ist absichtlich einfach gehalten, damit die Entwickler sie auf einen Blick verstehen können:

~/your-project/
└── memory/
    ├── MEMORY.md              # Hand-written long-term memory
    ├── 2026-02-09.md          # Today's work log
    ├── 2026-02-08.md
    └── 2026-02-07.md

Memsearch verwendet Milvus als Vektor-Datenbank, um diese Markdown-Dateien für eine schnelle semantische Suche zu indizieren. Entscheidend ist jedoch, dass der Vektorindex nicht die Quelle der Wahrheit ist - die Dateien sind es. Wenn Sie den Milvus-Index vollständig löschen, verlieren Sie nichts. Memsearch bettet die Markdown-Dateien einfach neu ein und indiziert sie neu, so dass die gesamte Abrufschicht in wenigen Minuten wiederhergestellt ist. Das bedeutet, dass der Speicher Ihres Agenten transparent, dauerhaft und vollständig rekonstruierbar ist.

Hier sind die wichtigsten Funktionen von memsearch:

Lesbares Markdown macht die Fehlersuche so einfach wie das Bearbeiten einer Datei

Die Fehlersuche im KI-Gedächtnis ist normalerweise mühsam. Wenn ein Agent eine falsche Antwort gibt, kann man bei den meisten Speichersystemen nicht klar erkennen, was er tatsächlich gespeichert hat. Der typische Arbeitsablauf besteht darin, benutzerdefinierten Code zu schreiben, um eine Speicher-API abzufragen, und sich dann durch undurchsichtige Einbettungen oder wortreiche JSON-Blobs zu wühlen, die beide nicht viel über den tatsächlichen internen Zustand der KI aussagen.

memsearch beseitigt diese ganze Klasse von Problemen. Der gesamte Speicher wird im Ordner memory/ in einfacher Markdown-Form gespeichert:

## Morning
- Fixed N+1 query issue — switched to selectinload()
- Query count dropped from 152 to 3

Wenn die KI etwas falsch macht, ist es so einfach wie das Bearbeiten der Datei. Aktualisieren Sie den Eintrag, speichern Sie, und memsearch indiziert die Änderung automatisch neu. Fünf Sekunden. Keine API-Aufrufe. Keine Werkzeuge. Keine Rätsel. Sie debuggen AI-Speicher auf dieselbe Weise wie Dokumentation - durch Bearbeiten einer Datei.

Git-gestützter Speicher bedeutet, dass Teams Änderungen nachverfolgen, überprüfen und rückgängig machen können

KI-Speicher, die in einer Datenbank gespeichert sind, lassen sich nur schwer gemeinsam bearbeiten. Um herauszufinden, wer was wann geändert hat, muss man sich durch Audit-Protokolle wühlen, und viele Lösungen bieten nicht einmal diese. Änderungen erfolgen stillschweigend, und bei Meinungsverschiedenheiten darüber, was die KI speichern soll, gibt es keinen klaren Lösungsweg. Teams verlassen sich dann auf Slack-Nachrichten und Annahmen.

Memsearch behebt dieses Problem, indem der Speicher nur aus Markdown-Dateien besteht - was bedeutet, dass Git die Versionierung automatisch übernimmt. Ein einziger Befehl zeigt die gesamte Historie an:

git log memory/MEMORY.md
git diff HEAD~1 memory/2026-02-09.md

Jetzt nimmt der KI-Speicher am selben Workflow teil wie der Code. Architekturentscheidungen, Konfigurationsaktualisierungen und Einstellungsänderungen werden alle in Diffs angezeigt, die jeder kommentieren, genehmigen oder rückgängig machen kann:

+ ## Architecture Decision
+ - Use Kafka for event bus instead of RabbitMQ
+ - Reason: better horizontal scaling

Klartextspeicher macht die Migration fast mühelos

Die Migration ist eine der größten versteckten Kosten von Speicher-Frameworks. Der Wechsel von einem Tool zu einem anderen bedeutet in der Regel, Daten zu exportieren, Formate zu konvertieren, erneut zu importieren und zu hoffen, dass die Felder kompatibel sind. Diese Art von Arbeit kann leicht einen halben Tag in Anspruch nehmen, und das Ergebnis ist nie garantiert.

memsearch umgeht dieses Problem vollständig, da der Speicher als Klartext-Markdown vorliegt. Es gibt kein proprietäres Format, kein Schema zu übersetzen, nichts zu migrieren:

  • Rechnerwechsel: rsync der Speicherordner. Erledigt.

  • Wechseln Sie das Einbettungsmodell: Führen Sie den Index-Befehl erneut aus. Es wird fünf Minuten dauern, und die Markdown-Dateien bleiben unberührt.

  • Wechseln Sie den Einsatz der Vektordatenbank: Ändern Sie einen Konfigurationswert. Wechseln Sie zum Beispiel von Milvus Lite in der Entwicklung zu Zilliz Cloud in der Produktion:

# Development
ms = MemSearch(milvus_uri="~/.memsearch/milvus.db")

# Production (change only this line)
ms = MemSearch(milvus_uri=“https://xxx.zillizcloud.com”)

Ihre Speicherdateien bleiben genau gleich. Die Infrastruktur um sie herum kann sich frei weiterentwickeln. Das Ergebnis ist eine langfristige Portabilität - eine seltene Eigenschaft bei KI-Systemen.

Gemeinsame Markdown-Dateien ermöglichen es Menschen und Agenten, gemeinsam am Speicher zu schreiben

Bei den meisten Speicherlösungen ist es erforderlich, Code für eine API zu schreiben, um zu bearbeiten, was sich die KI merkt. Das bedeutet, dass nur Entwickler den KI-Speicher pflegen können, und selbst für diese ist es umständlich.

Memsearch ermöglicht eine natürlichere Aufteilung der Verantwortung:

  • Die KI kümmert sich: Automatische Tagesprotokolle (YYYY-MM-DD.md) mit Ausführungsdetails wie "Bereitgestellt v2.3.1, 12% Leistungsverbesserung."

  • Menschen handhaben: Langfristige Prinzipien in MEMORY.md, wie "Team stack: Python + FastAPI + PostgreSQL."

Beide Seiten bearbeiten die gleichen Markdown-Dateien mit den Tools, die sie bereits verwenden. Keine API-Aufrufe, kein spezielles Tooling, kein Gatekeeper. Wenn der Speicher in einer Datenbank gesperrt ist, ist diese Art der gemeinsamen Autorenschaft nicht möglich. memsearch macht dies zum Standard.

Unter der Haube: memsearch läuft auf vier Workflows, die den Speicher schnell, frisch und schlank halten

memsearch hat vier Kern-Workflows: Überwachen (Monitor) → Indexieren (Chunking und Einbetten) → Suchen (Abrufen) → Verdichten (Zusammenfassen). Jeder von ihnen hat folgende Aufgaben.

1. Beobachten: Automatisches Neuindizieren bei jedem Speichern einer Datei

Der Watch-Workflow überwacht alle Markdown-Dateien im Speicher/Verzeichnis und löst eine Neuindizierung aus, sobald eine Datei geändert und gespeichert wird. Eine Verzögerung von 1500 ms stellt sicher, dass Aktualisierungen erkannt werden, ohne Rechenzeit zu verschwenden: Wenn mehrere Speicherungen kurz hintereinander erfolgen, wird der Timer zurückgesetzt und erst dann ausgelöst, wenn sich die Bearbeitungen stabilisiert haben.

Diese Verzögerung ist empirisch abgestimmt:

  • 100ms → zu empfindlich; wird bei jedem Tastendruck ausgelöst, brennende Einbettungsaufrufe

  • 10s → zu langsam; Entwickler bemerken Verzögerung

  • 1500ms → ideales Gleichgewicht zwischen Reaktionsfähigkeit und Ressourceneffizienz

In der Praxis bedeutet dies, dass ein Entwickler in einem Fenster Code schreiben und in einem anderen MEMORY.md bearbeiten kann, indem er eine URL für API-Dokumente hinzufügt oder einen veralteten Eintrag korrigiert. Speichern Sie die Datei, und die nächste KI-Abfrage nimmt den neuen Speicher auf. Kein Neustart, keine manuelle Neuindizierung.

2. Index: Intelligentes Chunking, Deduplizierung und versionssichere Einbettung

Index ist der leistungsentscheidende Workflow. Er behandelt drei Dinge: Chunking, Deduplizierung und versionierte Chunk-IDs.

Beim Chunking wird der Text entlang semantischer Grenzen - Überschriften und Textkörper - aufgeteilt, damit zusammengehörige Inhalte zusammenbleiben. Dadurch werden Fälle vermieden, in denen ein Satz wie "Redis-Konfiguration" auf mehrere Chunks aufgeteilt wird.

Zum Beispiel dieser Markdown:

## Redis Caching
We use Redis for L1 cache with 5min TTL.
The connection pool is configured with max 100 connections.

## Database
PostgreSQL 16 is the primary database.

Wird zu zwei Chunks:

  • Chunk 1: ## Redis Caching\nWe use Redis for L1 cache...

  • Chunk 2: ## Database\nPostgreSQL 16 is the primary database.

Die Deduplizierung verwendet einen SHA-256-Hash jedes Chunks, um zu vermeiden, dass derselbe Text zweimal eingebettet wird. Wenn mehrere Dateien "PostgreSQL 16" erwähnen, wird die Einbettungs-API einmal aufgerufen, nicht einmal pro Datei. Für ~500KB Text spart dies etwa $0,15/Monat. Im großen Maßstab summiert sich das zu Hunderten von Dollar.

Das Chunk-ID-Design kodiert alles, was nötig ist, um zu wissen, ob ein Chunk veraltet ist. Das Format ist hash(source_path:start_line:end_line:content_hash:model_version). Das Feld model_version ist der wichtige Teil: Wenn ein Einbettungsmodell von text-embedding-3-small auf text-embedding-3-large aktualisiert wird, werden die alten Einbettungen ungültig. Da die Modellversion in die ID integriert ist, erkennt das System automatisch, welche Chunks neu eingebettet werden müssen. Eine manuelle Bereinigung ist nicht erforderlich.

3. Suche: Hybrid Vector + BM25 Retrieval für maximale Genauigkeit

Für die Suche wird ein hybrider Ansatz verwendet: Vektorsuche mit einer Gewichtung von 70 % und BM25-Schlüsselwortsuche mit einer Gewichtung von 30 %. Dadurch werden zwei unterschiedliche Anforderungen, die in der Praxis häufig auftreten, ausgeglichen.

  • DieVektorsuche übernimmt den semantischen Abgleich. Eine Abfrage nach "Redis cache config" gibt einen Chunk zurück, der "Redis L1 cache with 5min TTL" enthält, auch wenn der Wortlaut unterschiedlich ist. Dies ist nützlich, wenn sich der Entwickler zwar an das Konzept, nicht aber an die genaue Formulierung erinnert.

  • BM25 behandelt exakte Übereinstimmungen. Eine Abfrage nach "PostgreSQL 16" gibt keine Ergebnisse über "PostgreSQL 15" zurück. Dies ist wichtig für Fehlercodes, Funktionsnamen und versionsspezifisches Verhalten, wo "close" nicht gut genug ist.

Die Standardaufteilung von 70/30 ist für die meisten Anwendungsfälle gut geeignet. Für Arbeitsabläufe, die stark auf exakte Übereinstimmungen ausgerichtet sind, ist die Erhöhung der BM25-Gewichtung auf 50 % eine einzeilige Konfigurationsänderung.

Die Ergebnisse werden als Top-K-Chunks (standardmäßig 3) zurückgegeben, die jeweils auf 200 Zeichen gekürzt sind. Wenn der vollständige Inhalt benötigt wird, lädt memsearch expand <chunk_hash> ihn. Diese schrittweise Offenlegung hält die Nutzung des LLM-Kontextfensters schlank, ohne den Zugang zu Details zu beeinträchtigen.

4. Kompakt: Historischen Speicher zusammenfassen, um den Kontext sauber zu halten

Angehäufter Speicher wird irgendwann zu einem Problem. Alte Einträge füllen das Kontextfenster, erhöhen die Token-Kosten und fügen Rauschen hinzu, das die Antwortqualität verschlechtert. Compact geht dieses Problem an, indem es einen LLM aufruft, um den historischen Speicher in einer komprimierten Form zusammenzufassen und dann die Originale zu löschen oder zu archivieren. Der Vorgang kann manuell ausgelöst oder für eine regelmäßige Ausführung geplant werden.

Wie man mit memsearch anfängt

Memsearch bietet sowohl eine Python-API als auch eine CLI, so dass Sie es innerhalb von Agenten-Frameworks oder als eigenständiges Debugging-Tool verwenden können. Die Einrichtung ist minimal, und das System ist so konzipiert, dass Ihre lokale Entwicklungsumgebung und der Produktionseinsatz fast identisch aussehen.

Memsearch unterstützt drei Milvus-kompatible Backends, die alle über die gleiche API zugänglich sind:

  • Milvus Lite (Standard): Lokale .db Datei, keine Konfiguration, geeignet für den individuellen Gebrauch.

  • Milvus Standalone / Cluster: Selbstgehostet, unterstützt mehrere Agenten, die Daten gemeinsam nutzen, geeignet für Teamumgebungen.

  • Zilliz Cloud: Vollständig verwaltet, mit automatischer Skalierung, Backups, hoher Verfügbarkeit und Isolierung. Ideal für Produktions-Workloads.

Der Wechsel von der lokalen Entwicklung zur Produktion ist normalerweise eine einzeilige Konfigurationsänderung. Ihr Code bleibt derselbe.

installieren

pip install memsearch

memsearch unterstützt auch mehrere Einbettungsanbieter, darunter OpenAI, Google, Voyage, Ollama und lokale Modelle. Dadurch wird sichergestellt, dass Ihre Speicherarchitektur portabel und anbieterunabhängig bleibt.

Option 1: Python-API (integriert in Ihr Agenten-Framework)

Hier ist ein minimales Beispiel für eine vollständige Agentenschleife mit memsearch. Sie können es kopieren/einfügen und nach Bedarf ändern:

from openai import OpenAI
from memsearch import MemSearch

llm = OpenAI()
ms = MemSearch(paths=[“./memory/”])


async def agent_chat(user_input: str) -> str:
# 1. Recall — search relevant memories
memories = await ms.search(user_input, top_k=3)
context = “\n”.join(f"- {m[‘content’][:200]}" for m in memories)


<span class="hljs-comment"># 2. Think — call LLM</span>
resp = llm.chat.completions.create(
    model=<span class="hljs-string">&quot;gpt-4o-mini&quot;</span>,
    messages=[
        {<span class="hljs-string">&quot;role&quot;</span>: <span class="hljs-string">&quot;system&quot;</span>, <span class="hljs-string">&quot;content&quot;</span>: <span class="hljs-string">f&quot;Memories:\n<span class="hljs-subst">{context}</span>&quot;</span>},
        {<span class="hljs-string">&quot;role&quot;</span>: <span class="hljs-string">&quot;user&quot;</span>, <span class="hljs-string">&quot;content&quot;</span>: user_input},
    ],
)

<span class="hljs-comment"># 3. Remember — write to markdown, update index</span>
save_memory(<span class="hljs-string">f&quot;## <span class="hljs-subst">{user_input}</span>\n<span class="hljs-subst">{resp.choices[<span class="hljs-number">0</span>].message.content}</span>&quot;</span>)
<span class="hljs-keyword">await</span> ms.index()
<span class="hljs-keyword">return</span> resp.choices[<span class="hljs-number">0</span>].message.content

Dies zeigt die Kernschleife:

  • Zur Erinnerung: memsearch führt eine hybride Vektor- und BM25-Suche durch.

  • Denken Sie: Ihr LLM verarbeitet die Benutzereingabe + den abgerufenen Speicher

  • Erinnern Sie sich: der Agent schreibt neuen Speicher in Markdown, und memsearch aktualisiert seinen Index

Dieses Muster passt natürlich in jedes Agenten-System - LangChain, AutoGPT, semantische Router, LangGraph oder benutzerdefinierte Agenten-Schleifen. Es ist vom Design her rahmenunabhängig.

Option 2: CLI (schnelle Operationen, gut zum Debuggen)

Die CLI ist ideal für eigenständige Arbeitsabläufe, schnelle Überprüfungen oder die Untersuchung des Speichers während der Entwicklung:

memsearch index ./docs/              # Index files
memsearch search "Redis caching"     # Search
memsearch watch ./docs/              # Watch for file changes
memsearch compact                    # Compact old memory

Die CLI spiegelt die Fähigkeiten der Python-API wider, funktioniert aber ohne das Schreiben von Code - ideal für Debugging, Inspektionen, Migrationen oder die Validierung der Speicherordnerstruktur.

Wie memsearch im Vergleich zu anderen Speicherlösungen abschneidet

Die häufigste Frage, die Entwickler stellen, ist, warum sie memsearch verwenden sollten, wenn es bereits etablierte Optionen gibt. Die kurze Antwort: memsearch tauscht fortgeschrittene Funktionen wie temporale Wissensgraphen gegen Transparenz, Portabilität und Einfachheit. Für die meisten Anwendungsfälle von Agentenspeicher ist das der richtige Kompromiss.

LösungStärkenBeschränkungenAm besten geeignet für
memsearchTransparenter Klartextspeicher, Mensch-KI-Ko-Autorenschaft, keine Reibungsverluste bei der Migration, einfaches Debugging, Git-nativKeine eingebauten zeitlichen Graphen oder komplexe Multi-Agenten-SpeicherstrukturenTeams, die Wert auf Kontrolle, Einfachheit und Portabilität im Langzeitspeicher legen
Mem0Vollständig verwaltet, keine Infrastruktur zu betreiben oder zu wartenUndurchsichtig - Speicher kann nicht inspiziert oder manuell bearbeitet werden; Einbettungen sind die einzige DarstellungTeams, die einen einfach zu verwaltenden Dienst wünschen und mit weniger Transparenz einverstanden sind
ZepReichhaltiger Funktionsumfang: temporales Gedächtnis, Modellierung mehrerer Personen, komplexe WissensgraphenSchwerfällige Architektur; mehr bewegliche Teile; schwieriger zu erlernen und zu bedienenAgenten, die wirklich fortgeschrittene Speicherstrukturen oder zeitbewusstes Denken benötigen
LangMem / LettaTiefe, nahtlose Integration in ihre eigenen ÖkosystemeFramework-Lock-in; schwer auf andere Agenten-Stacks zu portierenTeams sind bereits auf diese spezifischen Frameworks festgelegt

Testen Sie memsearch und lassen Sie uns Ihr Feedback wissen

Memsearch ist vollständig quelloffen unter der MIT-Lizenz, und das Repository ist ab heute für Produktionsversuche bereit.

Wenn Sie einen Agenten bauen, der sich Dinge über Sitzungen hinweg merken muss und die volle Kontrolle darüber haben will, was er sich merkt, ist memsearch einen Blick wert. Die Bibliothek wird mit einem einzigen pip install installiert, funktioniert mit jedem Agenten-Framework und speichert alles als Markdown, das Sie lesen, bearbeiten und mit Git versionieren können.

Wir entwickeln memsearch aktiv weiter und würden uns über Anregungen aus der Community freuen.

  • Eröffnen Sie einen Fehler, wenn etwas nicht funktioniert.

  • Reichen Sie einen PR ein, wenn Sie die Bibliothek erweitern wollen.

  • Veröffentlichen Sie das Repo, wenn Ihnen die Philosophie von Markdown-as-source-of-truth zusagt.

Das Speichersystem von OpenClaw ist nicht länger in OpenClaw eingeschlossen. Jetzt kann es jeder benutzen.

Lesen Sie weiter

    Try Managed Milvus for Free

    Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.

    Get Started

    Like the article? Spread the word

    Weiterlesen