AI Memory Framework 2026: своя среда или облако?

Эта статья помогает выбрать не самый функциональный, а подходящий способ развёртывания памяти для производственного AI Agent. Мы разделяем четыре сценария: отдельный слой памяти, граф с аудитом, облачный временной контекст и полноценный среда выполнения для состояния агента.

По документации Zep, управляемый контекстный слой заявляет задержку извлечения менее 200 мс, но это показатель конкретной реализации Zep, а не универсальный результат для всех AI Memory Framework. Поэтому наш вывод на 11 августа 2026 года простой: сначала выбирайте маршрут развёртывания по границам данных и форме Agent, а уже потом сравнивайте функции. Для существующего приложения сначала проверяйте Mem0. Для графового рассуждения, источников и аудита — Semantica. Для управляемого временного контекста — Zep. Для полноценного сохраняющего состояние агента — Letta. Чувствительные данные и нестабильную нагрузку разумно начинать с самохостингового PoC.

Последнее обновление: 11 августа 2026 года. Данные сверены с официальной документацией и репозиториями Mem0, Semantica, Zep и Letta.

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

Почему выбор нужно начинать не с количества функций

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

Mem0 можно рассматривать как отдельный слой памяти поверх уже существующего приложения. Официальный репозиторий описывает три рабочих маршрута: библиотеку, самохостинговый сервер и облачную платформу. Для интеграции это важно: не требуется сразу переносить весь жизненный цикл Agent. В приложение добавляются запись, поиск и фильтрация по идентификатору пользователя, агента или запуска. Документация Mem0 по режимам OSS и Platform подтверждает разделение самостоятельного и управляемого вариантов.

Но компонентная интеграция не означает отсутствия ответственности. Нужно отдельно проверить:

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

Последний пункт часто недооценивают. У Mem0 графовая память может использовать векторное хранилище вместе с отдельным графовым бэкендом. При самохостинге это уже не «один пакет», а набор зависимостей, которые нужно обновлять, резервировать и наблюдать. Официальное описание Graph Memory указывает, что связи и векторы хранятся в разных слоях, а графовый контекст добавляется к результатам поиска.

Оценка Mem0 для независимой памяти: 4,5/5. Сильная сторона — небольшой радиус изменений в существующем Agent. Слабая — качество извлечения, удаление и стоимость зависимостей остаются задачами команды.

Когда памяти недостаточно без источника и истории решений

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

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

Для технического руководителя это означает четыре дополнительные проверки:

1. Происхождение факта. Можно ли увидеть исходный документ, событие импорта и момент фиксации?
2. Конфликты. Что происходит, если более новый документ противоречит старому?
3. Временная валидность. Можно ли восстановить контекст, который существовал на момент решения?
4. Аудит. Можно ли выгрузить цепочку от источника до вывода без ручного восстановления из логов?

Semantica также заявляет поддержку W3C PROV-O, временных отметок и контрольных сумм SHA-256 для управления изменениями. В официальном обзоре указано более 1 000 проходящих тестов, однако это характеристика тестового покрытия проекта, а не доказательство качества конкретной инсталляции или точности вашего извлечения. Такие цифры нельзя напрямую сравнивать с задержкой Zep или скоростью Mem0. Официальный обзор Semantica подтверждает, что речь идёт о более широкой модели происхождения и управления контекстом, а не только о семантическом индексе.

Оценка Semantica для графа и аудита: 4,7/5. Сильная сторона — модель ответственности и трассируемость. Слабая — команде придётся проектировать онтологию, правила конфликтов, хранилище графа, резервирование и процедуры удаления. Для простого чат-ассистента это может быть избыточно.

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

Когда управляемый временной контекст действительно экономит время

Zep стоит оценивать не как «ещё одну базу памяти», а как управляемый сервис контекста. Его документация описывает временной Context Graph: сущности, связи и факты обновляются по мере поступления новых данных, а устаревшая информация должна вытесняться с сохранением истории. Сервис формирует готовый блок контекста для Agent и подключается к существующим интеграциям. Ключевые концепции Zep описывают эту модель.

Это подходит командам, которым нужно:

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

