Вы вчера полтора часа объясняли агенту структуру проекта — где лежат исходники, что нельзя трогать папку с сырыми источниками, какие правила у команды. Сегодня открываете новую сессию, и он снова спрашивает то же самое. История переписки вроде бы сохранена, но пользы от нее нет. Либо она вообще не подтягивается, либо подтягивается целиком и съедает половину бюджета на первом же запросе.
Память ИИ-агента — это не архив переписки, а несколько слоев хранения с разными правилами доступа. Устойчивые факты живут в коротком файле (в Hermes Agent под него отведено 2 200 знаков), полная история — в базе с быстрым поиском, знания — в связанной вики из Markdown. В контекст подгружается не все подряд, а только то, что нужно под текущий шаг.
- Пересылать всю историю в контекстное окно — худший из способов дать агенту память. Выходит дорого и медленно, а галлюцинаций становится больше.
- Инструкции режут на скиллы и подгружают выборочно, чтобы в промпт на старте шли только их короткие описания.
- Полная история живет в базе с поисковым индексом и достается по требованию, а не висит в промпте постоянно.
- Извлечение сдвигается от классического RAG к рекурсивной работе с контекстом (RLM), где модель сама решает, куда еще заглянуть.
- Оригинал знаний — Markdown-файл на диске. Вектор — только поисковая копия, и при расхождении верить нужно файлу.
- Почему ИИ-агент теряет нить и во что это обходится
- Чем память агента отличается от контекстного окна
- Четыре слоя рабочего пространства агента
- Где хранить историю, чтобы она не съедала бюджет
- RLM против классического RAG
- Пирамида правды и вики как конституция системы
- Гибридный поиск и почему Markdown главнее вектора
- Типичные ошибки при сборке памяти
- Как обслуживать память, чтобы она не зарастала мусором
- С чего начать, если агент у вас уже работает
- Частые вопросы
Почему ИИ-агент теряет нить и во что это обходится
Агент теряет нить не потому, что модель «глупая», а потому, что контекстное окно конечно и дорого. Каждый токен истории оплачивается заново при каждом вызове, а внимание модели по длинному окну распределяется неравномерно.
Простая пересылка всей переписки в промпт бьет сразу по нескольким местам. Счет растет по нарастающей, ведь вчерашние сообщения оплачиваются и сегодня, и завтра, а вместе со счетом растет задержка — огромный контекст надо прочитать перед первым словом ответа. Отдельно страдает качество. Чем больше в окне постороннего шума, тем выше шанс, что модель зацепится за него вместо инструкции.
Есть и отдельная беда, ее называют потерей в середине (lost in the middle). Если нужный фрагмент лежит не в начале и не в конце гигантского окна, а где-то посередине, модель его будто не замечает. Для русскоязычных проектов все это больнее вдвойне, ведь русский текст токенизируется примерно вдвое дороже английского - то же самое окно вмещает меньше смысла.
Дальше это упирается уже в деньги. Агент, который забывает вчерашние договоренности, не годится для многодневных задач, а внедряют его как раз ради них. Про то, что вообще считать агентом и из чего он состоит, у нас есть отдельный разбор - что такое AI-агент простыми словами.
Чем память агента отличается от контекстного окна
Контекстное окно — это то, что модель видит прямо сейчас, а память — то, откуда в окно попадает нужное. Путать их и значит собрать агента, который либо ничего не помнит, либо помнит все и разоряет владельца.
- живет один вызов модели;
- оплачивается токенами каждый раз;
- ограничено сверху жестко;
- наполняет его обвязка, модель только читает.
- живет между сессиями и месяцами;
- хранится на диске и почти ничего не стоит;
- ограничена только местом;
- работает, только если из нее умеют выбирать.
Внутри самой памяти принято различать четыре типа, и путать их тоже не стоит — у каждого свои правила записи и обновления.
- Рабочая (краткосрочная) - текущий диалог и промежуточные шаги задачи. Живет в окне и буфере сессии.
- Эпизодическая - события с привязкой ко времени. «Второго июля переделали схему публикации, потому что сломался вебхук».
- Семантическая - факты и знания без привязки к событию. Регламенты, документация, справочники. Это то, что обычно называют базой знаний.
- Процедурная - инструкции о том, как действовать. Порядок шагов, правила, готовые сценарии.
Разделение не академическое. Эпизодическую запись нельзя молча перезаписать, ее надо датировать, иначе агент потеряет причину решения. Процедурную, наоборот, нужно держать в одной актуальной версии, иначе он будет выполнять два противоречащих регламента сразу.
Четыре слоя рабочего пространства агента
Удобнее всего думать о памяти как о рабочем столе, а не как о жестком диске. На столе лежит только то, что нужно под текущую задачу, остальное разложено по ящикам и достается по требованию.
- Сессия - сам рабочий стол. Текущая переписка, открытые файлы, промежуточные результаты.
- Короткий файл памяти - блокнот с устойчивыми фактами о проекте и владельце. Только выжимка, лента событий сюда не пишется.
- База знаний - шкаф с документами. Регламенты, вики, статьи, исходники.
- Скиллы - технологические карты. Пошаговые инструкции под конкретный тип задач.
Больше всего экономит четвертый слой. Скиллы подгружаются выборочно, в промпт идут только короткие описания, а полностью читается лишь тот, что нужен под текущий шаг. Про то, как устроена обвязка, которая всем этим управляет, мы писали в материале про harness и цикл работы агента.
Где хранить историю, чтобы она не съедала бюджет
Историю сообщений правильнее держать в базе с полнотекстовым поиском. На первых сотнях сообщений разницы, впрочем, не видно, а вот на десятках тысяч чтение тяжелых Markdown-файлов становится узким местом.
Посмотреть, как это выглядит в живой системе, проще всего на Hermes Agent от лаборатории Nous Research - открытом self-hosted агенте, у которого схема памяти описана в документации до конкретных лимитов. Мы разбирали сам продукт в отдельной статье про агента Hermes и его настройку, здесь интересна только механика хранения.
- Файл фактов
- MEMORY.md, лимит 2 200 знаков (около 800 токенов) — заметки агента о среде и договоренностях.
- Профиль владельца
- USER.md, лимит 1 375 знаков (около 500 токенов) — предпочтения и стиль общения.
- История
- SQLite-база state.db с индексом FTS5, поиск возвращает реальные сообщения без пересказа, около 20 мс на запрос.
- Внешние хранилища
- девять подключаемых провайдеров памяти, от Mem0 до графовых и гибридных.
Цифры из официальной документации Hermes Agent, проверено: август 2026.
Обратите внимание на порядок величин. Две тысячи знаков на всю долгую память выглядят издевательски мало, пока не поймешь замысел. Файл устойчивых фактов и не должен расти, ведь его задача — дать агенту опору на старте, а не заменить собой архив. Все остальное достается поиском по требованию и в промпте постоянно не висит.
Второй элемент схемы — сжатие. Когда транскрипт подбирается к порогу (в нашей сборке это 75% окна), старая часть диалога заменяется резюме, свежие сообщения остаются дословно, а полная хронология уезжает в базу. Так нить разговора живет месяцами, не раздувая счет.
RLM против классического RAG
Классический RAG работает линейно, а рекурсивный подход — итеративно, и в этом вся разница. RAG берет запрос, находит десяток похожих фрагментов и вставляет их в промпт. Если нужного куска в топе не оказалось, ответ будет уверенным и неверным.
Рекурсивные языковые модели (Recursive Language Models, RLM) заходят с другой стороны. Длинный контекст для них — не текст в промпте, а внешняя среда, которую модель обходит сама, разбивая на части и рекурсивно вызывая себя на нужных кусках. В препринте Alex L. Zhang, Tim Kraska и Omar Khattab (декабрь 2025, ревизия май 2026) метод дает прирост в 26% против сжатия контекста на GPT-5 и 13% против Claude Code на длинных задачах, при сопоставимой стоимости вычислений.
Практический смысл рекурсии — в промежуточном шаге «осмотреться». Прежде чем отвечать, агент оценивает, каких данных ему не хватает, и делает точечные добавочные запросы. Это дороже по вызовам, зато честнее по результату.
Одна оговорка все же нужна. Авторы препринта проверяли метод на статичных документах, а живая среда меняется прямо под руками агента, и схему для нее приходится адаптировать.
Пирамида правды и вики как конституция системы
Когда источников много, нужен формальный порядок старшинства — иначе агент будет верить вчерашней реплике из чата больше, чем регламенту. Это и есть пирамида контекстов.
- Вершина — вики. Устойчивые правила, архитектура ролей и контракты между агентами. Тут-то почти ничего и не меняется.
- Середина — справочные файлы. Факты о проекте и о владельце, короткие заметки памяти, которые правятся осознанно и нечасто.
- Основание — история диалогов. Самый волатильный слой, где вчера договорились об одном, а сегодня передумали.
Идею такой вики предложил Андрей Карпаты, и она быстро разошлась по индустрии — в Hermes ее уже встроили отдельным скиллом. База знаний тут собирается под машинный поиск, а не под человеческое чтение. Агент один раз перерабатывает сырые источники в связанные Markdown-страницы с перекрестными ссылками, и дальше вопросы адресуются вики, тогда как исходники лежат нетронутыми.
В реализации этого паттерна в Hermes структура трехслойная. Каталог raw хранит неизменяемые источники — агент их читает, но не правит. Каталог wiki содержит страницы сущностей, концепций и сравнений, которые агент создает и переписывает сам. Файл SCHEMA.md задает правила и таксономию тегов. Плюс журнал log.md, который ротируется на пятистах записях, чтобы не разрастаться.
Операций всего три — загрузить источник, задать вопрос, проверить целостность. Третья интереснее прочих, потому что проверка ищет страницы-сироты, битые ссылки, противоречия между страницами и расхождение с первоисточником. По сути линтер, только для знаний.
Гибридный поиск и почему Markdown главнее вектора
Чисто семантический поиск промахивается там, где важно точное слово — имя файла, номер версии, название команды. Поэтому поиск делают гибридным, смешивая смысловую близость с обычным текстовым совпадением.
В нашей сборке пропорция такая — 75% веса отдано семантике через векторную базу и 25% точным вхождениям слов. Эмбеддинги считает локальная модель на 384 измерения, так что индексация ничего не стоит и не зависит от внешнего API. Пропорция не догма, ведь чем больше в проекте технических идентификаторов, тем сильнее стоит поднимать текстовую долю.
И главное правило иерархии данных. Оригинал знаний — Markdown-файл на диске, векторная база — всего лишь поисковая копия. Если содержимое вектора и файла разошлось, агент обязан верить файлу и переиндексировать запись. Конфликты между самими файлами решаются по метке времени, приоритет у более свежей.
Побочная выгода от Markdown — прозрачность. Открываете хранилище в Obsidian и видите граф связей ровно в том виде, в каком его строит агент. А вот отлаживать память через интерфейс векторной базы куда мучительнее.
Типичные ошибки при сборке памяти
Почти все проблемы с памятью сводятся к пяти сценариям, и все пять чинятся на этапе проектирования, а не подбором модели помощнее.
- Все в контекст. Историю целиком отправляют в промпт «чтобы не потерялось». Счет растет, ответы тупеют, и виноватой почему-то назначают модель.
- Память как свалка. В файл фактов пишут каждую мелочь, через месяц там противоречия, а лимита в 2 200 знаков хватает ровно на мусор.
- Правки мимо оригинала. Обновили базу эмбеддингов, а Markdown не тронули. Дальше агент отвечает по устаревшей копии, причем звучит при этом на редкость убедительно.
- Источники без старшинства. Регламент и случайная реплика из переписки весят одинаково, поэтому агент выполняет то, что нашлось последним.
- Запись без даты. Эпизодический факт сохранили без метки времени, и правило разрешения конфликтов по свежести перестает работать. Через полгода уже не разобрать, какая версия договоренности актуальна.
Как обслуживать память, чтобы она не зарастала мусором
Память замусоривается сама собой, поэтому обслуживание закладывают в систему сразу. Без регулярной чистки короткий файл фактов через пару месяцев наполовину состоит из дублей и отмененных договоренностей.
Рабочая схема — отдельная фоновая задача, что-то вроде cron для памяти. Раз в неделю или в месяц агент-смотритель перечитывает файлы фактов и профиль владельца, склеивает дубли, сжимает устаревшее, помечает противоречия и снимает то, что уже неверно. Там же прогоняется проверка целостности вики — сироты, битые ссылки, расхождения с источником.
Отдельно стоит договориться, что вообще попадает в долгую память. Хорошее правило — записывать только то, чего нельзя вывести из репозитория и истории коммитов. Кстати, оно же экономит место в лимите. Структура кода, прошлые правки и стандартные соглашения там уже есть, а вот «почему выбрали именно этот способ публикации» не восстановить ниоткуда.
С чего начать, если агент у вас уже работает
Начинать стоит не с векторной базы, а с разделения слоев — это дает основной эффект и почти ничего не стоит. Дальше добавляется поиск, потом вики, и только затем рекурсия.
И трезвая оговорка напоследок. Полная архитектура нужна не каждой задаче. Если агент выполняет одну узкую операцию по расписанию — скажем, наш бот кросспостинга Aisha раскладывает один пост по Telegram, VK, Threads и MAX, — его «память» сводится к профилю подключенных каналов и очереди отложенных публикаций. Ни вики, ни рекурсивного поиска там не нужно, и городить их означало бы усложнять систему без выигрыша. Многослойная память окупается там, где задача многодневная и контекст накапливается неделями. Про выбор между узким инструментом и универсальным агентом мы разбирали подробнее в материале про автоматизацию бизнеса с помощью ИИ.
Частые вопросы
Чем память ИИ-агента отличается от контекстного окна?
Окно — это то, что модель видит в момент одного вызова, и оно оплачивается токенами каждый раз. Память — хранилище на диске, которое живет между сессиями и стоит копейки. Задача архитектуры в том, чтобы из памяти в окно попадало только нужное под текущий шаг.
Обязательно ли нужна векторная база?
Не обязательно. На небольших объемах хватает полнотекстового поиска — Hermes Agent, например, ищет по истории через SQLite с индексом FTS5 и отдает реальные сообщения примерно за 20 мс. Вектор нужен там, где искать надо по смыслу, а точных слов в запросе нет.
Что делать, если данные в векторе и в файле разошлись?
Верить файлу и переиндексировать запись. Markdown на диске считается оригиналом, векторная база — поисковой копией. Если расходятся два файла между собой, приоритет отдается тому, у которого свежее метка времени.
Сколько фактов стоит держать в постоянной памяти?
Меньше, чем кажется. В Hermes Agent под заметки агента отведено 2 200 знаков, под профиль владельца — 1 375 знаков. Ограничение работает как фильтр, поэтому в постоянную память попадает только то, что нельзя вывести из репозитория, документации или истории переписки.
Чем RLM лучше обычного RAG?
Рекурсивная схема не ограничивается одним поиском — модель сама оценивает, каких данных не хватает, и делает добавочные запросы. По препринту авторов метода это дает около 26% прироста против сжатия контекста на GPT-5. Платить приходится большим числом вызовов и более сложной отладкой.
Как часто нужно чистить память агента?
Хватает фоновой задачи раз в неделю или раз в месяц — в зависимости от того, насколько активно агент пишет заметки. Смотритель склеивает дубли, сжимает устаревшее и прогоняет проверку вики на сироты и битые ссылки.
Можно ли обойтись готовым решением вместо своей архитектуры?
Можно, готовых провайдеров памяти хватает — от Mem0 до графовых хранилищ, в Hermes их подключается девять штук на выбор. Но правила старшинства источников и регламент чистки все равно придется описать самому — это знание про ваш проект, и в библиотеке ему взяться неоткуда.
