Как устроен MMW

Из этой страницы вы узнаете:

из чего состоит память MMW — записи, рабочие области, проекты и ключи;
что означают статусы unverified, stale и conflict и почему статуса «проверено» нет;
что происходит на сервере между вызовом remember и моментом, когда запись находит search.

Сквозной пример: в проекте backend агент сохранил факт «staging выкатывается через systemd-юнит app-staging», сославшись на документ docs/deploy.md. Потом документ поменяли.

Общая схема

  Ваш ассистент                      Сервер MMW
  (Claude, Cursor, Codex, ChatGPT)
        │
        │  MCP по HTTP, ключ mmw_…  ─────────►  Аккаунт
        │  (напрямую или через                    └─ Проект (ключ привязан к проекту)
        │   локальный mmw-agent)                      └─ Рабочая область (workspace)
        │                                                └─ Записи
        │                                                     ├─ content, fact_key
        │  remember(content, ...)                             ├─ source_id / source_hash
        │  ───────────────────────────►  Memory Guard          ├─ status
        │                                → запись              ├─ derived_from
        │                                → архивариус          └─ связи графа
        │  search(query)
        │  ───────────────────────────►  записи + источник + статус
        ◄──────────────────────────────

Записи

Запись — один факт, решение или договорённость. Главное поле — content (текст). Остальное необязательно, но делает память полезнее:

Поле	Зачем
`fact_key`	Ключ темы, например `deploy-staging`. Записи с одним ключом сравниваются между собой.
`source_id`, `source_hash`, `source_revision`	Откуда взят факт: документ, файл, сессия — и хеш его содержимого.
`confidence`	Уверенность от 0 до 1, по умолчанию 0,5.
`derived_from`	ID записей, которые эта запись обобщает (до 50).
`scope`	Ярлык для фильтра (`shared`, `private`). Доступ он не ограничивает.

remember никогда не удаляет и не перезаписывает записи. Если сохранить факт с тем же fact_key ещё раз, появится более новая версия, а старые останутся и будут помечены. Удаление — только явным вызовом forget, и оно мягкое: запись уходит из поиска вместе со связями графа, а факт удаления сохраняется для аудита.

Рабочие области, проекты и ключи

Аккаунт делится на проекты, проект — на рабочие области (workspace).
Рабочая область по умолчанию называется default и создаётся при первой записи. Используйте отдельные области, чтобы не смешивать темы, например backend и personal.
Ключ можно привязать к проекту: агент с таким ключом видит только этот проект. Удобно выдавать отдельный ключ на каждый проект или каждый компьютер.
Аккаунты, проекты и рабочие области изолированы друг от друга. В организации поверх этого действуют правила видимости записей — см. Видимость.

Статусы

Статус	Когда появляется	Что делать агенту
`unverified`	Всегда у новой записи.	Использовать как сведения с указанием источника.
`stale`	Источник изменился: в `search` или `validate_memory` передан другой `current_source_hash`.	Перечитать источник и сохранить актуальный факт.
`conflict`	Есть записи с тем же `fact_key`, но разным содержимым.	Показать человеку расхождение, не выбирать молча.

Статуса «проверено» (verified) нет. source_hash — это сведения о происхождении, а не доказательство: клиент может прислать любой хеш, поэтому сервер не считает запись подтверждённой.

В примере: после правки docs/deploy.md агент вызывает validate_memory с source_id="docs/deploy.md" и новым хешем. В отчёте старая запись окажется среди устаревших, а в search с тем же хешем получит статус stale. Подробнее — Источник и свежесть.

Сводки и derived_from

Агент может сжать несколько записей в одну сводку и передать их ID в derived_from. Сводка наследует статусы источников: если одна из исходных записей в конфликте или устарела, сводка тоже получит conflict или stale. Так обобщение не прячет нерешённые расхождения. Подробнее — Конфликты и сводки.

Что происходит после remember

Проверки. Пустой или слишком длинный content, source_hash без source_id, confidence вне 0..1, больше 50 ID в derived_from или несуществующие ID — запрос отклоняется с понятной ошибкой. Проверяется и лимит записей тарифа.
Memory Guard. Секреты (API-ключи, токены, пароли) в любом поле заменяются заглушками. Запись, похожая на попытку внедрить инструкции в память агента, отклоняется с ошибкой Memory rejected by Security Guard: ….
Сохранение. Запись получает ID и статус unverified. Если клиент передал заголовок X-Idempotency-Key, повтор того же запроса вернёт ту же запись; тот же ключ с другим содержимым вернёт 409 Conflict.
Архивариус. Модель анализирует новую запись: строит связи с недавними записями (они видны в search как graph_relations) и может пометить старую запись как уточнённую или устаревшую. В организации архивариус работает только с записями, которые видит автор.
Поиск. search ищет по смыслу и ключевым словам и возвращает записи с источником, уверенностью, статусом, derived_from и связями.

Локальный агент

mmw-agent — необязательный посредник на вашем компьютере. Он пересылает все вызовы на сервер, добавляет инструмент mmw_sync_status и, только после вашего согласия в терминале (mmw-agent consent), загружает историю сессий Claude Code и Codex. Поиск по загруженным сессиям пока не сделан. Подробнее — Агент mmw-agent.

Что дальше

Основные понятия Подробно о записях, ключах фактов и уверенности.

Рабочие области и проекты Как разложить память, чтобы агенты не мешали друг другу.

Архивариус Связи, уточнения и устаревание записей.

Справочник remember Все параметры и ошибки.