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

Три команды хорошо показывают философию проекта: запись, поиск и генерация ответа разделены. Можно пользоваться только хранением и поиском, не заставляя Memanto отвечать за вашего основного агента.

Что происходит под капотом

Упрощённо стек выглядит в три этажа. Сверху - AI-агент: Claude Code, Cursor, Codex, ваш собственный код на Python или TypeScript, либо любой MCP-клиент. В середине - Memanto Gateway: командная строка, REST на FastAPI, сессии, типы памяти, разбор противоречий, экспорт и синхронизация. Снизу - Moorcheh: семантическое хранение и поиск, в облаке или в локальном Docker.

В исследовательской статье авторы разделяют gateway и внутренние сервисы: через один шлюз проходят и команды CLI, и REST-запросы, и интеграции, а за ним живут отдельные службы Remember, Recall, Answer, Agent Manager, Session/Auth Manager, Conflict Resolution, Daily Summary и Memory Sync.

Отдельно стоит понять роль Moorcheh, иначе картина будет неполной: Memanto отвечает за поведение памяти и агентское API, а фактический семантический поиск делегирует Moorcheh. Авторы называют подход Information-Theoretic Search - вместо привычной схемы HNSW плюс косинусная близость движок использует собственное двоичное представление и информационно-теоретическую оценку. Практическое следствие, важное именно пользователю Memanto: записанная память доступна для поиска сразу, без отдельной долгой стадии построения индекса.

Одну формулировку тут легко понять неверно. "Нет ожидания индексации" не означает "модель не участвует вообще". Обычный remember записывает уже сформулированную память без участия модели. Но если попросить Memanto вытащить долговременные факты из сырой переписки, операция --from-conversation обратится к модели - об этом ниже.

Установка

Для командной строки нужен Python 3.10 или новее:

Первый запуск открывает мастер и предлагает выбрать backend: Moorcheh Cloud - тогда понадобится API-ключ, либо Moorcheh On-Prem - тогда нужен Docker, а облачный ключ не требуется. Проверить, что всё встало:

Если работаете из Node.js, ориентируйтесь на Node 20 и новее: именно эта граница записана в package.json официального TypeScript SDK. Более низкие версии, которые попадаются в старых руководствах, пакет уже не принимает.

Первая рабочая память

Память живёт внутри агента, поэтому сначала создаём агента под проект:

Создание сразу активирует сессию, так что можно записывать:

В каждой записи три смысловые части. Имя агента изолирует память конкретного проекта. Содержимое - это одна атомарная мысль, которую стоит сохранить. И тип, который сообщает системе, что перед ней: факт, решение, инструкция или предпочтение.

У записи есть и служебная обвязка, о которой стоит знать сразу. Уверенность задаётся флагом --confidence и по умолчанию равна 0.8. Происхождение задаётся флагом --provenance и по умолчанию считается явным утверждением, а всего система различает шесть источников: явное утверждение, вывод, исправление, подтверждение, наблюдение и импорт. Есть также заголовок, теги и указание автора записи - человека или конкретного агента. Загрузить пачку памяти разом можно из JSON-файла флагом --batch.

Зачем тринадцать типов памяти

Обычная векторная база держит всё в одном пространстве. Memanto добавляет семантическую классификацию, и не ради красоты: типы дают управляемый поиск - можно искать только решения, только обязательства или только ошибки.

Эффект практический: вопрос "что мы обещали закончить?" можно ограничить типом commitment, а "какие ошибки уже совершали?" - типом error. Шум отсекается ещё до того, как модель увидит результаты.

Поиск по смыслу и готовый ответ

Достаточно спросить обычными словами:

Запрос не обязан дословно повторять текст памяти. Если сохранено "Для ORM выбрали Drizzle", поиск найдёт запись и по формулировкам вроде "чем работаем с базой?" или "какой слой данных был выбран?". А если нужно сузить выдачу, добавляются тип и лимит:

Это важная архитектурная привычка: не возвращать модели пятьдесят воспоминаний на всякий случай. Чем точнее фильтр и разумнее лимит, тем меньше шум и дешевле последующий вызов модели.

Если же собирать prompt самому не хочется, есть шаг дальше:

Разница простая. recall возвращает воспоминания, а answer находит релевантную память и передаёт её выбранной модели, чтобы получить готовый ответ. Когда вы уже строите собственный конвейер промптов, полезнее recall - вы сами решаете, как вставить память в системную инструкцию. Когда нужен быстрый memory-RAG эндпоинт, удобнее answer.

Агенты, сессии и подключение к редактору

Memanto разделяет долгоживущего агента и временную сессию: агент - это область памяти, сессия - активный доступ к этой области.

REST API работает по session-токену. В официальном быстром старте создаваемая сессия ограничена по времени - это позволяет не раздавать клиентскому коду постоянный доступ к backend, а сам ключ Moorcheh остаётся на стороне сервера Memanto.

Изоляция здесь не формальность. Если два несвязанных проекта пользуются одной областью памяти, агент однажды вспомнит техническое решение не из того проекта. Разделяйте области по границам, которые действительно должны делить знания.

Самое интересное для тех, кто живёт в редакторе: собственную интеграцию писать не нужно, командная строка сама устанавливает нужную конфигурацию в проект.

По документации для интеграций с редакторами Memanto ставит файл, специфичный для инструмента - например CLAUDE.md или правило Cursor. Есть режим для текущего проекта и глобальный:

Одного и того же агента можно подключить сразу к нескольким инструментам - тогда Claude Code, Cursor и Windsurf получают общий слой проектной памяти. Для этого есть отдельная команда memanto connect multi, а снять подключение позволяет memanto connect remove.

Если писать каждую память руками не хочется

Обычный remember хорош, когда уже понятно, что именно надо сохранить. Но Memanto умеет принять сырую историю разговора и вытащить из неё долговременные записи:

За один проход извлекается не больше двадцати записей - это значение по умолчанию, и его можно поднять или опустить флагом --max-memories. Модель для извлечения тоже переопределяется отдельно, флагом --ai-model, а источником может быть не только файл: если передать дефис вместо пути, разговор читается со стандартного ввода.

Вот здесь и работает извлечение моделью. Дашборд предлагает полезный промежуточный режим: сначала показать получившиеся карточки памяти, дать поправить тип, текст и уверенность, и только потом сохранить. Это хороший производственный приём - важную память не обязательно доверять полностью автоматическому извлечению, а для критичных областей разумно оставить шаг проверки перед записью.

Память меняется во времени

Один из самых интересных элементов Memanto - временные запросы. Память рассматривается не как текущий мешок фактов, а как состояние, которое меняется.

Через REST это выглядит так:

Такие запросы отвечают на вопросы вроде "какое решение действовало до миграции?", "что поменялось за неделю?", "какой срок считался актуальным в начале месяца?".

Из той же природы долгоживущей памяти вырастает неизбежная проблема: сначала "релиз 15 августа", потом "релиз перенесён на 1 сентября". Если просто сохранить обе строки, агент может выбрать старую. Для этого есть отдельный разбор противоречий:

Найдя противоречие, система предлагает варианты: оставить новую запись, оставить старую, сохранить обе, удалить обе или заменить их вручную сформулированной памятью. Это принципиально лучше тихой перезаписи, когда важна история решения: эволюция знания сохраняется, а временные запросы позволяют восстановить, какое состояние было актуально раньше.

Файлы, экспорт и переносимость

Помнить можно не только короткие факты - файлы загружаются прямо в память агента. Документация перечисляет .pdf, .docx, .xlsx, .json, .txt, .csv и .md.

Здесь граница между памятью агента и обычным RAG становится тонкой, и правило из документации разумное: короткий атомарный факт сохраняйте через remember, а большой готовый документ - через upload.

Память полезна ровно до тех пределов, пока вы можете её забрать. Memanto экспортирует всё хозяйство в Markdown, синхронизирует MEMORY.md и работает с Open Knowledge Format:

OKF описан как независимый от вендора набор Markdown-файлов: его можно читать глазами, держать в Git и импортировать в другого агента Memanto. Предусмотрен и переезд с других систем - Mem0, Letta, Supermemory и Langfuse, плюс импорт готового набора OKF обратно в агента:

REST API и TypeScript SDK

Локальный API поднимается одной командой:

По умолчанию сервер слушает http://localhost:8000, интерактивная документация OpenAPI доступна по /docs. Клиент передаёт X-Session-Token, а ключ Moorcheh хранится на серверной стороне и клиенту не нужен вовсе. Полный цикл из Python выглядит так:

Три шага здесь ровно те же, что в командной строке: активировали сессию для нужной области памяти, записали типизированную память, получили записи по смыслу вопроса.

Для Node.js есть отдельный пакет:

У этого SDK есть деталь, о которой лучше знать заранее: если не передать адрес уже работающего сервера, он сам поднимает локальный сервер Memanto через uvx, ждёт проверки здоровья, при необходимости создаёт агента, активирует сессию и подставляет токен в запросы. То есть это не чистая JS-библиотека внутри процесса - за удобным клиентом всё равно запускается сервер на Python. Для предсказуемого производственного развёртывания разумнее держать отдельный постоянно работающий сервер и передавать SDK его адрес.

Полностью локальный контур

Мастер On-Prem разворачивает backend Moorcheh в Docker и использует Ollama как локальный embedder и модель для ответов:

Готовых моделей по умолчанию здесь нет: в конфигурации локального контура поля провайдера и модели для embeddings и ответов пустые, пока вы не выберете их в мастере. Заранее задан только адрес - сервер Moorcheh работает на localhost:8080, а шлюз Memanto обычно на localhost:8000. В настройках qwen2.5 предлагается как один из примеров, а не как значение по умолчанию, и учтите, что первая загрузка любой локальной модели может занять несколько гигабайт. В такой схеме ваш код обращается к Memanto, тот - к локальному Moorcheh и Ollama, и наружу не уходит ничего.

Лицензия: нюанс, который стоит проверить до внедрения

Сам репозиторий Memanto лицензирован по MIT - это видно и на GitHub, и в pyproject.toml. Но локальный backend для поиска - это отдельный проект, Moorcheh Community Edition, и у него собственная лицензия.

Официальный репозиторий Moorcheh On-Prem прямо называет Community Edition source-available, а не одобренным OSI открытым исходным кодом, и описывает бесплатное использование для одноузлового и некоммерческого развёртывания. Многоузловые, корпоративные и часть коммерческих сценариев требуют другой лицензии.

Корректная формулировка поэтому такая: ядро Memanto - MIT, локальный backend Moorcheh имеет отдельные лицензионные условия. Переносить MIT автоматически на весь локальный стек нельзя, и перед коммерческим внедрением это надо проверить.

Memanto и Mem0: похожая задача, разный акцент

Mem0 - библиотечный слой памяти. В типичном сценарии он принимает разговор и автоматически извлекает из него компактные факты, а сильная сторона - программируемое API памяти и заменяемые модель, embedder и векторное хранилище.

Memanto - сервис памяти поверх Moorcheh. Базовый remember пишет уже сформулированную типизированную память напрямую, а извлечение из разговора существует как отдельная операция. Акцент здесь на интеграциях с coding-агентами, типах, времени, разборе противоречий, командной строке и экспорте.

Ни один подход не "правильнее". Если приложению нужна библиотека, где вы сами собираете конвейер памяти и меняете векторную базу, естественно выглядит Mem0. Если хочется быстро дать нескольким агентам общую проектную память, управлять ею из терминала и подключить Claude Code, Cursor или Codex - удобнее архитектура Memanto.

К сравнению примыкают и заявленные цифры. Создатели публикуют 89.8% на LongMemEval и 87.1% на LoCoMo; в их исследовании итоговая конфигурация использует одиночный семантический запрос и Gemini 3 для вывода, без конвейера графа знаний. Читать эти результаты стоит как результаты авторов системы на конкретной конфигурации оценки, а не как гарантию, что любое приложение на Memanto окажется лучше любого приложения на Mem0: качество системы памяти зависит от модели, построения запроса, данных, лимита выдачи, порога, типизации и способа измерения. Хорошая новость - команда публикует репозиторий оценки и наборы данных, поэтому сравнительные утверждения можно проверить и повторить, а не принимать на веру.