Сравнение провайдеров памяти агентов: политика захвата и self-hosting

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

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

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

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

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

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

Внешние зависимости. Каждый внешний поставщик, кроме Holographic, требует как минимум один вызов внешнего сервиса — LLM для извлечения памяти, модель эмбеддингов для семантического поиска или базу данных, такую как PostgreSQL, для хранения. Эти зависимости имеют прямые последствия для конфиденциальности, стоимости и того, может ли ваш стек памяти работать полностью самохостином (self-hosted). Hindsight, ByteRover и Mnemosyne объединяют или устраняют наибольшее количество зависимостей; Honcho, Mem0 и Supermemory требуют наибольшего количества движущихся частей. Там, где поставщик поддерживает Ollama или любой OpenAI-совместимый endpoint, вы можете направлять вызовы 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

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

Honcho работает параллельно с существующей памятью — USER.md остается как есть, и Honcho добавляет дополнительный слой контекста. Он моделирует разговоры как пиры, обменивающиеся сообщениями — один пользовательский пир плюс один ИИ-пир на профиль Hermes, все разделяющие workspace.

Внешние зависимости: Honcho требует LLM для суммаризации сессий, вывода пользовательского представления и диалектического рассуждения; модели эмбеддингов для семантического поиска по наблюдениям; PostgreSQL с расширением pgvector для векторного хранения; и Redis для кэширования. Управляемое облако на api.honcho.dev берет на себя все это за вас. Для самохостинг-развертываний (Docker, K3s или Fly.io) вы предоставляете собственные учетные данные. Слот LLM принимает любой OpenAI-совместимый endpoint, включая 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’): Время сброса (flush): async, turn, session или целое число N
• observationMode (по умолчанию ‘directional’): directional (все включены) или unified (общий пул)

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

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

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

Настройка:

hermes memory setup  # выбрать "honcho"
# или legacy: hermes honcho setup

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

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

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

OpenViking

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

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.

Память пользователя против памяти агента. Модель идентичности 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 преобразует разговорный материал в дискретные воспоминания и выполняет логику дедупликации и обновления. Это удобно, но это означает, что происхождение (provenance) извлечения важно — сгенерированный вывод ассистента может стать структурно неотличимым от факта, заявленного пользователем, если путь захвата не отфильтрует его до запуска извлечения.

Инструменты: 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-совместимый endpoint). Модель эмбеддингов и модель кросс-энкодерного реранкинга включены внутрь самого Hindsight — они выполняются локально внутри пакета hindsight-all и не требуют внешнего API. PostgreSQL также включен с встроенной установкой Python через управляемый каталог данных pg0; вы также можете указать Hindsight на внешний экземпляр PostgreSQL. Для полностью локальной, безоблачной конфигурации установите HINDSIGHT_API_LLM_PROVIDER=ollama и укажите локальную модель Ollama — retain и recall работают полностью; reflect требует модели, способной к tool-calling (например, 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

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

Holographic

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

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

Внешние зависимости: Отсутствуют. Holographic не требует LLM, модели эмбеддингов, базы данных или сетевого подключения. Кодирование памяти выполняется полностью через алгебру HRR, работающую в процессе. Это делает его уникальным среди всех поставщиков в этом сравнении — это единственный, который работает с нулевыми внешними вызовами. Обратной стороной является то, что качество поиска ниже, чем у семантического поиска на основе эмбеддингов, и нет кросс-памятного синтеза, похожего на reflect Hindsight. Для пользователей, для которых конфиденциальность и работа с нулевыми зависимостями являются негласным условием (non-negotiable), 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

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

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

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

Mnemosyne также реализует специфичные для поставщика стагированные записи (staged writes) для 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 предоставляет явные инструменты recall и recall-summary, позволяя агенту извлекать операционный контекст, когда он действительно это нужно, а не при каждом промпте. Это снижает загрязнение промпта, но само по себе не устраняет риск обратной записи на стороне записи — завершенные походы и трассировки выполнения все еще могут быть захвачены автоматически в фоне, поэтому Memori подходит пользователям, которые хотят, чтобы агент учился на предыдущей работе, более, чем установкам, требующим строгого явного-only хранения.

Настройка:

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

ByteRover

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

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

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

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

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

Настройка:

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

Supermemory

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

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

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

Текущая интеграция Hermes пишет полную сессию через endpoint разговора 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, а не рассматривать его как drop-in поставщика Hermes.
• AgentMemory делает акцент на исходных событиях, аудируемости и семантике удаления — актуально после проблем с осиротевшими производными записями, обсужденными для Mnemosyne выше.
• XMemo предоставляет консервативные значения по умолчанию: автоматический захват временной шкалы может оставаться выключенным, и удаление может быть ограничено. Принятие (adoption) все еще достаточно раннее, чтобы не оправдывать полную секцию.

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

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