Память агентов: mem0, Letta и Zep — что на самом деле хранится между сессиями

Аннотация

Память агента обычно покупают как компонент: подключить SDK, получить методы add и search, считать задачу решённой. К октябрю 2026 года таких компонентов три выраженных типа, и отвечают они на разные вопросы. mem0 сжимает историю на записи: LLM извлекает из пары сообщений факты и решает, что с ними делать — добавить, обновить, удалить или проигнорировать¹. Letta не сжимает: она держит небольшие блоки прямо в контексте и выносит их переписывание в отдельный фоновый агент²³. Zep строит граф фактов с двумя осями времени и не удаляет устаревшее, а помечает недействительным⁴⁵.

Главный вывод обзора: различия между системами меньше, чем различия между методиками их измерения. Одна и та же Zep на одном и том же LoCoMo получает 58,44%, 65,99%, 75,14% и 84% в четырёх разных прогонах⁶⁷¹, а голый filesystem в эксперименте команды MemGPT набирает 74%⁸. Разница между «лидером» и «отстающим» здесь сопоставима с разницей между двумя реализациями одного протокола, поэтому лидерборд не является основанием для выбора.

Источники: семь академических работ (обзор таксономии памяти агентов, оба основных бенчмарка, статьи MemGPT, mem0, Zep и A-MEM), официальная документация mem0, Letta и Graphiti, исследовательские блоги вендоров и публичный трекер, где команды обмениваются претензиями к замерам. Данные на 2026-10-24. Собственных замеров в обзоре нет — только разбор опубликованных, с указанием того, что в них не сходится.

Введение

Актуальность. Аргумент «контекст кончился» перестал работать: в статье mem0 перечислены модели с окнами от 128 тысяч до 10 миллионов токенов, и авторы честно признают, что рост окна «лишь откладывает, а не решает» проблему¹. Причина не в ёмкости, а в двух других вещах: история за месяцы превышает любое окно, а релевантное в ней перемешано с нерелевантным, и внимание к дальним токенам деградирует¹. Одновременно память стала рынком: у mem0 есть тарифная сетка с отдельным уровнем за графовую память⁹, у Letta — исследовательская программа от MemGPT до sleep-time compute¹⁰³, у Zep — открытый движок Graphiti и коммерческий слой поверх него¹¹⁵.

Цель — разобрать три архитектуры по трём осям: где именно происходит сжатие истории и кто принимает решение о том, что помнить; как каждая система обходится с противоречием («пользователь сменил работу»); и во что это обходится в токенах, латентности и деньгах. Отдельная задача — показать, почему опубликованные числа нельзя сравнивать напрямую.

Границы. Не рассматриваются: параметрическая память и дообучение, латентная (векторная в скрытом пространстве) память, мультимодальная память и обучение политики памяти с подкреплением; эти направления описаны в обзоре как отдельные формы¹², но практических систем с воспроизводимыми замерами там пока мало. Не разбираются по отдельности MemOS, Cognee, LangMem и A-MEM — последняя упомянута как источник идеи связного графа заметок¹³. Числа производительности взяты из публикаций вендоров и статей, независимого воспроизведения в этом обзоре нет.

1. Что именно называют памятью агента

Обзор «Memory in the Age of AI Agents» начинается с констатации: поле фрагментировано, а традиционное деление на краткосрочную и долговременную память больше не описывает практику¹². Авторы раскладывают память по трём осям: форма (токенная, параметрическая, латентная), функция (фактическая, опытная, рабочая) и динамика (формирование, эволюция, извлечение)¹². Все три системы из этого обзора работают в одной клетке этой схемы — токенная, фактическая, с эволюцией через перезапись, — и различаются только политикой.

Это различие восходит к MemGPT, где память описана как иерархия в духе операционной системы: «main context» играет роль RAM, «external context» — диска, а модель сама вызывает функции, чтобы подкачать нужное в окно¹⁰. Важное следствие: любая такая память всё равно возвращается в контекст, то есть память — это не хранилище, а политика отбора. Вопрос «какая система лучше помнит» на самом деле означает «какая система лучше решает, что выбросить».

