Как настроить память ИИ-агента: USER.md, MEMORY.md, skills и история сессий

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

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

В Hermes USER.md и MEMORY.md находятся в ~/.hermes/memories/ и загружаются как снимок в начале сессии. Это короткая постоянная память; поиск по истории и проектным источникам остаётся отдельным механизмом.

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

Отсюда три типичных сбоя:

1. агент вытаскивает устаревший факт и принимает его за действующее правило;
2. временная деталь начинает влиять на все будущие задачи;
3. приватная информация попадает туда, где её увидит другой проект, инструмент или участник.

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

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

Хорошая запись:

Пользователь предпочитает сначала получить итог, затем краткие доказательства.

Плохая запись:

Сегодня нужно проверить статью №16 до вечера.

Вторая фраза — временная задача. Ей место в карточке исполнения или текущей сессии, а не в профиле человека.

Долговременная память нужна для компактных фактов о среде и договорённостях, которые применимы шире одного проекта. Она не должна превращаться в журнал действий.

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

Skill — это не факт, а инструкция, которая загружается по триггеру и ведёт агента через повторяемый процесс. Туда относятся порядок действий, проверки, команды, шаблоны результата и известные ошибки.

Например, «сервер использует Ubuntu» — факт. А «как безопасно обновить агент на Ubuntu, проверить сервис и откатиться» — процедура для skill.

Архитектурные решения, план релиза, состояние эксперимента, спецификация продукта и журнал измерений должны храниться рядом с проектом. Так команда видит изменения в Git, может сравнить версии и не зависит от скрытой памяти одного агента.

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

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

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

Задайте пять вопросов:

1. Это устойчивое свойство конкретного пользователя? Тогда USER.md.
2. Это короткий факт, полезный в разных будущих сессиях? Тогда MEMORY.md.
3. Это повторяемая инструкция с шагами и проверками? Тогда skill.
4. Это состояние, решение или данные конкретного проекта? Тогда проектный источник.
5. Это нужно только для продолжения текущего разговора? Оставьте в истории сессии.

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

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

Ожидаемый результат: у команды есть одна таблица решений, а не набор догадок.

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

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

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

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

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

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

• применить предпочтение пользователя;
• вспомнить долговечный факт;
• загрузить нужный skill;
• открыть проектный источник;
• не выдавать временную деталь старого разговора за действующую истину.

Ожидаемый результат: нужные знания воспроизводятся, а нерелевантные не вмешиваются.

Проведите тест в новой сессии и запишите источник каждого ответа:

1. Какой формат ответа предпочитает пользователь?
2. Какое постоянное правило среды нужно учитывать?
3. Какой skill должен загрузиться для этой задачи?
4. Где лежит актуальное состояние проекта?
5. Какое решение из прошлой переписки ещё действует и чем это подтверждено?

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

Не помещайте в память API-ключи, токены, пароли, приватные ключи, строки подключения, платёжные данные и полные выгрузки личной переписки. Ссылку на секретное хранилище можно сохранять только как маршрут без самого секрета.

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

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

Скорее всего, записи слишком длинные или лишены области действия. Разделите их, удалите хронологию и перенесите процедуры в skills.

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

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

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

Готовность подтверждает не объём сохранённых заметок, а воспроизводимый результат:

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

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

Возьмите пять реальных записей своего агента и распределите их по слоям. Затем проведите тест в новой сессии. Если хотите пройти этот путь с готовыми инструкциями, проверками и поддержкой, изучите Среду внедрения ИИ «Человек 2.0».