Memory Bank: постоянная память для AI-агентов в Kilo Code и Claude Code

У AI-агентов для разработки есть общее архитектурное ограничение: каждая новая сессия стартует с нуля. Агент не знает стека проекта, принятых решений и текущего статуса задач — контекст приходится вводить заново при каждом запуске. При активной разработке это систематические потери времени.

Решение — Memory Bank: набор Markdown-файлов в корне проекта, которые агент читает в начале каждой сессии. Это не встроенная функция конкретного инструмента, а паттерн уровня файловой системы. Поэтому он переносится между агентами без изменений: ниже разберём настройку в Kilo Code (AI-агент для VS Code) и в Claude Code — сами файлы памяти в обоих случаях одинаковы, меняется только способ подключения инструкции.

Зачем нужна постоянная память для AI-агента?

Без Memory Bank каждая сессия требует повторного ввода контекста вручную: стек проекта, архитектурные решения, текущий фокус, известные проблемы. При активной разработке это — систематические потери времени.

С Memory Bank агент стартует с полным контекстом — аналог коллеги, который прочитал документацию перед встречей. Обновление файлов происходит автоматически после каждой значимой задачи.

Структура Memory Bank: четыре файла

Создаётся папка memory-bank/ в корне проекта со следующим содержимым:

your-project/
├── memory-bank/
│   ├── projectbrief.md      # цели и требования
│   ├── techContext.md       # стек и архитектура
│   ├── activeContext.md     # текущее состояние
│   └── progress.md          # прогресс и проблемы
└── src/

projectbrief.md — цели и требования

Отвечает на вопрос: что строится и для кого. Заполняется один раз, корректируется при смене требований.

# Project Brief
## Цель
Описание продукта в одном предложении.
## Целевые пользователи
Кто использует систему и в каком контексте.
## Ключевые требования
- Центральная сущность и её связи
- Бизнес-правила, которые нельзя нарушать
- Ограничения (производительность, безопасность, compliance)

techContext.md — стек и архитектура

Технические решения с обоснованием. Особенно важны отказы от альтернатив — это предотвращает повторное предложение агентом уже отклонённых вариантов.

# Tech Context
## Стек
- Backend: Node.js + PostgreSQL
- Frontend: React + TypeScript
- Инфраструктура: Docker, self-hosted
## Ключевые решения
- pgvector для семантического поиска
- Аутентификация через JWT
- REST API (GraphQL отклонён: избыточная сложность для команды)

activeContext.md — текущее состояние

Обновляется после каждой значимой сессии. Содержит текущий фокус, последние решения и открытые вопросы.

# Active Context
## Текущий фокус
Реализация модуля сроков — динамический расчёт дедлайнов с механизмом переопределения.
## Последние решения
- Базовый срок хранится в справочнике, переопределения — в отдельной таблице
- Формат дат: ISO 8601
## Открытые вопросы
- Механизм уведомлений о приближающихся дедлайнах: push, email или polling?

progress.md — прогресс и известные проблемы

Чеклист завершённого, активного и отложенного. Раздел с известными проблемами критически важен — исключает повторную отладку уже выявленных узких мест.

# Progress
## Сделано
- [x] Схема БД (11 сущностей)
- [x] API авторизации
- [x] CRUD для основной сущности
## В работе
- [ ] Модуль сроков
- [ ] Фильтрация и поиск
## Известные проблемы
- Деградация производительности при большом наборе записей — требуется пагинация на уровне API

Как настроить Memory Bank в Kilo Code?

Шаг 1. Создать файлы через агента

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

Проанализируй этот проект и создай папку memory-bank/ в корне со следующими файлами:
1. projectbrief.md — цели проекта, ключевые требования, целевые пользователи
2. techContext.md — стек, архитектурные решения, ключевые зависимости
3. activeContext.md — текущее состояние, что сейчас в процессе
4. progress.md — что сделано, что осталось, известные проблемы
Правила:
- Перед написанием прочитай ВСЕ файлы проекта
- Пиши конкретно и по факту, без общих фраз
- Язык файлов — русский

Шаг 2. Добавить инструкцию в настройках агента

Открыть Kilo Settings → Поведение агента → Агенты, выбрать нужный режим (например, code) и в поле «Пользовательское переопределение промпта» добавить:

В начале каждой сессии молча прочитай все файлы в memory-bank/.
После выполнения любой значимой задачи обнови activeContext.md и progress.md.

