Сравнение провайдеров памяти для агентов: политика захвата данных и самостоятельное развёртывание

Обновлено в сентябре 2026 года: добавлены Mnemosyne и Memori, расширены настройки Honcho и Hindsight, а также добавлено сравнение политик фиксации данных (capture policy) наряду с исходной таблицей инфраструктуры.

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

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

Для специфичного для Hermes ограниченной ядровой памяти (MEMORY.md и USER.md), поведения замораживания и триггеров см. Систему памяти Hermes Agent. Подключение провайдеров — это один уровень более широкой иерархии знаний агента — файлы идентичности, резидентная память, навыки, вики и банки памяти, каждый со своим триггером инъекции, — отображенной в Иерархический контекст: иерархия знаний для ИИ-агентов. Для контекста о том, как нативные провайдеры памяти Hermes способствуют растущему преимуществу его внедрения перед OpenClaw — включая звёзды на GitHub, рейтинги токенов OpenRouter и сравнения размеров экосистем — см. OpenClaw vs Hermes Agent: звёзды, загрузки и использование 2026.

Существует другая ось, важность которой не уступает качеству извлечения: управление памятью (memory governance). Провайдеры кардинально различаются в том, что они автоматически фиксируют, может ли сгенерированный ассистентом вывод стать долговременной памятью, сохраняются ли размышления в качестве фактов, как разрешаются противоречия и может ли человек просмотреть запись перед тем, как она станет будущим контекстом. Для агентов с длительным временем работы эти различия могут иметь большее значение, чем ещё несколько пунктов на бенчмарке извлечения воспоминаний — см. Самоусиляющиеся циклы памяти в ИИ-агентах о том, почему автоматическая фиксация может превратить сгенерированный вывод в будущую посылку, и Mnemosyne для Hermes Agent: быстрое начало с локальной памятью в качестве примера консервативной конфигурации.

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

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

Активация с Hermes Agent

Командные шаги ниже отражают таблицы в шпаргалке CLI для Hermes Agent.

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

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

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

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

Политика фиксации и управление

Хранилище и зависимости отвечают на вопрос «могу ли я это запустить?». Таблица ниже отвечает на другой вопрос, который имеет не меньшее значение для агентов с длительным временем работы: что записывается без запроса и может ли человек или политика вмешаться до того, как это станет долговременным? См. Самоусиляющиеся циклы памяти в ИИ-агентах о том, почему эта ось важна.

Это архитектурные категории риска, а не баллы качества — тщательно настроенный сложный провайдер на практике может быть безопаснее, чем плохо настроенный простой.

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

Honcho

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

Honcho работает наряду с существующей памятью — USER.md остается без изменений, и Honcho добавляет дополнительный слой контекста. Он моделирует разговоры как обмены сообщениями между равными (пиров) — один пользовательский пир плюс один ИИ-пир на каждый профиль 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 (общий пул)

Режимы наблюдения и само-моделирование. directional, значение по умолчанию для новых конфигураций, позволяет и пользователям, и ИИ-пирам наблюдать за собой и друг другом — более богатое диалектическое рассуждение, но это также означает, что сообщения, авторами которых является ИИ, вносят вклад в модель самого ИИ в Honcho. unified — более консервативный вариант: ИИ моделирует пользователя из сообщений пользователя, не создавая соответствующий цикл само-наблюдения из своего собственного вывода. Любому, кто конкретно беспокоится о том, что сгенерированные выводы попадают обратно в будущее рассуждение — см. Самоусиляющиеся циклы памяти в ИИ-агентах — следует рассматривать unified как более безопасное значение по умолчанию.

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

Маппинг мульти-пиров: Рабочее пространство — это общая среда между профилями. Пользовательский пир (peerName) — это глобальная человеческая идентичность. ИИ-пир (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                   # Дополняет ИИ-пиров для существующих профилей

OpenViking

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

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

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

Инструменты: viking_search, viking_read (поэтапно), viking_browse, viking_remember, viking_add_resource.

Память пользователя vs память агента. Модель идентичности OpenViking может разделять пространство имен памяти пользователя от опционального ассистентского пира. Это разделение важно для гигиены памяти: факты о пользователе и опыт, сгенерированный агентом, не должны разделять одну и ту же политику удержания, что является полезным свойством, если вы хотите изолировать состояние, созданное ассистентом, от состояния, созданного пользователем.

Установка:

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 обрабатывает всю инфраструктуру. Библиотека с открытым исходным кодом и самохостинговый сервер предоставляют полный контроль.

Внешние зависимости: 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 в режиме самохостингового сервера — оба могут работать локально. Полностью локальный, нулевой облачный стеック Mem0 достижим: Ollama для LLM, Ollama для эмбеддингов и локальный экземпляр Qdrant, все настроено через Memory.from_config.

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

Инструменты: 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, обход графа, временная), затем объединяет и пересортировывает результаты с использованием взаимного рангового слияния.

