Постоянная память

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

Как это работает

Память агента собирается из двух файлов:

Оба файла лежат в ~/.hermes/memories/ и при старте сессии подмешиваются в системный промпт как замороженный снимок. Своей памятью агент распоряжается сам через инструмент memory — он умеет добавлять, заменять и удалять записи.

Как память отображается в системном промпте

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

══════════════════════════════════════════════
MEMORY (your personal notes) [67% — 1,474/2,200 chars]
══════════════════════════════════════════════
User's project is a Rust web service at ~/code/myapi using Axum + SQLx
§
This machine runs Ubuntu 22.04, has Docker and Podman installed
§
User prefers concise responses, dislikes verbose explanations

Из чего складывается формат:

• Заголовок указывает хранилище (MEMORY или USER PROFILE)
• Процент заполнения и счётчик символов — агент видит, сколько места осталось
• Отдельные записи разделены знаком § (символ параграфа)
• Запись может занимать несколько строк

Шаблон замороженного снимка. Содержимое системного промпта фиксируется один раз при старте сессии и посреди работы не меняется. Сделано так намеренно: это сохраняет префиксный кэш LLM и держит скорость. Когда агент в ходе сессии добавляет или убирает записи, изменения тут же пишутся на диск, но в системный промпт они попадут лишь со следующей сессии. А вот ответы инструмента всегда показывают актуальное состояние.

Памяти нужны границы сессий

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

Это важно на платформах мессенджеров (Telegram, Discord и т. д.), где чат намеренно является одной непрерывной сессией, которая переживает перезапуски, падения шлюза и перезагрузки машины. Выключение компьютера на ночь сессию не завершает — следующее сообщение продолжит ровно с того места, где всё остановилось. Если никогда не сбрасывать, чат может неделями идти одной сессией: удобно, но дорожает (сжатие раз за разом прогоняет всё более длинную историю), а цикл обучения забыть → вспомнить из памяти → поискать по прошлым сессиям почти никогда не срабатывает. Свежие записи памяти к тому же остаются невидимыми для текущей сессии из-за описанного выше замороженного снимка.

На практике: делайте /new на естественных границах — законченная задача, смена темы, начало дня. Каждая такая граница и есть момент, когда память окупается: агент перечитывает обновлённый снимок MEMORY.md/USER.md, стартует с дешёвого короткого контекста и тянется к session_search, когда история ему действительно нужна. В CLI это в основном происходит само (каждый запуск — новая сессия); в шлюзах границу создаёте вы.

Разбор проблем: «Я попросил запомнить, а в следующей сессии он забыл»

Самая частая жалоба выглядит так: вы говорите агенту, где что лежит (хранилище Obsidian, каталог проекта, сервер), он отвечает «Готово, запомню», а свежая сессия понятия не имеет, о чём речь. Проверяйте по порядку — первый пункт объясняет подавляющее большинство случаев.

1. Проверьте, была ли запись на самом деле. Память сохраняется, только когда модель вызывает инструмент memory; фраза «Я добавил это в память» — просто текст. Откройте файл и поищите запись:

   cat ~/.hermes/memories/MEMORY.md
   cat ~/.hermes/memories/USER.md

   Если факта там нет, модель заявила о сохранении, которого не делала. Небольшие локальные модели (примерно до 30B параметров) и модели со слабым вызовом инструментов делают так часто — выдают подтверждение без вызова инструмента. Попросите явно («use the memory tool to save the vault path /srv/vault») и убедитесь, что запись попала в файл. Если это повторяется, лечится не новыми инструкциями, а более сильной моделью на время настройки; когда записи уже есть, модель поменьше читает их без проблем, потому что они приходят в системном промпте.

2. Проверьте, не отложена ли запись. При write_approval: true записи вне интерактивного CLI ждут проверки и не попадают в файл, пока их не одобрят, — выполните /memory pending и /memory approve all. См. Управление записью в память.

3. Проверьте, что читаете ту же память, в которую писали. Память своя у каждого профиля: hermes -p work (или work chat / work gateway start) читает ~/.hermes/profiles/work/memories/, а не ~/.hermes/memories/. Сессия CLI в профиле по умолчанию и Telegram-бот на другом профиле заметок не делят. Что есть, покажет hermes profile list.

