Память: что записывать, что обновлять, что забывать

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

Память: что записывать, что обновлять, что забывать

Память агента — это решение о том, какая информация переживёт конец сессии, в какой форме и по какому правилу она устареет. Инструменты вторичны: Richmond Alake из MongoDB прямо говорит, что «нет одного способа решить память», у каждой команды выходит своя схема. Дальше — про то, что здесь уже измерено, а что остаётся открытым.

Четыре типа памяти — и зачем их различать

Рабочая рамка, на которую сходятся почти все источники, — CoALA (Cognitive Architectures for Language Agents, Принстон), в изложении IBM Technology: working (само окно контекста), semantic (факты, знания, конвенции), procedural (как делать — skills, файлы правил), episodic (что случалось в прошлых сессиях и чему агент научился). Lance Martin из LangChain даёт ту же тройку с привязкой к реализации: семантическая — факты, эпизодическая ложится на few-shot примеры, процедурная — на rules-файлы вроде CLAUDE.md, и она обычно грузится целиком при старте, а факты подтягиваются выборочно.

Различать их нужно ради одного практического вывода, который IBM формулирует напрямую: не каждому агенту нужны все четыре. Рефлекторному агенту (термостат, роутинг-бот) хватает working. Узкому саппорт-агенту, который сбрасывает пароли, — working и procedural. Все четыре нужны кодинг-агенту. Это дешёвый критерий «не строить лишнего».

Второе наблюдение IBM снимает половину инфраструктурных фантазий: академическая литература описывает semantic memory как векторные БД и графы знаний, «но в большинстве продакшн-систем сегодня это просто .md-файлы» — CLAUDE.md в корне проекта с архитектурой, конвенциями и списком того, чего делать нельзя. Платится за это постоянным расходом окна, потому что файл грузится в каждую сессию (об этом — в следующей части).

Самый трудный тип — эпизодический. Наивная реализация (сохранять транскрипты и искать по ним) формально эпизодическая, практически бесполезна. Продакшн-системы дистиллируют: строка «в прошлый раз при отладке auth-модуля проблема была в middleware-слое» полезнее полного транскрипта 45-минутной сессии. IBM честно перечисляет, что здесь не решено: что удалять, когда информация устаревает, хранить ли проектные воспоминания после того, как пользователь сменил работу. «Забывание для агентов — инженерная задача».

Измеренный эффект: Datadog и флип-флоп решений

Самый полезный количественный результат в этой теме — у Diane Lin из Datadog (доклад «Why Your Agent Disagrees With Itself»). Постановка: агент-триажер алертов безопасности, 93 алерта, каждый прогоняется три раза. В 25% случаев решения между прогонами расходятся — тот же вход, тот же промпт, разный вердикт. Из этих 25 процентных пунктов 15 закрывает эпизодическая память, оставшиеся 10 уходят человеку.

Механика простая и воспроизводимая маленькой командой. Эпизодическая память — «я видел похожие случаи, их пометили benign», без дистилляции причины. Она автоматически закрывает повторяющиеся случаи, а в безопасности повторы — основная масса шума. Остаток идёт человеку, человек дистиллирует правило в семантическую память: «password spray без успешного входа — benign, с успешным входом — malicious». В следующий раз правило работает само. Ключевой выбор Datadog: после нахождения спорных точек модель переобучать не стали, файнтюн дорог и медленно итерируется. Вместо этого систему дополнили двумя видами памяти.

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

Что произошло: уверенность модели оказалась бесполезным сигналом

• Кто: Diane Lin, Datadog («Why Your Agent Disagrees With Itself»).
• Что делали: искали способ автоматически находить решения, которым нельзя доверять. Пробовали самооценку модели («насколько ты уверен в вердикте»), затем — расхождение между тремя независимыми прогонами одного и того же алерта на выборке из 93 алертов.
• Результат: самооценка уверенности оказалась ненадёжной — модель уверенно ошибается и неуверенно попадает. Работает только межпрогонное расхождение: 25% флип-флопа, из которых 15 п.п. снимает эпизодическая память, 10 п.п. остаются человеку.
• Вывод: не спрашивай модель, уверена ли она. Гоняй один и тот же вход несколько раз и смотри на дисперсию ответа — это и есть детектор мест, где памяти не хватает.

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

Консолидация: что Anthropic называет «dreaming»

