Долговременная память ИИ-агента: как не терять контекст между сессиями

Если вы плотно работаете с ИИ-агентом — Claude Code или подобным, — вы уже видели эту стену. Каждая новая сессия начинается «с чистого листа»: агент не помнит ни прошлых договорённостей, ни того, как устроен ваш проект, ни ваших замечаний «делай вот так, а не так». Наивное лечение напрашивается само: свалить всё важное в один файл (обычно CLAUDE.md) и подкладывать его каждую сессию. Работает ровно до той недели, когда файл раздувается, факты в нём начинают дублироваться, а копии — расходиться. Агент читает первую попавшуюся версию правды, и вы снова тратите время на «нет, мы же договаривались иначе».

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

Сначала честно: нужно ли это именно тебе

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

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

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

Решение: не одно хранилище, а слои по ролям

Правильная система — это несколько хранилищ, у каждого своя роль. Их четыре.

Ключ к слоям — не в названиях, а в вопросе «что это по типу?». Инструкция агенту, как себя вести, — правило. Разовый факт про конкретный проект — память. Знание, которое пригодится и в другом проекте, — вика. Приём, который хочется применять снова и передать, — навык. Один и тот же абзац, положенный не в свой слой, превращается в источник путаницы.

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

Прежде чем про принципы — про место, потому что здесь спотыкается почти каждый. Память проекта хранится не в папке проекта. Есть два разных места, и их путают:

1. Папка проекта на диске — сам проект: код, файлы. Памяти агента тут нет. Вложенная служебная папка бывает пустой или хранит только настройки — и это нормально, не пугайтесь.
2. Служебная папка агента в профиле пользователя (~/.claude) — вот тут живёт всё «агентское»: глобальные правила и подпапка projects с отдельной папкой на каждый проект, а внутри — memory (файлы памяти) и логи сессий.

~/.claude/← профиль пользователя, не папка проекта├── CLAUDE.md└── projects/    └── D--projects-myproject/← имя = путь проекта: / и : → дефисы        └── memory/            ├── MEMORY.md1 факт = 1 файл            └── *.md

D:\projects\myproject\└── (код и файлы — памяти агента здесь НЕТ)

Связь между ними — по имени: путь проекта кодируется в имя служебной папки заменой разделителей (двоеточий и слэшей) на дефисы. Условно путь проекта D:\projects\myproject превращается в папку памяти с именем вроде D--projects-myproject. Отсюда и типовая растерянность: «я включил память, а папка проекта пустая» — потому что смотреть надо в профиль агента, а не в проект.

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

Принципы — и почему они такие

Слои держатся на нескольких принципах. Каждый — не догма, а лечение конкретной боли.

• Единый источник истины. Один факт живёт в одном месте. Почему: две копии расходятся за считанные дни — и получаете «две версии правды», непонятно, какая настоящая. Прямое следствие — правило «продвинул — удали источник»: перенёс факт выше (в глобальные правила или вику) — в тот же заход удали исходную копию или ужми её до короткого указателя.
• Разделение ответственности. Правила ≠ статусы ≠ знание — каждое в своём слое. Почему: смешаешь — не найдёшь нужное и раздуешь контекст, который грузится в каждую сессию (а он не бесплатный).
• Типизация по переносимости. Тест при сомнении: «пригодится ли это в другом проекте?». Да → общая вика. Нет → память или локальная вика проекта.
• Снимок против живого состояния. Память — это фотография на момент записи, а не живое состояние. Почему важно: память устаревает и сама об этом не знает. Живые, меняющиеся статусы («этап 3», «ждём сервер», «в проде») ведите там, где они реально обновляются, а не замораживайте в памяти.
• Индекс. У каждого набора — файл-навигатор (MEMORY.md, index.md): одна короткая строка на запись. Почему: агент читает индекс первым и по нему решает, куда смотреть.
• Кросс-ссылки. Страницы знаний связывают ссылками друг на друга. Почему: сила базы знаний — в плотности связей, а не в объёме. Это и есть суть метода Карпаты (о нём — в конце).
• Сохранность. Единый источник истины защищает от расхождения, но не от потери. Про бэкап — отдельный разговор ниже, но принцип держите с самого начала.

Десять граблей — коротким кейсом каждая

Самое ценное для практика — не теория, а конкретные ямы. Вот те, в которые наступают чаще всего.