Внешние зависимости: Hindsight требует LLM для извлечения фактов и сущностей при вызовах retain, а также для синтеза при вызовах reflect (по умолчанию: OpenAI; поддерживаемые провайдеры включают Anthropic, Gemini, Groq, Ollama, LM Studio и любой OpenAI-совместимый эндпоинт). Эмбеддинги и реранкинг по умолчанию используют локальные модели в процессе (SentenceTransformers; жирный Docker/образ hindsight-all включает BGE + MiniLM), и вы можете заменить их на другие локальные модели или внешний OpenAI-совместимый / TEI эндпоинт — например, Qwen3-Embedding-0.6B и BGE-reranker-v2-m3 на CPU. PostgreSQL включен через управляемую директорию данных pg0, или вы можете указать Hindsight на внешний экземпляр PostgreSQL. Для полностью локального генеративного пути установите HINDSIGHT_API_LLM_PROVIDER на локальный OpenAI-совместимый сервер (Ollama или llama.cpp); retain и recall работают полностью, а reflect требует модели с поддержкой вызова инструментов.

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

Установка:

hermes plugins install hindsight
hermes memory setup hindsight   # выбрать local_external для отдельного Hindsight API

Облачной режим по-прежнему принимает API-ключ в ~/.hermes/.env. Самохостинговая установка использует Docker Compose против встроенного или существующего PostgreSQL — см. пошаговое руководство, связанное ниже. Требуется текущая пара клиента/API Hindsight (документация плагина указывает >= 0.4.22).

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

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

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

Для полного пошагового руководства по самохостингу — Docker Compose, локальные эмбеддинги и реранкинг, управление путём записи (auto_retain) и подключение local_external Hermes — см. Hindsight для Hermes Agent: самохостинговая память с локальными LLM. OpenCode, CLI Cursor и другие кодинг-обвязки используют другой пакет, с банком на репозиторий: Память Hindsight для OpenCode, Cursor и других кодинг-агентов.

Для консервативной гигиены памяти стоит рассмотреть настройку auto_retain=false, оставив auto_recall=true — семантическое извлечение остается доступным, но завершенные ходы больше не попадают в долговременную память автоматически. Рассматривайте вывод reflect как произведенное знание, синтезированное через воспоминания, а не как независимое наблюдение с той же доказательной силой, что и воспоминания, из которых он был построен.

Holographic

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

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

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

auto_extract по умолчанию установлено в false, поэтому Holographic может работать преимущественно как небольшая явная база данных фактов с оценками доверия, а не как автономный конвейер из транскрипта в память. В сочетании с нулевыми зависимостями, это делает его одним из двух самых простых вариантов — наряду с Mnemosyne — для читателей, которые намеренно не хотят автоматической фиксации.

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

Установка:

hermes memory setup  # выбрать "holographic"

RetainDB

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

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

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

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

Интеграция RetainDB с Hermes выросла за пределы удаленной базы данных памяти — она теперь включает диалектический синтез и само-модель агента, что архитектурно приближает ее к Honcho, а не к простому векторному хранилищу. Это полезно для непрерывности, но также повышает важность разделения исходных фактов от сгенерированной интерпретации, та же обеспокоенность, что и с режимом directional в Honcho.

Установка:

hermes memory setup  # выбрать "retaindb"

Mnemosyne

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

Mnemosyne не является одним из оригинальных связанных провайдеров памяти Hermes — он поставляется как отдельный плагин провайдера Hermes, но интегрируется через тот же интерфейс MemoryProvider. Его главное преимущество — контроль: автоматическое сохранение разговоров может быть ограничено по ролям или полностью отключено с sync_roles: [], логирование результатов инструментов отключено по умолчанию, явные операции remember/recall/forget остаются доступными независимо, а более новые версии включают опциональное подавление само-эха вокруг границ сжатия контекста.

Внешние зависимости: Нет для установки core; дополнительный пакет embeddings добавляет локальный векторный поиск. Хранилище — локальный SQLite с FTS5 и опциональным векторным извлечением. Система также поддерживает рабочую память, эпизодическую память, структурированные факты, временные тройки, канонические факты и консолидацию.

Mnemosyne также реализует специфичные для провайдера пофазовые записи для memory.write_approval Hermes, хотя одобрение внешних провайдеров еще не стандартизировано через Hermes, поэтому этот путь следует тестировать против точных версий, которые разворачиваются. Дополнительная изощренность имеет цену: производственная память создает больше жизненных состояний для инспекции и очистки. Недавние релизы Mnemosyne конкретно ужесточили валидацию конфликтов, поведение удаления и обработку само-эха — см. Самоусиляющиеся циклы памяти в ИИ-агентах для аудита производства, который мотивировал изменение валидации конфликтов.

Установка:

python -m pip install "mnemosyne-memory[embeddings]" mnemosyne-hermes
mnemosyne-hermes install
hermes config set memory.provider mnemosyne

