Большинство AI-чатов, которыми ты пользовался, на самом деле не имеют памяти. У них есть контекстное окно — а это совсем другая вещь. Всё, что ты сказал раньше в рамках текущего разговора, модель ещё видит. Всё, что ты сказал вчера, — исчезло. На следующий день начинаешь с нуля, и ассистент заново представляется как незнакомец.
Hermes Agent устроен иначе. У него есть настоящий слой памяти — отдельный от контекста разговора — который со временем запоминает вещи о тебе, переносит их между сессиями и платформами и заставляет бота вести себя как один и тот же персонаж при каждом разговоре. Этот пост — о том, как это работает на самом деле, какие решения важны, и что изменил подключаемый интерфейс памяти в v0.7.0.
Краткосрочная память vs долговременная память
Сначала — разграничение, которое имеет значение.
Краткосрочная память в Hermes — это контекстное окно текущей сессии. Это фрагмент истории разговора, которую агент ведёт прямо сейчас, управляемый стратегией проактивного сжатия: когда контекст приближается к лимиту модели, Hermes прогоняет проход суммаризации — старые реплики сворачиваются в структурированное резюме, а последние обмены сохраняются дословно. Сжатие подкручивали от версии к версии — структурированные саммари с итеративным обновлением в v0.4.0, защита хвоста по token-бюджету, настраиваемый эндпоинт суммаризации, поддержка fallback-модели. В длинных разговорах это тихо держит агента быстрым и дешёвым, не теряя важный контекст.
Долговременная память — вот где интересное. Это хранилище фактов, предпочтений, поправок и пользовательских моделей, живущее за пределами разговора. Ты сегодня говоришь боту в Telegram: «меня зовут Алиса» — факт записывается в долговременную память. Завтра ты спрашиваешь что-то через Slack — факт достаётся и впрыскивается в контекст до того, как агент увидит твоё сообщение. Модель по-прежнему получает только то, что влезает в окно, но окно уже подготовлено тем, что она должна знать о тебе.
Краткосрочная память — это буфер. Долговременная память — это личность.
Honcho: что это и почему важно
Провайдер долговременной памяти в Hermes по умолчанию — Honcho, библиотека, построенная специально для AI-нативной памяти. Задача Honcho — работать за спиной агента и делать три конкретные вещи:
- 1.Наблюдать. Каждое сообщение пользователя и каждый ответ агента поступают в Honcho как поток событий. Honcho строит внутреннюю модель пользователя из этого потока — не сырую историю чата, а структурированные факты и предпочтения, выведенные из разговора.
- 2.Рассуждать о пользователе. Honcho гоняет небольшой «диалектический» слой, который пытается собрать связную картину того, кто ты, чего хочешь и что поправлял. Это не извлечение ключевых слов — это работающая ментальная модель пользователя.
- 3.Впрыскивать. На каждом новом ходе Honcho генерирует короткий фрагмент контекста, суммирующий то, что, по его мнению, о тебе важно. Hermes подставляет его к системному промпту. Фрагмент меняется по мере того, как Honcho узнаёт больше.
Два момента стоит выделить — их легко пропустить.
Во-первых, запись в Honcho — асинхронная. Агент не блокируется на записи в память. Он отвечает, а слой памяти обрабатывает обмен в фоне. Это значит, что длинные разговоры не платят «налог на задержку» за обновления памяти, а падение бэкенда памяти не останавливает бота — теряются обновления за время простоя, но ассистент продолжает отвечать.
Во-вторых, результат recall Honcho намеренно вынесен за пределы кэшируемого системного префикса. Функция prompt caching у Anthropic (активно используется с моделями вроде Claude Sonnet 4.6) требует, чтобы системный промпт был стабильным между ходами — тогда кэш попадает. Фрагмент от Honcho меняется каждый ход, поэтому Hermes добавляет его после кэшируемой системной секции. Статические части пользуются кэшем, динамический слой памяти — своим. Это из тех механических компромиссов, которые не попадают в release notes, но решают, будет ли твой ежемесячный счёт $50 или $500.
Многопользовательская изоляция в gateway-режиме
По умолчанию шлюз Hermes пропускает нескольких пользователей через один процесс агента. Долговременная память должна быть per-user, иначе аллергии Алисы окажутся в кулинарных рекомендациях для Боба. В v0.3.0 добавили нормальную многопользовательскую изоляцию Honcho внутри шлюза, что на практике означает:
- •Каждый user ID шлюза маппится на отдельный Honcho peer, и записи в память скоупятся per-peer.
- •Сессии групповых чатов по умолчанию наследуют per-user сессии — общий канал пишет отдельные потоки памяти для каждого участника.
- •Изоляция памяти по профилям (v0.5.0/v0.6.0): если ты запускаешь несколько профилей Hermes на одной машине, память каждого профиля — отдельная вселенная. Смена профиля не протекает из одной персоны в другую.
Ничего из этого не видно пользователям. Всё это — причина, по которой бот не путает одного человека с другим.
Подключаемый интерфейс памяти (v0.7.0)
Первые пять релизов Hermes Honcho был вшит намертво. В v0.7.0 слой памяти рефакторнули в нормальный провайдерный интерфейс — небольшой Python ABC, который может реализовать любой бэкенд памяти. Архитектурно изменение скромное, а практически — огромное.
Интерфейс позволяет менять бэкенды памяти, не трогая ядро Hermes:
- •Honcho — эталонный провайдер (и всё ещё по умолчанию). Полнофункциональный, строит реальную модель пользователя, корректно изолирует per-user.
- •Supermemory добавили в v0.8.0 как второй first-class провайдер — с поддержкой нескольких контейнеров, настраиваемыми режимами поиска и шаблонами идентификации.
- •mem0, OpenViking, RetainDB, Hindsight и ByteRover — всё это community-плагины памяти в системе плагинов Hermes, с разной глубиной интеграции.
- •Можно написать свой. ABC маленький: реализуй
write(),recall(), пару lifecycle-хуков — и зарегистрируй как плагин.
Встроенный провайдер памяти — дефолт без зависимостей, если ты больше ничего не настраивал — это хранилище фактов на SQLite. Базовый набор: запись фактов, извлечение по релевантности, скоупинг по пользователю. Не такой умный, как Honcho, зато не нужен внешний сервис, и для персонального ассистента на VPS за $5 этого часто хватает.
Тихая штука, которую это открывает
Подключаемая память — из тех архитектурных изменений, которые в release notes выглядят как хозяйственная работа. «Рефакторнули память в провайдерный интерфейс» — не заголовок. А на деле это отвязывает вопрос «что AI-ассистент должен помнить о тебе» от вопроса «как устроен Hermes».
Теперь можно заменить Honcho на бэкенд памяти, заточенный под твой сценарий: vector store для тех, кому нужен семантический поиск по личной базе знаний; graph database для тех, кто хочет явные связи между сущностями; чисто локальный SQLite для тех, кто не хочет, чтобы данные памяти покидали машину; корпоративный сервис памяти для команд. Агент не меняется. Меняется только то, что стоит за интерфейсом memory.
Это правильная абстракция для проекта, который хочет жить не один год. Память — вещь личная, и правильный бэкенд для тебя — необязательно правильный для кого-то другого. Работа Hermes — быть хорошим соседом для любого слоя памяти, который ты подключишь, и не мешать ему.