Память OpenClaw

@dr0p_usdt

Бот работает, отвечает, выполняет команды. Но каждый новый диалог начинается с чистого листа — бот не помнит, о чём вы говорили вчера. В этом уроке разберёмся, как устроена память OpenClaw: где бот хранит знания, как ищет в них нужное и что делать, чтобы важная информация не терялась.

Для большинства случаев хватает стандартных настроек. Память работает из коробки — бот записывает заметки в файлы и читает их при каждом диалоге. Единственное, что желательно стоит настроить — векторный поиск (описано ниже). Всё остальное в этом уроке — для понимания, как система устроена, и для тонкой настройки, когда понадобится.

Как устроена память

У бота нет скрытого хранилища. Всё, что он помнит — записано в обычных Markdown-файлах в рабочей директории агента (~/.openclaw/workspace). Не записал — не помнит.

Два типа файлов:

MEMORY.md — долгосрочная память

Главный файл. Сюда попадают устойчивые факты: твои предпочтения, принятые решения, важные детали проектов. Файл подгружается при каждом новом диалоге.

Чтобы бот что-то запомнил, достаточно написать ему:

Запомни, что я предпочитаю деплоить на Timeweb и использую Claude для генерации кода.

Бот сам запишет это в MEMORY.md в подходящем формате. Файл можно редактировать и вручную — это обычный Markdown.

Дневные заметки

Файлы вида memory/2026-04-02.md — рабочие заметки за конкретный день. Сюда бот записывает текущий контекст: над чем работали, какие задачи решали, промежуточные результаты. Автоматически подгружаются заметки за сегодня и вчера.

Дневные заметки удобны тем, что со временем формируют историю работы. Если через неделю спросишь бота «что мы делали в прошлый понедельник» — он найдёт ответ через поиск по памяти.

Поиск по памяти

Когда заметок становится много, простое чтение файлов не помогает — нужен поиск. Бот использует два инструмента:

memory_search — находит релевантные заметки. Можно настроить поиск по смыслу (семантический) или только по ключевым словам.
memory_get — читает конкретный файл или диапазон строк. Когда бот уже знает, где лежит нужная информация.

Поиск по умолчанию (только ключевые слова)

Если не настроен embedding-провайдер, OpenClaw использует только keyword-поиск на основе BM25 — полнотекстовый индекс в SQLite. Он ищет точные совпадения слов и их формы.

Примечание: если у тебя уже прописан API-ключ OpenAI, Gemini, Voyage или Mistral (например, для чат-модели) — векторный поиск подхватится автоматически. OpenClaw определяет провайдер по доступным ключам.

Что это значит на практике: запрос «Docker» найдёт запись со словом «Docker», запрос «настройка сервера» найдёт «настройка сервера». Но запрос «как настраивал сервер» не найдёт запись про «деплой на VPS». «connection timeout» не найдёт «таймаут подключения». «С кем работал над проектом» не найдёт «коллега Андрей».

Чем больше накапливается заметок — тем острее эта проблема: бот не может вспомнить то, что знает, если запрос сформулирован иначе.

Проверить текущий статус поиска:

openclaw memory status

Если видишь сообщение no embedding provider is ready — значит работает только keyword-поиск.

Семантический (векторный) поиск

С embedding-провайдером подключается гибридный поиск: BM25 (точные слова) + векторный (смысл) одновременно. По умолчанию вес семантики — 70%, ключевых слов — 30%.

Что меняется: «как настраивал сервер» находит «деплой на VPS через Docker». «connection timeout» находит «таймаут подключения». Синонимы, перефразировки, разные языки — всё работает. При этом точные запросы (ID, имена конфигов, строки ошибок) по-прежнему находятся через BM25.

Как это работает под капотом. Embedding-модель — отдельная нейросеть, которая превращает текст в вектор из сотен чисел, кодирующих смысл. «Деплой на VPS через Docker» и «настройка сервера» дадут похожие векторы, а «рецепт борща» — совсем другой. Модель запускается при сохранении заметки (индексирование) и при каждом поиске.

Когда ты задаёшь вопрос, основной LLM (Claude, GPT) решает вызвать memory_search, embedding-модель превращает запрос в вектор, SQLite ищет похожие векторы + BM25, возвращает релевантные сниппеты, и LLM включает их в ответ.

Как включить векторный поиск

Для векторного поиска нужен API-ключ embedding-провайдера. Самый простой вариант — OpenAI.

Где взять ключ OpenAI: platform.openai.com

Самый быстрый и удобный способ настроить — попросить бота. Напиши ему в Telegram:

Документация: https://docs.openclaw.ai

Настрой векторный поиск, вот ключ sk-...

Бот сам прочитает документацию, пропишет ключ в конфиг и перезапустит gateway.

