Почему я держу память агента в проекте, а не во встроенной памяти Claude Code

Автор статьи на Habr, ранее описавший подход к долговременной памяти агента на markdown-файлах без вектор-базы, теперь объясняет, почему сознательно отказывается от встроенной памяти Claude Code. Встроенная память у Claude Code есть, включена по умолчанию и устроена почти так же, как авторская: индекс MEMORY.md плюс файлы-заметки. Однако автор держит свою память в проекте под git, и причина сводится к одному слову — место.

Встроенная память живёт в системном каталоге пользователя (~/.claude/…), вне репозитория, привязана к конкретной машине. Авторская память лежит в проекте под git. Разница по двум осям: сохранность и контроль. Память в репозитории видна в pull-request, едет вместе с кодом, переживает смену машины, каждое изменение хранится в коммитах. Системная память не даёт ничего из этого — она в домашней папке одного пользователя, невидима в проекте и не путешествует с ним.

Контроль над устройством — вторая ось. У встроенной памяти всегда-загружаемый индекс — один файл MEMORY.md с фиксированным потолком: первые ~200 строк или 25 КБ, что раньше наступит. Поднять порог настройкой нельзя — в документации такого ключа нет; когда индекс перерастает лимит, лишнее не грузится, а Claude Code просит переписать оглавление короче. У автора индекс под контролем: он держит его тонким и, когда фактов становится много, делит на под-индексы — по отдельным проектам, по крупным темам. Так структура оглавления растёт вместе с базой, а не упирается в один фиксированный файл.

Автор также снимает опасение про командную работу: раз индекс общий и лежит в git, не будет ли он вечно конфликтовать при параллельной правке? На практике — не чаще любого другого общего файла. MEMORY.md — обычный текст, он мержится построчно, а дробление на под-индексы разводит правки по разным файлам, так что пересечений становится меньше.

Отключается встроенная память одной строкой: autoMemoryEnabled: false в настройках проекта. Это важно: по умолчанию встроенная память перехватывает «запомни» первой и уносит запись в свою системную папку, мимо проекта. С выключенной встроенной памятью «запомни» проваливается в обычную инструкцию, и уже авторский протокол кладёт запись в нужное место.

Отдельно автор объясняет, почему ушёл от вектор-поиска и RAG для памяти и кода. Вектор ищет по «смыслу», считая его по кускам-чанкам. Для сплошного текста это работает, но код — жёстко детерминированный синтаксис: там нужно точное совпадение, и обычный grep с регулярками находит его точнее, чем вектор по нарезанным фрагментам. Смысл куска кода, вырванного из функции, — вообще странная величина. То же и с памятью: фактов немного, у каждого есть короткий заголовок в индексе, и модель открывает нужный файл по оглавлению — примерно как человек открывает документацию по содержанию, а не листает всю базу разом.

Автор честно признаёт: формального замера «RAG против грепа» он не гонял. Выбор идёт не из бенчмарка, а из практики — на его объёмах оглавление плюс grep стабильно находят нужное, без отдельной инфраструктуры и без риска, что нарезка порвёт смысл. Вектор он держит в уме для другого класса задач — большие слабоструктурированные тексты, где нет ни оглавления, ни жёсткого синтаксиса. Это просто разные инструменты, и для памяти и кода он по умолчанию к вектору не идёт.

Итог: автор сознательно держит память в проекте, а встроенную — выключает. Причина — сохранность, переносимость и контроль над устройством индекса. Для тех, кто хочет повторить, рецепт прост: папка с md-файлами, индекс MEMORY.md, пара правил в конфиге и autoMemoryEnabled: false.