Память у AI-агентов: как агент помнит контекст

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

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

Почему модель не помнит ничего

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

Отсюда два следствия. Первое: «память» в пределах одного разговора — это просто растущий массив сообщений, и он ограничен размером контекстного окна. Второе: как только сессия закончилась, массив выбросили — и агент действительно ничего не помнит. Если вы только знакомитесь с темой, начните с базы: что такое AI-агент простыми словами.

Три уровня памяти у агента

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

1. Контекст сессии (короткая память)

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

2. Рабочая память (заметки по ходу задачи)

Агент сам записывает промежуточные результаты во внешнее хранилище — обычно в обычные файлы вроде NOTES.md или progress.md. Смысл в том, что план, найденные факты и статус задачи переживают обрезку контекста: даже если историю сообщений свернут в краткую выжимку, файл на диске останется. Anthropic в своём материале по контекст-инжинирингу называет этот приём structured note-taking и сравнивает его с тем, как человек ведёт список дел вместо того, чтобы держать всё в голове.

3. Долговременная память (между сессиями)

Знания, которые должны пережить перезапуск: предпочтения пользователя, конвенции проекта, накопленный опыт («в этом репозитории тесты запускаются так»). Хранится во внешней базе — файлах, СУБД, векторном индексе или графе знаний — и подтягивается в контекст выборочно, когда нужна.

Что ломается, когда контекст просто растёт

Соблазн очевидный: взять модель с окном на миллион токенов и складывать туда всё подряд. На практике это упирается в три стены.

• Деньги и скорость. Стоимость запроса линейно зависит от объёма входа, а задержка растёт вместе с ним. Подробнее — в заметке о том, как считать токены и экономить.
• Деградация внимания. Anthropic прямо формулирует: «context rot» — по мере роста числа токенов способность модели точно извлекать информацию из контекста снижается. Контекст стоит считать конечным ресурсом с убывающей отдачей, а цель — «наименьший набор высокосигнальных токенов».
• Мусор вытесняет сигнал. Двадцать устаревших результатов поиска и три версии файла, который агент уже переписал, не просто занимают место — они конкурируют за внимание модели с актуальными данными.

Приёмы, которыми это лечат

Компактизация (compaction). Когда переписка подходит к порогу, модель сама пишет структурированное резюме — что за задача, что сделано, какие ограничения выяснились, что дальше — и вся история заменяется этой выжимкой. В SDK Anthropic компактизация по умолчанию срабатывает на 100 000 токенов. Риск известен: слишком агрессивная свёртка теряет тонкие, но важные детали.

Очистка результатов инструментов (context editing). Более хирургический вариант: удалять не всё подряд, а только старые результаты вызовов инструментов, которые модель уже обработала. В Claude API за это отвечает стратегия clear_tool_uses_20250919: параметр trigger задаёт порог срабатывания (по умолчанию 100 000 входных токенов), keep — сколько последних пар «вызов-результат» сохранить (по умолчанию 3), exclude_tools — какие инструменты не трогать никогда. На месте удалённого остаётся заглушка, чтобы модель понимала, что данные были и их убрали. Важный нюанс: очистка инвалидирует кэш префикса, поэтому есть параметр clear_at_least — чтобы чистить сразу заметный объём и не платить за перезапись кэша впустую.

Подтягивание по требованию (just-in-time). Вместо того чтобы залить в контекст всю базу знаний заранее, агенту дают инструменты и лёгкие идентификаторы — пути к файлам, ID записей — и он сам достаёт нужное в момент работы. Механику вызова инструментов разбирали отдельно: tool calling — как ИИ вызывает инструменты.

Поиск по смыслу. Когда «памяти» становится много, простого чтения файлов мало и нужен полноценный поиск — обычно векторный. Это ровно та же механика, что и в RAG, только источником выступают не документы компании, а накопленные агентом факты.

Подагенты. Тяжёлое исследование выносят в отдельного агента с чистым контекстом, а наверх он возвращает сжатую сводку на одну-две тысячи токенов. Главный контекст остаётся незамусоренным.

Как это выглядит в реальных инструментах

Memory tool в Claude API

Anthropic отдаёт память как обычный инструмент типа memory_20250818, доступный на моделях Claude 4 и новее. Модель шлёт команды работы с файлами — view, create, str_replace, insert, delete, rename, — а выполняет их ваше приложение. Инструмент клиентский: где и как физически лежат файлы, решаете вы. Всё живёт в каталоге /memories, и API автоматически добавляет в системный промпт инструкцию сначала заглянуть в память, а по ходу работы записывать туда прогресс — с прямой оговоркой «предполагай прерывание: контекст может обнулиться в любой момент».

