Провайдеры памяти

Hermes Agent поставляется с 2 плагинами внешних провайдеров памяти (RetainDB и ByteRover), которые дают агенту знания, сохраняющиеся между сессиями, — сверх встроенных MEMORY.md и USER.md; ещё несколько (например, Honcho, Hindsight, Supermemory и Holographic) доступны в каталоге плагинов. Активным одновременно может быть только один внешний провайдер — встроенная память при этом работает всегда, параллельно с ним.

Быстрый старт

hermes memory setup      # интерактивный выбор + настройка
hermes memory status     # проверка, что сейчас активно
hermes memory off        # отключить внешний провайдер

Выбрать активный провайдер памяти можно также через hermes plugins → Provider Plugins → Memory Provider.

Либо задайте вручную в ~/.hermes/config.yaml:

memory:
  provider: retaindb  # или byterover,
                      # или honcho / hindsight / supermemory / mem0 / openviking / holographic
                      # (каталог плагинов — сначала выполните `hermes plugins install <name>`)

Как это работает

Когда провайдер памяти активен, Hermes автоматически:

1. Внедряет контекст провайдера в системный промпт (то, что провайдер знает)
2. Заранее подгружает релевантные воспоминания перед каждым ходом (в фоне, без блокировки)
3. Синхронизирует ходы диалога с провайдером после каждого ответа
4. Извлекает воспоминания по завершении сессии (для провайдеров, которые это поддерживают)
5. Дублирует записи встроенной памяти во внешний провайдер
6. Добавляет специфичные для провайдера инструменты, чтобы агент мог искать, сохранять воспоминания и управлять ими

Встроенная память (MEMORY.md / USER.md) продолжает работать точно так же, как и раньше. Внешний провайдер лишь дополняет её.

Всё, что Hermes передаёт провайдеру (ходы, транскрипт вместе с выводом инструментов, поисковые запросы, транскрипты конца сессии и перед сжатием, продублированные записи памяти, результаты делегирования и аргументы собственных инструментов провайдера), сначала проходит ту же очистку от секретов, что и доставка в чат-платформы и из cron, так что ключ, попавший в вывод инструмента, маскируется до того, как провайдер успеет его сохранить. Как и в той доставке, очистка работает даже при security.redact_secrets: false. Учётные данные без узнаваемой формы (произвольный пароль, непрозрачный токен вне контекста key=value или Bearer) не обнаруживаются; ваш локальный транскрипт хранит исходный текст.

Доступные провайдеры

Honcho

AI-нативное моделирование пользователя между сессиями с диалектическим рассуждением, внедрением контекста в рамках сессии, семантическим поиском и постоянными выводами (conclusions). Базовый контекст теперь включает сводку сессии вместе с представлением пользователя (user representation) и карточками пиров (peer cards), благодаря чему агент понимает, что уже обсуждалось.

Инструменты (5): honcho_profile (чтение/обновление карточки пира), honcho_search (семантический поиск), honcho_context (контекст сессии — сводка, представление, карточка, сообщения), honcho_reasoning (синтез на базе LLM), honcho_conclude (создание/удаление выводов)

Архитектура: двухуровневое внедрение контекста — базовый слой (сводка сессии + представление + карточка пира, обновляется по contextCadence) плюс диалектическая надстройка (рассуждение LLM, обновляется по dialecticCadence). Диалектика автоматически выбирает между промптами холодного старта (общие факты о пользователе) и промптами «прогретого» состояния (контекст в рамках сессии) — в зависимости от того, есть ли уже базовый контекст.

Три независимых параметра конфигурации отдельно управляют стоимостью и глубиной:

• contextCadence — как часто обновляется базовый слой (частота вызовов API)
• dialecticCadence — как часто срабатывает диалектическая LLM (частота вызовов LLM)
• dialecticDepth — сколько проходов .chat() выполняется за один вызов диалектики (1–3, глубина рассуждения)

Автоматически внедряемая диалектика также масштабирует уровень рассуждения по длине запроса (длиннее запрос → глубже рассуждение, с потолком reasoningLevelCap); см. Адаптивный уровень рассуждения по запросу.

Мастер настройки:

hermes plugins install honcho   # из каталога плагинов
hermes memory setup             # выберите "honcho" — запустится специфичный для Honcho этап после настройки