Второй измеренный кусок — консолидация памяти между сессиями. Anthropic (команда платформы, доклад «Memory and dreaming for self-learning agents») описывает отдельный фоновый процесс, который проходит по накопленным воспоминаниям и сворачивает их: пять почти одинаковых записей об одном и том же — в одну, а повторяющийся паттерн через несколько сессий выделяется примерно за 60 секунд работы процесса. Эффекты у клиентов, на которые ссылается Anthropic: Harvey — шестикратный рост завершения задач, Rakuten — минус 90% ошибок первого прохода.

К этим цифрам стоит относиться как к вендорским: методика замера публично не разложена, а базовая линия («до чего именно 6×») не описана. Но направление совпадает с тем, что говорят все остальные: память без регулярной переработки деградирует. Emre из OpenAI («Build Hour: Agent Memory Patterns») называет консолидацию — слияние, очистку и переписывание памяти — отдельной регулярной операцией, наравне с записью и чтением.

Архитектурно Anthropic описывает эволюцию от claude.md через memory tool в SDK к памяти как файловой системе, которой модель управляет сама через bash и grep. Логика перехода — «уходить с дороги модели». Вокруг этого три слоя проектирования: storage (где лежит, какие метаданные и атрибуция), structure/content (файлы, skills), process (что и как часто триггерит обновление). Из требований клиентов чаще всего всплывает version history с атрибуцией «какой агент, когда, в какой сессии внёс правку» — маленькой команде это даёт обычный git поверх каталога памяти.

Cognition: механизм записи важнее хранилища

Walden Yan из Cognition (система knowledge в Devin) даёт цифру, которая переворачивает приоритеты: около 95% всех воспоминаний Devin сгенерированы автоматически. Логика — «очень мало кто садится писать большие доки о том, как работать с технологией», поэтому Devin сам предлагает память: как только человек поправил агента («нет, git у нас используют не так»), Devin предлагает это запомнить, а человек одним движением подтверждает или отклоняет. Автомерж таких записей, по их наблюдениям, живёт порядка двух недель — дальше правило либо подтверждается практикой, либо начинает мешать и требует ревизии. Стоимость всей этой памяти считают на инженера, потому что большая часть записей персональна («Cole обычно предпочитает draft PR»).

Отсюда два названных провала памяти. Переобобщение при генерации: разовая просьба «открой draft PR» не должна превращаться в правило «все и всегда открывают draft PR» — правильный уровень фиксирует, кто и что обычно предпочитает. Промах при retrieval: при тысячах воспоминаний нужно достать нужные, не взорвав окно бесполезными. И честное предупреждение: «удивительно много eval-работы уходит только на то, чтобы память оставалась надёжной по мере смены моделей». Если строишь накопительную память — закладывай на неё бюджет тестов, а не только хранилище.

Главная ловушка: semantic similarity и business relevance — разные вещи

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

Ishita Daga из Tesla («Enterprise Agents Have a Structure Problem») даёт чистый пример. Команда A считает «среднее время до вехи» от завершения предыдущей вехи до завершения текущей, команда B — от старта текущей до старта следующей. Обе метрики верны и дают разные числа. Semantic layer хранит оба определения, agent memory (mem0, memory.md) хранит предпочтение — но не понимает разницы между двумя метриками и того, когда какую брать. Автор называет это открытой проблемой индустрии: нужен роутинг, который учитывает, кто и из какой команды спрашивает, а не только близость векторов.

Практический ответ, который уже работает, — типизировать память под домен. Daniel Chalef из Zep и Graphiti предлагает вместо «извлекаем любые факты» описать бизнес-объекты своего домена — FinancialGoal, DebtAccount, IncomeSource — через Pydantic, Zod или Go structs, с полями и бизнес-правилами, и зарегистрировать их при старте приложения. Retrieval после этого фильтруется по типам нод, а инструмент «получить финансовый снапшот» реализуется несколькими параллельными поисками, каждый со своим фильтром по типу, — то есть форму ответа задают заранее, а не выводят из top-k. Его же вывод: универсальной памяти не бывает, модель памяти обязана повторять бизнес-домен. Для маленькой команды это буквально несколько pydantic-классов.