4. Проверьте, что память включена. memory.memory_enabled: false (или memory в agent.disabled_toolsets) убирает инструмент целиком — модель ничего не может сохранить, что бы она ни говорила. См. Конфигурация.

5. Помните, что снимок замораживается при старте сессии. Факт, сохранённый в текущей сессии, виден следующей сессии, а не другой, которая уже шла. После записи начните новую сессию (/new или свежий запуск CLI).

Две вещи, которые не заставляют агента помнить: переменные в .env (это учётные данные и настройки, а не память) и факты, упомянутые мимоходом без просьбы их сохранить. Для места, которое агенту нужно при каждом запуске повторяющейся задачи, навык часто подходит лучше записи в памяти: он грузится только когда нужен и не соревнуется за бюджет в 2200 символов.

Действия инструмента памяти

Агент работает с инструментом memory через три действия:

• add — добавить новую запись в память
• replace — заменить существующую запись обновлённым содержимым (поиск по подстроке через old_text)
• remove — убрать запись, которая больше не нужна (поиск по подстроке через old_text)

Действия read нет: содержимое памяти само подтягивается в системный промпт при старте сессии. Свои воспоминания агент видит как часть контекста разговора.

Поиск по подстроке

Действиям replace и remove достаточно короткой уникальной подстроки — полный текст записи указывать не нужно. Параметр old_text должен лишь однозначно указывать ровно на одну запись:

# If memory contains "User prefers dark mode in all editors"
memory(action="replace", target="memory",
       old_text="dark mode",
       content="User prefers light mode in VS Code, dark mode in terminal")

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

replace перезаписывает всю найденную запись значением content — old_text лишь находит запись, а не вырезается и заменяется. Новый content должен быть полной новой записью, включая всё из старой, что вы хотите сохранить. (old_text, равный всей записи целиком, сопоставляется точно и побеждает совпадения по подстроке.)

Два хранилища

memory — личные заметки агента

Сюда идёт всё, что агенту полезно держать в голове об окружении, рабочих процессах и собственных уроках:

• Факты об окружении (ОС, инструменты, структура проекта)
• Договорённости и настройки проекта
• Особенности инструментов и найденные обходные приёмы
• Дневник завершённых задач
• Приёмы и техники, которые сработали

user — профиль пользователя

Сюда — всё, что касается личности пользователя, его предпочтений и манеры общения:

• Имя, роль, часовой пояс
• Предпочтения по общению (кратко или подробно, желаемый формат)
• Раздражители и то, чего стоит избегать
• Привычки в работе
• Уровень технической подготовки

Что сохранять, а что пропускать

Что сохранять (проактивно)

Агент сохраняет сам — просить его не нужно. Запись появляется, когда он узнаёт:

• Предпочтения пользователя: «Я предпочитаю TypeScript, а не JavaScript» → в user
• Факты об окружении: «На сервере Debian 12 с PostgreSQL 16» → в memory
• Поправки: «Не используй sudo для команд Docker, пользователь в группе docker» → в memory
• Договорённости: «В проекте табы, ширина строки 120 символов, докстринги в стиле Google» → в memory
• Завершённую работу: «Перенёс БД с MySQL на PostgreSQL 2026-01-15» → в memory
• Явные просьбы: «Запомни, что ротация моего API-ключа идёт раз в месяц» → в memory

Это лучше пропустить

• Очевидные мелочи: «Пользователь спрашивал про Python» — слишком расплывчато, толку ноль
• То, что легко найти заново: «Python 3.12 поддерживает вложенные f-строки» — гуглится за секунду
• Сырые выгрузки данных: большие блоки кода, логи, таблицы — для памяти это слишком громоздко
• Эфемерные детали сессии: временные пути к файлам, разовый контекст отладки
• То, что уже есть в файлах контекста: содержимое SOUL.md и AGENTS.md

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

У памяти жёсткие лимиты символов — так системный промпт остаётся ограниченным по размеру:

Что происходит, когда память заполнена

Если попытаться добавить запись, которая выйдет за лимит, инструмент вернёт ошибку:

{
  "success": false,
  "error": "Memory at 2,100/2,200 chars; adding this entry (250 chars) would exceed the limit by 153 chars. Retry as ONE 'operations' batch that removes or shortens (replace) stale entries from current_entries below to free at least 153 chars AND adds this entry — the limit is checked only on the batch result.",
  "current_entries": ["..."],
  "usage": "2,100/2,200"
}

Тогда агент заново отправляет один пакет operations: он освобождает не меньше указанного числа символов (удаляет записи или заменяет их через replace более короткими версиями) и добавляет новую запись. Лимит проверяется только по итоговому результату пакета. replace/remove, у которых old_text не совпал ни с одной записью, завершаются так же ошибкой, а самые похожие записи приходят в поле closest_entries.

Полезная привычка. Когда память заполнена больше чем на 80% (это видно в заголовке системного промпта), уплотняйте записи до того, как добавлять новые. Скажем, три отдельные заметки «в проекте используется X» имеет смысл свести в одно ёмкое описание проекта.

Примеры удачных записей

Лучше всего работают компактные записи с высокой плотностью информации:

# Good: Packs multiple related facts
User runs macOS 14 Sonoma, uses Homebrew, has Docker Desktop and Podman. Shell: zsh with oh-my-zsh. Editor: VS Code with Vim keybindings.

# Good: Specific, actionable convention
Project ~/code/api uses Go 1.22, sqlc for DB queries, chi router. Run tests with 'make test'. CI via GitHub Actions.

# Good: Lesson learned with context
The staging server (10.0.1.50) needs SSH port 2222, not 22. Key is at ~/.ssh/staging_ed25519.

# Bad: Too vague
User has a project.

# Bad: Too verbose
On January 5th, 2026, the user asked me to look at their project which is
located at ~/code/api. I discovered it uses Go version 1.22 and...

Защита от дубликатов

Система памяти сама отбраковывает полные дубли. Попробуете добавить содержимое, которое уже есть, — получите успешный ответ с пометкой «no duplicate added».

Сканирование на безопасность

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

Поиск по сессиям

Помимо MEMORY.md и USER.md агент может искать по своим прошлым разговорам через инструмент session_search:

• Все сессии CLI и шлюза сообщений хранятся в SQLite (~/.hermes/state.db) с полнотекстовым поиском FTS5
• Поисковые запросы возвращают реальные сообщения из БД — без пересказа от LLM, без обрезки
• Агент находит то, что обсуждал недели назад, даже если этого уже нет в активной памяти
• Внутри найденной сессии можно листать вперёд и назад

hermes sessions list    # Browse past sessions

Про три формы вызова (поиск / прокрутка / просмотр) и формат ответа смотрите инструмент поиска по сессиям.

session_search или память

Память — для критичных фактов, которые всегда должны быть в контексте. Поиск по сессиям — для вопросов вроде «обсуждали ли мы X на прошлой неделе?», когда агенту нужно поднять подробности из прошлых разговоров.

Путь обучения (/journey)

Путь обучения — это таймлайн всего, чему научился Hermes: сохранённые навыки и записи памяти, разложенные по времени (сверху — самые старые, снизу — новые), с воспроизводимым скраббером «созвездие», который прокручивает всю историю накопления. Одни и те же данные графа обслуживают три поверхности:

• Классический CLI / standalone — hermes journey (алиасы: hermes learning, hermes memory-graph) рисует таймлайн в терминале. Флаги: --play анимирует накопление (--fps настраивает скорость), --width/--height задают размер рендера, --no-color отключает цвет, --json выгружает сырые данные графа.
• TUI — /journey (алиасы: /learning, /memory-graph) открывает таймлайн оверлеем.
• Десктопное приложение — /journey открывает панель Star Map / графа памяти — интерактивную визуализацию тех же узлов.

Навык появляется на таймлайне, как только у него есть сигнал обучения: он создан в этом профиле (результат /learn или создание через skill_manage в переднем плане), создан фоновой проверкой либо использован хотя бы раз. Встроенные и написанные вручную навыки, которыми ни разу не пользовались, на таймлайн не попадают.