Для полной установки и обзора консервативной конфигурации, см. Mnemosyne для Hermes Agent: быстрое начало с локальной памятью.

Memori

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

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

В отличие от провайдеров, которые преимущественно инжектируют большой блок памяти перед каждым ходом, Memori exposes явные инструменты recall и recall-summary, позволяя агенту извлекать операционный контекст, когда ему это действительно нужно, а не при каждом промпте. Это снижает загрязнение промпта, но не устраняет риск обратной связи на стороне записи только по себе — завершенные ходы и следы выполнения по-прежнему могут фиксироваться автоматически на заднем плане, поэтому Memori подходит пользователям, которые хотят, чтобы агент учился из предыдущей работы, больше, чем он подходит установкам, требующим строгого явного-только удержания.

Установка:

pip install hermes-memori
hermes memory setup  # выбрать "memori"

ByteRover

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

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) и данные не покинут вашу машину.

Hermes обеспечивает auto_extract: false для отключения автоматических хуков курации, что помещает ByteRover в группу провайдеров рядом с Holographic и Mnemosyne, где автоматическая фиксация является опциональной, а не значением по умолчанию.

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

Установка:

hermes memory setup  # выбрать "byterover"

Supermemory

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

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

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

Текущая интеграция Hermes пишет полную сессию через разговорный эндпоинт Supermemory как единицу, буферизуя разговор и импортируя его в конце сессии, при сбросе или сжатии. Это производит более богатый контекст сущностей и профилей, чем изолированные записи фактов, но это также означает, что сгенерированный ассистентом текст является частью материала, представленного конвейеру извлечения памяти, а не только заявлениями пользователя.

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

Установка:

hermes memory setup  # выбрать "supermemory"

Как выбрать

Вместо выбора одного глобального победителя, сопоставьте провайдера с задачей:

• Самая простая локальная явная память: Holographic — нулевые зависимости, auto_extract отключено по умолчанию
• Локальная память с более богатым управлением жизненным циклом: Mnemosyne — SQLite, гранулярное удержание, подавление само-эха
• Синтез на основе графа: Hindsight — граф знаний плюс reflect
• Моделирование пира или пользователя: Honcho — диалектическое рассуждение, режим unified для консервативного само-моделирования
• Знания в стиле файловой системы: OpenViking — поэтапная иерархия viking://
• Автоматическое извлечение без вмешательства: Mem0 — извлечение фактов на основе LLM без конфигурации
• Операционная/инструмент-ориентированная память: Memori — фиксация ходов и следов выполнения
• Читаемое человеком, аудируемое, без конвейера эмбеддингов: ByteRover — обычное markdown-контекстное дерево
• Корпоративное ограждение контекста: Supermemory — импорт графа сессий, размещенный на Cloudflare
• Частые обновления, самохостинг не требуется: RetainDB — дельта-сжатие, диалектическая само-модель

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

Более широкая экосистема сторонней памяти Hermes

Hermes документирует интерфейс пакета/плагина для внешних провайдеров памяти, включая каталоги, установленные пользователем, и точки входа Python, поэтому экосистема теперь расширяется за пределы провайдеров с полными разделами выше. Несколько заслуживают внимания без добавления полного раздела каждый:

• Scope Recall рассматривает SQLite как долговременную истину, сохраняя фиксацию сырого разговора отдельно в рамках, с опциональным компаньоном turn-closure-audit для консервативного обзора после хода — он разделяет сырые журнальные доказательства от долговременной семантической памяти, а не рассматривает каждый зафиксированный ход как немедленно эквивалентное долговременное знание.
• Cognee — это конвейер импорта графа знаний / ECL, а не плагин разговорной памяти Hermes. Он преуспевает в структурированной проектной или институциональной памяти, но является более автоматическим, чем явное хранилище фактов; см. быстрое начало Самохостинга Cognee и Выбор правильного LLM для Cognee вместо того, чтобы рассматривать его как провайдер Hermes, устанавливаемый «как есть».
• AgentMemory акцентирует события источника, аудируемость и семантику удаления — релевантно после проблем с осиротевшими производными записями, обсужденными выше для Mnemosyne.
• XMemo поставляется с консервативными значениями по умолчанию: автоматическая фиксация временной линии может оставаться отключенной, и удаление может быть ограничено. Внедрение все еще достаточно рано, чтобы не оправдывать полный раздел.

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

• Хаб памяти ИИ-систем — охват этого подкластера и ссылки на руководства Cognee
• Самоусиляющиеся циклы памяти в ИИ-агентах — почему политика фиксации и шлюзы одобрения важны, подробно
• Mnemosyne для Hermes Agent: быстрое начало с локальной памятью — полная установка и консервативная конфигурация для провайдера Mnemosyne, рассмотренного выше
• Система памяти Hermes Agent — основная память из двух файлов перед плагинами
• Боевое развертывание Hermes Agent — подключение провайдеров по профилям на практике