Local — автоопределение, приоритет №1. GGUF-модель, ~0.6 ГБ при первом запуске, полностью офлайн.
OpenAI — автоопределение. По умолчанию text-embedding-3-small.
Gemini — автоопределение. Поддерживает мультимодальные эмбеддинги (изображения, аудио).
Voyage — автоопределение.
Mistral — автоопределение.
Ollama — не автоопределяется, локальный, указывать явно.

Порядок в списке — это порядок автоопределения: OpenClaw выбирает первый провайдер, для которого доступен ключ или модель. Если хочешь использовать конкретный — укажи его явно через memorySearch.provider.

Вариант без облака — provider: "local". Скачается GGUF-модель, всё работает офлайн и бесплатно. Но на слабых VPS (2 CPU / 4 GB RAM) индексация будет медленной. Для таких серверов лучше облачный провайдер.

Но если у вас хотя бы 8 GB RAM, спокойно работает локальная модель. У меня краб не захотел скачивать стандартную GGUF-модель, поэтому я попросил его установить Ollama и настроить embeddinggemma. Все заработало отлично.

Сколько стоит векторный поиск

Embedding-модели на порядки дешевле чат-моделей. OpenAI text-embedding-3-small стоит $0.02 за 1 млн токенов.

На практике: проиндексировать всю память (100 заметок, ~40 000 токенов) — меньше 0.1 рубля. Тысяча поисковых запросов в день — около 0.03 рубля. Для сравнения: один обычный разговор с Claude стоит в сотни раз больше. Это не та статья расходов, о которой стоит думать.

Тонкая настройка поиска

Когда заметок накопится много (сотни файлов за несколько месяцев), стандартный поиск может возвращать устаревшие или дублирующиеся результаты. Две опции помогут:

Temporal Decay (затухание по времени) — старые заметки постепенно теряют вес в результатах. С дефолтным периодом полураспада 30 дней запись месячной давности получит 50% от своего исходного веса. При этом «вечнозелёные» файлы вроде MEMORY.md не затухают никогда.
MMR (разнообразие результатов) — если пять заметок описывают одну и ту же настройку роутера, MMR выберет разные темы вместо пяти копий одного и того же.

Включить обе опции:

{
  agents: {
    defaults: {
      memorySearch: {
        query: {
          hybrid: {
            mmr: { enabled: true },
            temporalDecay: { enabled: true }
          }
        }
      }
    }
  }
}

Мультимодальная память. Если используешь Gemini Embedding 2, можно индексировать изображения и аудиофайлы наряду с Markdown. Поисковые запросы остаются текстовыми, но находят совпадения по визуальному и аудиоконтенту.

Индексация файлов за пределами workspace. Встроенный бэкенд поддерживает extraPaths — можно добавить в поиск Markdown-файлы из любых директорий (проектная документация, заметки команды) без установки QMD:

{
  agents: {
    defaults: {
      memorySearch: {
        extraPaths: ["~/notes", "/srv/project-docs"]
      }
    }
  }
}

Пути могут быть абсолютными или относительными к workspace. Директории сканируются рекурсивно для .md файлов.

Поиск по истории сессий. Экспериментальная фича — можно индексировать транскрипты прошлых разговоров, чтобы memory_search находил информацию из старых диалогов, даже если она не была сохранена в файлы памяти:

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

Индексация сессий работает асинхронно — результаты могут немного отставать от текущего состояния.

Компакция — что происходит с длинными диалогами

У каждой модели есть контекстное окно — максимум токенов, которые она может обработать за раз. Когда диалог приближается к этому лимиту, OpenClaw компактит старые сообщения — сжимает их в краткую сводку.

Как это работает: старые сообщения заменяются кратким саммари, недавние остаются нетронутыми. Полная история при этом сохраняется на диске — компакция меняет только то, что видит модель в текущий момент.

Важный момент: перед компакцией бот автоматически сохраняет важные факты из разговора в файлы памяти. Это происходит без твоего участия — OpenClaw запускает скрытый «flush» перед тем, как сжать контекст. Поэтому ничего критичного не теряется.

Ещё один нюанс: если модель вернёт ошибку переполнения контекста (context-overflow), OpenClaw автоматически скомпактит диалог и повторит запрос. Ты даже не заметишь, что это произошло.

Если хочешь запустить компакцию вручную — напиши /compact в чате. Можно с подсказкой:

/compact Сохрани детали по настройке API

По умолчанию компакция использует основную модель агента. Можно указать другую — например, более дешёвую для экономии или более сильную для качественных саммари. Учитывай: плохое сжатие = потеря контекста, поэтому слишком слабая модель может навредить.

{
  agents: {
    defaults: {
      compaction: {
        model: "anthropic/claude-haiku-4-5"
      }
    }
  }
}