Кроме просмотра, в пути обучения можно чистить и исправлять то, что выучил Hermes:

Те же подкоманды list / delete <id> / edit <id> работают из команды /journey прямо в чате CLI, а десктопная панель предлагает правку и удаление узлов прямо на месте.

Конфигурация

# In ~/.hermes/config.yaml
memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 2200   # ~800 токенов
  user_char_limit: 1375     # ~500 токенов
  write_approval: false     # false = писать свободно (по умолчанию) | true = требовать подтверждение
  prefetch_spill_enabled: false  # внешний recall остаётся целым, пока вы явно не включите

Если выставить в false сразу оба ключа — memory_enabled и user_profile_enabled, — встроенные хранилища выключаются целиком: инструмент memory пропадает из схемы, а его блок с инструкциями — из системного промпта, так что модели даже не рассказывают про инструмент, которым она не может воспользоваться. Внешнего провайдера, заданного через memory.provider (Hindsight, Mem0, Honcho, …), это не касается: его инструменты остаются на месте. Так и поступают, когда нужен сторонний бэкенд памяти вместо встроенных файлов. Более грубый выключатель — прописать memory в agent.disabled_toolsets: тогда скроются и инструменты внешнего провайдера.

Если же выключен только memory_enabled, а профиль пользователя работает, инструмент никуда не денется — на нём держится хранилище профиля, — но в системном промпте полные инструкции по памяти сменятся узким блоком только про профиль. Схема инструмента объявит единственную цель user, а прямые и отложенные записи в отключённый MEMORY.md будут отклонены. Обратная конфигурация объявляет только memory и отклоняет записи в USER.md.

Размер внешнего recall

Внешние провайдеры памяти по умолчанию возвращают весь предзагруженный контекст целиком, вплоть до страховочного потолка в 10× hooks.output_spill.max_chars (не меньше 100 000 символов); всё, что больше, по-прежнему сбрасывается в файл, чтобы вышедший из-под контроля провайдер не переполнил окно контекста. Параметр memory.prefetch_spill_enabled: true включает для активного профиля замену слишком большого recall превью из начала и конца плюс путём к файлу. Это может уменьшить объём повторно отправляемого контекста, но отобранная по релевантности середина перестаёт быть сразу видна модели. По возможности лучше пользоваться собственным бюджетом recall вашего провайдера.

Согласие использует общие для hooks.output_spill порог, длину превью и каталог; hooks.output_spill.enabled: false по-прежнему отключает его. Обычные хуки плагинов по-прежнему сбрасывают крупный вывод по умолчанию, независимо от этого параметра памяти. Настройки считываются при регистрации провайдера: после их изменения перезапустите Hermes. Подробности настройки — в разделе слишком большие результаты prefetch.

Управление записью в память (write_approval)

По умолчанию агент пишет в память свободно — в том числе из фоновой проверки самоулучшения, что запускается после хода. Если вам спокойнее сначала подтверждать записи, выставьте memory.write_approval: true. Это простой переключатель «вкл/выкл», который действует сразу на оба случая: ходы на переднем плане и фоновую проверку.

Чтобы вовсе отключить память (а не просто поставить переключатель), задайте memory_enabled: false и user_profile_enabled: false разом. Когда оба встроенных хранилища выключены, встроенный инструмент memory скрывается автоматически.

Отложенные записи разбирают из CLI или с любой платформы сообщений:

/memory pending             # список отложенных записей в память (автоматические помечены [auto])
/memory approve <id>        # применить одну (или 'all')
/memory reject <id>         # отбросить одну (или 'all')
/memory approval on         # включить переключатель (или 'off') и сохранить выбор

Это и есть ответ на жалобу «агент запомнил про меня неверное допущение»: выставьте write_approval: true — и каждая запись, особенно непрошеные фоновые, будет ждать вашего «да/нет», прежде чем попасть в профиль.

Отложенные replace или remove (фоновая проверка откладывает их даже при выключенном гейте) запоминают полную запись, на которую нацелены, и /memory pending её показывает. Одобрение применяется ровно к этой записи: если она изменилась после того, как запись отложили, изменение отклоняется и остаётся в ожидании, чтобы вы его отвергли. replace/remove, отложенные до появления такой привязки, не имеют проверяемой цели и тоже отклоняются: отвергните их и сделайте изменение заново. /memory approve выводит полный текст каждой записи, которую перезаписал или удалил.

