Система памяти Hermes Agent: как на самом деле работает persistent AI memory

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

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

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

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

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

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

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

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

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

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

Какое-то время это работает. У вас есть окно контекста в 128K токенов. Туда можно впихнуть много текста.

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

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

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

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

Ландшафт исследований

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

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

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

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

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

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

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

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

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

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

Два уровня

Hermes выстраивает память в два уровня:

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

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

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

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

Сообщение пользователя
    |
    v
MemoryManager.prefetch_all(query)        <-- фаза извлечения (recall)
    |
    +-- provider.prefetch(query)        <-- каждый внешний провайдер ищет в своем хранилище
    |
    v
Контекст внедряется в ход LLM
    |
    v
LLM отвечает (сообщение ассистента)
    |
    v
MemoryManager.sync_all(user, assistant)  <-- фаза сохранения (store)
    |
    +-- 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.

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

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

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

══════════════════════════════════════════════
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.
§

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

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

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

Лимиты символов как преимущество

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

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

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

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

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

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

Каждая запись в памяти сканируется перед принятием. Система блокирует попытки инъекции промптов (prompt injection), кражи учетных данных, установки бэкдоров 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 и другими стеками, см. Agent memory providers compared.

Для настройки профиля и рабочих процессов в продакшене см. Hermes Agent production setup. AI Systems Memory hub содержит этот гайд, а также связанные статьи о 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, файловая система), и они выполняют совершенно разные роли. Это похоже на различие между пайплайнами retrieval-augmented generation и рабочей памятью агента — внешнее извлечение хорошо подходит для глубокого поиска знаний, но не для хранения идентичности и предпочтений. Внутренняя память — это мозг агента: всегда активна, курируется и переносится в каждую сессию. Внешние базы знаний — это его библиотека: обширные справочные ресурсы, к которым он обращается по запросу.

Различие

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

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

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

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

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

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

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

Obsidian: Хранилища персональных заметок с двунаправленными ссылками. Агент использует навык obsidian, чтобы читать, искать и создавать заметки. Obsidian является частью более широкой экосистемы personal knowledge management, к которой 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 против user

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

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

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

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

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

Пользователь работает на macOS 14 Sonoma, использует Homebrew, установлен Docker Desktop. Shell: zsh с oh-my-zsh. Editor: 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 намеренно проста: два файла, жесткие лимиты символов, отсутствие конвейера извлечения, отсутствие vector database и отсутствие задержки на каждый запрос. То, что кажется ограничением, и есть главная цель.

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

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

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

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

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