Урок 13.1. Обзор: топ-20 open-source инструментов Agent Memory

План лекции

В этой лекции мы сначала зафиксируем метод отбора инструментов из GitHub topic agent-memory, потому что сам topic содержит не только memory layers, но и книги, curated lists, generic databases, agent runtimes and experimental apps. Затем разберем топ-20 инструментов, которые стоит держать на архитектурной карте курса.

После обзорной таблицы мы сгруппируем инструменты по классам: graph memory, personal memory, coding-agent memory, stateful agent memory, context engines, local-first memory and shared memory. В конце построим decision map: какие инструменты смотреть первыми под разные задачи и какие вопросы задавать перед внедрением.

Цель лекции

Дать обзор популярных open-source и source-available инструментов из GitHub topic agent-memory, отфильтрованных по релевантности для AI Agent Memory.

Ожидаемый результат

Читатель понимает, какие инструменты стоит изучать в новом модуле, почему они не являются взаимозаменяемыми, какие архитектурные классы они представляют и по каким критериям их сравнивать.

Зачем это нужно

В предыдущих модулях мы уже разобрали базовые категории: dedicated memory frameworks, agent frameworks with state, RAG frameworks, vector/search/graph storage, observability and enterprise connectors.

Но GitHub ecosystem живет быстрее учебного плана. В topic agent-memory появляются десятки проектов, которые называют себя:

• memory layer;
• context engine;
• personal memory;
• coding-agent memory;
• knowledge graph memory;
• MCP-native memory;
• local-first memory;
• agent OS;
• shared memory for agent fleets.

Часть этих проектов действительно полезна. Часть является экспериментами. Часть использует agent-memory как широкий marketing tag. Поэтому этот модуль нужен как практический каталог: не "что сейчас самое модное", а "какие архитектурные идеи представлены в open-source инструментах".

Метод отбора

Список основан на снимке GitHub topic agent-memory от 2026-08-08.

Первичная выборка:

topic:agent-memory
sort: stars desc
limit: 100

Дальше использовалась ручная фильтрация. Это важно: stars and topic tags сами по себе не говорят, что перед нами зрелый memory framework.

В обзор попали репозитории, которые:

• имеют англоязычное описание или англоязычную документационную поверхность;
• являются инструментами, libraries, runtimes, context engines, memory layers or agent memory apps;
• помогают понять отдельный архитектурный подход к agent memory;
• не являются только книгой, awesome-list, paper list or generic database;
• не являются китайскоязычными проектами с основной китайскоязычной поверхностью.

Из первичного топа были сознательно исключены некоторые крупные репозитории. Например, pingcap/tidb and dolthub/dolt важны как infrastructure, но это не специализированные agent-memory tools. bojieli/ai-agent-book and several Awesome-* repositories полезны как материалы, но это не инструменты.

Важное предупреждение про open source

В этом модуле мы используем слово open-source в практическом смысле: публичный репозиторий, доступный код, возможность изучить архитектуру. Но это не юридическая рекомендация.

Перед production use нужно отдельно проверять:

• license;
• commercial restrictions;
• hosted vs self-hosted split;
• что находится в open-source core, а что только в cloud;
• активность maintainers;
• security posture;
• deletion and privacy guarantees.

Некоторые популярные репозитории в GitHub Search API имеют license Other или неочевидный статус. В обзорной карте такие проекты полезны как архитектурные кандидаты, но не как автоматическая production recommendation.

Ключевые термины

Топ-20 инструментов

Таблица ниже не является рейтингом "лучше-хуже". Она отсортирована по популярности на момент снимка и очищена от нерелевантных попаданий.

Stars указаны округленно по снимку на 2026-08-08. Для будущей публикации лучше обновлять таблицу автоматически или явно писать дату снимка.

Как читать эту таблицу

Если смотреть только на stars, можно сделать неправильный вывод: "первые пять инструментов всегда лучше остальных". Для memory systems это плохая логика.

Инструменты отличаются не только популярностью, но и формой задачи:

• один инструмент строит knowledge graph;
• другой хранит personal memory across agents;
• третий ищет по локальной истории coding agents;
• четвертый превращает corrections into skills;
• пятый является полноценным app, а не library.

Правильный вопрос:

Какую responsibility в memory architecture закрывает этот инструмент?

А не:

У кого больше stars?

Карта классов инструментов

Эта карта намеренно допускает пересечения. Например, EverOS одновременно относится к personal memory, local-first memory and declarative memory. MemSearch относится к coding-agent memory, но внутри использует Markdown, Milvus and hybrid retrieval. Cognee относится к graph memory, но может участвовать и в RAG-like workflows.

Класс 1: Graph and knowledge memory

В этот класс входят инструменты, которые рассматривают память как сеть сущностей, отношений and evidence.

Главные кандидаты:

• Cognee;
• Semantica;
• create-context-graph;
• частично Neo4j-based memory tools.

Graph memory полезна, когда агент должен отвечать не только на "что похоже?", но и на "как связано?".

Пример:

Question:
"Какие документы, решения и incidents связаны с migration проекта?"

Need:
project -> decision -> pull request -> incident -> owner -> current status

