Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors

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

Linux и DevOps

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

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

Memory Bank — не плагин и не API. Это соглашение о структуре файлов проекта плюс инструкция агенту: в Kilo Code — через поле переопределения промпта, в Claude Code — через файл CLAUDE.md.

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

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

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

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

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 рядом с кодом, плюс слэш-команды для обслуживания памяти. Освоив паттерн один раз, вы применяете его в любом агенте и любом проекте — от монолита до инфраструктурного репозитория.

Оцените статью
ctrllife.ru
Подписаться
Уведомить о
guest
0 комментариев
Старые
Новые Популярные
0
Оставьте комментарий! Напишите, что думаете по поводу статьи.x