Чтобы видеть, когда бот компактит контекст, включи уведомления:

{
  agents: {
    defaults: {
      compaction: {
        notifyUser: true
      }
    }
  }
}

Session Pruning — обрезка вывода инструментов

Pruning — более лёгкий механизм экономии контекста. Он не сжимает разговор, а обрезает старые результаты инструментов (вывод команд, содержимое файлов, результаты поиска), которые раздувают контекстное окно.

Для провайдера Anthropic pruning включается автоматически — он оптимизирует работу кэша промптов, что напрямую снижает стоимость. Для остальных провайдеров можно включить вручную:

{
  agents: {
    defaults: {
      contextPruning: {
        mode: "cache-ttl",
        ttl: "5m"
      }
    }
  }
}

Pruning работает только в оперативной памяти — на диске полная история сохраняется. Он дополняет компакцию: pruning убирает мусор из результатов инструментов между циклами компакции.

Сессии

Каждый разговор в OpenClaw — это сессия. Сообщения маршрутизируются в сессии по источнику: личные сообщения идут в одну сессию, каждый групповой чат — в свою, cron-задачи — в отдельные.

По умолчанию сессия сбрасывается раз в сутки (в 4:00 утра). Можно настроить сброс по неактивности — например, новая сессия после 30 минут молчания:

{
  session: {
    reset: {
      idleMinutes: 30
    }
  }
}

Чтобы начать новую сессию вручную — напиши /new (или /reset) в чате. /new claude-sonnet-4-6 заодно переключит модель.

ОЧЕНЬ ВАЖНО: возьми за правило — новая задача начинается с /new. Обсуждал настройку сервера и теперь хочешь попросить бота написать текст — сначала /new. Иначе бот потащит в контекст весь предыдущий разговор, потратит токены впустую и может запутаться. Это самый простой способ экономить и получать точные ответы.

Изоляция в многопользовательском режиме

Если с ботом общается несколько человек — настрой изоляцию сессий. Без неё все личные сообщения попадают в одну сессию: Алиса увидит, что писал Боб.

{
  session: {
    dmScope: "per-channel-peer"
  }
}

per-channel-peer — рекомендуемый режим: сессия изолирована по каналу и отправителю. Каждый пользователь в каждом канале получает свою отдельную сессию.

Если один и тот же человек пишет боту из нескольких каналов (например, Telegram и Discord) и нужно, чтобы они делили одну сессию — используй session.identityLinks для объединения идентичностей.

Проверить настройки безопасности:

openclaw security audit

Автоочистка старых сессий

Со временем на диске накапливаются файлы транскриптов (.jsonl). На VPS с ограниченным диском это может стать проблемой. OpenClaw умеет автоматически чистить старые сессии:

{
  session: {
    maintenance: {
      mode: "enforce",
      pruneAfter: "30d",
      maxEntries: 500
    }
  }
}

Перед включением можно проверить, что будет удалено:

openclaw sessions cleanup --dry-run

Бэкенды памяти

OpenClaw поддерживает три бэкенда. Для большинства задач хватает встроенного.

Builtin (по умолчанию)

SQLite-база с полнотекстовым индексом и векторным поиском. Работает сразу после установки, ничего дополнительного ставить не нужно.

Индекс хранится в ~/.openclaw/memory/<agentId>.sqlite. Файлы памяти отслеживаются автоматически — при изменении индекс обновляется за пару секунд.

Для подавляющего большинства случаев этого бэкенда достаточно.

QMD — продвинутый локальный поиск

Локальный поисковый движок с реранкингом и расширением запросов. Работает как sidecar-процесс рядом с OpenClaw.

Когда стоит рассмотреть: если у тебя большой объём заметок и встроенный поиск не справляется с качеством, если нужно индексировать файлы за пределами workspace (например, проектную документацию) или хочешь искать по истории прошлых сессий.

Установка:

bun install -g @tobilu/qmd

Включение в конфиге:

{
  memory: {
    backend: "qmd"
  }
}

QMD при первом запуске скачивает GGUF-модели (~2 ГБ) для реранкинга. Первый поиск будет медленным — дальше всё работает быстро. Если QMD по какой-то причине упадёт, OpenClaw автоматически переключится на встроенный бэкенд.

Honcho — кросс-сессионная AI-память

Плагин, который сохраняет контекст между сессиями и строит профиль пользователя. Обычная память OpenClaw работает через файлы — Honcho добавляет поверх неё AI-слой, который автоматически запоминает разговоры и формирует модель пользователя (предпочтения, стиль общения, контекст работы).

Когда это полезно: бот регулярно общается с несколькими людьми и нужно, чтобы он помнил контекст каждого без ручных записей в MEMORY.md.