Pure vector search может найти похожие fragments, но не построит reliable relationship path. Graph tools пытаются сделать эту структуру явной.

Риск graph memory в том, что граф кажется более authoritative, чем он есть. Если entity extraction ошиблась, relation устарела или source был слабым, graph traversal уверенно приведет агента к неправильному выводу. Поэтому graph tools требуют provenance, freshness and validation.

Класс 2: Personal and portable memory

Personal memory tools пытаются дать пользователю переносимую память между агентами and apps.

Главные кандидаты:

• memU;
• EverOS;
• personal-model;
• Supermemory;
• Bitterbot Desktop.

Этот класс отвечает на продуктовый вопрос:

Как пользователь может сохранить свой контекст один раз,
а потом использовать его в разных assistants?

Сюда попадают preferences, goals, background, work style, recurring projects and corrections.

Сильная сторона personal memory - continuity. Пользователь не объясняет заново, кто он, над чем работает and как предпочитает получать ответы.

Главный риск - over-personalization and privacy. Если personal memory слишком легко доступна всем agents, она может всплывать в неправильном контексте. Если пользователь не видит и не контролирует память, доверие быстро ломается.

Класс 3: Coding-agent local memory

Coding-agent memory стала отдельной категорией, потому что coding agents уже имеют богатую локальную среду:

• repository files;
• terminal history;
• git history;
• previous sessions;
• tool traces;
• project instructions;
• failed attempts;
• accepted fixes.

Главные кандидаты:

• MemSearch;
• magic-context;
• ctx;
• claude-smart;
• Deja-vu;
• projectmem;
• brain.md.

Этот класс часто делает ставку на local-first architecture. Вместо cloud memory используется:

• Markdown;
• SQLite;
• local logs;
• local search;
• local vector index;
• MCP server;
• single binary.

Для coding agents это здоровая архитектурная привычка. Current repository state должен оставаться source of truth, а memory помогает не повторять ошибки и быстрее находить прошлые решения.

Класс 4: Stateful agent memory

Stateful agent memory tools ближе к agent runtime. Они помогают агенту жить дольше одного запроса.

Главные кандидаты:

• Honcho;
• Letta Code;
• partially agent runtimes with memory such as Neo or agent OS projects.

Здесь memory связана с identity, session, relationships, conversations and state evolution.

Важно не путать:

• stateful agent runtime - как агент выполняется and maintains state;
• memory layer - какие facts, events and skills сохраняются and retrieved;
• application database - authoritative product data.

Stateful tools могут ускорить разработку ассистента, но не отменяют политики: consent, deletion, scopes, audit.

Класс 5: Experience and correction memory

Этот класс особенно важен для агентов, которые должны учиться на опыте.

Главные кандидаты:

• Agentic Context Engine;
• claude-smart;
• projectmem;
• AgentRecall-X;
• tools with reflection/procedural memory angle.

Они пытаются превратить события вроде:

"Этот подход не сработал."
"Пользователь исправил стиль ответа."
"В этом проекте нельзя запускать эту команду."
"Для такой ошибки помогает другой workflow."

в reusable memory.

Это близко к reflection memory and procedural memory из Module 02. Но здесь риск выше: если агент закрепит плохой урок, он начнет систематически ошибаться. Поэтому correction memory должна быть проверяемой and reversible.

Класс 6: Local-first context stores

Local-first memory важна по трем причинам:

1. Privacy: данные не уходят в cloud.
2. Portability: память можно перенести, просмотреть, version.
3. Debuggability: developer видит, что именно сохранено.

Главные кандидаты:

• EverOS;
• LycheeMem;
• ctx;
• Deja-vu;
• brain.md;
• TrueMemory;
• local SQLite/Markdown tools.

Local-first не значит примитивно. Некоторые инструменты используют hybrid search, MCP, vector indexes, graph-like structures and local dashboards. Но их сильная сторона не в масштабировании до enterprise, а в прозрачности and control.

Decision map

Decision map не заменяет architecture review. Он помогает выбрать первую группу инструментов для исследования.

Почему stars не равны зрелости

GitHub stars полезны как сигнал внимания сообщества, но в memory systems они особенно обманчивы.

Высокие stars могут означать:

• проект попал в тренд;
• у проекта красивый demo;
• tool решает больную проблему;
• команда активно продвигает продукт;
• README обещает сильные benchmark results.

Но production maturity проверяется иначе:

• есть ли стабильная release history;
• понятна ли license;
• есть ли migration path;
• как устроены deletion and export;
• есть ли тесты and benchmarks;
• можно ли self-host без скрытых cloud dependencies;
• как работает permissions;
• как observable memory read/write;
• можно ли объяснить, почему memory попала в prompt.

Поэтому в этом модуле каждый deep-dive должен завершаться не восхищением инструментом, а checklist внедрения.

Мини-кейс: выбор инструмента для coding agent

Команда хочет добавить память для coding assistant, который работает в локальных репозиториях.

Проблемы:

• агент повторяет уже провалившиеся подходы;
• не помнит project conventions;
• не находит прошлые решения похожих bugs;
• иногда использует устаревшие notes вместо текущих файлов.