Безголовые и удалённые машины. Для облачной авторизации на машине без браузера (SSH, удалённая ВМ) выбирайте в мастере метод авторизации device. CLI напечатает короткий код и ссылку для подтверждения; откройте ссылку в браузере на любой другой машине, подтвердите — и настройка завершится, без копирования API-ключей руками. Когда пригодного локального браузера не нашлось, мастер сам выбирает этот вариант по умолчанию.

Устаревшая команда hermes honcho setup по-прежнему работает (теперь она перенаправляет на hermes memory setup), но регистрируется только после того, как Honcho выбран активным провайдером памяти.

Конфигурация: $HERMES_HOME/honcho.json (для конкретного профиля) или ~/.honcho/config.json (глобально). Порядок разрешения: $HERMES_HOME/honcho.json > ~/.hermes/honcho.json > ~/.honcho/config.json. См. README плагина и руководство по интеграции Honcho.

{
  "apiKey": "your-key-from-app.honcho.dev",
  "hosts": {
    "hermes": {
      "enabled": true,
      "aiPeer": "hermes",
      "peerName": "your-name",
      "workspace": "hermes"
    }
  }
}

{
  "baseUrl": "http://localhost:8000",
  "hosts": {
    "hermes": {
      "enabled": true,
      "aiPeer": "hermes",
      "peerName": "your-name",
      "workspace": "hermes"
    }
  }
}

Настройка нескольких пиров:

Honcho моделирует диалоги как пиров, обменивающихся сообщениями, — один пир-пользователь плюс один AI-пир на каждый профиль Hermes, и все они делят общее рабочее пространство. Рабочее пространство — это общая среда: пир-пользователь общий для всех профилей, а каждый AI-пир — отдельная идентичность. Каждый AI-пир строит независимое представление / карточку на основе собственных наблюдений, поэтому профиль coder остаётся ориентированным на код, а профиль writer — на редакторскую работу, хотя оба работают с одним и тем же пользователем.

Соответствие понятий:

Новый профиль, новый пир Honcho

hermes profile create coder --clone

--clone создаёт блок хоста hermes.coder в honcho.json с aiPeer: "coder", общим workspace, унаследованными peerName, recallMode, writeFrequency, observation и т. д. AI-пир создаётся в Honcho заранее, ещё до первого сообщения.

Существующие профили, добавление недостающих пиров Honcho

hermes honcho sync

Сканирует каждый профиль Hermes, создаёт блоки хоста для тех профилей, у кого их ещё нет, наследует настройки из блока hermes по умолчанию и заранее создаёт новые AI-пиры. Идемпотентна — пропускает профили, у которых блок хоста уже есть.

Наблюдение для каждого профиля

Каждый блок хоста может независимо переопределять конфигурацию наблюдения. Пример: профиль, ориентированный на код, в котором AI-пир наблюдает за пользователем, но не моделирует сам себя:

"hermes.coder": {
  "aiPeer": "coder",
  "observation": {
    "user": { "observeMe": true, "observeOthers": true },
    "ai":   { "observeMe": false, "observeOthers": true }
  }
}

Переключатели наблюдения (свой набор для каждого пира):

Пресеты через observationMode:

• "directional" (по умолчанию) — все четыре флага включены. Полное взаимное наблюдение; включает диалектику между пирами.
• "unified" — у пользователя observeMe: true, у AI observeOthers: true, остальное false. Пул с единственным наблюдателем: AI моделирует пользователя, но не себя, а пир-пользователь моделирует только себя.

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

Полный справочник по наблюдению — на странице Honcho.

Сопоставление идентичностей шлюза

Описанная выше модель пиров охватывает сессии CLI, TUI и десктопа, где любой диалог разрешается в peerName. Шлюз добавляет второе измерение: пользователи приходят с платформенными runtime ID (Telegram UID, Discord snowflake, пользователь Slack), и три ключа определяют, в какого пира разрешается каждый ID.

Вне шлюза эти ключи ни на что не влияют. hermes memory setup запрашивает их только тогда, когда обнаруживает подключённую платформу шлюза. Лестницу разрешения идентичностей и процесс настройки см. на странице Honcho.

