Comments 10
" Ключевой принцип: zero-ops. Один бинарник, один файл SQLite " - респект, больше цинизма в ИТ!
Тоже смущает. Будет плохая переносимость, если к примеру нужно работать из нескольких мест над одним и тем же проектом. Лучше бы хранить базу проекта локально, в какой-нибудь папке .mcpmemmory внутри папки проекта.
Так никто не мешает создать проектный mcp с настройками на конкретную папку. И в Промте явно указать используем конкретный mсp для чтения и запоминания. Там же в репе лежит документация, и индексация по ней.
К тому же если говорить об разных применениях, то использование общей памяти, без документации - тоже имеет право быть.
Так я и не говорю что ваше решение - неверное. Просто лично мне проще было бы таскать на флешке в разные места весь проект. И тогда расположенное где то общее хранилище уже против меня будет играть
Согласен. Есть альтернативные решения, с хранением md или json рядом с кодом, я сам пользовался такими какое-то время. Но мне хотелось семантический поиск, и поиск по документации.
Сейчас смотрю, что аналогичных проектов появляется довольно много и есть из чего выбрать.
Есть такие уже готовые решения: банк памяти проектов, умное автоизменение банка памяти по закрытию сессии
Спасибо за комментарии. В ответ выпустил v0.3.1:
исправил проблемы с embedding-моделями/миграциями
добавил hybrid retrieval (vector + BM25) и финальное ранжирование
сделал session-close pipeline: авто-консолидацию и обновление project memory bank
Дополнительно: меньше RAM, больше скорости, и всё ещё почти zero-ops (SQLite + один бинарь).
Я когда купил 3д принтер в основном на нем улучшения к 3д принтеру и печатал
Как я спроектировал Memory MCP Server для AI-агентов: архитектура, SQLite, semantic search и грабли