Более дешёвый вариант того же принципа — у Arize: вырезанная середина контекста лежит в базе с ID, а инструмент отдаёт список ID, позицию в разговоре и короткий preview, чтобы агент сам решил, что вытащить обратно. И трезвая оценка от Ian Gotts, который держит около тысячи «мыслей» в личном графе: «всегда ли правильно достаёт? нет, не обязательно».

Что забывать и как память устаревает

Richmond Alake (MongoDB) описывает memory management как шесть компонентов: generation, storage, retrieval, integration, updating, deletion — и тут же оговаривается, что deletion в этом списке «ложь»: правильно реализовывать механизмы забывания, а не удаления. У него для этого заведены memory signals: recall count, recency, ID связанной беседы. Дальше — набор рабочих приёмов из разных источников:

Временные метки на каждом факте (Emre, OpenAI). «Люблю собак» два месяца назад против «люблю кошек» сегодня — новая память должна перекрыть старую, и модель должна видеть, что старее.

Weight decay или оконная функция, понижающая вес старых воспоминаний, — там же.

Temporal pruning (Carly Richmond, Elastic): удалять из хранилища всё старше порога. В демо порог — две недели: было 30 сообщений в индексе, удалено 15, осталось 15. Элементарно реализуемо любой командой.

Отбраковка по структуре графа (Vasilije Marković, Cognee): слабосвязанный узел с высоким шумом — кандидат в ошибочные; веса на рёбрах и нодах с temporal weighting показывают, как релевантность падает во времени; отсутствие причинных связей — индикатор недостоверности. Общего решения авторы не обещают: «зависит от use case».

Повышение сессионной памяти до глобальной (Emre, OpenAI): предпочтение, повторяющееся от сессии к сессии, «выпускается» в постоянное.

Против этого есть честное возражение. Nyah Macklin (Neo4j) напоминает, что скользящее окно и рецентность — компромисс: агент теряет важные детали просто потому, что счёл их старыми, критерий возраста не совпадает с критерием важности. Поэтому инварианты («это должно выжить любой ценой») стоит держать отдельным слоем, а не отдавать на откуп decay: Anthropic ровно так и разделяет compaction («это, наверное, больше не нужно») и memory tool («это должно выжить»).

И бытовое, но обязательное. Практик Jono Catliff показывает аккаунт с 17 записями автоматической памяти, среди которых — демо-проект из ролика на YouTube, который в памяти не нужен. Его практика: периодически спрашивать «покажи все свои воспоминания обо мне» и удалять лишнее. Проблема тут структурная: файл памяти не лежит в репозитории и не ревьюится как код. В Claude Code автоматическая память живёт в ~/.claude/projects/<проект>/memory/memory.md и при старте грузится первыми 200 строками — то есть сама память нуждается в курировании и структуре из индекса и отдельных файлов.

Наконец, граница знания. Dan Biderman (Engram) ставит вопрос «что интернализовать в веса, а что вынести в заметки» как открытый и признаёт, что некоторое забывание полезно: как только начинаешь вручную решать, что внутрь, а что наружу, получаешь whack-a-mole — у каждой компании свои данные. Его итоговая позиция трезвая: текстовые представления никуда не денутся, потому что интерпретируемы и аудируемы, а параметр-эффективные методы — слой поверх них.

Что с этим делать

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

Меряй расхождение прогонов. Прогоняй один и тот же вход 2–3 раза и смотри на разброс вердиктов. Самооценка модели как фильтр не работает (Datadog). Места расхождения — это ровно список того, чего не хватает в памяти.

Записывай автоматически, подтверждай в одно движение. 95% памяти Devin — автогенерация с подтверждением или отклонением (Cognition). Механизм записи важнее выбора хранилища. Проактивную документацию никто писать не будет.

Типизируй память под домен и фильтруй retrieval по типам. Похожесть по эмбеддингу и релевантность — разные вещи (Tesla, Zep). Несколько параллельных поисков с фильтром по типу лучше одного top-k.

Заведи регулярную консолидацию и явный порог забывания. Дедупликация близких записей (Anthropic), временные метки и decay (OpenAI), pruning старше N недель (Elastic). Инварианты выноси в отдельный слой, который decay не трогает.

Держи память под git и ревьюй её как код. Version history с атрибуцией — самое востребованное свойство у клиентов Anthropic. Маленькой команде это даёт обычный репозиторий, периодическая ручная ревизия (Catliff) и структура из индекса и отдельных файлов из-за лимита в 200 строк.