Сравнение Agent Memory Providers: Honcho, Mem0, Hindsight и еще пять решений

Современные ассистенты по-прежнему все забывают, как только вы закрываете вкладку, если только что-то не сохраняется за пределами контекстного окна. Провайдеры памяти агентов (Agent memory providers) — это сервисы или библиотеки, которые хранят факты и резюме между сессиями. Зачастую они подключаются как плагины, чтобы фреймворк оставался легковесным, в то время как масштабируемость памяти росла.

В данном руководстве сравниваются восемь бэкендов, поставляемых в качестве внешних плагинов памяти для Hermes Agent — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover и Supermemory — и объясняется, как они вписываются в более широкие стеки AI systems. Те же вендоры встречаются в OpenClaw и других инструментах для агентов через комьюнити-интеграции или официальные плагины. AI Systems Memory hub перечисляет эту статью наряду с Cognee и сопутствующими руководствами.

Для ознакомления с ограниченной базовой памятью, специфичной для Hermes (MEMORY.md и USER.md), поведением заморозки и триггерами, обратитесь к Hermes Agent Memory System.

Hermes Agent предлагает восемь плагинов внешних провайдеров памяти для обеспечения устойчивых, межсессионных знаний. Одновременно может быть активен только один внешний провайдер. Встроенные файлы MEMORY.md и USER.md остаются загруженными вместе с ним — они дополняют, а не заменяют память.

Внешние зависимости. Каждый внешний провайдер, за исключением Holographic, требует как минимум одного внешнего вызова сервиса — LLM для извлечения памяти, модели эмбеддингов для семантического поиска или базы данных, такой как PostgreSQL, для хранения. Эти зависимости напрямую влияют на конфиденциальность, стоимость и возможность запуска вашего стека памяти в режиме self-hosted. Hindsight и ByteRover объединяют или сводят к минимуму количество зависимостей; Honcho, Mem0 и Supermemory требуют наибольшего количества компонентов. Если провайдер поддерживает Ollama или любой совместимый с OpenAI эндпоинт, вы можете направлять вызовы LLM и эмбеддингов на локальную модель, полностью удерживая данные вне сторонних серверов.

Активация с помощью Hermes Agent

hermes memory setup   # Интерактивный выбор + конфигурация
hermes memory status  # Проверка активных компонентов
hermes memory off     # Отключение внешнего провайдера

Или вручную в ~/.hermes/config.yaml:

memory:
  provider: openviking  # или honcho, mem0, hindsight, holographic, retaindb, byterover, supermemory

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

Подробный разбор

Honcho

Лучше всего подходит для: мультиагентных систем, межсессионного контекста, согласования пользователя и агента.

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

Внешние зависимости: Honcho требует LLM для суммаризации сессий, вывода представлений пользователя и диалектического рассуждения; модель эмбеддингов для семантического поиска по наблюдениям; PostgreSQL с расширением pgvector для векторного хранилища; и Redis для кэширования. Управляемое облако по адресу api.honcho.dev берет все это на себя. При самостоятельном развертывании (Docker, K3s или Fly.io) вы используете собственные учетные данные. Поле LLM принимает любой эндпоинт, совместимый с OpenAI, включая Ollama и vLLM, поэтому инференс может оставаться локальным. Поле эмбеддингов по умолчанию использует openai/text-embedding-3-small, но поддерживает настраиваемых провайдеров через LLM_EMBEDDING_API_KEY и LLM_EMBEDDING_BASE_URL — работает любой сервер эмбеддингов, совместимый с OpenAI, включая локальные варианты, такие как vLLM с моделью BGE.

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

Ключевые параметры конфигурации:

• contextCadence (по умолчанию 1): Минимальное количество ходов между обновлениями базового слоя.
• dialecticCadence (по умолчанию 2): Минимальное количество ходов между вызовами LLM peer.chat() (рекомендуется 1–5).
• dialecticDepth (по умолчанию 1): Количество проходов .chat() за один вызов (ограничено 1–3).
• recallMode (по умолчанию ‘hybrid’): hybrid (автоматически + инструменты), context (только вставка), tools (только инструменты).
• writeFrequency (по умолчанию ‘async’): Частота записи: async, turn (ход), session (сессия) или целое число N.
• observationMode (по умолчанию ‘directional’): directional (все включено) или unified (общий пул).

Архитектура: Двухуровневая инъекция контекста — базовый слой (резюме сессии + представление + карточка участника) + диалектическая добавка (рассуждения LLM). Автоматически выбирает промпты для холодного старта или прогретого контекста.

Картирование нескольких участников: Рабочее пространство является общей средой для всех профилей. Участник-пользователь (peerName) — это глобальная идентичность человека. Участник-AI (aiPeer) — один на каждый профиль Hermes (по умолчанию hermes, для остальных hermes.<profile>).

Настройка:

hermes memory setup  # выберите "honcho"
# или устаревший вариант: hermes honcho setup

Конфигурация: $HERMES_HOME/honcho.json (локально для профиля) или ~/.honcho/config.json (глобально).

Управление профилями:

hermes profile create coder --clone  # Создает hermes.coder с общим рабочим пространством
hermes honcho sync                   # Заполняет данные AI-участников для существующих профилей

OpenViking

Лучше всего подходит для: управления знаниями в режиме self-hosted с древовидным просмотром.

OpenViking предоставляет иерархию файловой системы с многоуровневой загрузкой. Он бесплатен, self-hosted и дает полный контроль над хранилищем вашей памяти.

Внешние зависимости: OpenViking требует VLM (зрительно-языковую модель) для семантической обработки и извлечения памяти, а также модель эмбеддингов для векторного поиска — оба компонента обязательны. Поддерживаемые провайдеры VLM включают OpenAI, Anthropic, DeepSeek, Gemini, Moonshot и vLLM (для локального развертывания). Для эмбеддингов поддерживаются OpenAI, Volcengine (Doubao), Jina, Voyage и — через Ollama — любая локально обслуживаемая модель эмбеддингов. Интерактивный мастер openviking-server init может определить доступную оперативную память и рекомендовать подходящие модели Ollama (например, Qwen3-Embedding 8B для эмбеддингов, Gemma 4 27B для VLM), а также автоматически настроить всё для полностью локальной работы без API-ключей. Внешняя база данных не требуется; OpenViking хранит память в файловой системе.

Инструменты: viking_search, viking_read (многоуровневое чтение), viking_browse, viking_remember, viking_add_resource.

Настройка:

pip install openviking
openviking-server init   # интерактивный мастер (рекомендует модели Ollama для локальной настройки)
openviking-server
hermes memory setup  # выберите "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

Лучше всего подходит для: автоматизированного управления памятью без лишних манипуляций.

Mem0 обрабатывает извлечение памяти на стороне сервера с помощью вызова LLM при каждой операции add — он читает разговор, извлекает отдельные факты, удаляет дубликаты и сохраняет их. Управляемый облачный API берет на себя всю инфраструктуру. Open-source библиотека и self-hosted сервер дают вам полный контроль.

Внешние зависимости: Mem0 требует LLM для извлечения памяти (по умолчанию: OpenAI gpt-4.1-nano; поддерживается 20 провайдеров, включая Ollama, vLLM и LM Studio для локальных моделей) и модель эмбеддингов для поиска (по умолчанию: OpenAI text-embedding-3-small; поддерживается 10 провайдеров, включая Ollama и HuggingFace для локальных моделей). Хранилище использует Qdrant в /tmp/qdrant в режиме библиотеки или PostgreSQL с pgvector в режиме self-hosted сервера — оба варианта могут работать локально. Можно создать полностью локальный стек Mem0 без облака: Ollama для LLM, Ollama для эмбеддингов и локальный экземпляр Qdrant, всё настраивается через Memory.from_config.

Инструменты: mem0_profile, mem0_search, mem0_conclude.

Настройка:

pip install mem0ai
hermes memory setup  # выберите "mem0"
echo "MEM0_API_KEY=your-key" >> ~/.hermes/.env

Конфигурация: $HERMES_HOME/mem0.json (user_id: hermes-user, agent_id: hermes).

Hindsight

Лучше всего подходит для: поиска на основе графа знаний с учетом связей между сущностями.

Hindsight строит граф знаний вашей памяти, извлекая сущности и отношения. Его уникальный инструмент reflect выполняет синтез между различными областями памяти — объединяя несколько воспоминаний в новые идеи. Поиск запускает четыре стратегии извлечения параллельно (семантическая, ключевые слова/BM25, обход графа, временная), а затем объединяет и переупорядочивает результаты, используя метод reciprocal rank fusion.

Внешние зависимости: Hindsight требует LLM для извлечения фактов и сущностей при вызовах retain, а также для синтеза при вызовах reflect (по умолчанию: OpenAI; поддерживаются Anthropic, Gemini, Groq, Ollama, LM Studio и любые совместимые с OpenAI эндпоинты). Модель эмбеддингов и модель переранжирования (cross-encoder) встроены в сам Hindsight — они работают локально внутри пакета hindsight-all и не требуют внешнего API. PostgreSQL также поставляется вместе с встроенной установкой Python через управляемую директорию данных pg0; вы также можете указать Hindsight на внешний экземпляр PostgreSQL. Для полностью локальной настройки без облака установите HINDSIGHT_API_LLM_PROVIDER=ollama и укажите локальную модель Ollama — retain и recall будут работать полностью; для reflect потребуется модель, поддерживающая вызов инструментов (например, qwen3:8b).

Инструменты: hindsight_retain, hindsight_recall, hindsight_reflect (уникальный межпамятевый синтез).

Настройка:

hermes memory setup  # выберите "hindsight"
echo "HINDSIGHT_API_KEY=your-key" >> ~/.hermes/.env

Автоматически устанавливает hindsight-client (облако) или hindsight-all (локально). Требуется версия >= 0.4.22.

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

• mode: cloud или local
• recall_budget: low / mid / high
• memory_mode: hybrid / context / tools
• auto_retain / auto_recall: true (по умолчанию)

Локальный UI: hindsight-embed -p hermes ui start

Holographic

Лучше всего подходит для: настроек, ориентированных на приватность, с исключительно локальным хранилищем.

Holographic использует алгебру HRR (Holographic Reduced Representation) для кодирования памяти с оценкой доверия для проверки надежности данных. Никаких облачных зависимостей — всё работает локально на вашем оборудовании.

Внешние зависимости: Нет. Holographic не требует ни LLM, ни модели эмбеддингов, ни базы данных, ни сетевого подключения. Кодирование памяти происходит полностью через алгебру HRR внутри процесса. Это делает его уникальным среди всех восьми провайдеров — это единственный провайдер, работающий с нулевым количеством внешних вызовов. Обратной стороной является то, что качество поиска ниже, чем у семантического поиска на основе эмбеддингов, и отсутствует межпамятевый синтез, как в reflect у Hindsight. Для пользователей, для которых конфиденциальность и работа без зависимостей не обсуждаются, Holographic — единственный вариант, предоставляющий это безусловно.

Инструменты: 2 инструмента для операций с памятью через алгебру HRR.

Настройка:

hermes memory setup  # выберите "holographic"

RetainDB

Лучше всего подходит для: высокочастотных обновлений с дельта-компрессией.

RetainDB использует дельта-компрессию для эффективного хранения обновлений памяти и гибридный поиск (векторный + BM25 + переранжирование) для предоставления релевантного контекста. Это облачный сервис стоимостью $20 в месяц, где вся обработка памяти происходит на стороне сервера.

