Agent Memory 2026: Semantica, Mem0, Zep, Letta

Вам уже недостаточно передавать Agent последние сообщения, но после добавления «памяти» он начинает хранить устаревшие факты, смешивать пользователей и не объяснять источник решения.

Самое быстрое решение — сначала определить тип памяти, а затем выбирать проект: Mem0 для лёгкого универсального слоя, Letta для stateful Agent, Zep для временных отношений в графе, Semantica для контекстного графа, рассуждений и происхождения данных.

Кому стоит читать этот материал:

• разработчикам, которые добавляют долгосрочную память в чат- или task-Agent;
• корпоративным командам, которым нужны self-hosting и контроль над данными;
• архитекторам, сравнивающим векторную память, графовую модель и полноценный Agent runtime.

Последняя проверка: 14 августа 2026 года. Границы открытого кода, инструкции развёртывания и зависимости сверены по официальным репозиториям и документации проектов.

Начните с типа памяти

Слово «память» скрывает несколько разных задач. Если смешать их в одном тесте, сравнение Semantica, Mem0, Zep и Letta будет некорректным: один проект может быть хорошим хранилищем пользовательских фактов, а другой — полноценной средой выполнения Agent.

Перед выбором выпишите, что именно система должна сохранять:

• пользовательские предпочтения — язык общения, формат отчёта, ограничения и устойчивые настройки;
• состояние задачи — текущий этап workflow, открытые действия, промежуточные результаты и ожидаемые подтверждения;
• временную линию событий — что произошло, когда это произошло и какой факт позже стал неактуальным;
• отношения между объектами — пользователи, документы, компании, задачи, сотрудники и связи между ними;
• источник решения — документ, сообщение, запись аудита или правило, на основании которого Agent сделал вывод.

Векторный поиск обычно отвечает на вопрос «что похоже на этот запрос». Он не гарантирует, что найденный факт всё ещё действителен, кому он принадлежит и почему он попал в ответ. Для этого нужны отдельные поля времени, пространства имён, источника, версии и статуса удаления.

Практический вывод: если вы не можете сформулировать минимум пять типов данных, которые Agent должен запоминать, рано выбирать конкретный репозиторий. Сначала создайте схему памяти, иначе команда будет сравнивать разные уровни абстракции.

Сопоставьте четыре архитектурных маршрута

Ниже — не рейтинг «от первого до четвёртого», а карта того, какую роль играет каждый проект.

Mem0 официально описывается как универсальный memory layer для LLM-приложений. Его можно использовать как Python- или Node-библиотеку либо запустить self-hosted-сервер с панелью управления, ключами пользователей и журналом запросов. Это делает проект удобным кандидатом для прототипа, который должен постепенно перейти в корпоративное окружение. Официальный обзор Mem0 Open Source

Letta — другой уровень системы. В документации проект определён как платформа для stateful Agent, а не просто внешняя база воспоминаний. Letta ранее назывался MemGPT, поэтому старые статьи, примеры и обсуждения могут использовать прежнее имя. Репозиторий Letta и пояснение о переименовании

Zep и Graphiti также нельзя считать одним и тем же продуктом. Graphiti — открытый фреймворк Context Graph, который можно запускать локально. Zep позиционируется как более широкий Context Lake и коммерческий слой поверх графовой технологии; поэтому наличие открытого Graphiti не означает, что весь функционал Zep доступен в открытом self-hosted-виде. Описание границы Graphiti и Zep

Semantica ближе к инфраструктуре контекста и управляемого знания, чем к простой «памяти чата». Официальная архитектура включает извлечение, нормализацию, обнаружение конфликтов, дедупликацию, knowledge graph, ontology, reasoning, provenance и decision records. Репозиторий Semantica и архитектура проекта

Проверьте запись, обновление и забывание

Производственная память ломается не тогда, когда поиск ничего не нашёл, а тогда, когда Agent уверенно использует неправильный факт.

Для каждого кандидата проверьте четыре операции:

1. Запись — извлекается ли память автоматически из диалога или вы должны вручную задавать каждую запись.
2. Обновление — что происходит, если пользователь изменил предпочтение или бизнес-правило.
3. Конфликт — сохраняются ли две версии факта, выбирается ли более новая, фиксируется ли источник конфликта.
4. Удаление — можно ли удалить один факт, все данные пользователя или весь временной сегмент без ручного обхода внутренних таблиц.

Mem0 удобно оценивать как слой, который получает текст или событие, формирует память и возвращает релевантные записи при следующем запросе. В официальной документации отдельно вынесены настройка LLM, embedding-модели, vector store, reranker и оценка памяти; это хороший признак для отдельного memory pipeline, но не доказательство того, что проект автоматически решит вашу политику хранения. Документация Mem0 по конфигурации и оценке

В Letta обновление памяти связано с самим поведением Agent. Это полезно для персонального помощника или долгоживущего рабочего Agent, но требует более строгой проверки: модель может сама решить, что считать важным, а ошибка в инструкции памяти станет частью дальнейшего поведения. У self-hosted-сервера необходимо отдельно настроить embedding-модель для archival memory и постоянное хранилище. Инструкция запуска Letta через Docker