Подходящий first research set:

• MemSearch, если нужна Markdown + Milvus architecture;
• ctx или Deja-vu, если нужно искать по уже существующей истории coding agents;
• claude-smart, если ключевой сигнал - user corrections;
• EverOS or brain.md-style memory, если нужна human-readable project memory.

Неподходящий первый выбор:

• тяжелая graph memory platform, если главная задача - не relationships, а local task history;
• cloud personal memory, если проект требует полностью offline workflow;
• agent OS, если команда еще не определила memory records and policies.

Мини-кейс: выбор инструмента для research agent

Research agent читает документы, строит claims, сравнивает sources and обновляет synthesis неделями.

Проблемы:

• нужно связывать claims with sources;
• важно видеть contradictions;
• полезна entity graph;
• нужна provenance;
• memory должна отличать notes from verified facts.

Подходящий first research set:

• Cognee for graph/RAG/memory platform;
• Semantica for graph-native accountable context;
• create-context-graph for Neo4j-based graph scaffolding;
• Supermemory if context API and memory app are more important than graph rigor.

Здесь local coding history tools будут менее полезны. Они хороши для repeated developer workflows, но не обязательно для source-grounded research memory.

Мини-кейс: выбор инструмента для персонального ассистента

Personal assistant должен помнить user preferences, goals, recurring entities and corrections across sessions.

Проблемы:

• пользователь хочет видеть and edit memory;
• memory должна быть portable;
• нельзя смешивать work and personal scopes;
• нужно не сохранять sensitive data без consent;
• agent должен не переиспользовать старые preferences blindly.

Подходящий first research set:

• memU for personal memory across agents;
• EverOS for user-owned Markdown-native memory;
• personal-model for explicit HUMAN.md-style profile;
• Supermemory if нужен API/app layer;
• Honcho if нужен stateful assistant runtime.

Главный вопрос здесь не retrieval quality, а user control.

Что проверять перед внедрением любого инструмента

Перед тем как добавлять memory tool в продукт, нужно пройти короткий due diligence.

Если инструмент не отвечает на эти вопросы, его можно исследовать, но рано считать foundation for production memory.

План следующих лекций

Этот модуль дальше пойдет от крупных and показательных инструментов к более специализированным.

Порядок выбран так, чтобы сначала разобрать самые широкие memory platforms, затем personal/local tools, затем coding-agent and experience-memory patterns.

Типичные ошибки

Ошибка 1: брать первый tool по stars.

Популярность не говорит, что tool подходит под вашу data shape, latency, privacy and compliance.

Ошибка 2: считать public repo automatically open-source.

License может быть Other, неполной, source-available or unsuitable for commercial use. Проверяйте LICENSE.

Ошибка 3: смешивать app and infrastructure.

Некоторые проекты являются полноценными apps. Их полезно изучать как UX and architecture examples, но они не всегда легко встраиваются как library.

Ошибка 4: сравнивать graph memory and local coding history search напрямую.

Это разные problem shapes. Graph memory отвечает на relationships. Local history search помогает не повторять уже решенные or failed tasks.

Ошибка 5: не проверять deletion and export.

Memory tool без удаления and export - риск для user trust and compliance.

Ошибка 6: доверять benchmark claims без сценариев.

Даже хороший benchmark result не доказывает, что tool справится с вашими scopes, documents, agents and privacy rules.

Источники

• GitHub topic agent-memory: https://github.com/topics/agent-memory
• GitHub CLI search docs: https://cli.github.com/manual/gh_search_repos
• Cognee repository: https://github.com/topoteretes/cognee
• Supermemory repository: https://github.com/supermemoryai/supermemory
• Memori repository: https://github.com/MemoriLabs/Memori
• memU repository: https://github.com/NevaMind-AI/memU
• EverOS repository: https://github.com/EverMind-AI/EverOS
• Honcho repository: https://github.com/plastic-labs/honcho
• MemSearch repository: https://github.com/zilliztech/memsearch
• Agentic Context Engine repository: https://github.com/kayba-ai/agentic-context-engine
• Semantica repository: https://github.com/semantica-agi/semantica
• Deja-vu repository: https://github.com/vshulcz/deja-vu

Краткое резюме

GitHub topic agent-memory показывает, что open-source ecosystem вокруг agent memory уже разделилась на несколько классов: graph memory, personal memory, coding-agent memory, stateful memory, experience/correction memory and local-first context stores.

Топ-20 инструментов полезны не как leaderboard, а как карта архитектурных вариантов. Для выбора нужно смотреть на data shape, memory types, storage, retrieval, deletion, privacy, license and maturity.

Вопросы для самопроверки

1. Почему GitHub stars нельзя использовать как единственный критерий выбора memory tool?
2. Чем graph memory отличается от coding-agent local history search?
3. Какие инструменты из топ-20 лучше всего подходят для personal portable memory?
4. Почему license and deletion flow нужно проверять до production use?
5. Какой first research set вы выбрали бы для локального coding agent и почему?

Что дальше

В следующей лекции мы начнем deep-dive с Cognee: разберем, как graph-first memory platform связывает ingestion, knowledge graph, retrieval and agent memory.