Referenz zur Speicherkonfiguration

Diese Seite führt alle Konfigurationsoptionen für die OpenClaw-Speichersuche auf. Konzeptionelle Übersichten finden Sie unter:

Sofern nicht anders angegeben, befinden sich alle Einstellungen für die Speichersuche unter agents.defaults.memorySearch in openclaw.json (oder in einer agentenspezifischen Überschreibung unter agents.list[].memorySearch).

Provider-Auswahl

Wenn provider nicht festgelegt ist, verwendet OpenClaw OpenAI-Embeddings. Legen Sie provider explizit fest, um Bedrock, DeepInfra, Gemini, GitHub Copilot, Mistral, Ollama, Voyage, ein lokales GGUF-Modell oder einen OpenAI-kompatiblen /v1/embeddings-Endpunkt zu verwenden. Ältere Konfigurationen, die noch provider: "auto" enthalten, werden als openai aufgelöst.

Wenn provider nicht festgelegt ist, das ältere provider: "auto" vorhanden ist oder provider: "none" absichtlich den reinen FTS-Modus auswählt, kann der Speicherabruf weiterhin die lexikalische FTS-Rangfolge verwenden, wenn Embeddings nicht verfügbar sind.

Explizit konfigurierte nicht lokale Provider schlagen ohne Ausweichverhalten fehl. Wenn Sie memorySearch.provider auf einen konkreten, remote gestützten Provider wie Bedrock, DeepInfra, Gemini, GitHub Copilot, LM Studio, Mistral, Ollama, OpenAI, Voyage oder einen OpenAI-kompatiblen benutzerdefinierten Provider festlegen und dieser Provider zur Laufzeit nicht verfügbar ist, gibt memory_search ein Ergebnis mit dem Status „nicht verfügbar“ zurück, statt stillschweigend einen reinen FTS-Abruf zu verwenden. Korrigieren Sie die Provider-/Authentifizierungskonfiguration, wechseln Sie zu einem erreichbaren Provider oder legen Sie provider: "none" fest, wenn Sie bewusst einen reinen FTS-Abruf wünschen.

Benutzerdefinierte Provider-IDs

memorySearch.provider kann auf einen benutzerdefinierten models.providers.<id>-Eintrag für speicherspezifische Provider-Adapter wie ollama oder für OpenAI-kompatible Modell-APIs wie openai-responses / openai-completions verweisen. OpenClaw ermittelt den zugehörigen api-Besitzer für den Embedding-Adapter und behält zugleich die benutzerdefinierte Provider-ID für die Verarbeitung von Endpunkt, Authentifizierung und Modellpräfix bei. Dadurch können Konfigurationen mit mehreren GPUs oder Hosts Speicher-Embeddings einem bestimmten lokalen Endpunkt zuweisen:

{  models: {    providers: {      "ollama-5080": {        api: "ollama",        baseUrl: "http://gpu-box.local:11435",        apiKey: "ollama-local",        models: [{ id: "qwen3-embedding:0.6b", name: "Qwen3 Embedding 0.6B" }],      },    },  },  agents: {    defaults: {      memorySearch: {        provider: "ollama-5080",        model: "qwen3-embedding:0.6b",      },    },  },}

Auflösung des API-Schlüssels

Remote-Embeddings erfordern einen API-Schlüssel. Bedrock verwendet stattdessen die standardmäßige AWS-SDK-Anmeldedatenkette (Instanzrollen, SSO, Zugriffsschlüssel oder einen Bedrock-API-Schlüssel).

Konfiguration des Remote-Endpunkts

Verwenden Sie provider: "openai-compatible" für einen generischen OpenAI-kompatiblen /v1/embeddings-Server, der die globalen OpenAI-Chat-Anmeldedaten nicht übernehmen soll.

{  agents: {    defaults: {      memorySearch: {        provider: "openai-compatible",        model: "text-embedding-3-small",        remote: {          baseUrl: "https://api.example.com/v1/",          apiKey: "YOUR_KEY",        },      },    },  },}

Providerspezifische Konfiguration

{  agents: {    defaults: {      memorySearch: {        provider: "openai-compatible",        remote: {          baseUrl: "https://embeddings.example/v1",          apiKey: "${EMBEDDINGS_API_KEY}",        },        model: "asymmetric-embedder",        queryInputType: "query",        documentInputType: "passage",      },    },  },}

{  agents: {    defaults: {      memorySearch: {        provider: "bedrock",        model: "amazon.titan-embed-text-v2:0",      },    },  },}

{  "Effect": "Allow",  "Action": "bedrock:InvokeModel",  "Resource": "*"}

arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0

openclaw memory status --deep --agent mainopenclaw memory index --force --agent main

Zeitüberschreitung für Inline-Einbettungen

Indizierungsverhalten

Alle Optionen befinden sich unter memorySearch.sync, sofern nicht anders angegeben:

Konfiguration der hybriden Suche

Alle unter memorySearch.query:

Und unter memorySearch.query.hybrid:

Vollständiges Beispiel

