Просыпаясь, агент ничего не помнит: что такое память агента и зачем ею управлять

Ещё в мартовской статье про агентный RAG я написала, что управление памятью агента ощущается как очень горячая тема, в которую мне хочется погрузиться. Погружение было хаотичным, и только приглашение Хольгера Цшайге для выступления на митапе Moscow Legal Hackers по теме архитектурных подходов к контекстному инжинирингу побудило как-то собрать свои находки и мысли в одну корзинку. И именно часть про агентов я на митапе рассказать не успела подробно, поэтому появился этот пост. Он скорее обзорный и установочный: что такое память агента, почему ей необходимо управлять и какие существуют верхнеуровневые подходы.

Презентацию, подготовленную для митапа, прикладываю сюда. Этот пост раскрывает детальнее слайды 14 и 15 из неё.

Memento

Контекстное окно — это всё, что модель держит перед глазами в момент ответа. Системный промпт вендора, описания подключённых инструментов, ваши постоянные инструкции, приложенные документы, результаты веб-поиска и вызовов инструментов, история диалога, размышления модели. Ресурс ичерпаемый и, что важнее, контекст в рамках одного чата или сессии может испортиться задолго до того, как заполнится. Явление называют context rot: качество падает не в момент исчерпания заявленного вендором окна, а сильно раньше и иногда внезапно. На слайдах расписаны типы деградации контекста.

А в конце сессии всё это — неважно, деградировавшее или спасённое от протухания — просто исчезает. Агент просыпается, но ничего не помнит, как главный герой фильма Memento Нолана. И вот тут появляется память.

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

Устройство памяти принято описывать через четыре типа, заимствованные из символьных когнитивных архитектур 1980–2000-х Soar и ACT-R (которые, в свою очередь, брали за образец нашу с вами человеческую память, об этом подробнее в канонической публикации CoALA, на которой основаны почти все фреймворки):

• Рабочая — то, что агент держит в голове по ходу решения конкретной задачи: промежуточные выводы, черновики, результаты только что выполненных действий. Живёт внутри сессии и умирает вместе с ней.
• Эпизодическая — записи о произошедшем: что делали, чем закончилось, где ошиблись. Если вы практиковали в конце длинного чата делать его суммаризацию и переносить в новый чат для продолжения, то формировали эпизодическую память.
• Семантическая — факты и знания, не привязанные к событию: некое общее описание контекста задачи и сформулированных принципов и правил её решения. Применительно к условному сценарию согласования договоров это может быть в виде пересказа вашей матрицы рисков, уполномоченных подписантов, каких-то внутренних особенностей согласования.
• Процедурная — как здесь принято работать: методика проверки, чек-лист, порядок эскалации от агента до внимания человека, требования к оформлению.

Зачем управлять памятью: помогаем агенту вспомнить

Итак, каждая сессия начинается с нуля. Что решили в прошлый раз, какая редакция актуальна, что уже проверяли, где лежит правильный шаблон — агент не знает. Причём не знает, даже если все артефакты остались лежать в папке. Наличие файлов не равно памяти о них: агент должен ещё догадаться туда посмотреть и понять, что из этого важно. Здесь помогает навигационный слой (здесь, я надеюсь, вы уже сами достроите аналогию с фильмом Нолана), о котором ниже будет чуть подробнее.

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

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

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

OWASP (Open Worldwide Application Security Project) — некоммерческая организация, которая много лет ведёт списки главных рисков для веб-приложений; её top 10 стал фактическим стандартом, на который ссылаются в требованиях к безопасности и в договорах. В декабре 2025 года OWASP выпустил отдельный список для агентных систем, и отравление памяти и контекста идёт там под номером 6. Отравленная память переживает перезапуск сессии, очистку окна и смену модели. Подсаженная запись извлекается в будущих сессиях как собственный прошлый опыт агента.

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

Куда складывать знания: подходы

Здесь происходит главный сдвиг: инженерия контекста перерастает в инженерию знаний. Термин knowledge engineering не новый и не маркетинговый — дисциплина существует не первое десятилетие, у неё есть даже собственный стандарт ISO/IEC 5392:2024. Сейчас пришло время сдуть пыль с этой дисциплины и немного пересобрать под, так сказать, технологические вызовы времени.

