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

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

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

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

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

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

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

В этой статье подробно объясняется, как это работает: специфический слой Hermes внутри кросс-фреймворковой модели в Системы памяти в ИИ-ассистентах и более широкая стековая структура в Архитектура ИИ-ассистентов. Для команд активации и проверки (hermes memory, hermes dump, просмотр логов) используйте Шпаргалку по CLI Hermes Agent. Для сопутствующей стороны «долгосрочных знаний» Hermes — переиспользуемых процедур в SKILL.md, а не файлов курируемой памяти — см. Авторство навыков Hermes Agent — структура SKILL.md и лучшие практики.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Часть 2: Архитектура

Читайте эту часть сверху вниз — слои и припоминание/сохранение за ход, затем что находится в MEMORY.md и USER.md, затем как подключить внешний провайдер.

Два слоя

Hermes наслоивает память в два слоя:

1. Встроенный — MEMORY.md и USER.md, файловые, всегда активные. Жесткие лимиты 2200 символов (заметки агента) и 1375 символов (профиль пользователя).
2. Один внешний провайдер (опционально) — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover, Supermemory и другие, которые вы включаете через конфигурацию. Только один внешний бэкенд работает одновременно. Он добавляет извлечение и удержание рядом с файлами; он не заменяет их.

Ментальная модель аддитивна — замороженные основные файлы плюс максимум один плагин. Хуки предварительной выборки (prefetch) и синхронизации оркеструют внешний слой; два файла остаются внедренными отдельно как часть замороженного системного промпта.

Поток выполнения (prefetch и sync)

Припоминание происходит до того, как модель отвечает; сохранение — после сообщения ассистента. В менеджере памяти Hermes Agent это отображается на prefetch на входе и sync на выходе. Названия ниже соответствуют поверхности реализации (MemoryManager, prefetch / sync_turn / queue_prefetch для каждого провайдера).

Сообщение пользователя
    |
    v
MemoryManager.prefetch_all(query)        <-- фаза припоминания
    |
    +-- provider.prefetch(query)        <-- каждый внешний провайдер ищет в своем хранилище
    |
    v
Контекст внедряется в ход LLM
    |
    v
LLM отвечает (сообщение ассистента)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- фаза сохранения
    |
    +-- provider.sync_turn(user, assistant)
    +-- provider.queue_prefetch(user)    <-- фоновый поиск для следующего хода

Встроенные MEMORY.md и USER.md не извлекаются через prefetch_all — они уже являются частью замороженного системного промпта. Внешние бэкенды подключаются к prefetch_all / sync_all; queue_prefetch позволяет провайдеру разогреть извлечение для следующего хода, не блокируя текущий ответ.

Три пути в долгосрочную память

1. Встроенный инструмент memory. Модель вызывает memory с add, replace или remove, когда инструкции говорят, что что-то должно сохраниться — прочные факты, предпочтения, исправления, заметки об окружении. target='user' обслуживает USER.md; target='memory' обслуживает MEMORY.md. Пример формы: memory(action='add', target='user', content='…').

2. Пассивное удержание на внешних провайдерах. Каждый ход фреймворк вызывает путь синхронизации провайдера, чтобы разговор мог быть разбит на фрагменты, обобщен или извлечен без необходимости модели называть каждый факт. Поведение различается в зависимости от бэкенда — например, Hindsight группирует ходы и выполняет структурированное удержание с сущностями и отношениями; Honcho отправляет диалог через свою диалектическую трубу; стеки в стиле Mem0 и Supermemory пассивно извлекают факты из ходов.

3. Специфичные для провайдера инструменты. Когда плагин их предоставляет, явные записи, такие как honcho_conclude, hindsight_retain или honcho_profile, сохраняют прочные срезы по запросу.

Автоматическое припоминание против инструментов провайдера

Основной памяти не нужен инструмент чтения — она уже есть в промпте. Внешние бэкенды добавляют либо автоматическое внедрение из prefetch (без отдельного вызова инструмента припоминания для этого среза контекста), либо явные инструменты извлечения (honcho_search, honcho_reasoning, honcho_context, hindsight_recall, hindsight_reflect и другие), когда модели нужен более точный запрос, чем тот, который дает prefetch.

Режимы припоминания (внешние провайдеры)