При этом маркетинговое обещание «менее 200 мс» нельзя превращать в сравнительный вывод. Результат зависит от размера графа, региона, сети, формы запроса, очереди обработки и объёма возвращаемого контекста. Кроме того, документация интеграции с LangGraph разделяет семантический графовый поиск и точные операции ключ-значение: для точного чтения используется резервное хранилище, а Zep отвечает за семантический поиск. Описание интеграции Zep с LangGraph показывает эту важную границу.

Перед покупкой управляемого сервиса мы бы провели повторный тест на одном наборе данных:

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

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

Оценка Zep для управляемого контекста: 4,3/5. Сильная сторона — меньше графовой эксплуатации. Слабая — внешний контур данных, зависимость от API и необходимость подтвердить фактические условия обработки.

Почему Letta — это уже не просто Memory API

Letta следует рассматривать, когда Agent должен сохранять не только факты пользователя, но и собственное состояние, рабочие блоки памяти, историю сообщений, инструменты и правила поведения. В официальной документации Letta агенты описываются как сохраняющие состояние сервисы: приложение отправляет новые сообщения, а сервер управляет состоянием. Документация Letta подтверждает отличие от обычного stateless API.

Это заметно меняет объём миграции. Если Mem0 можно вставить между приложением и памятью, то при переходе на Letta нужно проверить:

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

В документации для создания Agent указано поле ограничения контекстного окна со значением по умолчанию 32 000 токенов. Это параметр конкретного интерфейса, а не гарантия производительности вашего приложения: итоговое потребление зависит от модели, инструментов, блоков памяти и состава сообщений. Руководство Letta по созданию Agent показывает, что контекстное окно является лишь одним из параметров полного состояния.

Letta предоставляет два основных организационных пути: управляемое развёртывание через Letta Cloud или самостоятельный запуск полного Agent App Server. Для кодового помощника, персонального ассистента или постоянно работающего цифрового сотрудника это может быть естественным выбором. Для обычного бизнес-чата с уже готовым оркестратором — причиной лишней миграции.

Оценка Letta для полного Agent Runtime: 4,6/5. Сильная сторона — единая модель состояния, памяти и инструментов. Слабая — переход затрагивает архитектуру Agent, а не только слой хранения фактов.

Какие ограничения появляются при самохостинге

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

Минимальный набор рисков выглядит так:

• Изоляция. Пользовательский идентификатор должен проходить через запись, поиск, удаление и фоновые задачи. Ошибка в одном фильтре может смешать воспоминания разных клиентов.
• Удаление. Удаление из индекса не всегда означает удаление из исходной базы, журнала, графа и резервной копии.
• Постоянное хранилище. Локальный диск подходит для PoC, но не является автоматически отказоустойчивым хранилищем.
• Ключи. API-ключи моделей, векторного сервиса и графовой базы нельзя хранить в образе контейнера или в открытом файле конфигурации.
• Очереди. Извлечение сущностей и построение графа могут выполняться асинхронно. Нужно определить, когда событие считается принятым и когда оно доступно для поиска.
• Наблюдаемость. Без трассировки невозможно отличить ошибку записи от ошибки извлечения, индексации или формирования промпта.
• Восстановление. Перезапуск должен сохранять состояние, а повторная доставка события не должна создавать дубликаты.

У Mem0 самохостинговый REST-сервер открывает операции OSS-памяти через HTTP. Это удобно для разделения приложений и слоя памяти, но одновременно добавляет аутентификацию, сетевую политику, проксирование и контроль версий API. Официальная документация REST API Mem0 указывает, что встроенная авторизация для самохостингового сервера включена по умолчанию.

Пошаговый план перехода от локального PoC к рабочей среде

Мы бы не начинали с полной миграции. Безопаснее двигаться по следующей последовательности.

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

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

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

1. Разделите запись и чтение. Логируйте исходное событие, нормализованный факт, идентификатор пользователя, результат извлечения, запись в хранилище и итоговый контекст, переданный модели.

1. Проверьте отказоустойчивость. Остановите сервис во время записи, перезапустите его, повторите событие и убедитесь, что данные не потеряны и не продублированы.

1. Проверьте удаление. Удалите пользователя и найдите его данные через обычный поиск, графовый поиск, точное чтение, журнал и резервную копию. Если хотя бы один слой сохраняет данные без понятного основания, PoC нельзя считать завершённым.

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

1. Введите критерии расширения. Увеличивайте нагрузку только после прохождения тестов на изоляцию, восстановление, задержку p95, качество извлечения и устойчивость длинных задач.

