Referenz zur Speicherkonfiguration

Diese Seite listet jeden Konfigurationsparameter für die OpenClaw-Speichersuche auf. Konzeptuelle Übersichten finden Sie hier:

Alle Einstellungen der Speichersuche befinden sich unter agents.defaults.memorySearch in openclaw.json, sofern nicht anders angegeben.

# Provider-Auswahl

# Reihenfolge der automatischen Erkennung

Wenn provider nicht gesetzt ist, wählt OpenClaw den ersten verfügbaren aus:

ollama wird unterstützt, aber nicht automatisch erkannt (setzen Sie es explizit).

# Benutzerdefinierte Provider-IDs

memorySearch.provider kann auf einen benutzerdefinierten Eintrag models.providers.<id> verweisen. OpenClaw löst den api-Eigentümer dieses Providers für den Embedding-Adapter auf und behält gleichzeitig die benutzerdefinierte Provider-ID für Endpoint-, Auth- und Modellpräfix-Verarbeitung bei. Dadurch können Setups mit mehreren GPUs oder Hosts Speicher-Embeddings einem bestimmten lokalen Endpoint zuweisen:

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

# API-Schlüsselauflösung

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

# Konfiguration für Remote-Endpoints

Für benutzerdefinierte OpenAI-kompatible Endpoints oder zum Überschreiben von Provider-Standards:

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

# Provider-spezifische Konfiguration

{
  agents: {
    defaults: {
      memorySearch: {
        provider: "openai",
        remote: {
          baseUrl: "https://embeddings.example/v1",
          apiKey: "env: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 main
openclaw memory index --force --agent main

# Timeout für Inline-Embeddings

# Konfiguration der Hybridsuche

Alles unter memorySearch.query.hybrid:

# Vollständiges Beispiel

{
  agents: {
    defaults: {
      memorySearch: {
        query: {
          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 Workspace sein. Verzeichnisse werden rekursiv nach .md-Dateien durchsucht. Die Behandlung von Symlinks hängt vom aktiven Backend ab: Die integrierte Engine ignoriert Symlinks, während QMD dem Verhalten des zugrunde liegenden QMD-Scanners folgt.

Für agentenspezifische agentenübergreifende Transkriptsuche verwenden Sie agents.list[].memorySearch.qmd.extraCollections statt memory.qmd.paths. Diese zusätzlichen Collections folgen derselben Form { path, name, pattern? }, werden jedoch pro Agent zusammengeführt und können explizite gemeinsame Namen beibehalten, wenn der Pfad außerhalb des aktuellen Workspace liegt. Wenn derselbe aufgelöste Pfad sowohl in memory.qmd.paths als auch in memorySearch.qmd.extraCollections erscheint, behält QMD den ersten Eintrag und überspringt das Duplikat.

# Multimodaler Speicher (Gemini)

Indizieren Sie Bilder und Audio 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 Neuindizierung oder Transkript-Aktualisierungen erneut eingebettet wird.

# Batch-Indizierung

Verfügbar für openai, gemini und voyage. OpenAI-Batch ist für große Backfills in der Regel am schnellsten und günstigsten.

remote.nonBatchConcurrency steuert Inline-Embedding-Aufrufe, die von lokalen/self-hosted Providern und gehosteten Providern verwendet werden, wenn Provider-Batch-APIs nicht aktiv sind. Ollama verwendet für Non-Batch-Indizierung standardmäßig 1, um kleinere lokale Hosts nicht zu überlasten; setzen Sie auf größeren Maschinen einen höheren Wert.

Dies ist getrennt von sync.embeddingBatchTimeoutSeconds, das den Timeout für Inline-Embedding-Aufrufe steuert.

# Session-Memory-Suche (experimentell)

Sitzungstranskripte indizieren und über memory_search bereitstellen:

# SQLite-Vektorbeschleunigung (sqlite-vec)

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

# Indexspeicher

# QMD-Backend-Konfiguration

Setzen Sie memory.backend = "qmd", um es zu aktivieren. Alle QMD-Einstellungen befinden sich unter memory.qmd:

searchMode: "search" ist rein lexikalisch/BM25-basiert. OpenClaw führt für diesen Modus keine semantischen Vektorbereitschaftsprüfungen oder QMD-Embedding-Wartung aus, auch nicht während memory status --deep; vsearch und query erfordern weiterhin QMD-Vektorbereitschaft und Embeddings.

OpenClaw bevorzugt die aktuellen QMD-Collection- und MCP-Abfrageformen, hält ältere QMD-Versionen aber lauffähig, indem bei Bedarf kompatible Collection-Pattern-Flags und ältere MCP-Toolnamen ausprobiert werden. Wenn QMD Unterstützung für mehrere Collection-Filter angibt, werden Collections aus derselben Quelle mit einem QMD-Prozess durchsucht; ältere QMD-Builds behalten den Kompatibilitätspfad pro Collection bei. Dieselbe Quelle bedeutet, dass dauerhafte Memory-Collections zusammen gruppiert werden, während Session-Transcript-Collections eine separate Gruppe bleiben, sodass die Quellendiversifizierung weiterhin beide Eingaben hat.

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

QMD-Boot-Aktualisierungen verwenden während des Gateway-Starts einen einmaligen Subprozesspfad. Der langlebige QMD-Manager besitzt weiterhin den regulären Datei-Watcher und die Intervall-Timer, wenn die Memory-Suche für die interaktive Nutzung geöffnet wird.

# Vollständiges QMD-Beispiel

{
  memory: {
    backend: "qmd",
    citations: "auto",
    qmd: {
      includeDefaultMemory: true,
      update: { interval: "5m", debounceMs: 15000 },
      limits: { maxResults: 6, 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 läuft als ein geplanter Sweep und verwendet interne Light-/Deep-/REM-Phasen als Implementierungsdetail.

Konzeptuelles Verhalten und Slash-Befehle 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
• Memory-Übersicht
• Memory-Suche