Система памяти агента Hermes: как на самом деле работает постоянная память ИИ

Вам знакомо это чувство. Вы открываете чат с ИИ-агентом, объясняете ему свой проект, делитесь предпочтениями, получаете результат и закрываете вкладку. Возвращаетесь через неделю — и оказывается, что вы общаетесь с незнакомцем: весь контекст потерян, все предпочтения забыты, проект приходится объяснять заново.

Это не ошибка. Так работают модели больших языковых языков (LLM) по своей конструкции. Они безсостоятельны (stateless): каждый запрос независим, каждый ответ генерируется на основе того промпта, который вы отправляете прямо сейчас, без памяти, без истории и без непрерывности за пределами токенов в текущем окне контекста.

Для одношаговых взаимодействий это нормально. Задайте вопрос, получите ответ, переходите дальше. Но для агентов — систем, которые должны выполнять задачи между сессиями, учиться на ошибках и развиваться вместе с вами, — безсостоятельность является жестким архитектурным ограничением. Это одна из центральных нерешенных проблем в самохостинговых системах ИИ.

Отрасля пыталась решить эту проблему. LangChain добавил модули памяти. OpenAI представила ассистентов с потоками (threads). Фреймворки вроде Letta, Zep и Cognee построили целые архитектуры вокруг персистентной памяти. Databricks опубликовали исследование по «масштабированию памяти» — идею о том, что производительность агентов улучшается с накоплением опыта. С 2024 года появились специализированные бенчмарки, обзоры эпизодической памяти и быстро растущая экосистема инструментов, призванных решить то, что все чаще признается одной из центральных нерешенных проблем в агентном ИИ.

Большинство этих подходов разделяют общую проблему: они рассматривают память как нечто вторичное — как базу данных для запросов, как окно контекста, которое нужно «запихнуть», как систему поиска, добавляющую задержку и шум вместо ясности.

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

В этой статье подробно объясняется, как это работает.

Часть 1: Проблема памяти ИИ-агента

Почему «просто добавить контекст» не масштабируется для агентов

Очевидным решением проблемы безсостоятельности ИИ является добавление контекста. Прикрепите предыдущий разговор. Включите документацию проекта. Отправьте всю историю.

Некоторое время это работает. У вас есть окно контекста на 128K токенов. В него можно поместить много текста.

Но контекст — это не память, между ними есть реальное и важное различие. Контекст — это все, что вам показывают прямо сейчас; память — это то, что вы активно сохраняете и передаете дальше.

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

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

Человеческая память работает так же. Вы не помните каждый разговор, который когда-либо вели. Вы помните то, что важно: с кем вы говорите, что их волнует, о чем вы договорились, чему вы научились. Остальное либо забывается, либо доступно для поиска, когда это необходимо.

Исследовательский ландшафт

Пространство памяти ИИ-агентов взорвалось после 2024 года, появились специализированные наборы бенчмарков, растет исследовательская литература, и наблюдается измеримый разрыв в производительности между разными архитектурными подходами. Вот как обстоят дела.

Letta (ранее MemGPT) был одним из первых фреймворков, рассматривающих персистентную память как первоклассную проблему, достигнув 21,7K звезд на GitHub. Он использует трехуровневую модель, вдохновленную ОС: основная память (маленькая, всегда в контексте), память воспоминаний (поисковая история разговоров) и архивная память (долгосрочное холодное хранилище). Инсайт о том, что не вся память одинакова, был верным. Однако реализация требует, чтобы агенты работали полностью внутри рантайма Letta — его внедрение означает принятие всей платформы, а не только слоя памяти.

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

Cognee построен для извлечения знаний из документов и структурированных данных, имеет более 30 коннекторов для импорта и бэкенд графа знаний. Он excels в институциональных знаниях и RAG-конвейерах, но менее сосредоточен на личной памяти агента. См. самохостинг Cognee с локальными LLM для практического руководства по настройке.

Hindsight использует поиск на основе графа знаний с отношениями сущностей и уникальный инструмент reflect синтеза, который выполняет кросс-памятный синтез — объединяя несколько воспоминаний в новые инсайты. Он входит в число лучших результатов на бенчмарках памяти агентов и доступен как провайдер памяти для Hermes Agent.

