Mnemon: open-source система памяти для multi-agent AI — архитектура, маршрутизация, governance

У меня три AI-агента — и они пишут в одни и те же файлы. Каждую ночь.

Claude Code локально, Euphoria на сервере, Cursor в IDE. Все трое читают мою личную базу знаний. Все трое пишут в неё: задачи, контекст, состояние проектов. Через шесть месяцев такой работы я получил 200+ файлов, разбросанные дублирующие факты, конфликты при git merge и нулевой аудит — кто что поменял.

Я посмотрел на рынок memory-систем. Их около 50. Ни одна не решает multi-agent проблему по-настоящему.

Что не так с существующими системами

Главный изъян прост: каждая система агентной памяти спроектирована для одного агента. Это решённая задача. Нерешённая — shared memory для команды агентов, каждый из которых работает с разными правами и разными паттернами записи.

Вот текущий ландшафт:

Mem0 — самый популярный. У них 48K звёзд и $24M инвестиций. Но когда два агента записывают в один и тот же ключ памяти, Mem0 передаёт конфликт на разрешение LLM. Это недетерминированно, не воспроизводимо и не оставляет следов. Никакого аудита, никакого rollback.

Letta ближе всего к тому, что нужно — агент ведёт свою память самостоятельно. Но это целый стек: Docker, PostgreSQL, собственный UI. Вы не добавляете memory layer к существующей системе — вы переходите на новый фреймворк.

Три gap, которые никто не закрыл

Gap A: Memory Governance

Ни одна production-система не имеет authority matrix — явной матрицы прав доступа на запись. Кто может писать в какой файл. Кто побеждает при конфликте. Как разрешать merge.

Mem0 отдаёт это на откуп LLM. Letta — агент-хозяин всего своего контекста. Остальные просто молча перезаписывают.

В моей системе это выглядит так:

# mnemon.agents.yaml
agents:
  claude-code:
    write: [tasks/, auto-memory/]
    read: ["**"]
  euphoria-bot:
    write: [tasks/BOARD.md:status_only]
    read: ["**"]
  human:
    write: ["**"]
    priority: highest
    conflict_wins: true

Euphoria может обновлять только поле status в BOARD.md. Claude Code пишет в задачи и auto-memory. Человек всегда побеждает. Это не LLM-решение — это декларативные правила, которые enforcement происходит детерминированно.

Gap B: Declarative Content Routing

Во всех существующих системах LLM решает, куда записать факт. Это имплицитно, не воспроизводимо и не поддаётся аудиту.

“Добавь в мою память, что я предпочитаю TypeScript” — куда это пойдёт? В Mem0 — в vector store, без предсказуемой схемы. Через неделю вы не найдёте это без embedding lookup.

Declarative routing — альтернатива:

# mnemon.routes.yaml
routes:
  - match: "финансы|долг|деньги|бюджет"
    target: finance/debts.md
  - match: "задача|таск|TODO|backlog"
    target: tasks/BOARD.md
  - match: "человек|контакт|встреча с"
    target: people/people.md
  - match: "книга|прочитал|рецензия"
    target: knowledge/books.md
  - match: "идея|стартап|концепт"
    target: ideas/ideas.md
  - default: journal/{{date}}.md

YAML в git. Human-readable. Версионированный. Можно написать тест на каждый route. Можно откатить. Можно объяснить коллеге за 30 секунд.

Это радикально отличается от “пусть LLM разберётся”.

Gap C: Memory-as-Infrastructure

Существующие системы решают задачу “память для одного агента”. Нерешённая задача — shared memory layer для целого AI-стека.

У меня:

• Claude Code локально (IDE агент)
• Euphoria на сервере (telegram-бот)
• Потенциально Cursor, другие инстансы Claude

Все три должны иметь одинаковый актуальный контекст о моих проектах, людях, предпочтениях, текущих задачах. Ни одна из 50+ систем не проектировалась для этого сценария.

Архитектура Mnemon

Четыре слоя памяти

Вся система строится на явной иерархии, где каждый слой имеет отдельную ответственность:

Ключевой принцип: никакого дублирования между слоями. Конкретное правило проекта не дублируется в memory graph. Кросс-проектные пользовательские факты не дублируются в project-local memory. Каждый факт живёт ровно в одном месте.

Markdown как source of truth

Все данные — это markdown-файлы. Не PostgreSQL. Не векторная база. Не проприетарный формат.

Это сознательный выбор с конкретными следствиями:

• Obsidian читает их нативно — человек работает в привычном интерфейсе
• grep и ripgrep работают без дополнительных слоёв
• Git хранит полную историю каждого изменения
• Любой текстовый редактор может открыть и отредактировать
• Backup = git push

Недостаток: семантический поиск требует embeddings поверх markdown. Это решается гибридным retrieval (см. ниже).

Git-backed versioning

Каждое изменение памяти — это git commit. Это означает:

• Полный аудит: кто, что, когда
• Rollback любого изменения в одну команду
• Diff между состояниями памяти
• Merge conflict resolution с понятными инструментами
• Backup через git push на несколько remote

Когда Euphoria обновляет статус задачи в BOARD.md, это коммит с Updated: 2026-03-04 @euphoria. Когда Claude Code добавляет заметку в auto-memory, это коммит с @claude-code. История не исчезает.

Ни одна из существующих систем не даёт этого из коробки.

Anti-duplication rules

Самая дорогая проблема в knowledge management — scattered, contradictory facts. Одна и та же информация в трёх местах, три разных версии, непонятно какая актуальная.

Mnemon решает это явными правилами маршрутизации данных:

Правила написаны явно. LLM не принимает это решение самостоятельно каждый раз.

Use Cases

Solopreneur с 3+ AI-агентами

Это мой собственный случай. Claude Code на ноутбуке, Euphoria-бот на сервере, иногда Cursor для специфических задач.

Без Mnemon: каждый агент знает только то, что я объяснил ему в начале сессии. Контекст о проектах, людях, предпочтениях — либо копируется вручную, либо теряется. После шести месяцев: 200+ файлов, дублирующие факты, конфликты, ноль аудита.

С Mnemon: один source of truth. Claude Code знает про Euphoria. Euphoria знает про текущие задачи в BOARD.md. Оба работают по одним правилам маршрутизации. Конфликты разрешаются по authority matrix, не по случайности.

Цифры по моей системе: 200+ файлов, 6 месяцев работы, 3 агента, ~30 git sync в день — ни одного неразрешённого конфликта, полный аудит каждого изменения.

Dev team с shared project memory

4 разработчика, у каждого свой Claude Code. Им нужна общая база: architecture decisions, API specs, debugging notes, onboarding контекст.

Authority matrix в этом сценарии:

agents:
  junior-dev-claude:
    write: [notes/, debugging/]
    read: ["**"]
  senior-dev-claude:
    write: [architecture/, notes/, debugging/]
    read: ["**"]
  tech-lead:
    write: ["**"]
    priority: highest
    conflict_wins: true

Junior не может случайно перезаписать архитектурное решение. Senior может. Tech lead всегда побеждает. Git хранит всю историю.

Merge strategy для конфликтов:

• Status fields: побеждает последний timestamp
• Content: старший агент > младший агент
• Structural changes (новые секции, переименования): только designated owner

Personal AI stack evolution

Классический паттерн: начинаешь с одним агентом. Добавляешь второй. Потом третий. Через год — хаос.

Без governance: агент #2 не знает, что агент #1 уже записал факт X в файл A. Записывает в файл B. Теперь два источника правды. Через полгода — пять источников, три устаревших.

С Mnemon:

• Tiering: importance: critical (всегда загружается) / importance: warm (по релевантности) / importance: cold (только по explicit запросу)
• Staleness TTL: ttl: 90d в frontmatter — файл автоматически помечается на архивацию через 90 дней без обновления
• Auto-archival: устаревшие факты уходят в archive/, не засоряют активный контекст

---
last_updated: 2026-01-15
importance: warm
ttl: 90d
description: "Текущие финансовые обязательства и дедлайны"
---

Технические детали — Retrieval

Поиск по markdown работает через гибридный retrieval: 70% vector similarity + 30% BM25.

Это лучше чистого vector search для structured knowledge bases, потому что:

• BM25 хорошо работает с точными терминами, именами, датами
• Vector хорошо работает с семантической близостью
• Комбинация покрывает оба режима поиска

Boosting через frontmatter:

---
importance: critical
tags: [architecture, decision]
---

importance: critical даёт +0.3 к гибридному score. Критичные архитектурные решения всегда всплывают выше заметок с митинга.

Search hints для неочевидного routing:

---
search_hints: ["MVP", "минимальный продукт", "первый релиз", "v1"]
---

Если кто-то ищет “когда выйдет MVP”, файл с search_hints: ["MVP"] будет найден, даже если само слово в тексте встречается редко.

Staleness в retrieval: файлы с устаревшим last_updated получают penalty к score. Вы не получаете устаревший факт раньше свежего.

Roadmap

Phase 1 (сейчас): battle-tested на production. Моя личная система — 3 агента, 200+ файлов, 6 месяцев. Все компоненты работают: routing rules, authority matrix, git versioning, hybrid retrieval, tiering, staleness TTL.

Phase 2 (Q2 2026): извлечь routing engine и governance layer в mnemon-core — npm и pip пакет. Отдельно от конкретной KB-структуры. Вы приносите свои файлы — mnemon-core добавляет governance поверх.

Phase 3: MCP server, который любой LLM-клиент может подключить как инструмент. CLI для non-technical пользователей. Документация и примеры для разных use cases.

Если вы строите multi-agent систему и память — ваше узкое место: github.com/nikitacometa/mnemon-kb

Обсуждаю архитектуру и отвечаю на вопросы в Telegram: t.me/nikitacometa