1. Ищут память в папке проекта. Её там нет — она в профиле агента. Пустая папка проекта — это норма, а не поломка.
2. Продвинули правило, а копию не удалили. Записали и в память проекта, и в глобальные правила — две копии разошлись. Лечение: «продвинул — удали источник».
3. Универсальное правило — в память одного проекта. Память проекта грузится только в его сессиях; в других правила не будет. Универсальное правило поведения — в глобальный CLAUDE.md.
4. Кросс-проектное знание застряло в памяти полигона. Наработка, полезная многим проектам, но записанная в память одного, — невидима остальным. Заведите ей «паспорт» в общей вике.
5. Устаревший статус. «Ждём X», «этап N» — когда всё давно изменилось. Память — снимок; живые статусы ведите в вике, а память периодически чистите.
6. Журнал под видом памяти. Файл памяти, который растет дописыванием сессия за сессией до сотен строк. Память — «один файл = один факт»; хронику выносите в архивную страницу вики.
7. Смешали типы в одном файле. Правило поведения и знание в одном месте. Разделите: первое — в правила/память, второе — в вику.
8. Хранилище без бэкапа. Единственная копия на одном диске, без git и удалённого репозитория. Реальный случай: вика со всеми знаниями долго жила без git — одна поломка диска стёрла бы всё.
9. Имя удалённого бэкапа ≠ имя локальной папки. Репозиторий назвали иначе, чем папку, от которой зависят пути. При восстановлении git clone создаст папку по имени репозитория — и все пути, ждущие старое имя, сломаются в момент восстановления. Правило: имя репозитория = имя папки (или задокументируйте точную команду клона).
10. Указатель ведёт на неверный путь. Ужали память до указателя «детали — в такой-то папке», а файл лежит в другой. Файл не потерян, но переход бьётся — и это тихо: проверка «а есть ли файл с таким именем?» проходит, потому что имя-то верное. Лечение: после ужатия сверять путь указателя целиком — имя и папку.

Гигиена: уборка и бэкап

Система живёт, пока за ней убирают. Два ритуала держат её здоровой.

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

Бэкап. Единый источник истины защищает от расхождения, но не от потери. Каждое критичное хранилище должно иметь копию вне машины: вику и проекты — под git и удалённый репозиторий (приватный, если данные личные); память — бэкапить отдельно, она не в git. Физическое расположение (какой диск) от потери не спасает — спасает копия вне машины. Системный диск переустанавливают, диски выходят из строя. Не откладывайте: незабэкапленное хранилище — риск с первого дня.

Честные границы — и чем этот подход отличается

Начистоту: это авторская сборка известных паттернов, а не готовый стандарт с одним именем. Кирпичи индустриальные: единый источник истины, разделение ответственности, слои памяти и база знаний по методу Карпаты — знание компилируется в перелинкованную вику в момент поступления, а не переоткрывается из сырых документов при каждом запросе. Первоисточник — публичный гист Андрея Карпаты (апрель 2026).

И тут важная оговорка, чтобы не продавать вам велосипед. Идея «вики для LLM по Карпаты» не уникальна — на GitHub уже есть популярные репозитории на эту тему. Ценность здесь не в самой вике, а в том, что это шаг дальше, а не её повтор:

• Многослойная типизация, а не одна вика. Правила + память проекта + вика + навыки — разнесены по ролям, а не свалены в один «умный» файл.
• Лестница масштаба и честное «кому НЕ нужно». Подход говорит не только «как сделать», но и «стоит ли вообще» — и на какой вы ступени.
• Названа грабля «где физически лежит память» — профиль агента против папки проекта. Мелочь, на которой теряют часы.
• Русскоязычно. Заметные аналоги — англо- и китаеязычные; на русском такого разбора почти нет.

И повторим границу из лестницы: система стоит своих усилий не для всех. Одному маленькому проекту хватит одного файла заметок. Слои окупаются, когда проектов несколько и знания между ними пересекаются. Конкретика (расположение памяти, имена файлов, кодирование пути в имя папки) — специфика Claude Code; принцип «слои по ролям + единый источник истины» переносится на любого агента, детали — нет.

Готовый шаблон: клонируй и заполни под себя

Чтобы не собирать это с нуля, есть открытый скелет — llm-wiki-starter (публичный, лицензия MIT). Внутри: слой правил (CLAUDE.md), демо-проект с памятью (наглядно показано, что память лежит не в папке проекта), общая вика с кросс-ссылками, шаблоны-бланки файлов памяти и страниц вики, образец оформленного навыка. Папки размечены по ступеням лестницы — включаете слои под свою ступень, остальное удаляете.

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

Если вы только выбираете, с каким ассистентом всё это ставить, — загляните в разбор как выбрать нейросеть под задачу и в словарь: там про разницу моделей и про то, чем «модель» отличается от «агента».

Нашли устаревшее? Напишите нам — поправим и обновим страницу. Ответ придёт в Телеграме.