У AI-агентов для разработки есть общее архитектурное ограничение: каждая новая сессия стартует с нуля. Агент не знает стека проекта, принятых решений и текущего статуса задач — контекст приходится вводить заново при каждом запуске. При активной разработке это систематические потери времени.
Решение — Memory Bank: набор Markdown-файлов в корне проекта, которые агент читает в начале каждой сессии. Это не встроенная функция конкретного инструмента, а паттерн уровня файловой системы. Поэтому он переносится между агентами без изменений: ниже разберём настройку в Kilo Code (AI-агент для VS Code) и в Claude Code — сами файлы памяти в обоих случаях одинаковы, меняется только способ подключения инструкции.
Memory Bank — не плагин и не API. Это соглашение о структуре файлов проекта плюс инструкция агенту: в Kilo Code — через поле переопределения промпта, в Claude Code — через файл CLAUDE.md.
- Зачем нужна постоянная память для AI-агента?
- Структура Memory Bank: четыре файла
- projectbrief.md — цели и требования
- techContext.md — стек и архитектура
- activeContext.md — текущее состояние
- progress.md — прогресс и известные проблемы
- Как настроить Memory Bank в Kilo Code?
- Шаг 1. Создать файлы через агента
- Шаг 2. Добавить инструкцию в настройках агента
- Индексация кодовой базы: дополнение к Memory Bank
- Тот же паттерн в Claude Code
- Шаг 1. Файлы Memory Bank — без изменений
- Шаг 2. Инструкция через CLAUDE.md
- Шаг 3. Слэш-команды для обслуживания памяти
- Особый случай: Claude Code в браузере
- Как работает цикл сессий на практике?
- Memory Bank vs альтернативные подходы
- Заключение
Зачем нужна постоянная память для 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 отклонён: избыточная сложность для команды) Фиксируйте не только принятые решения, но и отклонённые альтернативы с причинами. Без этого агент периодически будет предлагать GraphQL вместо REST или Kubernetes вместо Docker Compose.
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 по умолчанию (локальное хранилище, без внешних зависимостей)
Индексация позволяет агенту находить релевантные файлы по семантическому сходству, а не только по имени или пути.
Для полностью локальной инфраструктуры: Ollama в качестве провайдера эмбеддингов + LanceDB как векторное хранилище. Данные кодовой базы не покидают машину.
Тот же паттерн в Claude Code
Memory Bank не привязан к Kilo Code — это соглашение о структуре файлов, а значит переносится в любой агент. В Claude Code сами файлы memory-bank/ остаются без единого изменения, меняется только проводка: здесь нет поля «переопределение промпта», его роль выполняет файл CLAUDE.md, а разовые операции обслуживания памяти оформляются слэш-командами.
CLAUDE.md — встроенный механизм Claude Code. Это Markdown-файл в корне проекта, который агент читает автоматически в начале каждой сессии и держит как контекст на всю сессию. Прямой аналог постоянной инструкции из настроек Kilo.
Шаг 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.
Содержимое CLAUDE.md трактуется как сильная рекомендация, а не как жёсткое правило. В подавляющем большинстве задач этого достаточно. Если нужна гарантия выполнения действия независимо от решения модели — используется механизм перехватчиков (PreToolUse hook).
Шаг 3. Слэш-команды для обслуживания памяти
Регулярные операции — фиксация после задачи, сверка с кодом, сжатие разросшихся файлов — оформляются отдельными командами. Это Markdown-файлы в каталоге .claude/commands/; имя файла становится именем команды. Запуск контролируете вы, а не модель — для обслуживания памяти это важнее автосрабатывания:
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/commands/ внутри репозитория — проектные: версионируются в Git и доступны всем, кто склонирует проект. Для команд на все проекты сразу используется каталог ~/.claude/commands/ в домашней директории.
Особый случай: 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".
После коммита файлы автоматически подтянутся в каждой следующей веб-сессии. После первого деплоя проверьте, что команды видны по вводу / — в облачной сессии они подхватываются из репозитория, а не из ~/.claude/, которого в песочнице нет.
Принцип переноса: файлы memory-bank/ — общие для обоих агентов; в Kilo Code инструкция живёт в настройках режима, в Claude Code — в версионируемом CLAUDE.md рядом с кодом.
Как работает цикл сессий на практике?
Схема взаимодействия при каждом запуске одинакова для обоих агентов:
- Открывается новая сессия агента
- Агент молча читает все файлы в
memory-bank/ - Разработка продолжается — агент оперирует актуальным стеком и архитектурой
- После завершения задачи агент обновляет
activeContext.mdиprogress.md - Следующая сессия снова стартует с актуальным контекстом
Memory Bank — это не система памяти агента, а система документирования проекта, адаптированная под LLM-контекстное окно. Побочный эффект: документация проекта актуальна всегда.
Memory Bank vs альтернативные подходы
Сравнение с другими способами передачи контекста AI-агентам:
| Подход | Персистентность | Версионирование | Сложность |
|---|---|---|---|
| Memory Bank (Markdown) | Постоянная | Git-совместимо | Минимальная |
| Ручной ввод в каждой сессии | Нет | Нет | Высокая (время) |
| Внешняя база знаний (Notion, Confluence) | Постоянная | Зависит от платформы | Высокая (интеграция) |
| Встроенная память агента (если есть) | Зависит от провайдера | Нет | Нулевая |
Markdown-файлы в репозитории — единственный подход, который одновременно решает задачу памяти агента и актуальной документации проекта, хранимой в системе контроля версий.
Заключение
Memory Bank — минималистичный, но готовый к промышленной эксплуатации паттерн для работы с AI-агентами в долгосрочных проектах. Четыре Markdown-файла в репозитории устраняют главное ограничение LLM-агентов — отсутствие контекста между сессиями — без внешних сервисов, без привязки к поставщику и с полным контролем над данными проекта.
Ключевое достоинство — переносимость. Сами файлы memory-bank/ не зависят от инструмента, и при смене агента переписывается лишь одна строка проводки: в Kilo Code инструкция живёт в настройках режима, в Claude Code — в версионируемом CLAUDE.md рядом с кодом, плюс слэш-команды для обслуживания памяти. Освоив паттерн один раз, вы применяете его в любом агенте и любом проекте — от монолита до инфраструктурного репозитория.









