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

Kilo Code — AI-агент для VS Code, который пишет и редактирует код по инструкциям на естественном языке. Главное архитектурное ограничение: каждая новая сессия стартует с нуля. Агент не знает стека, принятых решений и текущего статуса задач.

Решение — Memory Bank: набор Markdown-файлов в корне проекта, которые агент читает в начале каждой сессии. Это не встроенная функция Kilo Code, а архитектурный паттерн, который настраивается за 10 минут без внешних зависимостей.

Зачем нужна постоянная память для 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.

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

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

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

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

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

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

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

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

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

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

Заключение

Memory Bank — минималистичный, но production-ready паттерн для работы с AI-агентами в долгосрочных проектах. Четыре Markdown-файла в репозитории плюс одна инструкция в настройках режима агента устраняют главное ограничение LLM-агентов — отсутствие контекста между сессиями — без внешних сервисов, без vendor lock-in и с полным контролем над данными проекта.