Отсюда три разных ответа. mem0 выбрасывает на входе, оставляя атомарные факты. Letta не выбрасывает ничего, но держит в контексте маленький редактируемый блок, а остальное делает доступным по запросу. Zep выбрасывает текст, оставляя структуру — сущности и связи с временем действия. Ниже — механика каждой.

2. mem0: сжатие на записи

Пайплайн mem0 состоит из двух фаз. На входе — пара сообщений (предыдущее и текущее), к ним добавляется суммаризация всей беседы и окно последних сообщений; в экспериментах окно равно 10 сообщениям. LLM извлекает из этого контекста набор кандидатов в память¹. Затем для каждого кандидата достаются 10 семантически близких записей, и решение принимает та же LLM — не отдельный классификатор:

The LLM itself determines which of four distinct operations to execute: ADD for creation of new memories when no semantically equivalent memory exists; UPDATE for augmentation of existing memories with complementary information; DELETE for removal of memories contradicted by new information; and NOOP when the candidate fact requires no modification to the knowledge base.¹

Это и есть та самая «атомарная память»: единица хранения — не реплика и не абзац, а утверждение, прошедшее через разрешение конфликтов на записи. Графовый вариант, Mem0ᵍ, добавляет второй проход: извлекаются сущности и отношения, новые триплеты сравниваются с существующими узлами по порогу похожести, а конфликтующие отношения не удаляются, а помечаются недействительными — «marking them as invalid rather than physically removing them to enable temporal reasoning»¹. То есть даже в «плоской» версии mem0 время присутствует, но только через DELETE: старая запись исчезает вместе с историей.

Практическая цена такой схемы — стоимость записи. Каждая пара сообщений проходит через LLM-извлечение и через LLM-разрешение конфликтов; в open-source сборке по умолчанию это gpt-5-mini и эмбеддинги text-embedding-3-small, векторное хранилище — локальный Qdrant в /tmp/qdrant, история — SQLite в ~/.mem0/history.db; в серверной сборке векторное хранилище уже Postgres с pgvector¹⁴. Тарифная сетка это отражает: бесплатный уровень даёт 10 000 запросов на добавление и 1 000 на извлечение в месяц, а графовая память с привязкой сущностей и консолидация «Dream» появляются только на уровне Pro за 249 долларов в месяц⁹. Иными словами, архитектура, ради которой написана статья, в облаке доступна начиная с довольно высокого тарифа, а в self-host варианте её надо собирать самому.

3. Letta: память как часть контекста

Letta идёт от MemGPT и делает ставку на противоположный принцип — не сжимать, а держать важное на виду. Основная абстракция — memory block: «structured sections of the agent’s context window that persist across all interactions», которые «always visible — no retrieval needed»². Технически блок — это кусок текста, подставляемый в промпт в XML-подобной обёртке, с четырьмя полями: label, description, value и limit в символах; description — главный сигнал для модели, по которому она понимает, что в блок писать². Блоки бывают read-only и могут быть общими для нескольких агентов сразу, то есть работать как примитив координации, а не только хранения².

Второй слой — archival memory: «general-purpose vector DB», где записи нельзя закрепить в контексте и надо запрашивать инструментами archival_memory_insert и archival_memory_search; важная деталь — записи «agent-immutable»: агент не может их править или удалять, это доступно только разработчику через SDK¹⁵. Третий слой — вся история сообщений, доступная поиском, но не редактируемая агентом¹⁵.

Разделение труда между слоями формализовано в sleep-time compute: при создании такого агента Letta поднимает двоих — основной агент общается с пользователем и не имеет инструментов редактирования core memory, а sleep-time агент эти инструменты получает и правит блоки основного³. Мотивация прямая: в классическом MemGPT управление памятью, разговор и обычные инструменты свалены в один цикл, из-за чего агент медленнее и менее надёжен, а инкрементальное формирование памяти «may become messy and disorganized over time»³. Двум агентам можно дать разные модели — быструю на диалог и сильную на консолидацию, — но частота консолидации напрямую увеличивает расход токенов³.

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

4. Zep и Graphiti: граф, который не забывает, а инвалидирует