{
  "apiKey": "your-key",
  "workspace": "hermes",
  "peerName": "eri",
  "hosts": {
    "hermes": {
      "enabled": true,
      "aiPeer": "hermes",
      "workspace": "hermes",
      "peerName": "eri",
      "recallMode": "hybrid",
      "writeFrequency": "async",
      "sessionStrategy": "per-directory",
      "observation": {
        "user": { "observeMe": true, "observeOthers": true },
        "ai": { "observeMe": true, "observeOthers": true }
      },
      "dialecticReasoningLevel": "low",
      "dialecticDynamic": true,
      "dialecticCadence": 2,
      "dialecticDepth": 1,
      "dialecticMaxChars": 600,
      "contextCadence": 1,
      "messageMaxChars": 25000,
      "saveMessages": true
    },
    "hermes.coder": {
      "enabled": true,
      "aiPeer": "coder",
      "workspace": "hermes",
      "peerName": "eri",
      "recallMode": "tools",
      "observation": {
        "user": { "observeMe": true, "observeOthers": false },
        "ai": { "observeMe": true, "observeOthers": true }
      }
    },
    "hermes.writer": {
      "enabled": true,
      "aiPeer": "writer",
      "workspace": "hermes",
      "peerName": "eri"
    }
  },
  "sessions": {
    "/home/user/myproject": "myproject-main"
  }
}

См. README плагина и руководство по интеграции Honcho.

Обновление со встроенного Honcho

Прежние версии Hermes поставляли Honcho внутри дерева. Если в профиле всё ещё стоит memory.provider: honcho, Hermes сам установит плагин из каталога при следующем запуске или при hermes update: ваш ~/.honcho/config.json (или $HERMES_HOME/honcho.json), блоки хостов, пиры и сопоставления сессий читаются ровно так же, как раньше, так что память не теряется. Чтобы сделать это вручную или на машине без сети при запуске, выполните hermes plugins install honcho.

OpenViking

База данных контекста от Volcengine (ByteDance) с иерархией знаний в стиле файловой системы, многоуровневым извлечением (tiered retrieval) и автоматическим извлечением воспоминаний по 6 категориям.