Graphiti решает другую задачу: новые эпизоды добавляются в граф, отношения получают временные атрибуты, а устаревшие факты могут быть признаны недействительными с сохранением истории. Поэтому Zep разумнее оценивать на сценариях вроде «какая должность была у пользователя в момент принятия решения», а не только на поиске похожего абзаца. Официальный quickstart Graphiti

Semantica полезна там, где важны не только текущие значения, но и происхождение утверждения, конфликт между источниками и объяснение решения. При этом вам придётся заранее продумать онтологию и правила нормализации; графовая модель не отменяет работу по качеству входных данных.

Разберите вопросы самохостинга

Semantica и Mem0 для self-hosting

Если под self-hosting вы понимаете «быстро запустить memory layer в собственной инфраструктуре», начните с Mem0. Официальная документация предлагает библиотечный режим и self-hosted-сервер, а компоненты LLM, embeddings, vector store и reranker можно заменять. В серверном варианте также предусмотрены аутентификация и аудит запросов. Возможности Mem0 OSS

Semantica подходит для более сложной схемы контроля данных, но её нельзя оценивать как один автономный контейнер. В официальных инструкциях для production указаны секретный ключ, постоянное графовое хранилище вроде Neo4j, FalkorDB, Apache AGE или Neptune, а также отдельный векторный backend. Это открытая и расширяемая архитектура, но операционная нагрузка выше. Инструкция установки Semantica

Таким образом, Mem0 — кандидат для компактного слоя памяти, Semantica — для контекстной платформы, где сам граф и трассировка являются частью продукта.

Zep и Letta: разные задачи Agent Memory

Zep через Graphiti строит временные связи между сущностями и поддерживает комбинацию семантического, полнотекстового и графового поиска. Такой подход подходит для динамических бизнес-данных, где факт должен иметь дату, источник и историю изменения. Graphiti поддерживает Neo4j, FalkorDB и Amazon Neptune; драйвер Kuzu в официальном репозитории помечен как устаревающий, поэтому не стоит строить новую production-схему вокруг него. Официальный репозиторий Graphiti

Letta хранит состояние самого Agent: его рабочие блоки памяти, историю, инструменты и поведение между сессиями. Это более цельный runtime-подход. Он удобен, когда Agent не просто ищет сведения, а продолжает долгую задачу, пересматривает свои инструкции и пользуется инструментами.

Выбирайте Zep, если центральный объект — изменяющийся граф фактов. Выбирайте Letta, если центральный объект — долгоживущий stateful Agent. Их можно комбинировать, но это уже две системы с разными зонами ответственности, а не простая замена одного SDK другим.

Разделите векторную и графовую память

На вопрос «вектор или knowledge graph» нет универсального ответа.

Векторная память рациональна, когда:

• данные представлены короткими фактами и предпочтениями;
• запросы в основном семантические;
• вам не требуется объяснять цепочку отношений;
• структура сущностей ещё меняется и преждевременная онтология будет мешать.

Графовая память оправданна, когда:

• нужно находить связи между несколькими объектами;
• факты меняются со временем;
• требуется сохранять источник, период действия и историю;
• Agent должен объяснять, как он пришёл к выводу;
• важны правила, роли, зависимости и причинные отношения.

Semantica и Graphiti нельзя честно сравнивать с Mem0 по одной метрике поиска. У них разные выходные данные и разные требования к модели данных. Если проект хранит пользовательское предпочтение, измеряйте точность извлечения и корректность обновления. Если проект строит контекстный граф, дополнительно проверяйте правильность узлов, рёбер, временных границ и источников.

Проведите проверку локального развёртывания

Практическая последовательность для команды выглядит так:

1. Зафиксируйте схему данных. Разделите preference, task state, event, entity relation и decision source; для каждого поля задайте владельца, срок актуальности и правило удаления.
2. Подготовьте единый набор эпизодов. Включите новые факты, исправления, противоречия, повторяющиеся сущности, запрос на удаление и данные двух разных пользователей.
3. Поднимите минимальную установку. Для Mem0 проверьте библиотечный режим и серверный режим; для Letta — Docker-сервер с постоянным каталогом; для Graphiti — выбранную графовую базу; для Semantica — графовый и векторный backend.
4. Ограничьте внешние зависимости. Отдельно отметьте, где нужны API-ключи LLM, embeddings, reranker, графовая база, векторное хранилище и объектное хранилище. «Открытый исходный код» не означает отсутствие этих зависимостей.
5. Проверьте изоляцию. Создайте два пространства пользователей и убедитесь, что поиск одного Agent не возвращает память другого.
6. Проверьте устаревание. Запишите факт «роль пользователя — A», затем добавьте «роль пользователя — B» и измерьте, возвращается ли старое значение, сохраняется ли история и можно ли получить действующее значение на конкретную дату.
7. Проверьте происхождение. Для каждого ответа сохраните идентификатор эпизода, документа или сообщения, из которого извлечена память.
8. Проверьте удаление. Удалите пользователя, проект и отдельный факт, после чего повторите поиск по исходным формулировкам и синонимам.
9. Сравните эксплуатацию. Зафиксируйте сложность резервного копирования, миграций, обновления схемы, ротации ключей и восстановления после сбоя.
10. Запретите миграцию без двойного прогона. До переноса production-данных две системы должны несколько циклов обработать один и тот же набор событий, а расхождения должны быть разобраны вручную.