Индексация кодовой базы: дополнение к Memory Bank

Memory Bank решает задачу контекста между сессиями. Для семантического поиска по коду внутри сессии — используется встроенный механизм Индексация, доступный в том же разделе настроек Kilo Code:

• Kilo Settings → Индексация → Включить глобально — активировать
• Провайдер эмбеддингов — OpenAI, Ollama (локально) или другой совместимый провайдер
• Векторное хранилище — LanceDB по умолчанию (локальное хранилище, без внешних зависимостей)

Индексация позволяет агенту находить релевантные файлы по семантическому сходству, а не только по имени или пути.

Тот же паттерн в Claude Code

Memory Bank не привязан к Kilo Code — это соглашение о структуре файлов, а значит переносится в любой агент. В Claude Code сами файлы memory-bank/ остаются без единого изменения, меняется только проводка: здесь нет поля «переопределение промпта», его роль выполняет файл CLAUDE.md, а разовые операции обслуживания памяти оформляются слэш-командами.

Шаг 1. Файлы Memory Bank — без изменений

Структура и промт создания идентичны разделу для Kilo Code. Тот же запрос агенту анализирует кодовую базу и заполняет четыре файла по факту:

Проанализируй этот проект и создай папку memory-bank/ в корне со следующими файлами:
1. projectbrief.md — цели проекта, ключевые требования, целевые пользователи
2. techContext.md — стек, архитектурные решения, ключевые зависимости
3. activeContext.md — текущее состояние, что сейчас в процессе
4. progress.md — что сделано, что осталось, известные проблемы
Правила:
- Перед написанием прочитай ВСЕ файлы проекта
- Пиши конкретно и по факту, без общих фраз
- Язык файлов — русский

Шаг 2. Инструкция через CLAUDE.md

Вместо настроек режима — файл в корне репозитория. Если CLAUDE.md уже есть, раздел дописывается, а не перезаписывается:

## Банк памяти (memory-bank/)
В начале каждой сессии молча прочитай все файлы в memory-bank/.
После выполнения любой значимой задачи обнови activeContext.md и progress.md.

Файл подхватывается автоматически при старте сессии. Редактировать память из сессии удобно командой /memory; инициализировать заготовку CLAUDE.md — командой /init.

Шаг 3. Слэш-команды для обслуживания памяти

Регулярные операции обслуживания памяти оформляются отдельными командами. Это Markdown-файлы в каталоге .claude/commands/; имя файла становится именем команды. Фиксация после задачи выполняется автоматически по инструкции из CLAUDE.md, а команды закрывают остальное: принудительную фиксацию (когда автозапись не сработала или нужно зафиксировать промежуточный результат), сверку с кодом и сжатие разросшихся файлов:

your-project/
├── .claude/
│   └── commands/
│       ├── mem-fix.md       # /mem-fix      — принудительно зафиксировать задачу
│       ├── mem-audit.md     # /mem-audit    — сверить с кодом
│       └── mem-compress.md  # /mem-compress — сжать файлы
├── memory-bank/
└── src/

Содержимое .claude/commands/mem-fix.md:

---
description: Зафиксировать выполненную задачу в банке памяти
---
Задача завершена. Обнови банк памяти:
- memory-bank/activeContext.md — перенеси выполненное из «в работе», добавь
  новый текущий фокус и открытые вопросы, возникшие по ходу.
- memory-bank/progress.md — добавь сделанное с конкретикой (что именно, в каких
  файлах), обнови «осталось» и «известные проблемы».
Меняй только то, что изменилось. Не переписывай файлы целиком и не трогай
projectbrief.md и techContext.md, если не менялись цели или стек.
Покажи дифф своих правок.

Аналогично оформляются mem-audit.md (сверка содержимого memory-bank/ с актуальным кодом, поиск устаревших записей и противоречий) и mem-compress.md (сжатие файлов без потери смысла, когда они разрослись). После раскладки команды появляются по вводу / и вызываются как /mem-fix.

Особый случай: Claude Code в браузере

В веб-версии сессия работает не на вашей машине, а во временной облачной песочнице, привязанной к репозиторию. Домашний каталог ~/.claude/ между сессиями не сохраняется — пользовательские команды класть некуда. Зато репозиторий клонируется в песочницу целиком, поэтому работает единственный надёжный путь: положить CLAUDE.md и .claude/commands/ внутрь репозитория и закоммитить. После этого они автоматически приедут в каждую следующую веб-сессию.