Уведомления о фоновой проверке (display.memory_notifications)

После хода фоновая проверка самоулучшения может потихоньку сохранить запись в память или поправить навык. Это и есть цикл обучения Hermes с учётом согласия: повторяющиеся поправки и устойчивые уроки по рабочим процессам превращаются в компактные записи памяти или процедурные навыки, а write_approval умеет откладывать такие записи на проверку, прежде чем они повлияют на будущие сессии. По умолчанию она показывает в чате короткую строчку 💾 Memory updated, чтобы вы знали о случившемся. Насколько она разговорчива — настраивается:

display:
  memory_notifications: on    # off | on (default) | verbose

Настройка управляет только уведомлением в чате шлюза. Саму проверку и записи в хранилища памяти и навыков она не затрагивает. Задать её для конкретной платформы можно через display.platforms.<platform>.memory_notifications.

Успешные пачки операций с навыками перечисляют каждое применённое действие и в режиме on, и в verbose — включая запись и удаление вспомогательных файлов и удаление самого навыка. Подготовленные записи, ждущие одобрения, и откатанные пачки завершёнными изменениями не считаются. Сводка по пачке строится на фактических результатах, а не на предположении, что запрошенные записи прошли.

Запуск проверки на более дешёвой модели (auxiliary.background_review)

По умолчанию проверка идёт на вашей основной модели чата и повторно прогоняет разговор — он уже тёплый в кэше промпта, так что чтения из кэша дешёвые. Если основная модель дорогая, проверку можно перевести на модель подешевле:

auxiliary:
  background_review:
    provider: openrouter
    model: google/gemini-3-flash-preview   # auto (по умолчанию) = основная модель чата

Если указать модель, отличную от основной, проверка на ней обходится заметно дешевле (в бенчмарках — примерно в 3–5 раз). Раз другая модель всё равно не может переиспользовать кэш промпта основной модели, форк автоматически прогоняет не полную стенограмму, а компактный дайджест разговора (последние ходы дословно + краткое содержание более старых) — это минимизирует объём, который пишется в новый кэш. Захват данных не страдает: в тестах захват памяти был идентичен, а захват навыков — почти идентичен проверке на основной модели.

Оставьте значение auto (или укажите вашу основную модель) — ничего не изменится: проверка по-прежнему пойдёт на основной модели с полным прогоном тёплого кэша.

Рассуждения при проверке на той же модели

Проверка на той же модели, что и у родителя, всегда наследует родительское усилие рассуждений. Настройка auxiliary.background_review.reasoning_effort его не перебивает — ни при маршруте auto, ни при явно выбранном родительском провайдере и модели.

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

Чтобы сократить работу проверки, не меняя усилия основного разговора, подкрутите memory.nudge_interval / skills.creation_nudge_interval, отключите автоматические проверки, как описано ниже, или отправьте их на другую модель. Маршрут на другую модель работает по дайджесту и тёплый префикс родителя не делит; на этом маршруте auxiliary.background_review.reasoning_effort учитывается (не задан — значение по умолчанию у провайдера маршрута). Если ключ задан, а проверка осталась на основной модели, один раз печатается предупреждение. Управление частотой и маршрутизацией не развязывает рассуждения при работе на той же модели.

Отключение автоматических проверок (enabled)

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

auxiliary:
  background_review:
    enabled: true              # false = не запускать автоматические форки после хода

При enabled: false автоматические форки после хода не запускаются; ручной вызов /refine продолжает работать.

Ограничение стоимости проверки (max_input_tokens)

Цикл проверки заново прогоняет разговор при каждом запросе к провайдеру, поэтому одна проверка может умножить входные токены на число своих итераций с инструментами. max_input_tokens ограничивает СУММУ заново прогнанных входных токенов за одну проверку; цикл останавливается, не переходя этот порог. <= 0 означает «без ограничения».

auxiliary:
  background_review:
    max_input_tokens: 48000  # <= 0 = unlimited