{  agents: {    defaults: {      memorySearch: {        query: {          maxResults: 6,          minScore: 0.35,          hybrid: {            vectorWeight: 0.7,            textWeight: 0.3,            mmr: { enabled: true, lambda: 0.7 },            temporalDecay: { enabled: true, halfLifeDays: 30 },          },        },      },    },  },}

Zusätzliche Speicherpfade

{  agents: {    defaults: {      memorySearch: {        extraPaths: ["../team-docs", "/srv/shared-notes"],      },    },  },}

Pfade können absolut oder relativ zum Arbeitsbereich sein. Verzeichnisse werden rekursiv nach .md-Dateien durchsucht. Die Behandlung symbolischer Links hängt vom aktiven Backend ab: Die integrierte Engine überspringt symbolische Links, während QMD dem Verhalten des zugrunde liegenden QMD-Scanners folgt.

Verwenden Sie für die agentenspezifische, agentenübergreifende Transkriptsuche agents.list[].memorySearch.qmd.extraCollections anstelle von memory.qmd.paths. Diese zusätzlichen Sammlungen verwenden dieselbe Struktur { path, name, pattern? }, werden jedoch pro Agent zusammengeführt und können explizite gemeinsame Namen beibehalten, wenn der Pfad außerhalb des aktuellen Arbeitsbereichs liegt. Wenn derselbe aufgelöste Pfad sowohl in memory.qmd.paths als auch in memorySearch.qmd.extraCollections vorkommt, behält QMD den ersten Eintrag bei und überspringt das Duplikat.

Multimodaler Speicher (Gemini)

Indizieren Sie Bilder und Audiodateien zusammen mit Markdown mithilfe von Gemini Embedding 2:

Unterstützte Formate: .jpg, .jpeg, .png, .webp, .gif, .heic, .heif (Bilder); .mp3, .wav, .ogg, .opus, .m4a, .aac, .flac (Audio).

Embedding-Cache

Verhindert, dass unveränderter Text bei einer Neuindizierung oder bei Transkriptaktualisierungen erneut eingebettet wird. Lassen Sie maxEntries für einen unbegrenzten Cache nicht gesetzt; legen Sie einen Wert fest, wenn die Begrenzung des Speicherplatzwachstums wichtiger als die maximale Neuindizierungsgeschwindigkeit ist. Wenn ein Wert festgelegt ist, werden zuerst die ältesten Einträge (nach dem Zeitpunkt der letzten Aktualisierung) entfernt, sobald der Cache den Grenzwert überschreitet.

Batch-Indizierung

Verfügbar für gemini, openai und voyage. OpenAI Batch ist bei umfangreichen nachträglichen Befüllungen üblicherweise am schnellsten und kostengünstigsten.

remote.nonBatchConcurrency steuert Inline-Embedding-Aufrufe, die von lokalen bzw. selbst gehosteten Providern und gehosteten Providern verwendet werden, wenn die Batch-APIs des Providers nicht aktiv sind. Ollama verwendet für die Indizierung ohne Batch standardmäßig 1, um kleinere lokale Hosts nicht zu überlasten; legen Sie auf leistungsfähigeren Systemen einen höheren Wert fest.

Dies ist unabhängig von sync.embeddingBatchTimeoutSeconds, das die Zeitüberschreitung für Inline-Embedding-Aufrufe steuert.

Sitzungsspeichersuche (experimentell)

Indizieren Sie Sitzungstranskripte und stellen Sie sie über memory_search bereit:

Treffer aus Sitzungstranskripten unterliegen ebenfalls tools.sessions.visibility. Die standardmäßige Sichtbarkeit tree stellt nur die aktuelle Sitzung und die von ihr gestarteten Sitzungen bereit. Um aus einer anderen Sitzung, beispielsweise einer Direktnachricht, auf eine nicht zusammenhängende, demselben Agenten zugeordnete und vom Gateway gestartete Sitzung zuzugreifen, erweitern Sie die Sichtbarkeit bewusst auf agent (oder nur dann auf all, wenn auch ein agentenübergreifender Zugriff erforderlich ist und die Richtlinie für die Kommunikation zwischen Agenten dies zulässt).

In den folgenden Beispielen werden diese Einstellungen unter agents.defaults eingeordnet. Sie können entsprechende memorySearch-Einstellungen auch in einer agentenspezifischen Überschreibung anwenden, wenn nur ein Agent Sitzungstranskripte indizieren und durchsuchen soll.

Für den Abruf vom Gateway zu Direktnachrichten innerhalb desselben Agenten:

{  agents: {    defaults: {      memorySearch: {        experimental: { sessionMemory: true },        sources: ["memory", "sessions"],      },    },  },  tools: {    sessions: { visibility: "agent" },  },}

{  agents: {    defaults: {      memorySearch: {        experimental: { sessionMemory: true },        sources: ["memory", "sessions"],      },    },  },  memory: {    backend: "qmd",    qmd: {      sessions: { enabled: true },    },  },  tools: {    sessions: { visibility: "agent" },  },}

Bei Verwendung von QMD exportieren agents.defaults.memorySearch.experimental.sessionMemory und sources: ["sessions"] allein keine Transkripte nach QMD. Legen Sie zusätzlich memory.qmd.sessions.enabled: true fest.