Чтобы не разворачивать структуру вручную, всё разворачивает один промт. Он анализирует кодовую базу, создаёт файлы памяти, дописывает секцию в CLAUDE.md, раскладывает слэш-команды и коммитит результат:

Разверни в этом репозитории паттерн Memory Bank. Выполни по шагам.

1. Проанализируй проект: прочитай ВСЕ файлы кодовой базы, конфиги,
   зависимости, README и существующую документацию.

2. Создай папку memory-bank/ в корне со следующими файлами,
   заполненными конкретикой по факту (без общих фраз, язык — русский):
   - projectbrief.md  — цель продукта, целевые пользователи,
                         ключевые требования и ограничения
   - techContext.md   — стек, архитектурные решения с обоснованием,
                         ОБЯЗАТЕЛЬНО отклонённые альтернативы с причинами
   - activeContext.md — текущий фокус, последние решения, открытые вопросы
   - progress.md      — что сделано, что в работе, известные проблемы

3. Создай или дополни CLAUDE.md в корне (если файл есть — допиши секцию,
   не перезаписывай) следующим блоком:

   ## Банк памяти (memory-bank/)
   В начале каждой сессии молча прочитай все файлы в memory-bank/.
   После выполнения любой значимой задачи обнови activeContext.md и progress.md.

4. Создай слэш-команды в .claude/commands/:

   .claude/commands/mem-fix.md:
   ---
   description: Зафиксировать выполненную задачу в банке памяти
   ---
   Задача завершена. Обнови банк памяти:
   - memory-bank/activeContext.md — перенеси выполненное из «в работе»,
     добавь новый текущий фокус и открытые вопросы, возникшие по ходу.
   - memory-bank/progress.md — добавь сделанное с конкретикой (что именно,
     в каких файлах), обнови «осталось» и «известные проблемы».
   Меняй только то, что изменилось. Не переписывай файлы целиком и не трогай
   projectbrief.md и techContext.md, если не менялись цели или стек.
   Покажи дифф своих правок.

   .claude/commands/mem-audit.md:
   ---
   description: Сверить банк памяти с актуальным кодом
   ---
   Сверь содержимое memory-bank/ с актуальным состоянием кодовой базы.
   Найди устаревшие записи, противоречия и расхождения со стеком.
   Предложи правки диффом, ничего не меняя без подтверждения.

   .claude/commands/mem-compress.md:
   ---
   description: Сжать разросшиеся файлы банка памяти
   ---
   Сожми файлы memory-bank/ без потери смысла: убери дублирование,
   объедини связанные пункты, сократи устаревшую детализацию.
   Структуру разделов сохрани. Покажи дифф.

5. Закоммить все созданные файлы: memory-bank/, CLAUDE.md,
   .claude/commands/ — одним коммитом с сообщением
   "chore: add Memory Bank pattern".

После коммита файлы автоматически подтянутся в каждой следующей веб-сессии.

Развёртывание сразу под несколько веток

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

Разверни в этом репозитории паттерн Memory Bank в раскладке, не дающей
конфликтов при слиянии веток. Выполни по шагам.

1. Проанализируй проект: прочитай ВСЕ файлы кодовой базы, конфиги,
   зависимости, README и существующую документацию.

2. Создай папку memory-bank/ в корне, заполнив файлы конкретикой по факту
   (без общих фраз, язык — русский):

   - projectbrief.md  — цель продукта, целевые пользователи,
                        ключевые требования и ограничения
   - techContext.md   — стек, архитектурные решения с обоснованием,
                        ОБЯЗАТЕЛЬНО отклонённые альтернативы с причинами
   - progress.md      — дописываемый журнал. Заголовок `# Progress`, далее
                        по одной строке на запись в формате
                        `- ДАТА | ветка ИМЯ | сделано: что именно, в каких файлах`.
                        Восстанови историю по коммитам за последние 2 месяца,
                        по одной строке на значимое изменение. Разделов
                        «в работе» и «известные проблемы» здесь быть не должно.
   - activeContext.md — НЕ содержимое, а описание схемы: текущий контекст
                        хранится по одному файлу на ветку в memory-bank/active/,
                        имя файла — имя ветки с заменой `/` на `-`. Ниже —
                        шаблон файла ветки с разделами «Текущий фокус»,
                        «Открытые вопросы», «Известные проблемы».