Для временной проверки вам может подойти удалённая среда разработки, чтобы не устанавливать все графовые и векторные зависимости на рабочий ноутбук. В зависимости от региона можно посмотреть варианты аренды Mac mini в США или сравнить общие условия аренды Mac mini, если тестовый стенд должен быть доступен команде постоянно.

Используйте приёмочную матрицу

Оценивайте не «скорость поиска вообще», а конкретные типы ошибок:

• Recall фактов: нашёлся ли нужный факт среди результатов.
• Freshness: выбран ли актуальный факт после обновления.
• Isolation: не пересеклись ли данные пользователей, проектов и Agent.
• Provenance: можно ли показать источник утверждения.
• Deletion: исчезли ли удалённые данные из обычного и семантического поиска.
• Conflict handling: не превратился ли конфликт в случайный выбор одной записи.
• Operational fit: можно ли обновлять, резервировать и масштабировать систему без ручного редактирования базы.

Не подменяйте эти проверки количеством звёзд на GitHub, рекламными заявлениями или одной цифрой latency. Даже опубликованные benchmark-результаты нельзя переносить на вашу модель, размер эпизодов, embedding-провайдер и способ записи без повторяемого теста.

Для каждой из двух финальных систем подготовьте одинаковый журнал:

идентификатор пользователя
идентификатор Agent
входной эпизод
ожидаемая память
допустимый ответ
источник
срок актуальности
операция удаления
фактический результат
ошибка классификации

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

Примените чек-лист выбора

• [ ] Мне нужен отдельный слой памяти, а не новый runtime для всего Agent.
• [ ] Мне нужно хранить устойчивые предпочтения и факты без сложной онтологии.
• [ ] Мне требуется stateful Agent с рабочей памятью и инструментами.
• [ ] Мне необходимо учитывать дату действия и историю изменения фактов.
• [ ] Мне нужно строить отношения между сущностями, а не только искать похожий текст.
• [ ] Мне требуется источник каждого решения и возможность аудита.
• [ ] Я проверил, какие компоненты действительно входят в открытый репозиторий.
• [ ] Я отдельно перечислил LLM, embeddings, vector store и graph database.
• [ ] Я протестировал изоляцию нескольких пользователей и Agent.
• [ ] Я проверил обновление, конфликт и удаление памяти.
• [ ] Я не переношу production-данные до двойного прогона двух кандидатов.
• [ ] Я подготовил план резервного копирования и восстановления.

Выберите маршрут для команды

Прототип или универсальный чат-Agent. Начните с Mem0. Это наиболее прямой кандидат, если вам нужен отдельный слой долгосрочной памяти с возможностью использовать библиотеку или self-hosted-сервер. В качестве альтернативы рассмотрите Letta, если уже сейчас понятно, что Agent будет долгоживущим и stateful.

Состояние и продолжение задач. Выбирайте Letta, особенно если Agent должен помнить рабочие блоки, инструменты и собственное состояние между сессиями. Альтернативой может быть Mem0 в связке с вашим существующим runtime, если вы не хотите менять архитектуру Agent.

Временная карта знаний. Оценивайте Zep через открытый Graphiti, когда ключевая задача — временные отношения, динамические события и гибридный поиск по графу. Альтернатива — Semantica, если кроме времени нужны ontology, provenance и объяснимые решения.

Графовый контекст и высокий уровень управления. Начинайте с Semantica. Это более тяжёлая архитектура, зато она рассчитана на контекстные графы, контроль схемы, конфликт-детекцию и трассировку. Альтернативой будет Graphiti, если требования к ontology и decision audit пока не сформированы.

Во всех четырёх случаях безопаснее сначала выбрать две системы, прогнать их на едином наборе данных и только потом переносить реальные воспоминания. Миграция памяти — это не только экспорт записей: нужно сохранить идентификаторы, источники, сроки действия, права доступа и правила удаления.

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

В этой ситуации аренда Mac через ZavCloud может быть практичнее временной закупки отдельного оборудования: вы получаете удалённую среду для повторяемого тестирования, не привязываете эксперимент к одному рабочему месту и можете отключить её после завершения сравнения. Для постоянной высоконагруженной эксплуатации, физических периферийных устройств или полного контроля над железом собственный сервер всё равно будет разумнее; но для двухнедельной проверки Mem0, Letta, Graphiti и Semantica облачная среда обычно лучше соответствует задаче принятия решения.