Почему AI-агент забывает ваш проект (и что с этим делать)

Коротко: агент забывает проект не потому, что «плохая модель», а потому что его память — это окно контекста, и только оно. Между сессиями окно сбрасывается, внутри длинной сессии его режет сжатие, а отдельного слоя, где лежало бы состояние проекта, в дефолтной связке нет. Лечится это добавлением такого слоя — от простого файла с правилами до MCP-памяти; что выбрать, зависит от того, что именно теряется у вас.

Три причины забывания

Когда агент «всё забыл», конкретная причина обычно одна из трёх — и у каждой свой ремонт.

1. Окно сбрасывается между сессиями. Модель не хранит ничего между запусками. Каждая новая сессия — это чистый лист плюс то, что клиент положил в контекст: system prompt, правила проекта, может быть, несколько файлов. Вчерашний разговор о том, почему вы выбрали Postgres, в этот список не входит. Симптом: в начале каждой сессии вы заново объясняете проект.

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

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

Диагностика: какой у вас случай

Проведите неделю, отмечая моменты, когда агент что-то потерял. Обычно картина складывается быстро:

• Теряется всё между сессиями, внутри сессии всё помнит → причина 1, вам хватает устойчивого контекста на старте.
• Теряет договорённости внутри длинных сессий → причина 2, нужны короткие сессии плюс запись фактов по ходу.
• Теряет решения и их мотивы («почему мы так сделали»), даже если вы их повторяли → причина 3: решения нигде не живут, кроме чатов.
• Теряет статусы работ («что сейчас в работе, что сделано») → снова причина 3: состояние задач не существует вне вашей головы.

У большинства команд, которые работают с агентом каждый день, диагноз — комбинация 1+3.

Спектр решений

Решения выстраиваются в линейку по силе и цене внедрения.

Файл правил (CLAUDE.md, AGENTS.md, .cursor/rules). Статичный документ, который клиент подкладывает в каждую сессию. Хорошо несёт стандарты: «деплой только через скрипт», «тесты обязательны». Плохо — состояние: файл правил не обновляется сам, и «что мы решили вчера» в него не попадает, пока вы сами не впишете. Стоимость внедрения — вечер.

RAG по документам. Индексация репозитория, вики, прошлых документов; агент ищет по ним смысловым поиском. Хорошо отвечает на вопрос «что у нас написано про X». Плохо отвечает на «что мы решили про X» — решения в чатах, а не в документах, и RAG их не видит. Плюс инфраструктура: эмбеддинги, индекс, переиндексация.

MCP-память (наш вариант — MaxGraph). Отдельный сервер, где агент сам ведёт граф знаний: сущности проекта, решения владельца, открытые баги и задачи, события. В начале сессии агент читает дайджест, по ходу — записывает факты, в конце — закрывает сессию с итогами. Состояние живёт вне окна, поэтому переживает и смену сессии, и compaction. Заодно это дешевле по токенам: старт сессии с дайджестом стоит ~4 200 токенов против ~8 900 у чтения проекта с нуля.

Когда что выбирать

• Одиночный проект, короткие задачи, агент нужен «подправить и забыть» — достаточно файла правил. Состояние у вас в голове, и это нормально.
• Агент каждый день, один проект, раздражает пересказ по утрам — MCP-память. Именно этот случай закрывает дайджест на старте и запись решений по ходу. Настройка: 10 минут для Claude Code или для Cursor.
• Большая база документов, вопросы в основном «где написано» — RAG, возможно поверх памяти.
• Несколько проектов и людей, решения теряются между ними — память с разделением по проектам; RAG по документам — дополнением, не заменой.

Частый сценарий — начать с файла правил, через месяц упереться в «он не помнит вчерашнее» и добавить память. Это нормальный путь: слои дополняют, а не заменяют друг друга.

FAQ

Большое окно контекста (1M токенов) не решает проблему? Нет. Окно сбрасывается между сессиями независимо от размера. А внутри сессии длинный контекст ухудшает точность: модель хуже находит детали в середине простыни. Размер окна лечит симптом, не причину.

А если просто писать подробные промпты в начале сессии? Работает, но ценой вашего времени и полноты. По нашим замерам ручной брифинг конкурентен по токенам, но человек пишет его каждый раз и в упаковку на 1 500 символов не влезают десятки решений и статусы задач.

Память — это не просто ещё один файл с заметками? Нет, и разница в том, кто пишет. Файл с заметками ведёте вы. Память ведёт сам агент — по протоколу: записывает решение в момент принятия, обновляет статус задачи при закрытии, читает дайджест на старте. Ваша роль — не писать, а проверять.

Мои данные уходят в облако? Зависит от реализации. MaxGraph — локальный сервер, данные лежат в data/ на вашей машине, экспорт в JSON в один клик. Интернет нужен один раз — для активации лицензии после триала.

Что дальше

• Обзор всех подходов к памяти: гид по памяти агентов.
• Как устроено сжатие и что при нём теряется: про compaction.
• Сравнение MCP-памяти с готовыми сервисами: MaxGraph vs Mem0 и Zep.
• Термины: глоссарий памяти агентов.