Большинство чат-ботов и агентов сегодня работают как золотая рыбка. Закрыл диалог, и агент забыл, что вы веган, что вас зовут Игорь и что вчера уже объясняли ему задачу трижды. Long-term memory агента решает эту проблему: она хранит факты о пользователе во внешней базе и подтягивает их в промпт при новом обращении. Разберем архитектуру такой памяти, разницу между memory bank и обычной базой данных, и как собрать профиль пользователя, который агент реально запомнит.
В 2026 году агент с долгосрочной памятью строится на трех блоках: ingestion (извлечение фактов), хранилище (векторная, графовая или key-value база) и retrieval (семантический поиск при ответе). Готовые решения вроде Mem0 или Vertex AI Memory Bank закрывают это за 2-3 строки кода, но для Telegram-бота хватит и своей таблицы в Postgres.
Чем короткая память агента отличается от долгосрочной?
Короткая память живет внутри окна контекста и исчезает вместе с сессией. Долгосрочная память хранится отдельно от диалога, в базе данных, и переживает перезапуск, обновление модели и месяц молчания пользователя.
Модель по своей природе stateless: она не помнит ничего, кроме того, что ей передали в этом запросе. Рабочая память, то есть история текущего чата плюс системный промпт, это и есть весь ее мир на момент ответа. Как только диалог закрыт, все содержимое контекстного окна пропадает.
Долгосрочная память работает иначе. Факты сохраняются во внешнем хранилище с привязкой к user_id, а при следующем обращении агент делает отдельный запрос: найди все, что относится к этому человеку. Именно так устроен цикл "помнить, отвечать, учиться", который лежит в основе любого state-aware агента. Разница ощущается сразу: спросите бота через месяц про его собственный совет, и обычный чат-бот переспросит, а агент с памятью продолжит с того места, где остановились.
Как устроена архитектура memory bank у агента?
Memory bank это не просто база данных, а пайплайн из трех шагов: извлечение фактов из диалога, их хранение с метаданными и семантический поиск при новом запросе. Google называет это asynchronous memory extraction, и здесь работает та же логика.
В Vertex AI Agent Platform Memory Bank после каждой сессии транскрипт уходит на анализ модели Gemini, которая вытаскивает не сырой текст, а структурированные факты. Фраза "купил щенка золотистого ретривера по кличке Макс" превращается в пару значений: порода собаки и кличка. Это и есть суть ingestion, сжать шум диалога до сигнала.
Дальше факты попадают в хранилище с тегами по теме: предпочтения, ограничения, история покупок. При новом сообщении срабатывает preload-инструмент, который автоматически ищет релевантные записи и подмешивает их в промпт до генерации ответа, без ручной логики со стороны разработчика. Сервис берет с разработчика $0.25 за 1000 сохраненных событий и воспоминаний по состоянию на август 2026, что делает эксперименты почти бесплатными.
Семантическая, эпизодическая и процедурная память в чем разница?
Семантическая память хранит устойчивые факты о пользователе, эпизодическая помнит конкретные события с датой, процедурная запоминает навыки и последовательности действий. Продакшн-агенту обычно нужны все три, но в разных пропорциях.
Аналогия с человеческой памятью здесь работает почти буквально. Вы помните, что живете в Москве, это семантика. Помните, что в прошлый вторник ходили на AI-конференцию, это эпизод. И помните, как настраивать Windsurf под свой проект, это процедура, навык, а не факт.
| Тип памяти | Что хранит | Пример | Технология |
|---|---|---|---|
| Семантическая | Устойчивые факты и профиль | Пользователь веган, разработчик на Python | Векторная база, RAG |
| Эпизодическая | Датированные события | Обращался в поддержку 12 августа | Key-value, Mongo, Redis |
| Процедурная | Навыки и алгоритмы | Как обрабатывать жалобу клиента вежливо | Векторный стор с шаблонами |
Для агента поддержки эпизодическая память критична: он должен помнить, что клиент уже жаловался на доставку. Для персонального ассистента важнее семантика, стабильные предпочтения. Смешивать все три в одну таблицу без разметки, частая ошибка новичков в этой теме.
Нужна ли агенту векторная база данных?
Не всегда. Если факты о пользователе редко меняются и их немного, key-value хранилища вроде Redis работают быстрее и дешевле. Векторная база нужна, когда важен семантический поиск по смыслу, а не по точному совпадению.
Векторная база находит связанные понятия, даже если пользователь не использовал те же слова, что и в сохраненном факте. Запрос "двухколесный транспорт" найдет запись про велосипед, обычный поиск по ключевым словам этого не сделает. Но у этого подхода есть цена: латентность и токены на эмбеддинг растут вместе с объемом памяти.
Готовые слои памяти решают это по-разному. Mem0 работает на Apache 2.0 лицензии и набрал больше 60 тысяч звезд на GitHub к июлю 2026 года, интегрируется с CrewAI, LangGraph и Claude Code тремя строками кода. Zep через движок Graphiti строит временной граф знаний и обгоняет Mem0 на бенчмарке LongMemEval, 63.8% против 49%, именно там, где важна временная логика, кто что сказал и когда.
| Инструмент | Тип хранения | Цена | Лучше всего для |
|---|---|---|---|
| Mem0 | Вектор + опциональный граф | Free, от $19/мес | Быстрый старт, любой фреймворк |
| Zep / Graphiti | Временной граф знаний | Cloud, Graphiti open-source | Точная хронология событий |
| Letta | Многоуровневая память в стиле ОС | От $20/мес | Полный контроль над логикой |
| Vertex AI Memory Bank | Управляемый сервис Google | $0.25 за 1000 событий | Проекты на ADK и Gemini |
| Своя таблица в Postgres | Key-value | Бесплатно | MVP, Telegram-бот, до 1000 пользователей |
Как построить профиль пользователя, который агент реально запомнит?
Профиль строится вокруг entity_id, идентификатора пользователя, команды или проекта, и содержит только высокосигнальные факты. Правило простое: не сохранять весь диалог, а сохранять то, что реально изменит следующий ответ агента.
Философия "высокосигнальных фактов" отличает работающую память от свалки логов. Сохранять стоит компетентность пользователя, его ограничения и контекст задачи, а не каждую реплику подряд. Если агент помнит, что человек новичок в Python, это меняет тон следующего ответа. Если он помнит, что вчера была пятница, это почти никогда не пригодится.
Разделение на коллекции помогает масштабировать профиль без каши. Отдельная коллекция под "предпочтения", отдельная под "рабочий контекст", отдельная под конкретный проект, если агент обслуживает несколько задач одного пользователя. Так работает подход с разными "мозгами" для разных тем в Mem0, испанский репетитор и Python-ассистент не путают факты друг друга, даже если пользователь один и тот же.
Максим: «Мог просто засесть до пяти ночи и просто там править одну какую-то функцию, которая не работала. Если бы не терпение, в моменте я уже испотел, и мне хотелось просто все это закрыть. Но я понимал, что это можно решить и нужно решить, чтобы идти дальше.»
С памятью агента бывает похожая история: retrieval работает на тестах и молчит в проде из-за неправильного порога сходства векторов. Здесь помогает та же выдержка, что и в любой отладке.
Как собрать своего агента с памятью за вечер?
Минимальный рабочий вариант собирается из четырех частей: таблица в базе, функция сохранения, функция извлечения истории и вызов модели с подмешанным контекстом. Готовый слой памяти вроде Mem0 сокращает это до пары вызовов SDK.
Шаг 1. Выбираем хранилище
Для MVP достаточно serverless Postgres, например Neon, и одной таблицы: user_id, сообщение пользователя, ответ агента, timestamp. Для продакшн-агента с сотнями пользователей уже имеет смысл готовый слой памяти, чтобы не писать логику извлечения фактов вручную.
Шаг 2. Настраиваем ingestion
После каждого сообщения короткий вызов модели превращает диалог в 2-4 факта: кто пользователь, что он хочет, какие у него ограничения. Не нужно сохранять реплику целиком, задача, вытащить сигнал и выбросить шум.
Шаг 3. Делаем retrieval перед ответом
Перед генерацией ответа агент ищет релевантные факты по user_id и добавляет их в системный промпт короткой строкой: "Известно про пользователя: работает на Python, предпочитает короткие ответы". Это и есть preload-механизм, который делает агента контекстным без ручной логики на каждый ход.
Шаг 4. Добавляем команды управления памятью
Пользователю стоит дать возможность посмотреть, что помнит агент, и удалить лишнее. В Mem0 это команды /memories и /forget, и такой же паттерн стоит повторить в своем боте, доверие к памяти растет, когда ей можно управлять.
Собрать такой стек в вайбкодинге реально за один вечер, если писать промптами в Claude Code или Cursor: база плюс две функции плюс изменение системного промпта, без глубокого знания Python.
Какие ошибки убивают долгосрочную память агента?
Главные проблемы продакшн-памяти: гонки при одновременной записи, устаревшие факты и отсутствие версионирования. Решение из практики Anthropic, асинхронный процесс "мечтания" (dreaming), который отдельно проверяет и обновляет память, не мешая основному диалогу.
Простая память в моменте работает хорошо, а на масштабе начинает ломаться. Два агента одновременно пишут в один и тот же профиль, и один факт затирает другой. Без версионирования откатить ошибочное обновление памяти невозможно. Без прав доступа личные факты пользователя А могут утечь в контекст пользователя Б при неаккуратной архитектуре мультиагентной системы.
Подход с "мечтанием" выносит проверку памяти в отдельный асинхронный процесс: раз в день или после N диалогов суб-агент читает транскрипты и предлагает правки, добавить пропущенную тему, поправить настройку инструмента, зафиксировать правило стиля для всей команды. Это разгружает основной диалог от лишней логики и держит память актуальной без ручной чистки.
Стоит ли внедрять долгосрочную память в свой продукт?
Да, если агент работает с одним и тем же пользователем дольше одной сессии: поддержка, репетитор, персональный ассистент. Нет смысла городить memory bank для одноразового генератора картинок или калькулятора, который не помнит контекст по задумке.
Сильная сторона такой памяти очевидна: пользователь не повторяет то же самое дважды, а агент со временем становится точнее и дешевле в токенах, потому что не тащит всю историю в контекст. Слабая сторона тоже есть, и говорить о ней честно важнее, чем хвалить. Память требует инфраструктуры, мониторинга устаревания фактов и решения по GDPR, если проект работает с международной аудиторией. Для маленького Telegram-бота на 500 пользователей это может быть избыточно.
| Сценарий | Что выбрать | Почему |
|---|---|---|
| MVP, до 1000 пользователей | Таблица в Postgres/Neon | Быстро, бесплатно, легко отладить |
| SaaS-продукт с персонализацией | Mem0 или Letta | Готовая экстракция фактов, масштабируется |
| Enterprise на Google Cloud | Vertex AI Memory Bank | GA-статус, встроен в ADK и LangGraph |
| Нужна точная хронология событий | Zep / Graphiti | Лучший результат на LongMemEval по временной логике |
Если проект метит в нишу AI-агентов для конкретной профессии, стоит заглянуть в каталог агентов VibeCoderz, там уже 297 ниш и почти под каждую задачу есть готовый шаблон, куда память ложится естественным дополнением.
Часто задаваемые вопросы
Что такое long-term memory у AI-агента простыми словами? Это внешняя база, где агент хранит факты о пользователе между разговорами. Без нее каждый новый чат начинается с нуля, с ней агент помнит контекст неделями и месяцами.
Чем memory bank отличается от обычной базы данных? Memory bank сам решает, что сохранить, обрабатывает текст моделью и отдает факты по смыслу через семантический поиск. Обычная база просто хранит то, что вы в нее положили, и ищет по точному совпадению.
Какую векторную базу выбрать для памяти агента? Для старта хватит Qdrant или Chroma, они бесплатны и легко разворачиваются локально. Для продакшн-нагрузки удобнее готовый слой вроде Mem0, который сам управляет векторным хранилищем внутри.
Сколько стоит добавить долгосрочную память боту? Своя таблица в Neon бесплатна на старте. Mem0 дает бесплатный тариф на 10 тысяч записей памяти, Vertex AI Memory Bank берет $0.25 за 1000 событий по состоянию на август 2026.
Можно ли сделать память агента без глубокого кода? Да, вайбкодингом через Claude Code или Cursor: описываете промптом структуру таблицы и логику сохранения/извлечения, модель пишет код за вас. Понимать архитектуру из этой статьи все равно нужно, чтобы объяснить модели, что строить.
Как агент забывает ненужную информацию? Либо вручную через команду вроде /forget, либо автоматически, если система отслеживает частоту обращения к факту и считает редко используемые записи устаревшими.
Нужна ли долгосрочная память маленькому Telegram-боту? Не всегда. Если бот решает одну разовую задачу, генерация картинки, конвертация файла, память не нужна вообще. Если бот ведет пользователя через недели, репетитор, трекер привычек, дневник, память резко повышает удержание.
Глоссарий
- Memory bank — сервис, который извлекает, хранит и находит факты о пользователе для AI-агента.
- Векторная база данных — хранилище, где данные ищутся по смысловой близости, а не по точному тексту.
- Embedding — числовое представление текста, по которому векторная база сравнивает смысл.
- RAG — retrieval augmented generation, подход, при котором модель получает релевантные данные перед ответом вместо всей истории целиком.
- Ingestion — процесс превращения сырого диалога в структурированные факты для памяти.
- Retrieval — поиск и извлечение релевантных воспоминаний под текущий запрос.
- Entity ID — идентификатор, вокруг которого строится память, обычно user_id, team_id или project_id.
- LongMemEval — открытый бенчмарк для оценки качества долгосрочной памяти AI-агентов.
Заметили, что агент, который помнит пользователя с первого сообщения, конвертит в разы лучше обычного бота. Разберите каталог инструментов на vibecoderz.ru/ide, там есть свежие обзоры Claude Code, Cursor и Windsurf с точки зрения агентных задач. А если нужен разбор конкретно под ваш продукт, запишитесь на консультацию к Максиму, обсудим стек и бюджет под вашу нагрузку.