Внешние зависимости: Вызовы LLM, конвейер эмбеддингов и переранжирование в RetainDB работают на собственной облачной инфраструктуре RetainDB — вы предоставляете только RETAINDB_KEY. Извлечение памяти использует Claude Sonnet на стороне сервера. Вариант self-hosting или локальный режим отсутствуют. Все данные разговоров отправляются на серверы RetainDB для обработки и хранения. Если суверенитет данных или автономная работа важны для вашего случая использования, этот провайдер не подходит.

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

Настройка:

hermes memory setup  # выберите "retaindb"

ByteRover

Лучше всего подходит для: памяти по принципу local-first с человекочитаемым и проверяемым хранилищем.

ByteRover хранит память в виде структурированного контекстного дерева Markdown — иерархии файлов доменов, тем и подтем — вместо векторов эмбеддингов или базы данных. LLM читает исходный контент, рассуждает о нем и помещает извлеченные знания в нужное место в иерархии. Поиск осуществляется с помощью полнотекстового поиска MiniSearch с многоуровневым переходом к поиску на базе LLM; база данных векторов не требуется.

Внешние зависимости: ByteRover требует LLM для курирования памяти и поиска (поддерживается 18 провайдеров, включая Anthropic, OpenAI, Google, Ollama и любой совместимый с OpenAI эндпоинт через слот openai-compatible). Ему не требуется модель эмбеддингов или база данных — контекстное дерево представляет собой локальную директорию с обычными markdown-файлами. Облачная синхронизация опциональна и используется только для командной работы; по умолчанию всё работает полностью автономно. Для полностью автономной локальной настройки подключите Ollama в качестве провайдера (brv providers connect openai-compatible --base-url http://localhost:11434/v1), и никакие данные не покинут вашу машину.

Инструменты: 3 инструмента для операций с памятью.

Настройка:

hermes memory setup  # выберите "byterover"

Supermemory

Лучше всего подходит для: корпоративных рабочих процессов с контекстным ограждением и импортом графов сессий.

Supermemory обеспечивает контекстное ограждение (изоляцию памяти по контексту) и импорт графа сессий (импорт всей истории разговоров). Он автоматически извлекает воспоминания, строит профили пользователей и запускает гибридный поиск, сочетающий семантический и ключевой поиск. Основной целью развертывания является управляемый облачный API.

Внешние зависимости: Облачный сервис Supermemory обрабатывает все вызовы LLM и эмбеддинги на стороне сервера — вы предоставляете только API-ключ Supermemory. Self-hosting доступен исключительно как дополнение к Enterprise-плану и развертывается в Cloudflare Workers; он требует наличия PostgreSQL с расширением pgvector (для векторного хранилища) и API-ключа OpenAI (обязательно, с необязательной поддержкой Anthropic и Gemini). Пути для локального или Docker-развертывания не существует — архитектура тесно связана с edge-вычислениями Cloudflare Workers. Для пользователей, которым нужен полный суверенитет данных без корпоративного контракта, этот провайдер не является подходящим выбором.

Инструменты: 4 инструмента для операций с памятью.

Настройка:

hermes memory setup  # выберите "supermemory"

Как выбрать

• Нужна поддержка мультиагентов? Honcho
• Хотите self-hosted и бесплатно? OpenViking или Holographic
• Нужна нулевая конфигурация? Mem0
• Хотите графы знаний? Hindsight
• Нужна дельта-компрессия? RetainDB
• Нужна эффективность трафика? ByteRover
• Нужны корпоративные функции? Supermemory
• Нужна приватность (только локально)? Holographic
• Нужно полностью локально без внешних сервисов? Holographic (вообще без зависимостей) или Hindsight/Mem0/ByteRover с Ollama
• Нужна человекочитаемая, проверяемая память без конвейера эмбеддингов? ByteRover

Для получения полных конфигураций провайдеров для каждого профиля и паттернов рабочих процессов в реальных условиях см. Hermes Agent production setup.

Связанные руководства

• AI Systems Memory hub — охват данного подкластера и ссылки на руководства Cognee
• Hermes Agent Memory System — основная двухфайловая память перед подключением плагинов
• Hermes Agent production setup — привязка профилей провайдеров на практике