Отсюда же и главное требование безопасности: обязательно проверяйте пути. Всё, что не начинается с /memories или содержит ../ и его URL-кодированные варианты, должно отклоняться — иначе агент получает произвольную запись по файловой системе.

Состояние диалога в OpenAI

У OpenAI в Responses API есть три способа держать состояние: переслать всю историю руками, сослаться на предыдущий ответ через previous_response_id либо завести объект Conversation с собственным идентификатором, который можно передавать между сессиями и устройствами. Параметр store управляет хранением: по умолчанию объекты ответов держатся 30 дней, у объектов Conversation TTL нет вообще. Это удобно, но это именно состояние диалога, а не отбор знаний: контекстное окно всё равно конечно, и лишнее из него никто за вас не выкинет.

Claude Code: правила и авто-память

В Claude Code память разведена на две части. Первая — файлы CLAUDE.md, которые пишете вы: конвенции, команды сборки, архитектура проекта; они грузятся в начале каждой сессии. Про них есть отдельный разбор: как писать правила проекта в CLAUDE.md.

Вторая — авто-память, которую агент ведёт сам: он записывает найденные команды, приёмы отладки и ваши поправки в каталог вида ~/.claude/projects/<project>/memory/. Точка входа — файл MEMORY.md, из которого в начале сессии подгружаются первые 200 строк или 25 КБ (что наступит раньше), а подробности лежат в отдельных тематических файлах и читаются по необходимости. Это плоские markdown-файлы: их можно открыть, вычитать и поправить руками через команду /memory.

MCP-сервер памяти как граф знаний

Референсный memory-сервер из экосистемы MCP хранит память не текстом, а графом: сущности (люди, компании, события), связи между ними в активном залоге и «наблюдения» — атомарные факты, привязанные к сущности, по одному факту на запись. Сервер даёт инструменты на создание и удаление сущностей, связей и наблюдений плюс чтение и поиск по графу; путь к файлу хранилища задаётся переменной MEMORY_FILE_PATH. Плюс подхода — структурность и точечное удаление; минус — надо заранее договориться о схеме.

Готовые слои памяти

Если не хочется писать своё, есть отдельный класс сервисов — mem0, Letta (бывший MemGPT), Zep и другие. Логика у них похожая: сообщения проходят стадии «захват — продвижение — извлечение», из диалога автоматически выделяются устойчивые факты и раскладываются по слоям (разговор, сессия, пользователь, организация), а при поиске сначала ранжируются пользовательские воспоминания, затем заметки сессии и только потом сырая история. Прежде чем брать такой сервис, честно оцените: не решается ли ваша задача одним markdown-файлом на пользователя.

Как спроектировать память под свою задачу

Практический порядок действий получается такой.

1. Ответьте, что именно должно пережить сессию. Обычно это предпочтения пользователя, факты о его проекте и статус длинных задач — а не вся переписка целиком.
2. Начните с самого простого хранилища. Файл или строка в базе на пользователя закрывает большинство сценариев. Векторный поиск и графы — когда записей станет сотни.
3. Разделите «что писать» и «что читать». Писать в память стоит выжимку, а не сырой диалог. Читать — только то, что относится к текущей задаче.
4. Задайте правила устаревания. Память без удаления превращается в свалку противоречий: свежий факт должен заменять старый, а не ложиться рядом с ним.
5. Сделайте память читаемой человеком. Простой текст, который можно открыть и поправить, экономит часы отладки по сравнению с непрозрачными эмбеддингами.
6. Измеряйте. Смотрите на объём контекста в токенах и на то, растёт ли качество ответов от добавленных воспоминаний. Часто половину памяти можно выкинуть без потерь.

Риски, о которых легко забыть

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

Второй риск — отравление памяти. Если агент записывает в долговременное хранилище то, что прочитал во внешнем документе или на странице сайта, туда может попасть внедрённая инструкция, которая всплывёт в следующей сессии уже как «собственное знание» агента. Поэтому память нужно считать недоверенным входом и по возможности отделять факты, извлечённые из внешних источников, от подтверждённых пользователем. Подробнее про границы прав и журналирование — в заметке о безопасности AI-агентов.

Коротко

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