Zep строится на трёх иерархических подграфах: эпизоды (сырые сообщения, текст, JSON), семантические сущности с отношениями и сообщества — кластеры сильно связанных сущностей с высокоуровневыми суммаризациями⁴. Эпизоды объявлены «non-lossy data store»: производные факты хранят двусторонние индексы к породившим их эпизодам, поэтому любой факт можно процитировать или проверить по источнику⁴. Вторая ключевая деталь — битемпоральность: одна ось отмечает, когда событие произошло, вторая — когда Zep узнал о нём; именно вторая ось позволяет разбирать относительные даты вроде «на следующей неделе» и «прошлым летом»⁴.

В документации механизм доведён до уровня поля: при инвалидации факта время, когда он перестал быть верным, записывается прямо на ребро графа, а типы контекста перечислены поимённо — факты, сущности, эпизоды, суммаризации тредов, «наблюдения» и суммаризация пользователя⁵. Открытый движок Graphiti, на котором это построено, добавляет инженерные детали: гибридный поиск (эмбеддинги + BM25 + обход графа), инкрементальная сборка без пересчёта всего графа, возможность задать онтологию типами Pydantic или оставить её выученной из данных¹¹.

Это единственная из трёх архитектур, которая отвечает на вопрос «а как это было раньше» без потери данных: старая работа пользователя остаётся в графе с закрытым окном действия, и запрос «где он работал в марте» имеет определённый ответ. Обратная сторона — обязательства: нужна графовая база (Neo4j 5.26, FalkorDB 1.1.2 или Neptune; поддержка Kuzu объявлена устаревшей и будет удалена), нужен LLM со structured output, и при слабых моделях «ingestion failures» прямо названы типичным исходом¹¹. Плюс ссылочные MCP- и REST-серверы в репозитории не имеют ни аутентификации, ни защиты от prompt injection, и авторы отдельно предупреждают не выставлять их в недоверенную сеть¹¹.

5. Что показывают бенчмарки

Публичные числа в этой области почти всегда получены на нескольких датасетах, из которых чаще всего цитируют два. LoCoMo — это 50 длинных диалогов, сгенерированных LLM-агентами по персонам и временным графам событий, с вопросами на single-hop, multi-hop, временные, commonsense и состязательные рассуждения¹⁶¹⁷. В конфигурации mem0 это 10 расширенных бесед примерно по 600 реплик и 26 тысяч токенов¹.

LongMemEval устроен иначе: 500 вопросов, проверяющих пять способностей — извлечение информации, рассуждение через много сессий, временное рассуждение, обновление знаний и отказ отвечать, — в истории, длина которой масштабируется; стандартные настройки — около 115 тысяч токенов (S) и 500 сессий примерно на 1,5 миллиона токенов (M)¹⁷. Главный результат авторов: коммерческие ассистенты и long-context модели теряют около 30% точности на длительных взаимодействиях, а на LongMemEval-S падение составляет от 30% до 60%; при этом ручная проверка показала, что лучшие коммерческие системы в существенно более простом сценарии дают 30–70%¹⁷.

И вот здесь начинается расхождение, которое важнее самих чисел. Авторы LongMemEval проверили не только системы, но и дизайн памяти, и получили два результата, которые бьют по обеим «атомарным» архитектурам. Первый: гранулярность «раунд» (одна пара сообщений) лучше, чем «сессия»; дальнейшее сжатие в отдельные пользовательские факты «harms overall performance due to information loss», хотя и повышает точность на вопросах, требующих сведения информации из многих сессий¹⁷. Второй: даже при идеальном извлечении ответить правильно трудно — чтение оказалось отдельным узким местом, и в 15–19% случаев ответ был неверным при корректно найденной информации¹⁷.

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

6. Цена памяти

Таблица из статьи mem0 — редкий случай, когда видны сразу и качество, и стоимость. Для LoCoMo авторы приводят среднее число токенов на запрос, латентность поиска и полного ответа, и итоговую оценку LLM-судьи: базовая mem0 — 1764 токена, 0,148 с (p50) и 0,200 с (p95) на поиск, 1,44 с p95 на полный ответ, 66,88% ± 0,15; Mem0ᵍ — 3616 токенов, 2,59 с p95, 68,44% ± 0,17; Zep в конфигурации авторов — 3911 токенов, 2,93 с p95, 65,99% ± 0,16¹. Полный контекст на тех же данных даёт около 73% и p95 около 17 секунд¹.