Плагины поддерживают настраиваемый режим припоминания (обычно recall_mode рядом с memory.provider в конфигурации), который обменивает токены на контроль.

Когда внешний провайдер не установлен (memory.provider пуст или не установлен), применяются только встроенные файлы и поиск по сессии — нет prefetch/sync от плагина.

Пути на диске и бюджеты

Встроенная память 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.

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

Паттерн замороженного снимка

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

══════════════════════════════════════════════
ПАМЯТЬ (ваши личные заметки) [7% — 166/2200 символов]
══════════════════════════════════════════════
Проект пользователя — микросервис на Go в ~/code/gateway, использующий gRPC + PostgreSQL
§
На этом компьютере работает Ubuntu 22.04, установлены Docker и kubectl
§
Пользователь предпочитает snake_case для имен переменных и избегает camelCase
§

══════════════════════════════════════════════
ПРОФИЛЬ ПОЛЬЗОВАТЕЛЯ (кто такой пользователь) [8% — 110/1375 символов]
══════════════════════════════════════════════
Пользователь — full-stack разработчик, уверенно владеющий TypeScript, Go и Python.
§
Пользователь предпочитает snake_case для имен переменных и избегает camelCase.
§

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

Почему замороженный? Кеширование префиксов. Системный промпт одинаков для каждого хода в сессии. Держа память статичной после начала сессии, модель может кэшировать вычисление префикса и обрабатывать только переменные части — разговор. Это значительная оптимизация производительности. Вы не пере вычисляете внимание по одним и тем же токенам памяти на каждом ходу.

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

Лимиты символов как функция

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

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

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

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

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

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

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

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

Внешние провайдеры памяти (активация и ссылки)

Помимо встроенных MEMORY.md и USER.md, Hermes Agent может подключать один внешний плагин памяти за раз — Honcho, OpenViking, Mem0, Hindsight, Holographic, RetainDB, ByteRover или Supermemory — для персистентных, кросс-сессийных знаний. Только один внешний провайдер активен одновременно; два основных файла остаются загруженными вместе с ним (аддитивно, а не замена).

Активируйте и проверяйте провайдеров с помощью hermes memory setup, hermes memory status и hermes memory off, или установите memory.provider и recall_mode в ~/.hermes/config.yaml. Паттерны учетных данных различаются (например, HINDSIGHT_API_KEY, ключи Honcho в $HERMES_HOME/honcho.json); используйте hermes memory setup для интерактивной настройки.

Минимальная YAML-структура только для встроенных:

memory:
  provider: ""
  memory_enabled: true
  user_profile_enabled: true

Пример активации для одного бэкенда (замените hindsight на honcho, mem0, supermemory или другие, которые поддерживает ваша установка):

memory:
  provider: "hindsight"

Для полной таблицы сравнения, заметок о зависимостях LLM и эмбеддингов, разбивки по провайдерам и о том, как эти бэкенды соотносятся с OpenClaw и другими стеками, см. Сравнение провайдеров памяти агентов.

Для настройки профиля и производственных рабочих процессов см. Настройка Hermes Agent для производства. Центр памяти ИИ-систем перечисляет это руководство, а также связанные статьи о Cognee и слое знаний.

Часть 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 на прошлой неделе?» Агент ищет историю сессий и возвращает резюме соответствующего разговора.

Инструменты внешних провайдеров (при настройке). Когда активен внешний провайдер памяти, фреймворк также выполняет шаг автоматического prefetch перед каждым ответом (см. Часть 2). Дополнительные инструменты, такие как honcho_search, hindsight_recall или mem0_search, предназначены для целевых поисков, когда агент выбирает явное извлечение — в зависимости от recall_mode, активны автоматическое внедрение, инструменты или оба.

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

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

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

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

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

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

Различие

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

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

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

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

Как они соотносятся

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

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

Obsidian: Персональные хранилища заметок с двунаправленными ссылками. Агент использует навык obsidian для чтения, поиска и создания заметок. Obsidian является частью более широкой экосистемы личного управления знаниями, которую Hermes может использовать как ресурс библиотеки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Инструмент memory

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

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

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

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 vs user

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

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

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

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

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

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

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

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

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

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

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

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

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

Почему ограниченная память побеждает неограниченную память

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

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

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

Скорость имеет значение. 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.