SQLite-Vektorbeschleunigung (sqlite-vec)

Wenn sqlite-vec nicht verfügbar ist, greift OpenClaw automatisch auf die prozessinterne Kosinusähnlichkeit zurück.

Indexspeicherung

Integrierte Speicherindizes befinden sich in der OpenClaw-SQLite-Datenbank des jeweiligen Agenten unter agents/<agentId>/agent/openclaw-agent.sqlite.

QMD-Backend-Konfiguration

Legen Sie zum Aktivieren memory.backend = "qmd" fest. Alle QMD-Einstellungen befinden sich unter memory.qmd:

searchMode: "search" verwendet ausschließlich lexikalische/BM25-Suche. OpenClaw führt für diesen Modus keine Prüfungen der semantischen Vektorbereitschaft und keine Pflege der QMD-Embeddings durch, auch nicht während memory status --deep; vsearch und query erfordern weiterhin die Vektorbereitschaft und Embeddings von QMD.

rerank: false ändert nur den QMD-Modus query und erfordert QMD 2.1 oder neuer. Im direkten CLI-Modus übergibt OpenClaw --no-rerank; im MCP-Modus über mcporter übergibt es rerank: false an das vereinheitlichte Abfragewerkzeug von QMD. Lassen Sie die Einstellung unausgefüllt, um das standardmäßige Reranking-Verhalten für QMD-Abfragen zu verwenden.

OpenClaw bevorzugt die aktuellen QMD-Formate für Sammlungen und MCP-Abfragen, unterstützt jedoch ältere QMD-Versionen weiterhin, indem bei Bedarf kompatible Flags für Sammlungsmuster und ältere MCP-Werkzeugnamen ausprobiert werden. Wenn QMD die Unterstützung mehrerer Sammlungsfilter meldet, werden Sammlungen derselben Quelle mit einem einzigen QMD-Prozess durchsucht; ältere QMD-Builds verwenden weiterhin den Kompatibilitätspfad pro Sammlung. „Dieselbe Quelle“ bedeutet, dass dauerhafte Speichersammlungen (Standardspeicherdateien sowie benutzerdefinierte Pfade) zusammen gruppiert werden, während Sammlungen von Sitzungstranskripten eine separate Gruppe bleiben, sodass die Quellendiversifizierung weiterhin beide Eingaben umfasst.

mcporter-Integration

Alle Einstellungen befinden sich unter memory.qmd.mcporter. QMD-Suchen werden über einen langlebigen mcporter-MCP-Daemon geleitet, anstatt für jede Abfrage qmd zu starten. Dies reduziert den Kaltstartaufwand bei größeren Modellen.

Erfordert eine installierte und über PATH verfügbare Version von mcporter sowie einen konfigurierten mcporter-Server, der qmd mcp ausführt. Lassen Sie diese Option für einfachere lokale Einrichtungen deaktiviert, bei denen die Kosten für das Starten eines Prozesses pro Abfrage akzeptabel sind.

{  memory: {    qmd: {      scope: {        default: "deny",        rules: [{ action: "allow", match: { chatType: "direct" } }],      },    },  },}

Wenn die QMD-Initialisierung beim Gateway-Start aktiviert ist, startet OpenClaw QMD nur für geeignete Agenten. Wenn update.onBoot auf true gesetzt und keine intervallbasierte Aktualisierungs- oder Einbettungswartung konfiguriert ist, verwendet der Startvorgang einen einmaligen Manager für die Aktualisierung beim Start und schließt ihn anschließend. Wenn ein Aktualisierungs- oder Einbettungsintervall konfiguriert ist, öffnet der Startvorgang den langlebigen QMD-Manager, damit dieser den Watcher und die Intervall-Timer verwalten kann. update.onBoot: false überspringt nur die unmittelbare Aktualisierung beim Start.

Vollständiges QMD-Beispiel

{  memory: {    backend: "qmd",    citations: "auto",    qmd: {      includeDefaultMemory: true,      update: { interval: "5m", debounceMs: 15000 },      limits: { maxResults: 4, timeoutMs: 4000 },      scope: {        default: "deny",        rules: [{ action: "allow", match: { chatType: "direct" } }],      },      paths: [{ name: "docs", path: "~/notes", pattern: "**/*.md" }],    },  },}

Dreaming

Dreaming wird unter plugins.entries.memory-core.config.dreaming konfiguriert, nicht unter agents.defaults.memorySearch.

Dreaming wird als ein geplanter Durchlauf ausgeführt und verwendet interne Light-/Deep-/REM-Phasen als Implementierungsdetail.

Informationen zum konzeptionellen Verhalten und zu Slash-Befehlen finden Sie unter Dreaming.

Benutzereinstellungen

Beispiel

{  plugins: {    entries: {      "memory-core": {        subagent: {          allowModelOverride: true,          allowedModels: ["anthropic/claude-sonnet-4-6"],        },        config: {          dreaming: {            enabled: true,            frequency: "0 3 * * *",            model: "anthropic/claude-sonnet-4-6",          },        },      },    },  },}

Verwandte Themen

• Konfigurationsreferenz
• Speicherübersicht
• Speichersuche