Dokumentacja referencyjna konfiguracji pamięci

Ta strona zawiera listę wszystkich ustawień konfiguracji wyszukiwania w pamięci OpenClaw. Omówienia koncepcyjne znajdziesz tutaj:

Wszystkie ustawienia wyszukiwania w pamięci znajdują się w agents.defaults.memorySearch w openclaw.json, o ile nie wskazano inaczej.

# Wybór dostawcy

# Kolejność automatycznego wykrywania

Gdy provider nie jest ustawione, OpenClaw wybiera pierwszą dostępną opcję:

ollama jest obsługiwane, ale nie jest wykrywane automatycznie (ustaw je jawnie).

# Niestandardowe identyfikatory dostawców

memorySearch.provider może wskazywać niestandardowy wpis models.providers.<id>. OpenClaw rozpoznaje właściciela api tego dostawcy dla adaptera osadzania, zachowując niestandardowy identyfikator dostawcy na potrzeby obsługi punktu końcowego, uwierzytelniania i prefiksu modelu. Dzięki temu konfiguracje z wieloma GPU lub wieloma hostami mogą przypisać osadzania pamięci do konkretnego lokalnego punktu końcowego:

{
  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",
      },
    },
  },
}

# Rozpoznawanie klucza API

Zdalne osadzania wymagają klucza API. Bedrock używa zamiast tego domyślnego łańcucha poświadczeń AWS SDK (role instancji, SSO, klucze dostępu).

# Konfiguracja zdalnego punktu końcowego

Dla niestandardowych punktów końcowych zgodnych z OpenAI lub nadpisywania ustawień domyślnych dostawcy:

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

# Konfiguracja specyficzna dla dostawcy

{
  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

# Limit czasu embeddingów inline

# Konfiguracja wyszukiwania hybrydowego

Wszystko w memorySearch.query.hybrid:

# Pełny przykład

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

# Dodatkowe ścieżki pamięci

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

Ścieżki mogą być bezwzględne lub względne względem przestrzeni roboczej. Katalogi są skanowane rekurencyjnie pod kątem plików .md. Obsługa dowiązań symbolicznych zależy od aktywnego backendu: wbudowany silnik ignoruje dowiązania symboliczne, natomiast QMD stosuje zachowanie bazowego skanera QMD.

Do wyszukiwania transkryptów między agentami w zakresie agenta użyj agents.list[].memorySearch.qmd.extraCollections zamiast memory.qmd.paths. Te dodatkowe kolekcje używają tego samego kształtu { path, name, pattern? }, ale są scalane osobno dla każdego agenta i mogą zachować jawne współdzielone nazwy, gdy ścieżka wskazuje poza bieżącą przestrzeń roboczą. Jeśli ta sama rozwiązana ścieżka pojawi się zarówno w memory.qmd.paths, jak i memorySearch.qmd.extraCollections, QMD zachowuje pierwszy wpis i pomija duplikat.

# Pamięć multimodalna (Gemini)

Indeksuj obrazy i audio obok Markdown przy użyciu Gemini Embedding 2:

Obsługiwane formaty: .jpg, .jpeg, .png, .webp, .gif, .heic, .heif (obrazy); .mp3, .wav, .ogg, .opus, .m4a, .aac, .flac (audio).

# Pamięć podręczna embeddingów

Zapobiega ponownemu tworzeniu embeddingów dla niezmienionego tekstu podczas ponownego indeksowania lub aktualizacji transkrypcji.

# Indeksowanie wsadowe

Dostępne dla openai, gemini i voyage. W przypadku dużych uzupełnień OpenAI batch jest zwykle najszybszy i najtańszy.

remote.nonBatchConcurrency steruje wywołaniami embeddingów inline używanymi przez lokalnych/samodzielnie hostowanych dostawców oraz dostawców hostowanych, gdy API wsadowe dostawcy nie są aktywne. Ollama domyślnie używa 1 dla indeksowania niewsadowego, aby nie przeciążać mniejszych hostów lokalnych; ustaw wyższą wartość na większych maszynach.

To ustawienie jest niezależne od sync.embeddingBatchTimeoutSeconds, które kontroluje limit czasu dla wywołań embeddingów inline.

# Wyszukiwanie w pamięci sesji (eksperymentalne)

Indeksuj transkrypcje sesji i udostępniaj je przez memory_search:

# Przyspieszenie wektorowe SQLite (sqlite-vec)

Gdy sqlite-vec jest niedostępny, OpenClaw automatycznie wraca do podobieństwa cosinusowego obliczanego w procesie.

# Przechowywanie indeksu

# Konfiguracja backendu QMD

Ustaw memory.backend = "qmd", aby włączyć. Wszystkie ustawienia QMD znajdują się w memory.qmd:

searchMode: "search" jest wyłącznie leksykalne/BM25. OpenClaw nie uruchamia sond gotowości wektorów semantycznych ani konserwacji osadzeń QMD dla tego trybu, także podczas memory status --deep; vsearch i query nadal wymagają gotowości wektorów QMD oraz osadzeń.

OpenClaw preferuje bieżącą kolekcję QMD i kształty zapytań MCP, ale zachowuje działanie starszych wydań QMD, próbując w razie potrzeby zgodnych flag wzorców kolekcji i starszych nazw narzędzi MCP. Gdy QMD ogłasza obsługę wielu filtrów kolekcji, kolekcje z tego samego źródła są przeszukiwane za pomocą jednego procesu QMD; starsze kompilacje QMD zachowują ścieżkę zgodności dla poszczególnych kolekcji. To samo źródło oznacza, że trwałe kolekcje pamięci są grupowane razem, natomiast kolekcje transkryptów sesji pozostają osobną grupą, dzięki czemu dywersyfikacja źródeł nadal ma oba wejścia.

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

Odświeżenia QMD przy rozruchu używają jednorazowej ścieżki podprocesu podczas startu bramy. Długotrwały menedżer QMD nadal odpowiada za zwykły obserwator plików i timery interwałów, gdy wyszukiwanie w pamięci zostanie otwarte do użytku interaktywnego.

# Pełny przykład QMD

{
  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 konfiguruje się w plugins.entries.memory-core.config.dreaming, a nie w agents.defaults.memorySearch.

Dreaming działa jako jeden zaplanowany przebieg i używa wewnętrznych faz light/deep/REM jako szczegółu implementacyjnego.

Opis zachowania koncepcyjnego i poleceń ukośnikowych znajdziesz w Dreaming.

# Ustawienia użytkownika

# Przykład

{
  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",
          },
        },
      },
    },
  },
}

# Powiązane

• Dokumentacja konfiguracji
• Omówienie pamięci
• Wyszukiwanie w pamięci