3. Создай memory-bank/active/main.md по этому шаблону, заполнив по факту:
   текущий фокус разработки, открытые вопросы, известные проблемы,
   найденные при анализе кодовой базы.

4. Создай или дополни .gitattributes в корне (не перезаписывай):
   memory-bank/progress.md    merge=union
   memory-bank/active/*.md    merge=union
   CLAUDE.md                  merge=union

5. Создай или дополни CLAUDE.md в корне (если файл есть — допиши секции,
   не перезаписывай существующее):

   ## Банк памяти (memory-bank/)
   В начале каждой сессии молча прочитай: projectbrief.md, techContext.md,
   active/main.md и файл текущей ветки active/<имя-ветки>.md, если он есть
   (имя — из `git rev-parse --abbrev-ref HEAD`, слэши → дефисы);
   из progress.md — только последние 50 строк (`tail -n 50`).
   activeContext.md — описание схемы каталога active/ и шаблон файла ветки,
   не рабочий контекст. Ветка правит только СВОЙ файл в active/;
   progress.md — append-only журнал, слияние держится на merge=union
   из .gitattributes. Сведение файлов влитых веток в active/main.md —
   /mem-merge (на main); сжатие — /mem-compress (только каталог active/,
   progress.md не трогается); сверка банка с кодом — /mem-audit.
   Банк памяти копит состояние; уроки копит секция «Уроки» этого файла.

   ## Автозапись в банк памяти
   Запись в банк выполняется АВТОМАТИЧЕСКИ, без команды пользователя.
   Триггер: ты завершил задачу, изменившую файлы проекта (создание, правка,
   удаление кода или конфигов), и следующим шагом собираешься отдать
   итоговый ответ или ждать нового указания. В этот момент, ПЕРЕД итоговым
   ответом:
   1. Определи ветку: `git rev-parse --abbrev-ref HEAD`, слэши → дефисы.
   2. memory-bank/active/<имя-ветки>.md — если файла нет, создай по шаблону
      из memory-bank/activeContext.md. Обнови «Текущий фокус», «Открытые
      вопросы», «Известные проблемы». Файлы других веток не трогай.
   3. memory-bank/progress.md — допиши В КОНЕЦ одну строку:
      `- ДАТА | ветка ИМЯ | сделано: что именно, в каких файлах`.
      Существующие строки не изменяй и не удаляй.
   Когда НЕ записывать: задача не меняла файлы (вопрос, чтение кода,
   анализ); изменение косметическое (опечатка, форматирование, один
   импорт); задача явно промежуточная и работа продолжается в этой же
   сессии. За одну сессию по одной задаче — одна запись, не дроби.
   projectbrief.md и techContext.md не трогай, если не менялись цели
   или стек. /mem-fix остаётся как ручной способ форсировать запись.
   Если одна и та же ошибка повторяется — не правь её руками в третий
   раз, а допиши правило в секцию «Уроки» ниже.

   ## Уроки
   Правила из повторяющихся ошибок дописываются ТОЛЬКО сюда, только
   в конец, по одной строке. Существующие строки не изменять и не удалять.

6. Создай слэш-команды в .claude/commands/:

   .claude/commands/mem-fix.md:
   ---
   description: Принудительно зафиксировать задачу в банке памяти
   ---
   Выполни процедуру автозаписи из секции «Автозапись в банк памяти»
   в CLAUDE.md немедленно, независимо от условий триггера и исключений.
   Покажи дифф своих правок.

   .claude/commands/mem-merge.md:
   ---
   description: Свести файлы завершённых веток в основной контекст
   ---
   Выполни `git branch --merged main` и сравни со списком файлов
   в memory-bank/active/.
   Для каждого файла ветки, уже слитой в main:
   - перенеси актуальные открытые вопросы и известные проблемы
     в memory-bank/active/main.md;
   - предложи удалить файл ветки.
   Проверь progress.md на дубли и взаимоисключающие записи, оставшиеся
   после объединяющего слияния. Покажи дифф, ничего не удаляй
   без подтверждения.

   .claude/commands/mem-audit.md:
   ---
   description: Сверить банк памяти с актуальным кодом
   ---
   Сверь содержимое memory-bank/ с актуальным состоянием кодовой базы.
   Отдельно проверь секцию «Уроки» в CLAUDE.md на устаревшие правила.
   Найди устаревшие записи, противоречия и расхождения со стеком.
   Предложи правки диффом, ничего не меняя без подтверждения.

   .claude/commands/mem-compress.md:
   ---
   description: Сжать разросшиеся файлы банка памяти
   ---
   Сожми файлы в memory-bank/active/ без потери смысла: убери дублирование,
   объедини связанные пункты, сократи устаревшую детализацию.
   progress.md НЕ ТРОГАЙ — это дописываемый журнал, его сжатие ломает
   объединяющее слияние. projectbrief.md и techContext.md тоже не трогай.
   Структуру разделов сохрани. Покажи дифф.

7. Закоммить всё одним коммитом: memory-bank/, .gitattributes, CLAUDE.md,
   .claude/commands/ — с сообщением "chore: add Memory Bank pattern".

После коммита файлы автоматически подтянутся в каждой следующей сессии.

Как работает цикл сессий на практике?

Схема взаимодействия при каждом запуске одинакова для обоих агентов:

1. Открывается новая сессия агента
2. Агент молча читает все файлы в memory-bank/
3. Разработка продолжается — агент оперирует актуальным стеком и архитектурой
4. После завершения задачи агент обновляет activeContext.md и progress.md
5. Следующая сессия снова стартует с актуальным контекстом

Ветки и конфликты при слиянии

На одиночной ветке паттерн работает без нареканий. Проблема появляется, когда над репозиторием идёт параллельная работа: несколько веток, фоновые сессии агента, облачные запуски. Каждая ветка правит activeContext.md и progress.md, причём в одних и тех же местах — раздел «Текущий фокус», раздел «Сделано». Git видит расхождение в соседних строках и останавливает слияние.

Показательно, что конфликтуют ровно два файла из четырёх. projectbrief.md и techContext.md меняются раз в месяц и проблемы не создают. Значит, и лечить нужно только два — переводом на структуру, при которой ветки физически не пишут в общие строки.

Приём 1. Объединяющее слияние через .gitattributes

В Git есть встроенный драйвер слияния union: при расхождении он берёт строки обеих сторон вместо остановки с конфликтом. Устанавливать ничего не нужно, достаточно файла .gitattributes в корне репозитория:

memory-bank/progress.md    merge=union
memory-bank/active/*.md    merge=union
CLAUDE.md                  merge=union

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

Приём 2. progress.md как дописываемый журнал

Разделы «Сделано», «В работе» и «Известные проблемы» внутри одного файла — главный источник конфликтов: любая ветка редактирует середину. Замена — журнал, куда записи только дописываются в конец и никогда не редактируются:

# Progress
- 2026-07-14 | ветка feature/deadlines | сделано: динамический расчёт дедлайнов, src/modules/deadlines/*, миграция 0042
- 2026-07-18 | ветка fix/pagination | сделано: пагинация на уровне API, src/api/list.ts, снята известная проблема деградации на больших выборках
- 2026-07-21 | ветка feature/notify | сделано: выбран polling вместо push, обоснование в techContext.md

Две ветки дописали каждая свою строку в конец — merge=union сохраняет обе, конфликта нет. Разделы «в работе» и «известные проблемы» из этого файла уезжают в контекст ветки.

Приём 3. Один файл активного контекста на ветку

Текущий фокус по определению у каждой ветки свой — держать его в общем файле не имеет смысла. Вместо одного activeContext.md заводится каталог, где имя файла повторяет имя ветки с заменой / на -:

memory-bank/
├── projectbrief.md
├── techContext.md
├── progress.md                    # дописываемый журнал
└── active/
    ├── main.md                    # контекст основной ветки
    ├── feature-deadlines.md
    └── fix-pagination.md

Ветки пишут в разные файлы, пересечений нет вообще. Сам activeContext.md остаётся в корне памяти как описание схемы и шаблон файла ветки — разделы «Текущий фокус», «Открытые вопросы», «Известные проблемы».

Автозапись вместо ручной фиксации

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

## Автозапись в банк памяти
Запись в банк выполняется АВТОМАТИЧЕСКИ, без команды пользователя.
Триггер: ты завершил задачу, изменившую файлы проекта (создание, правка,
удаление кода или конфигов), и следующим шагом собираешься отдать итоговый
ответ или ждать нового указания. В этот момент, ПЕРЕД итоговым ответом:

1. Определи ветку: `git rev-parse --abbrev-ref HEAD`, слэши → дефисы.
2. memory-bank/active/<имя-ветки>.md — если файла нет, создай по шаблону
   из memory-bank/activeContext.md. Обнови «Текущий фокус», «Открытые
   вопросы», «Известные проблемы». Файлы других веток не трогай.
3. memory-bank/progress.md — допиши В КОНЕЦ одну строку:
   `- ДАТА | ветка ИМЯ | сделано: что именно, в каких файлах`.
   Существующие строки не изменяй и не удаляй.

Когда НЕ записывать: задача не меняла файлы (вопрос, чтение кода, анализ);
изменение косметическое (опечатка, форматирование, один импорт);
задача явно промежуточная и работа продолжается в этой же сессии.
За одну сессию по одной задаче — одна запись, не дроби.
projectbrief.md и techContext.md не трогай, если не менялись цели или стек.
/mem-fix остаётся как ручной способ форсировать запись.

Команда /mem-fix при этом не исчезает, а меняет роль: из основного механизма превращается в принудительный вызов той же процедуры. Текст команды ссылается на секцию в CLAUDE.md, а не дублирует её — одно место правды:

---
description: Принудительно зафиксировать задачу в банке памяти
---
Выполни процедуру автозаписи из секции «Автозапись в банк памяти»
в CLAUDE.md немедленно, независимо от условий триггера и исключений.
Покажи дифф своих правок.

Раз запись в CLAUDE.md теперь тоже идёт под merge=union, для накопления правил заводится выделенная секция с тем же режимом «только в конец» — иначе две ветки, дописавшие правило в разные места середины файла, дадут при слиянии кашу:

## Уроки
Правила из повторяющихся ошибок дописываются ТОЛЬКО сюда, только в конец,
по одной строке. Существующие строки не изменять и не удалять.

Связка простая: банк памяти копит состояние, секция «Уроки» копит выводы. Если одна и та же ошибка повторяется — правило дописывается в «Уроки» вместо третьей ручной правки, а /mem-audit периодически проверяет секцию на устаревшие пункты.

Новая команда /mem-merge

Объединяющее слияние конфликты не разрешает, а выключает. Если две ветки записали противоречащие друг другу утверждения, Git молча оставит оба. Нужна точка контроля — команда сведения, запускаемая вручную раз в неделю:

---
description: Свести файлы завершённых веток в основной контекст
---
Выполни `git branch --merged main` и сравни со списком файлов
в memory-bank/active/.

Для каждого файла ветки, уже слитой в main:
- перенеси актуальные открытые вопросы и известные проблемы
  в memory-bank/active/main.md;
- предложи удалить файл ветки.

Проверь progress.md на дубли и взаимоисключающие записи, оставшиеся
после объединяющего слияния. Покажи дифф, ничего не удаляй без подтверждения.

Промт перестройки существующего банка памяти

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

Перестрой банк памяти в этом репозитории на схему, не дающую конфликтов
при слиянии веток, с автоматической записью. Накопленное содержимое не теряй.

1. Создай или дополни .gitattributes в корне:
   memory-bank/progress.md    merge=union
   memory-bank/active/*.md    merge=union
   CLAUDE.md                  merge=union

2. Преобразуй memory-bank/progress.md в дописываемый журнал: одна запись —
   одна строка формата `- ДАТА | ветка ИМЯ | сделано: что и в каких файлах`.
   Даты бери из истории коммитов там, где они определимы. Разделы
   «в работе» и «известные проблемы» из этого файла убери.

3. Создай каталог memory-bank/active/. Текущее содержимое activeContext.md
   перенеси в memory-bank/active/main.md. Сам activeContext.md оставь как
   описание схемы и шаблон файла ветки.

4. В CLAUDE.md перепиши секцию банка памяти: читать projectbrief.md,
   techContext.md, active/main.md и файл текущей ветки; из progress.md —
   последние 50 строк. Добавь секцию «Автозапись в банк памяти»: запись
   выполняется автоматически перед итоговым ответом по задаче, изменившей
   файлы проекта; ветка правит только свой файл в active/, в progress.md
   только дописывает строку в конец; исключения — задачи без изменения
   файлов, косметика, промежуточные шаги. Добавь секцию «Уроки»: правила
   из повторяющихся ошибок дописываются только туда, только в конец,
   по одной строке.

5. Перепиши .claude/commands/mem-fix.md: команда принудительно выполняет
   процедуру автозаписи из CLAUDE.md, независимо от триггера и исключений.

6. Создай .claude/commands/mem-merge.md для сведения файлов слитых веток.

7. В .claude/commands/mem-compress.md явно запрети трогать progress.md,
   ограничь его каталогом active/. В .claude/commands/mem-audit.md добавь
   проверку секции «Уроки» на устаревшие правила.

8. Закоммить одним коммитом: "refactor: conflict-free memory bank layout".

Что с этим делает GitHub Copilot?

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

Слой первый: файлы инструкций в репозитории

Copilot читает несколько форматов инструкций, лежащих в самом репозитории:

• AGENTS.md в корне, плюс вложенные файлы для отдельных частей проекта
• .github/copilot-instructions.md — общий файл
• .github/instructions/*.instructions.md — несколько файлов, каждый с заголовком YAML, указывающим, к каким путям он применяется
• CLAUDE.md и GEMINI.md — поддерживаются наравне с собственными форматами

Последний пункт важен практически: развёрнутый по этой статье CLAUDE.md подхватывается Copilot без единой правки. Memory Bank оказывается общим для трёх агентов сразу, а поддержка путей в .instructions.md дополнительно помогает с конфликтами — правила разносятся по подсистемам, и ветки перестают пересекаться в одном файле.

---
applyTo: "app/payroll/**"
---

- Начисления пишутся только через сервисный слой, прямых UPDATE по таблице нет.
- Пересечение периодов запрещено ограничением на уровне БД, обходить его нельзя.

Слой второй: Copilot Memory

Это уже не файлы, а хранилище на стороне GitHub. Агенты сами извлекают и сохраняют факты о репозитории — соглашения по коду, архитектурные шаблоны, критичные межфайловые зависимости — и переиспользуют их в следующих сессиях. Механизм появился в открытом предпросмотре в январе 2026 года, с марта включён по умолчанию для тарифов Pro и Pro+, а с мая умеет хранить ещё и личные предпочтения уровня пользователя, которые следуют за вами по всем репозиториям.

Ключевые свойства, которые отличают его от Memory Bank:

• записи привязаны к конкретному репозиторию и проверяются на соответствие текущему коду перед применением
• общие для нескольких инструментов: найденное фоновым агентом доступно проверке кода и наоборот
• автоматически истекают через 28 дней
• редактировать как текст нельзя — только просматривать и удалять в Settings → Copilot → Memory, там же выключатель на уровень репозитория

Memory Bank vs альтернативные подходы

Сравнение с другими способами передачи контекста AI-агентам:

Подход	Персистентность	Версионирование	Сложность
Memory Bank (Markdown)	Постоянная	Git-совместимо	Минимальная
Ручной ввод в каждой сессии	Нет	Нет	Высокая (время)
Внешняя база знаний (Notion, Confluence)	Постоянная	Зависит от платформы	Высокая (интеграция)
Copilot Memory	28 дней	Нет	Нулевая
Встроенная память агента (если есть)	Зависит от провайдера	Нет	Нулевая

Заключение

Memory Bank — минималистичный, но готовый к промышленной эксплуатации паттерн для работы с AI-агентами в долгосрочных проектах. Несколько Markdown-файлов в репозитории устраняют главное ограничение LLM-агентов — отсутствие контекста между сессиями — без внешних сервисов, без привязки к поставщику и с полным контролем над данными проекта.

Единственное место, где базовая схема даёт сбой, — параллельная работа над репозиторием. Лечится это не дисциплиной, а раскладкой файлов: журнал вместо редактируемых разделов, отдельный файл активного контекста на ветку, объединяющее слияние в .gitattributes и еженедельная команда сведения как точка контроля. Запись при этом автоматическая — процедура фиксации живёт в CLAUDE.md и срабатывает после каждой задачи, изменившей файлы; команда /mem-fix нужна только чтобы форсировать её вручную.

Ключевое достоинство — переносимость. Сами файлы memory-bank/ не зависят от инструмента, и при смене агента переписывается лишь одна строка проводки: в Kilo Code инструкция живёт в настройках режима, в Claude Code и GitHub Copilot — в версионируемом CLAUDE.md рядом с кодом, плюс слэш-команды для обслуживания памяти. Освоив паттерн один раз, вы применяете его в любом агенте и любом проекте — от монолита до инфраструктурного репозитория.