Из этих чисел следуют два неудобных вывода. Первый: графовая память удваивает расход токенов на запрос (3616 против 1764) ради примерно полутора процентных пунктов — обмен, который имеет смысл только при реальной потребности в многошаговых вопросах. Второй: полный контекст на 26 тысячах токенов всё ещё точнее любой памяти и проигрывает только по латентности в двенадцать раз¹.

Три системы образуют три разные кривые затрат. mem0 платит на записи: каждая пара сообщений проходит через извлечение и разрешение конфликтов, поэтому счёт растёт с объёмом переписки, а не с числом запросов¹¹⁴. Zep платит на ингесте ещё сильнее — LLM-извлечение сущностей и связей плюс поддержка графовой базы⁴¹¹. Letta платит на простоях: sleep-time агент работает в паузах, и частота его запуска прямо переводится в токены³. Полный контекст платит на каждом запросе. Выбирать между ними — это выбирать, какая из четырёх величин у вас дешевеет быстрее.

7. Эксплуатация: что ломается

Первое, что ломается, — воспроизводимость. Память — это состояние, и после консолидации тот же агент отвечает иначе на тот же вопрос. Практический выход предложен в LongMemEval: разложить систему на три стадии — индексация, извлечение, чтение — и мерить их по отдельности, потому что «правильный ответ» требует корректного извлечения примерно в 90% случаев, а идеального извлечения недостаточно¹⁷. Без такого разложения отладка памяти превращается в гадание.

Второе — семантика удаления. В mem0 удаление — это операция DELETE, то есть запись исчезает¹. В Zep устаревший факт остаётся с закрытым окном действия⁴⁵. Для требований «удалить данные пользователя» это разные объёмы работы: во втором случае нужен отдельный путь удаления, который не разрушит провенанс остальных фактов. В Letta archival memory агент вообще не может ни править, ни удалять записи — только разработчик через SDK¹⁵, что удобно для аудита, но означает, что «агент сам исправил ошибку в памяти» здесь невозможен по конструкции.

Третье — умолчания. Локальный Qdrant в /tmp/qdrant — документированное умолчание open-source mem0¹⁴; на многих системах /tmp чистится при перезагрузке, поэтому для чего-то долговечнее демо этот путь надо менять сразу. У Graphiti умолчание другое: SEMAPHORE_LIMIT=10, сниженное специально, чтобы не ловить 429 от провайдера LLM, — при этом авторы прямо предупреждают, что ссылочные серверы не аутентифицируют вызывающих и любой может читать и менять данные любого group_id¹¹. Это не мелочь: memory-слой по определению хранит персональные данные, и запуск демонстрационного сервера «как есть» в общей сети — утечка по проекту.

Четвёртое — границы тарифов. В облаке mem0 графовая память и консолидация доступны с уровня Pro⁹, хотя сам движок открыт¹⁴; в Zep коммерческий слой продаётся отдельно от открытого Graphiti¹¹. Это значит, что «попробовать архитектуру» и «эксплуатировать архитектуру» — разные бюджеты и часто разные команды.

Дискуссионные вопросы и противоречия

Сколько стоит Zep на LoCoMo. Публично зафиксированы четыре числа для одной системы на одном датасете.

Позиция mem0 изложена техническим директором в публичном issue: в оценке Zep в знаменатель не попали вопросы пятой, «состязательной» категории, хотя правильные ответы из неё в числитель попали — это «artificially inflated the reported accuracy by approximately 25.56 percentage points», а кроме того, по мнению mem0, были изменены системный промпт и шаблон извлечения, а результат опубликован по одному прогону вместо десяти⁶. Позиция Zep: mem0 неверно сконфигурировала их систему — назначила роль пользователя обоим участникам диалога, передавала время, приклеивая его к сообщениям вместо поля created_at, и выполняла поиск последовательно, завысив латентность⁷.

