План лекции
Сначала мы разберем, почему memU выделяется среди memory tools: он хранит персональную память как readable wiki/skills, работает across sessions, agents and devices, а его core memory logic намеренно сделана компактной.
Затем рассмотрим lifecycle memU: host adapter читает session logs, scheduled task готовит self-evolve jobs, агент сам решает, создать ли новый skill или обновить существующий, затем memU индексирует Markdown and возвращает relevant memory в будущих задачах. В конце обсудим self-hosted/local режим, storage backends, риски такого подхода and сценарии, где wiki-style memory особенно сильна.
Цель лекции
Понять memU как lightweight agent-driven memory system, который превращает историю работы coding/desktop agents в общую LLM wiki and reusable Markdown skills.
Ожидаемый результат
После лекции читатель понимает:
- чем wiki-style memory отличается от fact-store memory;
- как memU связывает memorize and retrieve через host adapters;
- почему skill extraction является формой procedural/reflection memory;
- какие storage and embedding backends поддерживаются;
- где memU удобен, а где лучше выбрать другой memory layer.
Короткая карточка инструмента
| Поле | Значение |
|---|---|
| Repository | https://github.com/NevaMind-AI/memU |
| Homepage | https://memu.pro |
| Cloud UI | https://memu.so |
| Stars snapshot | около 14.3k на 2026-08-08 по GitHub page |
| Primary language | Python |
| License | Apache-2.0 |
| Category | Personal memory across agents |
| Основная идея | Shared LLM wiki across sessions, agents and devices |
| Storage | Local SQLite, Postgres, in-memory for tests, cloud backend |
memU описывает себя как lightweight, agent-driven memory system. Его особенность в том, что память не прячется только в vector store. Полезный опыт агента превращается в readable Markdown skills: имя, описание, workflow, branches, edge cases and pitfalls.
Это важный дизайн. Когда память остается читаемой, пользователь and команда могут inspect, исправлять and переносить ее между инструментами.
Почему wiki-style memory важна
Многие memory systems хранят extracted facts:
User prefers Poetry.
Project uses GitHub Actions.
Deploy failed because lock file was stale.
Это полезно, но не всегда достаточно. Для coding agents часто нужно помнить не факт, а workflow:
Перед публикацией сайта:
1. запустить builder check;
2. проверить Mermaid diagrams;
3. убедиться, что mobile menu работает;
4. обновить poetry.lock, если pyproject.toml изменился;
5. затем запускать deploy.
Такую память удобнее хранить как skill. Skill - это не просто знание, а reusable procedure. В терминах курса это смесь procedural memory and reflection memory.
Базовая mental model
memU можно представить как sidecar рядом с агентом.
Главная особенность этой схемы: judgment and synthesis stay inside the agent. README прямо отмечает, что MemoryService не делает LLM/chat calls; он stores, embeds and retrieves skill Markdown, который подготовил агент.
Это меняет распределение ответственности. memU не пытается быть всемогущим extractor. Он организует цикл, где агент сам превращает опыт в читаемую память.
Две стороны цикла: memorize and retrieve
В README memU для host adapters описаны две важные стороны:
| Сторона | Что делает |
|---|---|
record / memorize |
Scheduled bridging task читает новые session logs and превращает их в job files. |
inject / retrieve |
Standing instruction просит агента выполнить retrieve before answering. |
То есть memU не только хранит память. Он встраивается в привычку агента:
Перед ответом проверь, есть ли relevant memory.
После сессии подумай, можно ли извлечь reusable skill.
Это похоже на человеческий workflow: мы не просто записываем заметки, а возвращаемся к ним перед похожей задачей.
Host adapters
memU поддерживает несколько host adapters для desktop and coding agents. В README перечислены Codex, Claude Code, Cursor, OpenClaw, Hermes, WorkBuddy, Cola and generic memu-agent.
Каждый adapter знает:
- где лежат session logs;
- как их читать;
- какой instruction file патчить;
- какой binary запускать;
- как проверить, что memorization and retrieval работают.
Пример из README:
| Host | Что читает | Что патчит |
|---|---|---|
| Codex | ~/.codex/sessions/**/*.jsonl |
~/.codex/AGENTS.md |
| Claude Code | session JSONL under ~/.claude/projects |
~/.claude/CLAUDE.md |
| Cursor | agent transcripts | project AGENTS.md |
| OpenClaw | SQLite or JSONL session store | OpenClaw workspace instructions |
| Hermes | ~/.hermes/state.db |
~/.hermes/SOUL.md |
Этот approach pragmatic: вместо того чтобы заставлять все agents говорить по одному API, memU адаптируется к их локальным следам.
Automatic skill extraction
Самая важная часть memU - automatic skill extraction. По README lifecycle выглядит так:
- Capture new sessions.
- Prepare self-evolve jobs.
- Let the agent decide.
- Write readable skill Markdown.
- Commit and index.
- Retrieve it later.
Разберем смысл каждого шага.
Capture new sessions означает, что memU не требует от пользователя вручную писать заметки после каждой задачи. Adapter находит новые session logs.
Prepare self-evolve jobs превращает большую session history в bounded task: агент получает нужные paths and context, чтобы оценить, есть ли reusable lesson.
Let the agent decide - ключевой момент. Иногда сессию не нужно превращать в memory. Иногда надо обновить existing skill. Иногда появился новый workflow.
Write readable skill Markdown делает память inspectable. Это не черный ящик.
Commit and index превращает skill в retrievable artifact.
Retrieve later возвращает relevant skill, когда похожая задача повторяется.
Skill как формат памяти
Skill в memU должен отвечать на практический вопрос:
Что агент должен делать в похожей ситуации в будущем?
Хороший skill обычно содержит:
- короткое имя;
- описание, когда применять;
- последовательность действий;
- branches for variants;
- edge cases;
- pitfalls;
- команды проверки;
- признаки успешного результата.
Это заметно отличается от memory fact. Fact говорит "что истинно". Skill говорит "как действовать".
Связь с procedural and reflection memory
В модуле 2 мы разделяли типы памяти. memU особенно хорошо ложится на две категории.
| Тип памяти | Как memU его реализует |
|---|---|
| Procedural memory | Markdown skills describe reusable workflows. |
| Reflection memory | Agent analyzes past sessions and extracts lessons. |
| Episodic memory | Session logs are source material. |
| Semantic memory | Skill descriptions and facts become searchable. |
| Shared memory | Multiple agents can use one configured backend. |
Это делает memU хорошим примером не только "agent remembers facts", а "agent learns how we work".
Shared memory across agents
README подчеркивает: all hosts share one configured memory backend через ~/.memu/config.env. То, чему один host научил memU, другой host retrieves.
Для пользователя это означает:
Например, Codex научился, что в проекте нужно запускать poetry run python website_builder/build.py check --input . --strict. Позже Claude Code or Cursor может получить тот же skill перед похожей задачей.
Это очень близко к идее personal operating memory: пользователь не хочет учить каждого агента заново.
Storage and embedding backends
memU поддерживает local and cloud memory backends. Для local/self-hosted режима README перечисляет:
| Backend | Vector search | Use case |
|---|---|---|
inmemory |
brute-force cosine | tests and throwaway sessions |
sqlite |
brute-force cosine | local/default, single writer |
postgres |
pgvector | concurrent access and larger stores |
Embedding providers включают OpenAI, Jina, Voyage, Doubao and OpenRouter. Практически это означает, что self-hosted setup все равно требует решения: где считать embeddings and какие данные уходят провайдеру.
Если нужна максимально приватная установка, нужно выбирать local-compatible embedding path or internal provider.
Cloud vs self-hosted
Cloud mode удобен для cross-device сценария. Пользователь может подключить несколько agents and devices к одному memory backend.
Self-hosted mode дает больше контроля:
- memory store находится локально or в собственной Postgres;
- можно управлять DSN and backups;
- проще вписать в корпоративные политики;
- меньше риска случайной передачи данных в внешний memory service.
Но self-hosted mode требует embedding key/provider. Это важный нюанс: даже если storage локальный, embeddings могут отправлять text наружу, если выбран external provider.
CLI and doctor
У memU есть CLI. README показывает команды вроде:
memu-codex retrieve "What should I remember about this project?"
Также есть <binary> doctor, который проверяет config, selected mode and live retrieval. Это хороший пример operational maturity для memory tools.
Memory layer часто ломается тихо: инструкция не пропатчилась, adapter не читает logs, embedding key неверный, retrieval ничего не возвращает. doctor делает эту цепочку проверяемой.
Мини-кейс: память для курса
Представим, что пользователь пишет большой курс с несколькими AI agents. В ходе работы появились правила:
- каждая лекция должна начинаться с плана;
- между схемами нужны связные объяснения;
- после каждой лекции нужен цикл проверки;
- диаграммы Mermaid должны рендериться;
- сайт собирается локальным builder script;
- mobile menu должен работать на главной.
В fact-store это будет набор разрозненных facts. В memU это может стать skill:
Skill: Write AI Agent Memory lecture
When: user asks to write a course lecture
Workflow:
1. Read module plan and neighboring lessons.
2. Draft lecture plan first.
3. Write prose-heavy lecture with tables/diagrams spaced by explanation.
4. Add summary and self-check questions.
5. Run website builder strict check.
Pitfalls:
- Do not make lecture only lists.
- Check Mermaid syntax.
Этот skill гораздо полезнее для будущей задачи, чем простая память "user likes plans".
Мини-кейс: команда разработчиков
В команде часто есть tribal knowledge:
- как запускать test suite;
- какие flaky tests игнорировать нельзя;
- как оформлять PR;
- какие deploy windows безопасны;
- какие команды запрещены в production;
- какие style conventions не описаны в README.
memU может постепенно превращать эту историю в shared skills wiki. Новый agent or новый developer получает не только docs, но и накопленный workflow knowledge.
Однако здесь нужно governance: кто редактирует skills, как удалять устаревшие workflows, как помечать project-specific instructions and как избегать записи секретов.
Сравнение с Memori
| Критерий | Memori | memU |
|---|---|---|
| Главный акцент | Agent execution as structured state | Shared LLM wiki and reusable skills |
| Основные primitives | entity, process, session | host adapters, session logs, skills, retrieve |
| Формат памяти | Structured augmentation | Readable Markdown skills |
| Кто синтезирует память | Memory/augmentation layer | Агент через self-evolve job |
| Отличный сценарий | Production agents with tools | Desktop/coding agents across tools |
| Проверяемость | Через structured records and dashboard/API | Через readable files, CLI and doctor |
Memori ближе к enterprise runtime memory. memU ближе к personal/coding workflow memory, которую пользователь может читать and править.
Сравнение с Supermemory
Supermemory делает ставку на user profiles and hybrid context API. memU делает ставку на learned workflows as Markdown.
Если вам нужно быстро ответить "что пользователь предпочитает?", Supermemory будет естественнее. Если нужно помнить "как мы обычно решаем такие задачи в этом проекте?", memU выглядит сильнее.
Их можно сочетать:
Profile сообщает "кто пользователь". Skill сообщает "как действовать".
Риски и ограничения
Первый риск - качество agent judgment. Если агент плохо извлек skill, memU аккуратно сохранит плохую процедуру. Поэтому readable format важен, но не заменяет review.
Второй риск - stale skills. Workflow меняется: команды сборки, deployment, API, policies. Если старый skill продолжает retrieval, агент может повторять устаревшие действия.
Третий риск - secrets in logs. Host adapters читают session logs, где могут быть tokens, paths, customer data. Нужны redaction rules and осторожная настройка.
Четвертый риск - instruction file patching. memU меняет host instruction files. Это удобно, но требует аккуратности: пользователь должен понимать, какие standing instructions добавлены.
Пятый риск - cross-agent contamination. Общая память полезна, но не все workflows должны быть общими. Personal, project and work scopes нужно отделять.
Как тестировать memU
| Тест | Что проверяет |
|---|---|
| Adapter detection | Находит ли memU правильные session logs and instruction file. |
| Memorize loop | Создается ли self-evolve job after session. |
| Skill quality | Получается ли readable, useful Markdown skill. |
| Retrieval relevance | Возвращается ли skill на похожей задаче. |
| Stale update | Обновляется ли skill при изменении workflow. |
| Scope separation | Не смешиваются ли личные and project skills. |
| Secret hygiene | Не попадают ли credentials and private snippets в memory. |
| Doctor command | Проверяет ли CLI реальный путь retrieval. |
Для thorough проверки нужно выполнить полный цикл: создать маленькую задачу, дать агенту извлечь skill, затем в новой сессии задать похожий запрос and проверить, что skill был retrieved.
Практический rollout
Начинайте с одного host adapter and одного проекта. Например, подключите memU к Claude Code or Codex only for a low-risk repository.
Затем выполните несколько задач, где явно есть reusable workflow. После этого проверьте generated skills manually. Исправьте названия, удалите случайные детали, добавьте pitfalls.
Только когда retrieval начал помогать, подключайте второй host. Shared memory имеет смысл тогда, когда качество уже приемлемое. Иначе вы просто распространяете noise между agents.
Антипаттерны
Первый антипаттерн - превращать каждый session log в skill. Большинство сессий не содержит reusable knowledge.
Второй антипаттерн - хранить слишком длинные skills. Если skill похож на transcript, он плохо работает как procedural memory.
Третий антипаттерн - не редактировать generated memory. Readable Markdown - преимущество только тогда, когда люди реально могут его review.
Четвертый антипаттерн - смешивать глобальные user habits and project-specific commands in one skill.
Чек-лист выбора memU
memU стоит рассмотреть, если:
- вы активно используете desktop/coding agents;
- задачи повторяются and требуют workflows;
- хочется shared memory across Codex, Claude Code, Cursor or OpenClaw;
- важна readable memory rather than opaque vectors;
- вы хотите local/self-hosted option;
- процедурная память важнее, чем strict factual graph;
- команда готова review generated skills.
Если основная задача - customer-facing personalization API, посмотрите Supermemory or Mem0. Если основная задача - graph relationships over documents, посмотрите Cognee.
Источники
- GitHub repository: https://github.com/NevaMind-AI/memU
- README: https://github.com/NevaMind-AI/memU/blob/main/README.md
- Project site: https://memu.pro
- Cloud UI referenced by README: https://memu.so
- Hosted skill instructions referenced by README: https://memu.pro/SKILL.md
Краткое резюме
memU показывает wiki-style approach to agent memory. Вместо того чтобы хранить только facts, он превращает полезную историю работы агента в Markdown skills, которые можно читать, исправлять, индексировать and возвращать в будущих задачах.
Его главная сила - procedural and reflection memory for desktop/coding agents. Он особенно полезен, когда пользователь работает с несколькими AI tools and хочет, чтобы они делили общий опыт.
Вопросы для самопроверки
- Чем wiki-style memory отличается от fact-store memory?
- Почему Markdown skills хорошо подходят для procedural memory?
- Какие две стороны цикла memU описываются как record and inject?
- Что делает host adapter?
- Почему
MemoryServiceбез LLM calls - важная архитектурная деталь? - Какие риски появляются при чтении session logs?
- Когда memU лучше Memori?
- Почему generated skills нужно review?
Что дальше
В следующей лекции мы перейдем к EverOS. Если memU показывает personal wiki across agents, то EverOS полезен как пример более широкой agent memory operating layer, где память связывается с productivity, organization and long-running context.