Mem0 обрабатывает извлечение памяти на стороне сервера через анализ LLM, требуя минимальной конфигурации. Исследовательская статья Mem0, опубликованная на ECAI 2025 (arXiv:2504.19413), протестировала десять различных подходов к памяти ИИ и валидировала подход селективного извлечения — хранение дискретных фактов, дедупликацию и извлечение только релевантного. Mem0 вырос до примерно 48K звезд на GitHub и поддерживает интеграцию с 21 фреймворком. Компромисс заключается в зависимости от облака и стоимости.

Исследования по масштабированию памяти Databricks ввели концепцию того, что производительность агентов улучшается с накопленным опытом. Их архитектура содержит системные промпты, корпоративные активы и эпизодическую/семантическую память, ограниченные на уровне организации и пользователя, подтверждая идею о том, что качество памяти так же важно, как и возможности модели.

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

Часть 2: Архитектура — Два файла, один мозг

Встроенная система памяти Hermes Agent существует в двух файлах.

• ~/.hermes/memories/MEMORY.md — Личные заметки агента (2200 символов, ~800 токенов)
• ~/.hermes/memories/USER.md — Профиль пользователя (1375 символов, ~500 токенов)

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

MEMORY.md: Заметки агента

Здесь агент хранит все, чему он научился об окружающей среде, проекте, инструментах, соглашениях и уроках. Вот как это выглядит:

Проект пользователя — это микросервис на Go по пути ~/code/gateway с использованием gRPC + PostgreSQL
Этот компьютер работает под управлением Ubuntu 22.04, на нем установлены Docker и kubectl
Пользователь предпочитает snake_case для имен переменных и избегает camelCase

Это не логи. Это факты. Плотные, декларативные, насыщенные информацией. Без временных меток, без воды, без «5 января пользователь попросил меня…»

USER.md: Профиль пользователя

Здесь агент хранит все, что он знает о вас.

Пользователь — full-stack разработчик, уверенно владеющий TypeScript, Go и Python.
Пользователь предпочитает snake_case для имен переменных и избегает camelCase.
Пользователь преимущественно использует Linux Ubuntu 22.04.
Пользователь разворачивает приложения в AWS с использованием Terraform.

Идентичность, роль, предпочтения, технические навыки, стиль общения, раздражители. То, что заставляет агента реагировать на вас иначе, чем на любого другого.

Паттерн «Замороженного снимка»

В начале сессии оба файла загружаются с диска и внедряются как замороженный блок в системный промпт. Вот как это выглядит:

══════════════════════════════════════════════
MEMORY (ваши личные заметки) [7% — 166/2,200 символов]

Проект пользователя — это микросервис на Go по пути ~/code/gateway с использованием gRPC + PostgreSQL § Этот компьютер работает под управлением Ubuntu 22.04, на нем установлены Docker и kubectl § Пользователь предпочитает snake_case для имен переменных и избегает camelCase §

══════════════════════════════════════════════ USER PROFILE (кто такой пользователь) [8% — 110/1,375 символов] ══════════════════════════════════════════════ Пользователь — full-stack разработчик, уверенно владеющий TypeScript, Go и Python. § Пользователь предпочитает snake_case для имен переменных и избегает camelCase. §

Формат использует заголовки, проценты использования, подсчет символов и разделители `§` (знак секции). Записи могут быть многострочными. Он предназначен для того, чтобы модель могла его парсить, оставаясь читаемым для человека.