Инструменты (6): viking_search (семантический поиск), viking_read (многоуровневое чтение: abstract/overview/full), viking_browse (навигация в стиле файловой системы), viking_remember (сохранение фактов), viking_forget (удаление файла памяти по точному URI viking://), viking_add_resource (загрузка URL/документов)

Настройка:

# Сначала подготовьте OpenViking
openviking-server init
openviking-server doctor
openviking-server

# Затем установите и настройте плагин Hermes
hermes plugins install openviking
hermes memory setup    # выберите "openviking"
# Или вручную:
hermes config set memory.provider openviking

hermes memory setup умеет переиспользовать или копировать параметры подключения из ~/.openviking/ovcli.conf. Ручная настройка идёт в файл .env активного профиля: для профиля по умолчанию это ~/.hermes/.env, для именованных профилей — ~/.hermes/profiles/<profile>/.env.

OPENVIKING_ENDPOINT=http://127.0.0.1:1933
# OPENVIKING_API_KEY=...
# OPENVIKING_ACCOUNT=default
# OPENVIKING_USER=default

Настройки самого сервера OpenViking живут в ov.conf (--config, OPENVIKING_CONFIG_FILE либо ~/.openviking/ov.conf). Параметры подключения клиента — в ovcli.conf (OPENVIKING_CLI_CONFIG_FILE либо ~/.openviking/ovcli.conf).

Если эндпоинт локальный и на нём никто не слушает, плагин запускает openviking-server в фоне. В версии из каталога этот сервер наследует всё окружение процесса Hermes (кроме PYTHONPATH), включая токены ботов, шлюза или релея, заданные там. Если это для вас важно, запускайте openviking-server сами до Hermes, чтобы плагин его никогда не порождал. Исправление отслеживается в апстриме: volcengine/OpenViking#5553.

Ключевые особенности:

• Многоуровневая загрузка контекста: L0 (~100 токенов) → L1 (~2k) → L2 (полный)
• Автоматическое извлечение воспоминаний при фиксации сессии (профиль, предпочтения, сущности, события, кейсы, паттерны)
• Схема URI viking:// для иерархической навигации по знаниям

OPENVIKING_ACCOUNT и OPENVIKING_USER используются в локальном/доверенном режиме. Идентичность пира не обязательна. По умолчанию Hermes не отправляет ID пира и записывает явные воспоминания в viking://user/<user>/memories/.... Настройка не спрашивает ID пира. Чтобы выделить отдельный контекст для ассистента, укажите memory.openviking.agent: work-assistant в config.yaml.

Уже заданные непустые настройки пира сохраняют свою запись и поиск в рамках пира — это касается OPENVIKING_AGENT, а также actor_peer_id или устаревшего agent_id в связанном конфиге OpenViking. Существующие воспоминания никуда не переносятся и не удаляются. Без ID пира поиск по умолчанию охватывает память пользователя и уже существующие воспоминания пира в рамках того же пользователя OpenViking. Старые воспоминания пира остаются доступными для поиска по прежним путям — какие из них вернутся, определяют ранжирование и лимиты результатов. Чтобы восстановить прежнюю запись в рамках пира, укажите memory.openviking.agent: hermes. Воспоминания, записанные на уровне пользователя до этого изменения, остаются на месте и по-прежнему доступны для поиска: настройка меняет будущие записи, а не расположение уже существующих.

Hermes отправляет User-Agent: openviking-memory-hermes/<version> в запросах к OpenViking. Это стандартный идентификатор клиента Hermes — в нём нет привязки к конкретному пользователю, и отдельного запроса он не добавляет.

Переход со встроенного OpenViking

Раньше OpenViking поставлялся внутри дерева Hermes. Если в вашем config.yaml уже стоит memory.provider: openviking, большинству пользователей делать ничего не нужно:

• hermes update ставит плагин из каталога в домашний каталог каждого профиля, где указан этот провайдер.
• Если при первом запуске агента (hermes chat, шлюз, Desktop) плагина всё ещё нет, Hermes ставит его и сообщает об этом.
• При security.allow_lazy_installs: false путь запуска агента ничего не устанавливает, а печатает точную команду hermes plugins install openviking.

memory.provider, memory.openviking.*, ключи OPENVIKING_* в .env, ~/.openviking/ и воспоминания на вашем сервере OpenViking не затрагиваются. Проверить можно через hermes memory status и hermes plugins list.

Mem0

Серверное извлечение фактов силами LLM с семантическим поиском, реранкингом и автоматической дедупликацией. Три режима подключения: Platform (Mem0 Cloud), self-hosted dashboard (сервер Mem0, который вы запускаете сами через Docker) и OSS (Mem0 в том же процессе, с вашей собственной LLM и векторным хранилищем).

SDK mem0ai отправляет анонимную телеметрию использования в PostHog, если не задать MEM0_TELEMETRY=false в вашей оболочке или в ~/.hermes/.env.

Инструменты (4): mem0_search (семантический поиск; опциональный реранкинг в режиме platform, по умолчанию выключен), mem0_add (сохранение фактов дословно), mem0_update (обновление по ID), mem0_delete (удаление по ID)

Настройка (Platform):

hermes plugins install mem0   # из каталога плагинов
hermes memory setup    # выберите "mem0" → "Platform"
# Или вручную:
hermes config set memory.provider mem0
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

Настройка (OSS):

hermes memory setup    # выберите "mem0" → "Open Source (self-hosted)"
# Или через флаги:
hermes memory setup mem0 --mode oss --oss-llm openai --oss-llm-key sk-... --oss-vector qdrant

Предпросмотр без записи файлов:

hermes memory setup mem0 --mode oss --oss-llm-key sk-... --dry-run

Настройка (Self-Hosted Dashboard): подключение к серверу Mem0, который вы запускаете через Docker (REST API панели):

hermes memory setup    # выберите "mem0" → "Self-hosted server"
# Или через флаги:
hermes memory setup mem0 --mode selfhosted --host http://localhost:8888 --api-key your-admin-api-key

Либо настройте вручную — через переменные окружения:

echo "MEM0_HOST=http://localhost:8888" >> ~/.hermes/.env
echo "MEM0_API_KEY=your-admin-api-key" >> ~/.hermes/.env

либо в mem0.json:

{ "host": "http://localhost:8888", "api_key": "your-admin-api-key" }

Плагин аутентифицируется через X-API-Key и использует маршруты сервера /search / /memories. api_key необязателен (опускайте его только для серверов с AUTH_DISABLED). Не задавайте mode: oss — он имеет приоритет над host.

Конфигурация: $HERMES_HOME/mem0.json (поведенческие настройки). В ~/.hermes/.env должен находиться только секрет MEM0_API_KEY.

Поддерживаемые провайдеры в OSS:

Переключение режимов: заново запустите hermes memory setup mem0 --mode <platform|selfhosted|oss> или отредактируйте mem0.json напрямую.

Переход со встроенного Mem0

Раньше Mem0 поставлялся внутри дерева Hermes (и как pip-extra hermes-agent[mem0]). Если в вашем config.yaml уже стоит memory.provider: mem0, большинству пользователей делать ничего не нужно:

• hermes update ставит плагин из каталога в домашний каталог каждого профиля, где указан этот провайдер.
• Если при первом запуске агента (hermes chat, шлюз, Desktop) плагина всё ещё нет, Hermes ставит его и сообщает об этом.
• При security.allow_lazy_installs: false путь запуска агента ничего не устанавливает, а печатает точную команду hermes plugins install mem0.

memory.provider, $HERMES_HOME/mem0.json, ключи MEM0_* в .env и воспоминания в Mem0 Cloud, на вашем сервере Mem0 или в локальном хранилище OSS не затрагиваются. Проверить можно через hermes memory status и hermes plugins list.

Hindsight

Долгосрочная память с графом знаний, разрешением сущностей (entity resolution) и извлечением по нескольким стратегиям. Инструмент hindsight_reflect даёт синтез между воспоминаниями, которого нет ни у одного другого провайдера. Автоматически сохраняет полные ходы диалога (включая вызовы инструментов) с отслеживанием документов на уровне сессии.

Инструменты: hindsight_retain (сохранение с извлечением сущностей), hindsight_recall (поиск по нескольким стратегиям), hindsight_reflect (синтез между воспоминаниями)

Настройка:

hermes plugins install hindsight   # из каталога плагинов; на вопрос "Use 'hindsight' as the memory provider now?" ответьте утвердительно
hermes memory setup                # выберите "hindsight"
# Или вручную:
hermes config set memory.provider hindsight
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

Плагин ложится в ~/.hermes/plugins/hindsight/ (в домашнем каталоге каждого профиля). Провайдер памяти активируется через memory.provider в config.yaml, а не через plugins.enabled: согласие на запрос установки (или флаг --enable) задаёт его, а отказ ничего не меняет, так что выбрать провайдера можно позже через hermes memory setup. hermes plugins enable hindsight провайдер памяти не активирует. hermes memory setup, hermes memory status, hermes plugins list и настройки Memory в дашборде работают с плагином, поставленным из каталога. В локальном встроенном режиме плагин при первом использовании ставит hindsight-all через механизм отложенной установки Hermes, который учитывает security.allow_lazy_installs.

Интерфейс локального режима: hindsight-embed -p hermes ui start

Конфигурация: $HERMES_HOME/hindsight/config.json

Полный справочник по конфигурации см. в документации апстрима по интеграции с Hermes.

Переход со встроенного Hindsight

Раньше Hindsight поставлялся внутри дерева Hermes (и как pip-extra hermes-agent[hindsight]). Если в вашем config.yaml уже стоит memory.provider: hindsight, большинству пользователей делать ничего не нужно:

• hermes update ставит плагин из каталога в домашний каталог каждого профиля, где указан этот провайдер. Каждая строка называет профиль, о котором идёт речь. В терминале он спрашивает, прежде чем готовить Python-зависимости плагина; если провайдер используют несколько профилей, вопросы задаются один раз, а ответы применяются ко всем. Без терминала (приложение Desktop, скрипт, служба) отвечать некому, поэтому каждый профиль готовит их без вопросов, если у него включён security.allow_lazy_installs (по умолчанию так и есть); профиль с выключенной настройкой получает точную команду hermes -p <profile> plugins install hindsight, а остальные профили всё равно переносятся.
• Если при первом запуске агента (hermes chat, Desktop, шлюз, …) плагина всё ещё нет, Hermes ставит его вместе с зависимостями и показывает ✓ Memory provider 'hindsight' moved out of core — installed its plugin from the catalog (memory.provider and your stored memories are unchanged; check its settings with `hermes memory status`). В мессенджерах эта строка приходит с первым ответом.
• Если установка при запуске агента невозможна, вы видите причину, а не молча остаётесь без внешней памяти: при security.allow_lazy_installs: false предупреждение называет команду установки для этого профиля; при отсутствии сети или отказе показываются ошибка и та же команда. После неудачной попытки запуски агента в течение следующего часа установку пропускают и лишь повторяют команду; hermes update всегда пробует снова.
• Запуск агента никогда не задаёт вопросов (терминал занят промптом чата). Поэтому провайдер из каталога, который никогда не поставлялся с Hermes (например, mnemosyne), при запуске агента не ставится: предупреждение называет hermes plugins install <name> для этого профиля, а ещё его можно поставить на странице Plugins в дашборде или Desktop.

Что меняется на диске: плагин появляется в ~/.hermes/plugins/hindsight/, а в config.yaml добавляется plugins.enabled: [hindsight]. memory.provider, $HERMES_HOME/hindsight/config.json, HINDSIGHT_API_KEY в .env и данные вашего банка памяти не затрагиваются. Проверить можно через hermes memory status (провайдер активен) и hermes plugins list (плагин установлен и включён).

Holographic

Локальное хранилище фактов на SQLite с полнотекстовым поиском FTS5, оценкой доверия (trust scoring) и HRR (Holographic Reduced Representations) для композиционных алгебраических запросов.

Инструменты: fact_store (9 действий: add, search, probe, related, reason, contradict, update, remove, list), fact_feedback (оценка «полезно/бесполезно», которая обучает показатели доверия)

Настройка:

hermes plugins install holographic   # из каталога плагинов
hermes memory setup                  # выберите "holographic"
# Или вручную:
hermes config set memory.provider holographic

Конфигурация: config.yaml, раздел plugins.hermes-memory-store

Уникальные возможности:

• probe — алгебраическое извлечение по конкретной сущности (все факты о человеке/предмете)
• reason — композиционные запросы «И» по нескольким сущностям
• contradict — автоматическое обнаружение противоречащих фактов
• Оценка доверия с асимметричной обратной связью (+0.05 за «полезно» / −0.10 за «бесполезно»)

У плагина из каталога свои заметки о выпусках и параметры сверх этого списка; актуальные действия инструментов и настройки смотрите в его README.

Переход со встроенного Holographic

Раньше Holographic поставлялся внутри дерева Hermes. Если в вашем config.yaml уже стоит memory.provider: holographic, делать ничего не нужно:

• hermes update ставит плагин из каталога в домашний каталог каждого профиля, где указан этот провайдер.
• Если при первом запуске агента (hermes chat, шлюз, Desktop) плагина всё ещё нет, Hermes ставит его и сообщает об этом.
• При security.allow_lazy_installs: false путь запуска агента ничего не устанавливает, а печатает точную команду hermes plugins install holographic.

Ваши факты ($HERMES_HOME/memory_store.db или заданный вами db_path) и настройки plugins.hermes-memory-store читаются ровно так же, как раньше, так что память не теряется. Проверить можно через hermes memory status и hermes plugins list.

Если вы ставили промежуточную копию Nous Research по URL (NousResearch/hermes-plugin-holographic, теперь в архиве), hermes plugins update holographic переведёт её на запись каталога; ваши данные остаются на месте.

RetainDB

Облачный API памяти с гибридным поиском (Vector + BM25 + Reranking), 7 типами воспоминаний и дельта-компрессией.

Инструменты (10): retaindb_profile (профиль пользователя), retaindb_search (семантический поиск), retaindb_context (контекст, релевантный задаче), retaindb_remember (сохранение с типом и важностью), retaindb_forget (удаление воспоминаний), плюс файловые: retaindb_upload_file, retaindb_list_files, retaindb_read_file, retaindb_ingest_file, retaindb_delete_file

Настройка:

hermes memory setup    # выберите "retaindb"
# Или вручную:
hermes config set memory.provider retaindb
echo "RETAINDB_API_KEY=your-key" >> ~/.hermes/.env

ByteRover

Постоянная память через CLI brv — иерархическое дерево знаний с многоуровневым извлечением (нечёткий текстовый поиск → поиск на базе LLM). Local-first с опциональной синхронизацией в облако.

Инструменты: brv_query (поиск по дереву знаний), brv_curate (сохранение фактов/решений/паттернов), brv_status (версия CLI + статистика дерева)

Настройка:

# Сначала установите CLI
curl -fsSL https://byterover.dev/install.sh | sh

# Затем настройте Hermes
hermes memory setup    # выберите "byterover"
# Или вручную:
hermes config set memory.provider byterover

Ключевые особенности:

• Автоматическое извлечение перед сжатием (сохраняет находки до того, как их отбросит сжатие контекста)
• Дерево знаний хранится в $HERMES_HOME/byterover/ (в рамках профиля)
• Синхронизация с облаком с сертификацией SOC2 Type II (опционально)

Supermemory

Семантическая долгосрочная память с извлечением профиля, семантическим поиском, явными инструментами для работы с памятью и захватом диалога ход за ходом (один документ на сессию за каждое 4-часовое окно).

Инструменты: supermemory_store (сохранение явных воспоминаний), supermemory_search (семантический поиск по схожести), supermemory_forget (забывание по ID или наиболее подходящему запросу), supermemory_profile (постоянный профиль + недавний контекст)

Настройка:

hermes plugins install supermemory   # из каталога плагинов
hermes memory setup                  # выберите "supermemory"
# Или вручную:
hermes config set memory.provider supermemory
echo 'SUPERMEMORY_API_KEY=***' >> ~/.hermes/.env

Настройка self-hosted:

npx supermemory local

После hermes plugins install supermemory и перед запуском hermes memory setup пропишите base_url в $HERMES_HOME/supermemory.json:

{
  "base_url": "http://localhost:6767"
}

Затем выполните hermes memory setup и введите API-ключ, который напечатал локальный сервер. Если задать эндпоинт заранее, проверочное подключение при настройке тоже останется локальным.

Конфигурация: $HERMES_HOME/supermemory.json

Переменные окружения: SUPERMEMORY_API_KEY (обязательна), SUPERMEMORY_BASE_URL (запасной вариант совместимости, когда base_url не настроен), SUPERMEMORY_CONTAINER_TAG (переопределяет конфигурацию).

Порядок разрешения базового URL: supermemory.json → SUPERMEMORY_BASE_URL → https://api.supermemory.ai. Операции SDK и проверки при настройке и статусе используют один и тот же разрешённый эндпоинт.

Ключевые особенности:

• Автоматическое ограждение контекста (context fencing) — убирает извлечённые воспоминания из захватываемых ходов, чтобы предотвратить рекурсивное загрязнение памяти
• Захват ход за ходом — каждый завершённый ход записывается сразу, один документ на сессию за каждое 4-часовое окно
• Неудавшиеся записи ходов повторяются (at-least-once) на следующем ходу, при завершении сессии, /reset или выключении
• Сквозная маршрутизация на self-hosted — SDK и проверочные запросы идут на один и тот же настроенный эндпоинт
• Факты профиля внедряются на первом ходу и с настраиваемым интервалом
• Контейнеры в рамках профиля — используйте {identity} в container_tag (например, hermes-{identity} → hermes-coder), чтобы изолировать воспоминания по профилям Hermes
• Режим нескольких контейнеров — включите enable_custom_container_tags со списком custom_containers, чтобы разрешить агенту читать и писать в именованные контейнеры. Автоматические операции остаются в пределах основного контейнера.

{
  "container_tag": "hermes",
  "enable_custom_container_tags": true,
  "custom_containers": ["project-alpha", "shared-knowledge"],
  "custom_container_instructions": "Use project-alpha for coding context."
}

Поддержка: Discord · support@supermemory.com

Переход со встроенного Supermemory

Раньше Supermemory поставлялся внутри дерева Hermes (и как pip-extra hermes-agent[supermemory]). Если в вашем config.yaml уже стоит memory.provider: supermemory, большинству пользователей делать ничего не нужно:

• hermes update ставит плагин из каталога в домашний каталог каждого профиля, где указан этот провайдер (это срабатывает, даже когда security.allow_lazy_installs равен false).
• Если при первом запуске агента (hermes chat, шлюз, …) плагина всё ещё нет, Hermes ставит его и печатает ✓ Memory provider 'supermemory' moved out of core — installed its plugin from the catalog (your memory.supermemory settings and data are unchanged).
• При security.allow_lazy_installs: false путь запуска агента вместо этого пишет в лог одну строку — Memory provider 'supermemory' is not installed; security.allow_lazy_installs is off — run `hermes plugins install supermemory`. — и hermes plugins install supermemory вы выполняете сами.

Что меняется на диске: плагин появляется в ~/.hermes/plugins/supermemory/, а в config.yaml добавляется plugins.enabled: [supermemory]. SDK Supermemory ставится из метаданных пакета самого плагина, поэтому extra hermes-agent[supermemory] больше не нужен. memory.provider, $HERMES_HOME/supermemory.json, ключи SUPERMEMORY_* в .env и воспоминания в вашем аккаунте Supermemory не затрагиваются. Проверить можно через hermes memory status (провайдер активен) и hermes plugins list (плагин установлен и включён).

Memori

Структурированная долгосрочная память на базе Memori Cloud, с фоновым захватом завершённых ходов, контекстом хода с учётом использованных инструментов и явными инструментами извлечения для фактов, сводок, квоты, регистрации и обратной связи.

Инструменты: memori_recall (поиск по долгосрочной памяти), memori_recall_summary (сводный контекст), memori_quota (использование/квота), memori_signup (запрос письма для регистрации), memori_feedback (отправка отзыва об интеграции)

Настройка:

hermes-memori — внешняя интеграция, а не имя управляемого инструмента PM. Установите CLI в независимое окружение по инструкции его издателя. Прежде чем запускать его установщик, убедитесь, что он нацелен на нужный домашний каталог Hermes и ставит провайдер с объявленными Python-зависимостями. Не позволяйте внешнему установщику делать pip install в выбранное окружение Hermes. Одно лишь наличие CLI не делает Python-провайдер доступным внутри Hermes; дистрибутиву, в котором есть только точка входа, нужна сборка, которую поддерживает её владелец и в которой этот провайдер есть.

# Run only after confirming the external installer's integration contract above.
hermes-memori install
hermes config set memory.provider memori
hermes memory setup

Если установщик не поддерживает приём провайдера-каталога под управлением PM, попросите издателя добавить такую интеграцию, а не придумывайте команду hermes pm install для пакета. После успешной подготовки зависимостей перезапустите Hermes.

Сравнение провайдеров

Изоляция профилей

Данные каждого провайдера изолированы по профилям:

• Провайдеры с локальным хранением (Holographic, ByteRover) используют пути $HERMES_HOME/, которые различаются для каждого профиля
• Провайдеры с конфигурационными файлами (Honcho, Mem0, Hindsight, Supermemory) хранят конфигурацию в $HERMES_HOME/, поэтому у каждого профиля свои учётные данные
• Облачные провайдеры (RetainDB) автоматически выводят имена проектов в рамках профиля
• Провайдеры на переменных окружения (OpenViking) настраиваются через файл .env каждого профиля

Провайдеры переезжают в каталог плагинов

Провайдеры памяти переезжают из дерева Hermes в собственные репозитории своих мейнтейнеров и публикуются через каталог плагинов. Первым переехал Hindsight (см. Переход со встроенного Hindsight), затем Honcho (см. Обновление со встроенного Honcho), Supermemory (см. Переход со встроенного Supermemory), Mem0 (см. Переход со встроенного Mem0), OpenViking (см. Переход со встроенного OpenViking) и Holographic (теперь его поддерживает itpartypattaya, см. Переход со встроенного Holographic). RetainDB и ByteRover покидают ядро 15 октября 2026 года; их отдельные репозитории не поддерживаются и открыты для нового мейнтейнера. Для вас ничего не меняется: имя провайдера, настройки, которые он читает, его каталог данных и инструменты остаются прежними. Когда настроенный у вас провайдер перестаёт поставляться с Hermes, hermes update ставит его плагин из каталога для каждого профиля, где он указан; если вы обновляетесь через десктопное приложение, агент делает то же самое при первом запуске. Каждый исход показывается вам — в терминале, в Desktop или с первым ответом в мессенджере. Если установка невозможна (security.allow_lazy_installs: false, нет сети, отказ), предупреждение содержит точную команду hermes plugins install <name>.

Создание провайдера памяти

Как создать собственный провайдер — см. Руководство разработчика: плагины провайдеров памяти.