В январе 2026 года KPMG выпустили доклад «The knowledge engineering imperative», и мысль там ровно та, которая несколько раз звучала на митапе Moscow Legal Hackers: у людей и у агентов принципиально разные потребности в данных. Все привычные форматы — таблицы, дашборды, схемки и инфографики с картинками — сделаны для человеческого глаза, который сам достроит недостающий смысл. Knowledge engineering у KPMG — это дисциплина описания знаний организации так, чтобы ими могла пользоваться машина. И первое, что нужно сделать, — сделать собственные знания понятными и доступными агенту. Предоставление доступа или раскладка в неком рабочем пространстве может быть устроена по-разному.

Базовый минимум: файлы в папках

Обычные текстовые файлы в понятной структуре папок, предпочтительный формат — markdown. У него несколько удобных свойств: он в целом понятен и человеку даже без специальных редакторов, он особенно понятен LLM, так как по сути является текстом, и его можно легко версионировать.

Формат давно массовый, есть довольно много инструментов для управления md-документацией. В Obsidian база знаний — буквально папка с .md-файлами. В российском Gramax (на котором работает открытая База знаний по нейросетям для юристов) визуальный редактор надстроен над git, а под капотом те же markdown-файлы; так же устроены открытые Wiki.js, BookStack и Outline. У Яндекс Вики свой близкий к markdown вариант поверх стандарта CommonMark, с переключением между визуальным режимом и режимом разметки.

Полезный критерий при выборе — не «поддерживает ли сервис markdown при вводе», а «можно ли выгрузить из него .md». Если у вас уже есть какая-то база знаний типа Confluence, то то, что статьи там хранятся не в .md — не блокер, можно воспользоваться конвертерами. Возможный блокер — это отсутствие порядка внутри.

Векторные базы

Когда корпус действительно большой и заранее не известно, какой фрагмент понадобится. Счастье для названия всех моих проектов: RAG не умер! Он переродился в один из инструментов агента (о чём я подробно писала здесь). На практике это может работать, как мой MCP-коннектор  к поисковому интерфейсу по практике ФАС. Векторная база живёт сама по себе, но агент с помощью коннектора вызывает её, когда сам решит, что по конкретному вопросу нужна практика. Не конвейер, отрабатывающий на каждый запрос, а справочник на полке, за которым ходят по необходимости.

Роскошный максимум: графы знаний

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

Из каждого утюга (LLM-вики)

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

Накладывается на любой из трёх вариантов выше. Физически это чаще всего та же папка markdown-файлов — просто с оглавлением, перекрёстными ссылками и правилом, что новый документ не кладётся в базу как есть, а разбирается в существующие страницы; сырые источники при этом хранятся отдельным слоем, чтобы можно было проверить, откуда что взялось. Ранние реализации появились у Cognition (DeepWiki, 2025), позже принцип сформулировал и вынес за пределы кодовых баз Андрей Карпати, сейчас он трансформируется разными способами разными авторами под свои потребности: например, интересный опыт описан у Степана Леонтьева.

Как складывать знания: принципы

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

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

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

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

Неверно выбран сценарий. База должна обслуживать задачу с понятным периметром, а не «все документы компании». Чем шире периметр, тем ниже качество на каждой конкретной задаче.

Концептуально работа с данными осталась ровно той же, что была в эпоху классического RAG. Изменилась расплата за беспорядок: конвейер ошибался предсказуемо и одинаково, а агент — по-разному в разных сессиях, и вы не увидите, что именно он не нашёл.

Навигационный слой

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

В экосистеме кодовых агентов это стандарт AGENTS.md: открытый стандарт, выпущенный OpenAI в августе 2025 и переданный в Linux Foundation в декабре 2025. У Anthropic своя конвенция — CLAUDE.md. В Claude Cowork ту же роль играют инструкции проекта, в других интерфейсах — системный промпт или инструкция ассистента. Плюс оглавление самой базы: индексный файл, понятные имена, метаданные.

Две рекомендации по генерации навигационного слоя:

1. Сгенерированный нейросетью файл нужно вычитывать. Соблазн очевидный: попросить модель посмотреть на папку и написать такую инструкцию за вас. Так можно, но результат требует правки. Команда ETH Zurich проверила это на 138 реальных задачах: авто-сгенерированные файлы в среднем проигрывали написанным человеком около 7 процентных пунктов. Причина не в том, что агент их игнорирует, а ровно наоборот — он добросовестно следует всему, что там написано, включая лишние и неточные пункты.
2. Файл не должен разрастаться. Anthropic рекомендует держать инструкции конкретными и краткими, класть туда то, что материально влияет на решения агента, и выносить подробности в отдельные файлы, подключаемые по необходимости.

Итого

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

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

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