Почему заморожено? [Кеширование префиксов](https://www.glukhov.org/ru/llm-performance/). Системный промпт одинаков для каждого хода в сессии. Держа память статичной после начала сессии, модель может кэшировать вычисление префикса и обрабатывать только переменные части — разговор. Это значительная оптимизация производительности. Вы не пересчитываете внимание по одним и тем же токенам памяти на каждом ходу.

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

### Ограничения символов как функция

2200 символов. 1375 символов. Это не произвольные ограничения. Это ограничения дизайна, которые принудительно заставляют курировать.

Неограниченная память — это слабость. Она поощряет сбрасывание всего подряд, никогда не консолидируя и в конечном итоге превращаясь в шум. Ограниченная память заставляет агента быть селективным. Что на самом деле важно? Что мне понадобится снова? Что можно сжать, не потеряв смысла?

Когда память заполнена, агент не просто молча падает. Он получает ошибку с текущими записями и использованием, затем следует рабочему процессу:

1. Прочитать текущие записи из ответа об ошибке
2. Определить записи, которые можно удалить или консолидировать
3. Использовать `replace` для объединения связанных записей в более короткие версии
4. Добавить новую запись

Вот как память остается полезной. Это не база данных. Это курируемая коллекция фактов, которые имеют значение.

### Безопасность: Сканирование на инъекции промптов

Каждая запись памяти сканируется перед принятием. Система блокирует попытки инъекции промптов, утечку учетных данных, SSH-бэкдоры и невидимые символы Unicode.

Память также дедуплицируется. Точные дублирующиеся записи автоматически отклоняются. Это предотвращает попытки злоумышленников внедрить вредоносный контент через повторные submission.

---

## Часть 3: Когда память срабатывает — Триггеры и решения

Самый частый вопрос о памяти Hermes Agent — когда она на самом деле сохраняет что-то.

Ответ: постоянно, но селективно. Агент управляет собственной памятью через инструмент `memory`, а решение о сохранении обусловлено комбинацией явных сигналов и неявных паттернов.

### Триггеры записи: Когда агент решает сохранить?

Агент сохраняет память проактивно. Он не ждет, пока вы попросите. Вот что его триггерит.

**Исправления пользователя.** Когда вы исправляете агента, это сигнал к запоминанию. «Больше так не делай». «Используй это вместо того». «Запомни это». Это явные инструкции по обновлению памяти.

Пример: вы просите агента настроить окружение Python. Он предлагает `pip`. Вы говорите: «Я использую `poetry` для всего». Агент сохраняет: `Пользователь предпочитает использовать менеджер пакетов 'poetry' для всех проектов на Python.`

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

Пример: после того, как агент увидел, как вы используете `poetry` несколько раз в разных проектах, он сохраняет это как предпочтение.

**Факты об окружении.** То, что касается машины, проекта, установленных инструментов. Это обнаруживается через исследование и сохраняется как факты.

Пример: агент проверяет, что установлено, и сохраняет: `Этот компьютер работает под управлением Ubuntu 22.04, на нем установлены Docker и kubectl.`

**Соглашения проекта.** Как структурирован проект, какие инструменты использует, какие паттерны следует. Это обнаруживается через инспекцию кода и сохраняется.

Пример: `Проект пользователя — это микросервис на Go по пути ~/code/gateway с использованием gRPC + PostgreSQL.`

**Завершенные сложные рабочие процессы.** После завершения задачи, которая потребовала 5+ вызовов инструментов, агент рассматривает возможность сохранения подхода как навыка или, по крайней мере, фиксации того, что сработало.

**Особенности инструментов и обходные пути.** Когда агент обнаруживает что-то неочевидное об инструменте, API или системе — ограничение, обходной путь, соглашение — он сохраняет это.

**Что пропускается:**

- Тривиальная или очевидная информация
- То, что легко обнаружить заново
- Сырые дамп данных
- Эфемерные данные сессии
- Информация, уже находящаяся в файлах контекста (SOUL.md, AGENTS.md)

### Триггеры чтения: Когда агент вспоминает?

Память не извлекается — она всегда есть. Но есть разные уровни доступа.

**Начало сессии (автоматически).** MEMORY.md и USER.md внедряются в системный промпт. Агент имеет их с первого токена. Не нужен запрос, нет задержки, нет вызова инструмента. Это ядро памяти — всегда активно.

**`session_search` (по требованию).** Когда агенту нужно найти что-то из прошлых разговоров, чего нет в ядре памяти, он использует инструмент `session_search`. Это запрашивает SQLite (`~/.hermes/state.db`) с полнотекстовым поиском FTS5 и суммаризацией Gemini Flash.

Пример: вы спрашиваете: «Мы обсуждали сетевые настройки Docker на прошлой неделе?» Агент ищет в истории сессий и возвращает резюме соответствующего разговора.

**Инструменты внешних провайдеров (когда настроены).** Когда активен внешний провайдер памяти, у агента есть дополнительные инструменты: `honcho_search`, `hindsight_recall`, `mem0_search` и т.д. Они используются, когда агент определяет, что нужен внешний контекст.

### Дерево решений

Вот как агент взвешивает «стоит ли это запомнить?»:

Это исправление или явная инструкция? ДА → Сохранить в память НЕТ → Это предпочтение или паттерн? ДА → Сохранить в профиль пользователя НЕТ → Это факт об окружении или соглашение? ДА → Сохранить в память НЕТ → Это легко обнаружить заново? ДА → Пропустить НЕТ → Это специфично для сессии? ДА → Пропустить НЕТ → Сохранить в память

Агент не переосмысливает это. Он сохраняет проактивно, консолидирует, когда заполнен, и доверяет ограничениям символов, чтобы держать вещи в узде.

---

## Часть 4: Внутренняя память против внешних баз знаний

Здесь часто возникает путаница. У Hermes Agent есть *внутренняя память* (MEMORY.md, USER.md, внешние провайдеры) и *внешние базы знаний* (LLM Wiki, Obsidian, Notion, ArXiv, файловая система), и они служат совершенно разным ролям. Это похоже на различие между конвейерами [генерации, дополненной извлечением](https://www.glukhov.org/ru/rag/) и рабочей памятью агента — внешнее извлечение хорошо для глубокого поиска знаний, но не для переноса идентичности и предпочтений. Внутренняя память — это мозг агента — всегда активна, курируема, переносится в каждую сессию. Внешние базы знаний — это его библиотека — обширные справочные ресурсы, консультируемые по требованию.

### Различие

**Внутренняя память (мозг):**

- Маленькая, персистентная, внедряется в системный промпт
- Содержит: предпочтения пользователя, соглашения агента, немедленные уроки
- Всегда «в уме» во время разговора
- Курируема, ограничена, активно управляема
- Примеры: MEMORY.md, USER.md, Honcho, Hindsight, Mem0

**Внешние базы знаний (библиотека):**

- Обширные, только для справки, доступны по требованию
- Содержат: документы, статьи, код, заметки, базы данных
- Доступны через инструменты, когда нужно
- Не «запоминаются» — ищутся
- Примеры: LLM Wiki, Obsidian, Notion, ArXiv, файловая система, GitHub

### Как они связаны

Агент *доступает* внешние базы через инструменты, когда нужно. Он не «запоминает» их — он их ищет.

**LLM Wiki (llm-wiki):** Связанная Markdown-база знаний Карпатского для построения и запроса доменных знаний. Агент использует навык `llm-wiki` для чтения, поиска и запроса. Это справочный ресурс, а не память.

**[Obsidian](https://www.glukhov.org/ru/knowledge-management/tools/obsidian-for-personal-knowledge-management/):** Личные хранилища заметок с двусторонними ссылками. Агент использует навык `obsidian` для чтения, поиска и создания заметок. Obsidian является частью более широкой экосистемы [управления персональными знаниями](https://www.glukhov.org/ru/knowledge-management/), которую Hermes может использовать как ресурс библиотеки.

**Notion/Airtable:** Структурированные базы данных и вики, доступные через API. Агент запрашивает их, когда нужно.

**ArXiv:** Репозитории академических статей. Агент ищет и извлекает статьи, когда исследует тему.

**Файловая система:** Код проекта, документация, конфигурации. Агент читает файлы, работая над проектом.

### Паттерн дистилляции

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

Пример: агент читает статью из ArXiv о масштабировании памяти для ИИ-агентов. Он не сохраняет всю статью в память. Он сохраняет ключевой вывод: `Масштабирование памяти: производительность агента улучшается с накопленным опытом через взаимодействие пользователя и бизнес-контекст, хранящийся в памяти.`

Внешний ресурс обширен. Внутренняя память — это дистилляция.

### Когда использовать что

**Внутренняя память для:**

- «Кого я помогаю?»
- «Что они предпочитают?»
- «Чему мы только что научились?»
- «Какая настройка проекта?»
- «Какие инструменты доступны?»

**Внешние базы знаний для:**

- «Какие последние исследования по X?»
- «Что в документации моего проекта?»
- «О чем мы говорили в прошлом месяце?»
- «Какой API для этого сервиса?»
- «Какова структура кода?»

Агент понимает разницу и использует каждый соответствующим образом — он не путает поиск документа с воспоминанием о том, чему он научился о вас и вашем окружении.

---

## Часть 5: Как это работает на самом деле

Давайте посмотрим на механику.

### Инструмент `memory`

Агент управляет памятью через один инструмент с тремя действиями: `add`, `replace`, `remove`.

Нет действия `read` — контент памяти автоматически внедряется в системный промпт. Агенту не нужно его читать, потому что он всегда там.

**`add`** — Добавляет новую запись.

```python
memory(action="add", target="memory",
       content="Пользователь работает на macOS 14 Sonoma, использует Homebrew, на нем установлен Docker Desktop.")

replace — Заменяет существующую запись, используя сопоставление подстрок.

memory(action="replace", target="memory",
       old_text="dark mode",
       content="Пользователь предпочитает светлую тему в VS Code, темную в терминале")

remove — Удаляет запись, используя сопоставление подстрок.

memory(action="remove", target="memory",
       old_text="temporary project fact")

Сопоставление подстрок

replace и remove используют короткие уникальные подстроки через old_text. Вам не нужен полный текст записи. Это делает хирургические правки возможными без знания точного контента.

Если подстрока совпадает с несколькими записями, возвращается ошибка, запрашивающая более конкретное совпадение. Затем агент уточняет свой запрос.

Целевые хранилища: memory против user

Параметр target определяет, какой файл обновляется.

• memory — Личные заметки агента. Факты об окружении, соглашения проекта, особенности инструментов, уроки.
• user — Профиль пользователя. Идентичность, роль, часовой пояс, предпочтения в общении, раздражители, привычки рабочего процесса.

Управление емкостью

Когда память заполнена более чем на 80%, агент консолидирует. Он объединяет связанные записи, удаляет устаревшие факты и сжимает информацию.

Хорошие записи памяти компактны и насыщены информацией:

Пользователь работает на macOS 14 Sonoma, использует Homebrew, на нем установлен Docker Desktop. Shell: zsh с oh-my-zsh. Редактор: Neovim с плагином Telescope.

Плохие записи памяти размыты или многословны:

У пользователя есть проект.
5 января 2026 года пользователь попросил меня посмотреть на его проект, который находится по пути ~/code/gateway и использует Go с gRPC и PostgreSQL для слоя базы данных.

Первая плотна и полезна. Вторая либо слишком размыта, либо слишком многословна.

Поиск сессий против персистентной памяти

session_search и персистентная память служат разным целям.

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

Часть 6: Внешние провайдеры памяти — Сравнение всех 8 опций

Помимо встроенных MEMORY.md и USER.md, Hermes Agent поддерживает 8 внешних плагинов провайдеров памяти для персистентных, кросс-сессийных знаний.

Только один внешний провайдер может быть активен одновременно. Встроенные файлы всегда активны вместе с внешним провайдером — аддитивно, а не заменой.

Активация

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 добавляет дополнительный слой контекста. Он моделирует разговоры как обмен сообщениями между равными — один пользовательский peer и один AI peer на профиль Hermes, все разделяют рабочее пространство.

Инструменты: honcho_profile (читать/обновлять карточку peer), 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 (общий пул)

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

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

OpenViking

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

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

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

Настройка:

pip install openviking
openviking-server
hermes memory setup  # выбрать "openviking"
echo "OPENVIKING_ENDPOINT=http://localhost:1933" >> ~/.hermes/.env

Mem0

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

Mem0 обрабатывает извлечение памяти на стороне сервера. Вам не нужно ничего настраивать — это просто работает. Компромисс: зависимость от облака и стоимость.

Инструменты: 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 выполняет кросс-памятный синтез — объединяя несколько воспоминаний в новые инсайты.

Инструменты: 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) для кодирования памяти, с оценкой доверия для надежности памяти. Нет зависимости от облака — все работает локально на вашем собственном оборудовании.

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

Настройка:

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

Нет зависимостей. Все работает локально.

RetainDB

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

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

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

Настройка:

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

ByteRover

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

ByteRover сжимает память перед извлечением, уменьшая использование пропускной способности. Доступен в локальном или облачном режимах.

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

Настройка:

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

Supermemory

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

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

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

Настройка:

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

Как выбрать

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

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

Часть 7: Философия

Почему ограниченная память лучше неограниченной

Инстинкт — сделать память как можно больше. Хранить все. Извлекать то, что нужно.

Ограниченная память работает лучше. Вот почему.

Курирование обеспечивает качество. Когда у вас ограничено место, вы сохраняете только то, что важно. Вы сжимаете, консолидируете и расставляете приоритеты. Неограниченная память поощряет сбрасывание всего и никогда не убирает.

Скорость имеет значение. 1300 токенов в системном промпте — это быстро. 100 000 токенов, извлеченных из базы данных — медленно. Память должна быть мгновенной, а не запросом.

Шум ухудшает производительность. Больше памяти — не значит лучшая память. Это шумная память. Модели приходится различать сигнал и шум, и это занимает внимание — внимание, которое должно быть потрачено на саму задачу.

Забывание — это функция. Человеческая память забывает. Это не ошибка — так мы расставляем приоритеты. Агенты тоже должны забывать. Не все заслуживает быть запомненным.

Проблема «забывания»

Агентам нужно забывать. Не просто забывать, но активно удалять устаревшую информацию.

Вот как Hermes Agent это обрабатывает:

• Действие remove: Удаляет записи, которые больше не актуальны.
• Действие replace: Обновляет записи новой информацией.
• Давление емкости: Когда память заполнена, агент консолидирует и удаляет старые записи.
• Сканирование безопасности: Блокирует вредоносные или поврежденные записи.

Забывание — это не неудача — это обслуживание. Агент, который не может забыть, в конечном итоге будет нести столько же шума, сколько и сигнал.

Масштабирование памяти

Databricks ввели концепцию «масштабирования памяти»: работает ли агент с тысячами пользователей лучше, чем один с единственным пользователем?

Их исследование предполагает да, но с оговорками. Масштабирование памяти требует:

1. Качественного извлечения: Не все взаимодействия заслуживают запоминания. Агент должен извлекать инсайты, а не логи.
2. Эффективного извлечения: Извлеченные воспоминания должны быть релевантными. Шум ухудшает производительность.
3. Генерализации: Воспоминания должны быть паттернами, а не спецификами. «Пользователь предпочитает Python» масштабируется. «Пользователь запустил команду X в метку времени Y» — нет.

Ограниченная память Hermes Agent естественно поддерживает масштабирование памяти. Принуждая к курированию, она гарантирует, что воспоминания обобщаемы, компактны и полезны.

Что это значит для будущего

Память становится конкурентным рвом в агентном ИИ — не сама модель, а то, что модель переносит между сессиями. Два агента с идентичными базовыми моделями могут работать очень по-разному: один помнит ваши предпочтения, ваше окружение и ваши прошлые ошибки; другой каждый раз начинается с холодного старта.

Вопрос больше не в том, должны ли агенты иметь персистентную память. Он решен: они должны. Открытый вопрос — как хорошо спроектировать эту память — что хранить, что отбрасывать, как сделать ее мгновенной и как предотвратить превращение ее в шум.

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

Заключение

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

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

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

А внешние базы знаний — LLM Wiki, Obsidian, Notion, ArXiv — служат другой роли. Это библиотека, а не мозг. Агент их ищет, а не запоминает. Критические инсайты дистиллируются во внутреннюю память; остальное остается в библиотеке.

Вот как ИИ-агент помнит вас. Не храня все, а запоминая то, что имеет значение.

Hermes Agent был выпущен Nous Research в феврале 2026 года и достиг более 64 000 звезд на GitHub к апрелю 2026 года (v0.9.0), с более чем 242 участниками. Он имеет открытый исходный код и доступен на github.com/NousResearch/hermes-agent. Для установки, конфигурации и руководств по рабочим процессам см. Обзор Hermes Agent.