Skip to content

vs-claude-mem-and-agentmemory.md

Latest commit

 

History

History
94 lines (55 loc) · 9.83 KB

vs-claude-mem-and-agentmemory.md

File metadata and controls

94 lines (55 loc) · 9.83 KB
Raw

vs claude-mem и agentmemory

Честное сравнение трёх систем персистентной памяти для Claude Code, которые я знаю на момент 2026 года. Одну из них я делал; две других — проекты, которые я уважаю. Каждая сделала разные ставки, и подходящий инструмент зависит от того, чего ты от него хочешь.

Две другие:

  • claude-mem — авто-захват каждого действия Claude Code, сжатие в observations, хранение в SQLite + Chroma, обслуживание через worker на :37777.
  • agentmemory — авто-захват через 12 хуков, многоуровневая память (working / episodic / semantic / procedural), in-memory vector index + BM25 + knowledge graph, 107 REST + 51 MCP tools.

Side-by-side

claude-mem agentmemory claude-wiki-memory
Захват авто, каждый PostToolUse авто, 12 хуков границы сессии + руками
Хранение SQLite + Chroma iii-engine + vector index Markdown в твоём репо
Поиск embeddings BM25 + vectors + KG, RRF grep + LLM-контекст
Авто-инжекция top-N результатов в сессию top-N результатов в сессию полный index.md дословно
Фоновые сервисы worker на :37777 сервисы на :3111 и :3113 нет
Зависимости Bun + uv + Chroma iii-engine + embedding-модель python3 + опц. claude-agent-sdk
Размер кодовой базы ~? ~21k LOC, 800 тестов ~1.5k LOC
Лицензия AGPL-3.0 unspecified MIT
Статус beta v0.9.4 v0.2
Артефакты в git нет нет да — wiki это и есть артефакт
Per-machine артефакты да да да (Слой 2)

В чём каждая хороша

claude-mem — для тех, кто хочет максимум авто

Доверяешь LLM фильтровать за тебя. Не хочешь думать, что сохранять; хочешь спросить «что я решил по X?» и получить ответ. Chroma-backed поиск работает: найдёт сессию про «auth», когда ищешь «login flow».

Цена — worker на порту и ощутимое дерево зависимостей (Bun + uv + Python + Chroma). Для одной dev-машины ок; для общих или locked-down окружений — трение. AGPL-3.0 заразная, форкать неосторожно нельзя.

agentmemory — для тех, кто хочет авто без сервисов

То же, что предлагает claude-mem, но без внешних сервисов, с более изощрённым retrieval'ом (BM25 + vector + KG с RRF действительно хорош) и production-grade тестовым набором. Четырёхуровневая модель памяти (working / episodic / semantic / procedural) — самая продуманная классификация в этой области, что я видел.

Цена — сложность. 21k LOC, 107 endpoints, 51 MCP tool. Большая поверхность, прежде чем уверенно кастомизировать. Авто-захват означает, что трудно знать, что именно в памяти в любой момент.

claude-wiki-memory — для тех, кто хочет читаемую память

Хочешь, чтобы то, что в памяти, было читаемо человеком. Хочешь читать wiki сам, гонять её через code review, дифать, передавать тиммейту. Хочешь гарантий того, что окажется в LLM-контексте (не «embeddings думают, что это релевантно»). Хочешь принести ноль новой инфраструктуры.

Цена — дисциплина. Авто-захват срабатывает только на границах сессии — нет «каждая команда залогирована», и LLM-фильтр иногда выбрасывает то, что ты бы оставил. Retrieval — это что бы LLM ни сделал с index.md плюс инструмент Read. Значит, надо хорошо писать index.md.

Когда тебе НЕ стоит брать эту систему

Будь честен. Не подходит, если:

  1. У тебя сотни сессий в неделю и ты хочешь, чтобы все были искабельны. Бери agentmemory — авто-захват именно для этого.

  2. Нужны размытые семантические вопросы вроде «что мы обсуждали в октябре?». Бери одну из двух других. Тут embeddings нет.

  3. Не хочешь поддерживать wiki, даже разреженную. Любая из двух других требует меньше курации. Весь смысл этой системы — что ты (или твоя команда) владеешь wiki.

  4. Нужно, чтобы кросс-сессионный retrieval ранжировался по релевантности. Эта система показывает LLM всю wiki и даёт LLM решать. Другие ранжируют retrieval-моделями. Для очень больших баз ranking помогает. Для ~50 статей — нет.

  5. Ты individual contributor на чужом репо и не можешь добавить директорию knowledge/. Этой системе нужно, чтобы knowledge/ жил в репо. Можно держать персональную копию вне репо, но тогда это agentmemory с лишними шагами.

Когда стоит взять

claude-wiki-memory подходит, если:

  1. Хочешь, чтобы то, что в памяти, жило в git. Code review, blame, диффы. Команда соглашается о wiki так же, как соглашается о коде.

  2. Не доверяешь авто-захвату. Из-за секретов и PII или потому что видел, как авто-захватные системы накапливают шум и retrieval ухудшается. Тут LLM-фильтр явный и легко настраивается.

  3. Хочешь ноль фоновых сервисов. Ничего на порту, ничего, что само себя держит, ничего, что надо мониторить.

  4. Память маленькая и форма известная. 20–100 концепций — sweet spot. Вся wiki влезает в одно LLM-контекстное окно. Retrieval становится «какой файл прочитать?», а не «какой кластер embeddings ближе?».

  5. Говоришь по-русски (или на любом не-английском) и хочешь LLM-промпты на своём языке. Тут есть переключатели языка во flush / compile / query / lint. Системы с embeddings слабее на не-английском.

  6. У тебя уже есть CLAUDE.md, FIXES.md, runbook'и в Doc/, и index.md естественно встал бы рядом. Система построена вокруг этой формы. Если проект уже выглядит так — установка одной командой, и wiki ощущается естественным продолжением.

Самая глубокая разница

У трёх систем — разные теории памяти:

  • Теория claude-mem: память — это всё, ранжированное. Захвати всё, верни top-K.
  • Теория agentmemory: память — структурирована, со слоями. У разных видов фактов разный жизненный цикл и разные паттерны retrieval'а; уважай это.
  • Теория claude-wiki-memory: память — это написанный артефакт. Понимание проекта командой кристаллизуется в страницы, написанные намеренно. Задача агента — поддерживать эти страницы и грузить их в контекст.

Каждая теория верна для разных задач. Моя — лучше всего, когда цель — общее понимание команды по долгоживущему проекту. Две другие — когда цель сделать flow одного человека с агентом эффективнее.

Не уверен, что подходит — самый дешёвый эксперимент: попробуй сначала эту. Установка — одна команда, удаление — одна команда. Если поймёшь, что хочется fuzzy retrieval по тысячам сессий — agentmemory покажется очевидно правильным.