Оба текста технические и в деталях проверяемы, но проверять их некому: нейтрального харнесса с зафиксированными реализациями всех систем не существует. Показательна и арифметика самого блога Zep: в подзаголовке заявлено превосходство «на 24%», а в первом абзаце — «на 10%»⁷, что не укрепляет доверия к аккуратности остальных чисел.

Filesystem против memory-слоя. Команда Letta — авторы MemGPT — повторила LoCoMo иначе: положила историю диалога в файл, дала агенту инструменты grep, search_files, open и позволила искать итеративно. С GPT-4o mini такой агент набрал 74,0% против 68,5%, которые mem0 отчитала для своего лучшего графового варианта⁸. Аргумент авторов: агенты хорошо умеют пользоваться инструментами, похожими на файловые операции, потому что такие операции есть в их обучении, а специализированные memory-инструменты, спроектированные под single-hop retrieval, проигрывают агенту, который сам переформулирует запрос и ищет, пока не найдёт⁸. Там же отдельно отмечено, что mem0 не ответила на запросы о том, как именно считались числа для MemGPT⁸.

Атомарные факты против целых реплик. Прямое противоречие между двумя статьями: mem0 строит защиту на извлечении компактных фактов и утверждает, что это даёт лучшие результаты, чем RAG по чанкам¹, а LongMemEval находит, что дальнейшее сжатие в отдельные факты ухудшает общую точность из-за потери информации, хотя и помогает на многосессионных вопросах¹⁷. Согласовать это можно только одним способом: обе правы на своём типе вопросов, а публичные бенчмарки не разделяют типы достаточно строго, чтобы это увидеть.

Память против длинного контекста. Zep прямо называет LoCoMo негодной оценкой, потому что диалоги в 16–26 тысяч токенов легко влезают в современное окно, и указывает, что в таблице самой mem0 полный контекст обгоняет систему памяти⁷. Это не риторика: число 73% против 68,44% стоит в статье mem0¹. Из него следует, что для приложений с историей в десятки тысяч токенов память — это оптимизация латентности и цены, а не точности.

Недостаточность данных

Независимого харнесса нет: все опубликованные сравнения сделаны либо вендором против конкурента, либо на датасете, собранном одной из команд. Осталось невыясненным следующее. Долговременная деградация: ни один из разобранных источников не измеряет качество памяти через месяцы непрерывной работы — самые длинные сценарии измеряются сотнями сессий, но не календарным временем. Стоимость ингеста в деньгах: статьи приводят токены и латентность, но не цену одной обработанной реплики при разных моделях. Поведение на русском и на смешанных языках не измерялось ни в одном бенчмарке; экстраполяция с английского здесь не обоснована. Наконец, для Zep нет публичных данных о цене enterprise-развёртывания, а для Letta — о том, как sleep-time агент ведёт себя при конфликтующих правках двух разных агентов одного пользователя.

Заключение

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

Если нужен ответ на вопрос «когда это было правдой» и аудит источника каждого факта — это битемпоральный граф: Zep или Graphiti. Цена — графовая база, LLM на ингесте и аккуратная работа с удалением, потому что устаревшее здесь не исчезает⁴¹¹⁵. Если нужен полный контроль над тем, что модель видит в каждом запросе, и маленький контекст — блоки Letta с вынесенной консолидацией; цена — зависимость от дисциплины модели при редактировании блока²³. Если нужен дешёвый и быстрый поиск по фактам при массовой записи — mem0; графовый вариант стоит брать только при реальной потребности в многошаговых вопросах, поскольку он удваивает токены на запрос ради примерно полутора пунктов¹. А если история приложения измеряется десятками тысяч токенов, разумный первый шаг — не покупать память вовсе: полный контекст в этом диапазоне точнее¹, а аккуратно сделанный filesystem-агент обходит специализированные слои⁸.

Практическая рекомендация одна и не зависит от выбора: перед покупкой прогнать свой трафик через три стадии — индексация, извлечение, чтение — и посмотреть, где именно теряется ответ¹⁷. Публичные лидерборды для этого не годятся: разброс между реализациями одной системы больше, чем разница между системами.

Quality Metrics