Для отдельного плана можно использовать руководство по настройке и приёмке самохостинговой среды для AI Agent Memory. Если тесты требуют постоянного рабочего окружения, полезно заранее сопоставить нагрузку с рекомендациями по выбору облачной Mac-конфигурации для длительно работающего Agent.

Четыре маршрута выбора

Вместо рейтинга функций мы используем условное распределение:

• Если существующее приложение уже стабильно, а нужен только межсессионный контекст, сначала проверяйте Mem0. Самохостинг предпочтителен при чувствительных данных; облачный режим — при ограниченной команде эксплуатации.

• Если каждое решение должно объясняться источниками, правилами и временной цепочкой, оценивайте Semantica. Не берите её только ради обычного семантического поиска: графовая модель окупается там, где аудит является частью требований.

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

• Если Agent должен постоянно жить, помнить состояние, использовать инструменты и выполнять длительные задачи, проверяйте Letta. Заранее оцените объём переноса существующей оркестрации.

Перед расширением мы рекомендуем пройти этот короткий контроль:

• [ ] Определены классы данных и допустимый маршрут их обработки.
• [ ] Для каждого пользователя, Agent и запуска есть отдельная область памяти.
• [ ] Запись, поиск, удаление и повторная доставка событий покрыты тестами.
• [ ] После перезапуска состояние восстанавливается без ручного вмешательства.
• [ ] Проверены свежие, устаревшие и конфликтующие факты.
• [ ] Измерены задержка p50 и p95 на одном наборе задач.
• [ ] Настроены секреты, журналы, резервные копии и уведомления об ошибках.
• [ ] Оставлен путь выхода: экспорт данных, смена хранилища или замена API.
• [ ] Только после этого согласовано увеличение нагрузки или переход к постоянному окружению.

Для оценки затрат полезно отдельно учитывать длительность PoC, требования к постоянной работе, параллельные задачи и необходимость изолированной среды. Эти параметры нельзя объединять в одну усреднённую сумму: краткий тест с обезличенными данными и круглосуточный Agent имеют разные требования к дискам, сети, резервированию и контролю доступа.

FAQ

Что выбрать для AI Agent Memory: собственный сервер или управляемое облако?

Выбирайте самохостинг, если данные нельзя выводить за пределы частного контура, требуется собственная политика удаления или нужно воспроизводить решения на аудите. Управляемый сервис разумнее, когда важны быстрый запуск, минимальная эксплуатационная нагрузка и команда не хочет поддерживать графовые базы, фоновые очереди, резервное копирование и обновления. Для чувствительных проектов безопаснее начать с ограниченного самохостингового PoC.

Для каких задач подходят Semantica и Mem0?

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

Zep и Letta — это память или полноценные платформы для агентов?

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

Какую среду подготовить для корпоративного AI Memory Framework?

Нужны изолированные секреты, постоянное хранилище, резервные копии, журналирование, мониторинг, политика удаления и отдельные пространства пользователей или Agent. Для PoC достаточно одной воспроизводимой среды с тестовым набором данных. Для производства заранее проверяют восстановление после перезапуска, пики ресурсов, сетевые тайм-ауты, повторную обработку событий и поведение при недоступности провайдера.

Итоговый выбор зависит не от того, у какого проекта длиннее список возможностей. Mem0 удобнее как независимый слой в уже работающем приложении, но при самохостинге появляются расходы на векторное и графовое окружение. Semantica сильнее там, где нужны источники, причинность и аудит, однако её модель требует более зрелой эксплуатации. Zep снимает часть графовой нагрузки, но добавляет зависимость от управляемого внешнего сервиса. Letta подходит для сохраняющих состояние Agent, но переход затрагивает саму архитектуру приложения.

Если текущая система — локальный PoC, временный сервер или обычная виртуальная машина, её слабые места обычно проявляются в отсутствии постоянного хранилища, ограниченном мониторинге, неочевидном восстановлении после сбоя и нестабильной доступности для длинных задач. В таких случаях аренда выделенной Mac-среды у ZekVPS может быть практичнее для изолированного теста или длительного запуска: сначала фиксируются срок PoC, границы данных и параллельность, затем подбирается среда, а не наоборот. Для сравнения регионов можно посмотреть варианты облачной аренды Mac в Южной Корее.