Если ключ не задан, бюджет выводится из разрешённого окна контекста модели проверки: 75% окна, но не больше 600 000 токенов, — так ограничение работает и на небольших локальных моделях (модель на 65 536 токенов получает 49 152), где фиксированное значение облачного масштаба никогда бы не сработало. Если окно определить не удаётся, действует осторожный запасной бюджет в 120 000 токенов. Обратите внимание: ключ живёт под auxiliary:; блок background_review: на верхнем уровне не читается.

Расход токенов форка сохраняется в session_model_usage с task='background_review', а строка о завершении пишется в agent.log (Background review complete: thread=bg-review calls=… in=… out=… result=…).

Разрешить дополнительный инструмент проверки с узкой областью действия (extra_tools)

По умолчанию фоновая проверка может пользоваться памятью, управлением навыками и инструментами для чтения файлов. Если профиль предоставляет ещё один инструмент, безопасный для проверки без присмотра, включите его по имени:

auxiliary:
  background_review:
    extra_tools:
      - propose_shared_memory

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

Локальные модели: разбор ждёт свободного GPU (defer)

У облачного провайдера разбор укладывается в секунды и спокойно идёт параллельно с тем, чем вы заняты дальше. Когда же разбор выполняется на управляемом локальном llama-server (Settings → Local models), тот же форк занимает видеокарту, которая нужна вашему следующему промпту, — на большой модели это минуты, — а отправка нового промпта его отменяет, и выученное пропадает. Поэтому на управляемой локальной среде разборы по умолчанию откладываются: их ставят в очередь по завершении хода и выполняют, когда машина побыла в покое короткое время отстоя. Сам разбор при этом не меняется — та же модель, тот же повтор всей переписки, те же записи, — переезжает только момент выполнения.

auxiliary:
  background_review:
    defer: auto            # auto (по умолчанию) | never
    defer_max_age_s: 1800  # через столько запустить отложенный разбор в любом случае

Отложенные разборы схлопываются по сессиям (снимок более свежего хода заменяет прежний — разбор всё равно проигрывает весь разговор, так что ничего не теряется), разбор, вытесненный новым промптом, возвращается в очередь, а не выбрасывается, а разбор, прождавший дольше defer_max_age_s, запускается, даже если машина так и не освободилась. Явная команда /refine выполняется немедленно. Очередь живёт в памяти: разборы, не начатые к моменту выхода из приложения, пропадают — ровно как пропал бы форк, оборванный на полпути.

Управление записью навыков (skills.write_approval)

У навыков тот же переключатель «вкл/выкл», но проверять их приходится иначе: SKILL.md слишком велик, чтобы уместиться в пузырьке чата.

skills:
  write_approval: false     # false = писать свободно (по умолчанию) | true = требовать подтверждение

При write_approval: true записи навыков (create / edit / patch / write_file / delete) всегда откладываются, откуда бы они ни шли. Однострочную выжимку вы смотрите на месте, а полный diff остаётся за пределами чата:

/skills pending             # список отложенных записей навыков + однострочная выжимка по каждой
/skills diff <id>           # полный unified diff (удобнее смотреть в CLI или дашборде)
/skills approve <id>        # применить (или 'all')
/skills reject <id>         # отбросить (или 'all')
/skills approval on         # включить переключатель (или 'off') и сохранить выбор

На платформе сообщений подтвердите навык по выжимке и метаданным или откройте /skills diff в CLI / дашборде / отложенный файл по пути ~/.hermes/pending/skills/<id>.json, когда захотите прочитать всё изменение целиком. Полностью — в разделе Контроль записи навыков агента.

Внешние провайдеры памяти

Для более глубокой постоянной памяти, выходящей за рамки MEMORY.md и USER.md, в составе Hermes идут 2 плагина внешних провайдеров памяти — RetainDB и ByteRover, — а другие, например Honcho, Hindsight, Supermemory, Mem0, OpenViking и Holographic, доступны в каталоге плагинов через hermes plugins install <name>.

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

hermes memory setup      # pick a provider and configure it
hermes memory status     # check what's active

Подробности по каждому провайдеру, инструкции по настройке и сравнение — в руководстве Провайдеры памяти.