Долговременная память ИИ-агента: как не терять контекст между сессиями
Если вы плотно работаете с ИИ-агентом — Claude Code или подобным, — вы уже видели эту стену. Каждая новая сессия начинается «с чистого листа»: агент не помнит ни прошлых договорённостей, ни того, как устроен ваш проект, ни ваших замечаний «делай вот так, а не так». Наивное лечение напрашивается само: свалить всё важное в один файл (обычно CLAUDE.md) и подкладывать его каждую сессию. Работает ровно до той недели, когда файл раздувается, факты в нём начинают дублироваться, а копии — расходиться. Агент читает первую попавшуюся версию правды, и вы снова тратите время на «нет, мы же договаривались иначе».
Эта статья — не «смотрите, как здорово я всё устроил». Это уже пройденный за вас путь: рабочая система из нескольких слоёв хранилищ, честный разбор, кому она вообще нужна (а кому нет), и десять граблей, на которые наступают все. В конце — готовый шаблон-репозиторий: клонируете, оставляете слои под свой масштаб, заполняете под себя.
Сначала честно: нужно ли это именно тебе
Слои памяти — не бесплатны: каждый требует поддержки (уборки, синхронизации, бэкапа). Заводить их «на вырост», заранее — значит платить за обслуживание впустую. Поэтому новый слой заводят в ответ на боль, а не заранее. Найдите свою ступень — и увидите, чего достаточно сейчас и по какому сигналу пора выше.
| Ступень | Ты здесь, если… | Чего достаточно | Сигнал «пора выше» |
|---|---|---|---|
| 0. Разовое | разовые задачи | ничего, хватает памяти одной сессии | возвращаешься к тому же и заново пересказываешь контекст |
| 1. Один малый проект | редкие сессии | один файл заметок (проектный CLAUDE.md) | заметок много, ищешь «а где я это записал» |
| 2. Один долгий проект | копятся решения и замечания | память проекта: 1 факт = 1 файл + индекс MEMORY.md | появился второй проект, знание из первого пригодилось бы |
| 3. Несколько проектов | знания пересекаются | общая вика + типизация (переносимое → вика, проектное → память) | «записал в память одного, а нужно везде»; дубли между проектами |
| 4. Крупный проект | у одного проекта свой большой объём данных | локальная вика в git проекта | память распухла, в неё сползает «журнал под видом памяти» |
| 5. Передаёшь другим | наработал повторяемые приёмы | слой навыков-методичек + обязательный бэкап | приём сработал третий раз; страшно потерять всё |
Мораль лестницы: ступень определяется не амбициями, а числом проектов и плотностью пересечений между ними. Один проект — даже большой — почти не требует слоёв. Окупаться они начинают, когда знание перетекает между проектами (это ступень 3).
Кому это НЕ нужно. Если у вас один небольшой или разовый проект — не городите систему. Один файл заметок закрывает всё. Дальше можно не читать: вернётесь, когда появится второй проект и знание из первого захочется переиспользовать.
Решение: не одно хранилище, а слои по ролям
Правильная система — это несколько хранилищ, у каждого своя роль. Их четыре.
| Слой | Что это | Роль | Где живёт (пример) |
|---|---|---|---|
| Правила поведения | инструкции агенту | «конституция», грузится в каждую сессию | глобальный CLAUDE.md + проектные CLAUDE.md |
| Память проекта | точечные факты, обратная связь | привязана к проекту, подгружается по релевантности | профиль агента: projects/имя-проекта/memory/ |
| База знаний (вика) | осмысленное переносимое знание | перелинкованная «энциклопедия» | общая вика + локальные вики крупных проектов |
| Навыки / методички | передаваемые методы-умения | оформленные приёмы для повторного применения | отдельная папка методичек в общей вике |
Ключ к слоям — не в названиях, а в вопросе «что это по типу?». Инструкция агенту, как себя вести, — правило. Разовый факт про конкретный проект — память. Знание, которое пригодится и в другом проекте, — вика. Приём, который хочется применять снова и передать, — навык. Один и тот же абзац, положенный не в свой слой, превращается в источник путаницы.
Грабля, на которую наступают все: где физически лежит память
Прежде чем про принципы — про место, потому что здесь спотыкается почти каждый. Память проекта хранится не в папке проекта. Есть два разных места, и их путают:
- Папка проекта на диске — сам проект: код, файлы. Памяти агента тут нет. Вложенная служебная папка бывает пустой или хранит только настройки — и это нормально, не пугайтесь.
- Служебная папка агента в профиле пользователя (
~/.claude) — вот тут живёт всё «агентское»: глобальные правила и подпапкаprojectsс отдельной папкой на каждый проект, а внутри —memory(файлы памяти) и логи сессий.
~/.claude), а не в папке проекта. Имя служебной папки получается из пути проекта заменой слэшей и двоеточий на дефисы — отсюда типовая растерянность «включил память, а папка проекта пустая».Связь между ними — по имени: путь проекта кодируется в имя служебной папки заменой разделителей (двоеточий и слэшей) на дефисы. Условно путь проекта D:\projects\myproject превращается в папку памяти с именем вроде D--projects-myproject. Отсюда и типовая растерянность: «я включил память, а папка проекта пустая» — потому что смотреть надо в профиль агента, а не в проект.
Почему так устроено: память и история сессий — приватные данные о работе, их держат в профиле пользователя, чтобы не засорять репозиторий и чтобы они случайно не попали в git. Вику, наоборот, кладут в папку проекта — чтобы она версионировалась вместе с ним.
Принципы — и почему они такие
Слои держатся на нескольких принципах. Каждый — не догма, а лечение конкретной боли.
- Единый источник истины. Один факт живёт в одном месте. Почему: две копии расходятся за считанные дни — и получаете «две версии правды», непонятно, какая настоящая. Прямое следствие — правило «продвинул — удали источник»: перенёс факт выше (в глобальные правила или вику) — в тот же заход удали исходную копию или ужми её до короткого указателя.
- Разделение ответственности. Правила ≠ статусы ≠ знание — каждое в своём слое. Почему: смешаешь — не найдёшь нужное и раздуешь контекст, который грузится в каждую сессию (а он не бесплатный).
- Типизация по переносимости. Тест при сомнении: «пригодится ли это в другом проекте?». Да → общая вика. Нет → память или локальная вика проекта.
- Снимок против живого состояния. Память — это фотография на момент записи, а не живое состояние. Почему важно: память устаревает и сама об этом не знает. Живые, меняющиеся статусы («этап 3», «ждём сервер», «в проде») ведите там, где они реально обновляются, а не замораживайте в памяти.
- Индекс. У каждого набора — файл-навигатор (
MEMORY.md,index.md): одна короткая строка на запись. Почему: агент читает индекс первым и по нему решает, куда смотреть. - Кросс-ссылки. Страницы знаний связывают ссылками друг на друга. Почему: сила базы знаний — в плотности связей, а не в объёме. Это и есть суть метода Карпаты (о нём — в конце).
- Сохранность. Единый источник истины защищает от расхождения, но не от потери. Про бэкап — отдельный разговор ниже, но принцип держите с самого начала.
Десять граблей — коротким кейсом каждая
Самое ценное для практика — не теория, а конкретные ямы. Вот те, в которые наступают чаще всего.
- Ищут память в папке проекта. Её там нет — она в профиле агента. Пустая папка проекта — это норма, а не поломка.
- Продвинули правило, а копию не удалили. Записали и в память проекта, и в глобальные правила — две копии разошлись. Лечение: «продвинул — удали источник».
- Универсальное правило — в память одного проекта. Память проекта грузится только в его сессиях; в других правила не будет. Универсальное правило поведения — в глобальный
CLAUDE.md. - Кросс-проектное знание застряло в памяти полигона. Наработка, полезная многим проектам, но записанная в память одного, — невидима остальным. Заведите ей «паспорт» в общей вике.
- Устаревший статус. «Ждём X», «этап N» — когда всё давно изменилось. Память — снимок; живые статусы ведите в вике, а память периодически чистите.
- Журнал под видом памяти. Файл памяти, который растет дописыванием сессия за сессией до сотен строк. Память — «один файл = один факт»; хронику выносите в архивную страницу вики.
- Смешали типы в одном файле. Правило поведения и знание в одном месте. Разделите: первое — в правила/память, второе — в вику.
- Хранилище без бэкапа. Единственная копия на одном диске, без git и удалённого репозитория. Реальный случай: вика со всеми знаниями долго жила без git — одна поломка диска стёрла бы всё.
- Имя удалённого бэкапа ≠ имя локальной папки. Репозиторий назвали иначе, чем папку, от которой зависят пути. При восстановлении
git cloneсоздаст папку по имени репозитория — и все пути, ждущие старое имя, сломаются в момент восстановления. Правило: имя репозитория = имя папки (или задокументируйте точную команду клона). - Указатель ведёт на неверный путь. Ужали память до указателя «детали — в такой-то папке», а файл лежит в другой. Файл не потерян, но переход бьётся — и это тихо: проверка «а есть ли файл с таким именем?» проходит, потому что имя-то верное. Лечение: после ужатия сверять путь указателя целиком — имя и папку.
Гигиена: уборка и бэкап
Система живёт, пока за ней убирают. Два ритуала держат её здоровой.
Периодическая уборка («линт»). Раз в несколько недель или по симптому (нашёл один дубль — почти наверняка есть и другие) проверяйте всю систему на дубли, битые ссылки, устаревшие статусы, факты не в своём слое. Важная тонкость: полный прогон делайте свежим взглядом — агент, который только что сам правил файлы, склонен подтверждать свою работу, а не проверять её. Если хранилища под git, точный журнал того, что уборка сделала, даёт история коммитов — по ней чистку удобно ревизовать постфактум.
Бэкап. Единый источник истины защищает от расхождения, но не от потери. Каждое критичное хранилище должно иметь копию вне машины: вику и проекты — под git и удалённый репозиторий (приватный, если данные личные); память — бэкапить отдельно, она не в git. Физическое расположение (какой диск) от потери не спасает — спасает копия вне машины. Системный диск переустанавливают, диски выходят из строя. Не откладывайте: незабэкапленное хранилище — риск с первого дня.
Честные границы — и чем этот подход отличается
Начистоту: это авторская сборка известных паттернов, а не готовый стандарт с одним именем. Кирпичи индустриальные: единый источник истины, разделение ответственности, слои памяти и база знаний по методу Карпаты — знание компилируется в перелинкованную вику в момент поступления, а не переоткрывается из сырых документов при каждом запросе. Первоисточник — публичный гист Андрея Карпаты (апрель 2026).
И тут важная оговорка, чтобы не продавать вам велосипед. Идея «вики для LLM по Карпаты» не уникальна — на GitHub уже есть популярные репозитории на эту тему. Ценность здесь не в самой вике, а в том, что это шаг дальше, а не её повтор:
- Многослойная типизация, а не одна вика. Правила + память проекта + вика + навыки — разнесены по ролям, а не свалены в один «умный» файл.
- Лестница масштаба и честное «кому НЕ нужно». Подход говорит не только «как сделать», но и «стоит ли вообще» — и на какой вы ступени.
- Названа грабля «где физически лежит память» — профиль агента против папки проекта. Мелочь, на которой теряют часы.
- Русскоязычно. Заметные аналоги — англо- и китаеязычные; на русском такого разбора почти нет.
И повторим границу из лестницы: система стоит своих усилий не для всех. Одному маленькому проекту хватит одного файла заметок. Слои окупаются, когда проектов несколько и знания между ними пересекаются. Конкретика (расположение памяти, имена файлов, кодирование пути в имя папки) — специфика Claude Code; принцип «слои по ролям + единый источник истины» переносится на любого агента, детали — нет.
Готовый шаблон: клонируй и заполни под себя
Чтобы не собирать это с нуля, есть открытый скелет — llm-wiki-starter (публичный, лицензия MIT). Внутри: слой правил (CLAUDE.md), демо-проект с памятью (наглядно показано, что память лежит не в папке проекта), общая вика с кросс-ссылками, шаблоны-бланки файлов памяти и страниц вики, образец оформленного навыка. Папки размечены по ступеням лестницы — включаете слои под свою ступень, остальное удаляете.
Практический порядок входа: определите свою ступень по таблице выше → клонируйте шаблон → оставьте нужные папки → разнесите то, что уже свалено в один файл, по типам → заведите бэкап вне машины. Дальше система ведёт себя сама, а вы перестаёте каждую сессию пересказывать агенту одно и то же.
Если вы только выбираете, с каким ассистентом всё это ставить, — загляните в разбор как выбрать нейросеть под задачу и в словарь: там про разницу моделей и про то, чем «модель» отличается от «агента».