Агент без сохранения данных между сессиями начинает каждую новую сессию с контекста, предоставленного ему. Сохранение может сократить необходимость повторного предоставления вводных данных, но также создает обязательства по конфиденциальности, точности, изоляции и удалению.
Это и есть проблема памяти. Контекстные окна обслуживают текущий разговор. Долговременной памяти — между сессиями, между днями, между месяцами — нужна собственная архитектура. И она сложнее, чем кажется.
В этой статье представлена эталонная архитектура для тестирования, а не сертифицированная реализация. Продуктовые команды должны самостоятельно проверять контроль доступа, исправление, хранение, удаление, восстановление и качество поиска в своей собственной инфраструктуре.
Что означает «память»
Упрощённый взгляд: память = «модель помнит вещи между разговорами». Реальность тоньше. Когнитивная наука различает типы памяти, и память ИИ-агента выигрывает от похожего разграничения:
Рабочая память. Текущий разговор. Удерживается в контекстном окне. Теряется, когда разговор заканчивается (если не сохранена).
Эпизодическая память. Конкретные прошлые события. «В прошлый вторник мы обсуждали X.» «Три месяца назад вы решили Y.»
Семантическая память. Общие факты. «Вас зовут Алиса.» «Вы предпочитаете лаконичные ответы.» «Ваша компания в Таллинне.»
Процедурная память. Как делать вещи. «Когда пользователь просит встречу, используй этот шаблон.» «Когда клиент уровня X, следуй процессу Y.»
Различные типы памяти служат разным функциям. Используйте только те слои, которые продукт может обосновать и поддерживать; хранение большего объема данных не всегда лучше.
Чего должна добиваться память
До архитектуры — цели:
Непрерывность. Агент продолжает с того места, где остановился. Не нужно представляться заново в каждой сессии.
Персонализация. Агент применяет ваши предпочтения, не спрашивая. Пишет вашим голосом, использует ваши инструменты, ссылается на вашу команду.
Сохранение контекста. Решения из прошлых разговоров влияют на текущие. «Мы решили X в прошлом месяце» должно помниться.
Повторное использование подтвержденных предпочтений. Система может повторно применять явное или проверенное предпочтение в тех областях, где оно действительно. Само по себе повторение не доказывает, что инструмент, язык или поведение должны стать стандартом.
Приватность и забывание. Что помнится, что нет, что удаляется. Ради доверия пользователя и юридического соответствия.
Эти цели могут вступать в конфликт. Непрерывность работы может выигрывать от избирательного сохранения данных, тогда как конфиденциальность и точность требуют минимизации, ограничения целей, исправления и удаления. Архитектура должна явно отражать эти компромиссы.
Архитектура
Типичная слоистая архитектура:
┌─────────────────────────────────────┐
│ Working memory (in-context) │ Текущий разговор
├─────────────────────────────────────┤
│ Session memory (recent) │ Последние N разговоров
├─────────────────────────────────────┤
│ Episodic memory (long-term) │ Конкретные прошлые события
├─────────────────────────────────────┤
│ Semantic memory (facts) │ Стабильные факты о пользователе
├─────────────────────────────────────┤
│ Procedural memory (preferences) │ Как вести себя для этого пользователя
└─────────────────────────────────────┘
Каждый слой требует явного поведения в отношении хранения, извлечения, доступа, происхождения данных, исправления, удержания и удаления; несколько логических слоев могут использовать общее физическое хранилище.
Пройдёмся по каждому.
Слой 1: Рабочая память
Уже разобрана в статье про инженерию контекста. Текущий разговор в контексте. Для многоходовых разговоров — многоуровневый контекст: недавние ходы дословно, более старые — в виде саммари.
Передача данных в долговременную память может происходить по явному контрольной точке, устойчивому событию или завершении сессии. Поскольку сессии могут завершаться внезапно, сохраняйте только одобренные кандидаты и делайте статус записи наблюдаемым, а не полагайтесь на то, что хук завершения сессии всегда выполняется.
Слой 2: Память сессий
Базовые принципы уже рассмотрены в статье «Проектирование контекста»: текущий диалог помещается в контекст, а в многоходовых беседах последние реплики можно хранить дословно, более ранние — в виде краткого резюме.
Краткие итоги недавних сессий могут храниться в ограниченном объеме, если продукт имеет обоснованную цель. Любое числовое ограничение, например «последние десять диалогов», является иллюстративным входным параметром политики, а не значением по умолчанию.
Реализация: саммари по каждой сессии с таймстампом и темой. Когда пользователь возвращается, у агента есть быстрый референс на то, что недавно происходило.
{
"session_id": "abc-123",
"user_id": "alice",
"started": "2026-05-14T10:30:00Z",
"ended": "2026-05-14T10:45:00Z",
"topic": "Drafting proposal for Acme Corp",
"summary": "Drafted v1 of the Acme proposal. Decided to lead with the cost-savings angle. Alice will review and send Friday.",
"facts_learned": ["Acme is a current customer", "Alice's deadline is Friday"],
"open_items": ["Alice to review v1 by Thursday"]
}
При новой сессии авторизованное подмножество недавних итогов может быть загружено после прохождения тестов качества извлечения, релевантности, бюджета токенов и конфиденциальности. Не загружайте фиксированное количество данных в контекст по умолчанию.
Это одна из относительно простых форм кросс-сессийной памяти, но она все равно требует тестирования изоляции, происхождения данных, исправления, жизненного цикла и извлечения.
Слой 3: Эпизодическая память
Конкретные прошлые события, которые стоит помнить дольше. Решения, ключевые точки, важные разговоры.
Они извлекаются из сессий, когда заметны. Сохраняются с богатой метаинформацией.
{
"event_id": "ev-456",
"user_id": "alice",
"date": "2026-04-22",
"type": "decision",
"description": "Alice decided to migrate from Postgres to ClickHouse for the analytics workload, citing query performance.",
"context_summary": "After 3 weeks of evaluation including performance tests and cost analysis.",
"related_topics": ["infrastructure", "analytics", "database"],
"importance": "high"
}
Извлечение: когда это релевантно текущему разговору, агент достаёт связанные эпизоды. Через семантический поиск (эмбеддим текущий запрос, ищем подходящие эпизоды), через сопоставление по темам или через темпоральные запросы («что было в прошлом месяце?»).
Сложность заключается в определении того, что qualifies как эпизод, достойный запоминания. Один из возможных паттернов предполагает, что модель предлагает решения, обязательства или ключевые этапы на одобренной контрольной точке, с указанием исходных фрагментов текста и правил подтверждения. Метка важности, сгенерированная моделью, не является основанием для сохранения персональных данных.
Слой 4: Семантическая память
Стабильные факты о пользователе, которые всегда должны быть доступны. «Алиса — CEO Acme. Её предпочтительный стиль общения — лаконичный. Она работает в часовом поясе Таллинна.»
Их объём меньше, чем эпизодов, но достают их чаще. Они формируют «модель пользователя» у агента.
Реализация: структурированный профиль.
{
"user_id": "alice",
"profile": {
"name": "Alice Tamm",
"role": "CEO at Acme Corp",
"location": "Tallinn, Estonia",
"timezone": "Europe/Tallinn",
"preferred_language": "English",
"communication_style": "concise, direct, no preamble",
"expertise_areas": ["product strategy", "go-to-market"],
"tools_used": ["Notion", "Slack", "Linear"]
}
}
Обновления происходят, когда агент узнаёт новые факты. После сессии LLM находит новые стабильные факты и предлагает их; либо они автоматически вливаются, либо ставятся в очередь на проверку.
Важно: семантические факты должны быть уверенными и стабильными. Случайная реплика в одном разговоре («может, попробую Python») не должна становиться семантическим фактом («Алиса предпочитает Python»). Планка выше.
Иллюстративный рабочий процесс уверенности, который все равно требует проверки происхождения данных и калибровки:
- Выведено один раз: только кандидат, с указанием исходного фрагмента текста и без автоматического поведенческого эффекта.
- Явно заявлено: кандидат для заявленной области применения; подтверждение перед существенным повторным использованием.
- Явно подтверждено: сохранено с указанием происхождения данных, области применения, даты пересмотра и элементов управления пользователя.
Это удерживает агента от «обучения» неверным фактам на случайных репликах.
Слой 5: Процедурная память
Как агент должен вести себя для этого пользователя: рабочие процессы, шаблоны и предпочтения для конкретных действий.
Примеры:
{
"user_id": "alice",
"procedural": {
"email_signature": "...",
"meeting_preferences": "always offer 3 time slots, never schedule before 9am",
"code_style": "Python, type hints required, dataclasses over dicts",
"tone_for_clients": "warm, direct, with explicit next steps",
"approval_process": "all customer-facing communications need Alice's review before sending"
}
}
Это шаблоны, которым агент следует, когда встают релевантные задачи.
Обновления могут начинаться с явной инструкции или повторяющегося паттерна. Поведение, повторяющееся многократно, может инициировать запрос подтверждения, но не должно молча создавать устойчивую процедуру.
Варианты хранения
Где живёт память?
SQL-база. Надёжно, легко запрашивается, хорошо изучено. Каждый тип памяти — таблица. Джойны для извлечения. Хорошо для структурированных шаблонов доступа.
Векторная база. Для семантического извлечения эпизодов («найди воспоминания по этой теме»). Эпизоды эмбеддятся; извлечение по сходству.
Комбинация. SQL вместе с векторным индексом является одним из кандидатов, когда требуются как структурированный, так и семантический доступ. Дублирование представлений увеличивает обязательства по синхронизации и удалению, поэтому проведите бенчмаркинг по сравнению с более простым хранилищем.
Специализированные инструменты памяти. Mem0, Letta (бывший MemGPT), Zep. Это специально построенные слои памяти для агентов. Стоит рассмотреть, если хотите абстракцию повыше.
Начните с наименьшего хранилища, которое удовлетворяет требованиям структурированного доступа, семантического извлечения, изоляции арендаторов, происхождения данных, исправления, удержания, удаления, резервного копирования и восстановления. Подойдут SQL, векторный индекс, их комбинация или специализированный слой; сравнивайте операционную нагрузку и затраты на миграцию, а не полагайтесь на стандартный выбор команды.
Шаблоны извлечения
Как агент подтаскивает память в контекст?
Шаблон 1: Автозагрузка при старте сессии
Когда стартует новая сессия, автоматически подтягиваются:
- Семантический профиль пользователя.
- N последних саммари сессий.
- Открытые обязательства и follow-up’ы.
Это базовый контекст, который есть у агента к моменту появления пользователя.
Шаблон 2: Извлечение по запросу
Когда сообщение пользователя намекает на прошлые темы, достаются релевантные эпизоды.
Пример: пользователь спрашивает «к чему мы пришли в обсуждении базы данных?». Агент ищет эпизоды по слову «база данных» и достаёт релевантный.
Реализация: эмбеддим сообщение пользователя, находим похожие эпизоды, включаем в контекст.
Шаблон 3: Явные инструменты памяти
У агента есть инструменты для запроса памяти:
search_episodes(query): найти конкретные прошлые события.get_user_profile(): получить семантический профиль.list_open_items(): открытые обязательства.
Агент решает сам, когда их вызывать, исходя из разговора.
Шаблон 4: Фоновое обогащение памяти
Фоновый процесс периодически просматривает память и:
- Консолидирует связанные эпизоды в темы.
- Обновляет уверенность по фактам.
- Угашает старые воспоминания, к которым давно не обращались.
Это «обслуживание памяти» — поддержание хранилища полезным со временем.
Запись памяти
Когда память записывается?
Извлечение по контрольной точке или завершении сессии
Одна из пакетных схем, подлежащая тестам на устойчивую доставку и внезапное завершение. На одобренной контрольной точке или при завершении сессии:
- LLM анализирует разговор.
- Извлекает:
- Саммари сессии.
- Заметные события (для эпизодической памяти).
- Новые факты (для семантической памяти).
- Сигналы предпочтений (для процедурной памяти).
- Обновляет и сохраняет.
Пакетная обработка может сократить объем работы в рамках сессии, однако при неожиданном завершении сессии она способна привести к потере обновлений и задержкам при их исправлении. Оценивайте оба аспекта поведения и используйте надежные задачи там, где требуется сохранность данных.
Промпт для извлечения:
Проанализируйте этот разговор. Выведите JSON с:
1. summary: краткая сводка из 2–3 предложений о том, что произошло.
2. notable_events: массив значимых событий, которые стоит запомнить (принятые решения, ключевые точки, важный контекст).
3. new_facts: массив стабильных фактов о пользователе (включайте только при высокой уверенности).
4. preference_signals: массив наблюдаемых предпочтений (только если выражены явно или повторяются).
5. open_items: массив нерешённых пунктов, к которым пользователь может вернуться.
Будьте консервативны. Включайте только пункты с высокой уверенностью. Лучше упустить, чем галлюцинировать.
Обновления в реальном времени для ценных фактов
Для некоторых фактов ждать конца сессии неправильно. Если пользователь говорит «вообще-то меня зовут Алекс, а не Алиса» — поправку нужно применить немедленно.
Шаблон: научить агента детектировать явные поправки или важные новые факты в реальном времени и обновлять память на лету.
Это требует аккуратной разработки — LLM может «выучить» неправильные факты. Часть команд требует подтверждения от пользователя перед применением онлайн-обновлений.
Обновления по инициативе пользователя
Пользователь может явно сообщить агенту, что запомнить:
- «Пожалуйста, запомни, что я предпочитаю X.»
- «Забудь то, что я сказал про Y.»
- «Всегда делай Z.»
Эти механизмы должны быть полноценными элементами управления. Запускайте запрошенное действие немедленно, отображайте его область действия и статус, а также разъясняйте любые законные ограничения на хранение или сроки истечения резервных копий, которые препятствуют немедленному универсальному удалению. Явное заявление обеспечивает надежное происхождение данных, но не гарантирует корректность каждого вычисленного объема.
Конкретный инструмент, который агент может предложить:
remember(content: string, type: "fact" | "preference" | "procedure")
forget(content: string)
list_what_you_remember()
Дать пользователю такой контроль — это про доверие.
Забывание и угасание
Неограниченная память создает риски для поиска, стоимости, конфиденциальности и точности. Документированный жизненный цикл обязателен; временное затухание является лишь одним из вариантов и не заменяет требования к сохранению или удалению данных.
Угасание по времени
Старые воспоминания реже извлекаются. Реализация:
- Оцениваем извлечение как
relevance * recency_decay. - Старые воспоминания фактически исчезают, если на них прямо не сослаться.
Удержание по важности
Важные эпизоды держатся дольше; тривиальные угасают быстрее.
- Проставляйте метки важности эпизодам в момент записи.
- События высокой ценности: период хранения, специфичный для цели, с владельцем и датой пересмотра; не устанавливайте хранение по умолчанию как бессрочное.
- Рутинные события: затухание в течение нескольких месяцев.
Забывание по инициативе пользователя
Пользователь может запросить удаление конкретных воспоминаний.
- Конкретные факты.
- Конкретные временные периоды.
- Конкретные темы.
Реализация: рабочий процесс удаления, который удаляет основную запись и все производные фрагменты, эмбеддинги, сводки, индексы, кэши, экспорты и поставленные в очередь задачи. Метка «погребения» (tombstone) может предотвратить повторное индексирование, однако простое сокрытие записи не является удалением. Определите порядок истечения резервных копий и проверьте, что удаленные данные не появляются после восстановления.
Удаление по требованию соответствия
Юридические требования могут предписывать стирание или сохранение данных. Статья 17 GDPR определяет право на стирание с исключениями; юридический консультант должен сопоставить его и другие применимые правила с продуктом, юрисдикцией и ролью обработки данных.
- Запрос на удаление учетной записи пользователя → вызовите проверенный рабочий процесс удаления или ограничения для всех охваченных хранилищ и сообщите об исключениях или сроках истечения резервных копий.
- Удаление данных по запросу → найдите охваченные записи и производные данные, затем подтвердите результат.
- Ограничения хранения → автоматически истекайте охваченные записи в соответствии с утвержденным графиком.
Это должно быть встроено с самого начала. Доделывать постфактум мучительно.
Соображения приватности
Память чувствительна. Агент знает о пользователе много. Что учитывать:
Шифрование на хранении
Данные памяти шифруются. Стандартная практика.
Контроль доступа
Кто может видеть память пользователя? Только он, только система, поддержка при определённых условиях? Определите чётко. Аудитируйте доступ.
Обработка PII
Персональные идентифицирующие данные (настоящие имена, адреса, финансовая информация) должны помечаться и обрабатываться аккуратно. Особый контроль доступа, особые процедуры удаления.
Видимость для пользователя
Там, где продукт и применимые права требуют этого, предоставьте пользователям возможность просматривать, исправлять, ограничивать область действия и удалять записи памяти. Панель управления памятью является одним из вариантов реализации; проверяйте понимание функционала и защищайте ее так же, как любую другую поверхность работы с конфиденциальными данными.
Что агент помнит о вас:
Профиль:
- Имя: Alice Tamm
- Роль: CEO at Acme Corp
- Стиль общения: лаконичный, прямой
Недавние сессии:
- 2026-05-14: Подготовлено предложение для Acme
- 2026-05-12: Просмотрены итоги Q1
- ...
Предпочтения:
- Предпочитает лаконичные ответы
- Использует Notion, Slack, Linear
[Редактировать] [Удалить отдельные пункты] [Удалить всё]
Эта прозрачность строит доверие. Скрытая память — это жутковато.
Шеринг между контекстами
Если у пользователя несколько «режимов» (рабочий агент, личный агент), он может хотеть, чтобы воспоминания были раздельны. Не делитесь воспоминаниями между режимами автоматически, если об этом не попросили.
Типичные провалы
Несколько шаблонов:
Провал 1: Галлюцинированные воспоминания
Агент утверждает, что помнит то, чего не было. «На прошлой неделе мы договорились про X» — но X никогда не обсуждался.
Причина: LLM «дорисовывает» правдоподобно звучащие воспоминания при извлечении или при подтягивании из памяти.
Исправление: операции с памятью опираются на реальные данные разговора. LLM извлекает; верификация идёт по фактической стенограмме. Галлюцинированные факты должны помечаться.
Провал 2: Выучены неправильные факты
Агент уверенно сообщает неправильные факты. «Вы сказали, что предпочитаете Python», когда вы на самом деле сказали, что вынуждены использовать Python на работе.
Причина: неверная интерпретация при извлечении.
Исправление: пороги уверенности. Учиться только из явных, повторяющихся или подтверждённых заявлений. Пользователь может поправить.
Провал 3: Утечки приватности
Память одного пользователя всплывает в разговоре другого. Катастрофа.
Причина: баги в логике скоупа пользователя.
Исправление: жёстко обеспечивайте скоуп пользователя на уровне хранения и извлечения. Аудитируйте. Никогда не доверяйте фильтрацию LLM.
Провал 4: Раздувание памяти
Через год память — это мегабайты на пользователя. Извлечение тормозит. Расходы растут.
Причина: нет угасания или прореживания.
Исправление: агрессивное угасание. Большая часть памяти становится недоступной (с низким приоритетом извлечения) через месяцы. Периодическая компакция.
Провал 5: Устаревшие факты
Пользователь сменил роль 6 месяцев назад. Агент по-прежнему ссылается на старую роль.
Причина: факты не обновляются при их вытеснении.
Исправление: выявляйте противоречия, сохраняйте происхождение и эффективные даты, а также запрашивайте подтверждение, когда авторитетное значение неясно. Принцип «победы новейшего» небезопасен для отложенных, цитируемых или злонамеренных входных данных.
Провал 6: Дезориентирующая консолидация
Фоновая консолидация памяти временами переписывает воспоминания так, что теряется информация.
Причина: агрессивное обобщение без сохранения ключевых фактов.
Исправление: консолидация должна явно сохранять факты. Тестируйте консолидацию на реальных стенограммах памяти.
Эскиз реализации: персональный ассистент с памятью
Иллюстративная эталонная архитектура: персональный ИИ-ассистент для индивидуальных пользователей.
Слои памяти:
- Рабочая: текущий разговор.
- Сессионная: последние 7 сессий в виде саммари.
- Эпизодическая: 100 самых недавних заметных событий с семантическим поиском.
- Семантическая: профиль пользователя (имя, роль, предпочтения, инструменты).
- Процедурная: явные рабочие процессы, заданные пользователем.
Хранение:
- SQL (Postgres): структурированный профиль, сессии, эпизоды, процедуры.
- Векторная БД (pgvector): семантический поиск по эпизодам.
Операции:
- Старт сессии: автозагрузка семантического профиля + 3 последних сессий + открытых пунктов.
- В середине сессии: извлечение эпизодов триггерится релевантностью темы.
- Конец сессии: извлечение через LLM; пользователь может пересмотреть, что было выучено.
- Фон: еженедельная консолидация (объединение связанных эпизодов, угасание устаревших).
Контроли пользователя:
- Панель управления памятью, показывающая, что именно запоминается.
- Возможность редактирования и удаления отдельных элементов.
- Кнопка «Забыть последний час».
- Рабочий процесс полной очистки учетной записи с подтвержденным покрытием, документированными исключениями и поведением сроков истечения резервных копий.
Необходимые доказательства перед объявлением этого успешным:
- завершение задачи с использованием и без использования извлеченной памяти на фиксированном наборе для оценки,
- точность сохраненных фактов и извлеченных воспоминаний, включая обработку противоречий,
- тесты изоляции между арендаторами и пользователями,
- распространение исправлений и удалений через записи, эмбеддинги, кэши, экспорты, задачи и истечение резервных копий,
- токены, объем хранилища, задержка и операционные затраты на основе реальных трассировок,
- тесты понимания и контроля со стороны пользователей вместо предположений об уверенности.
Закрытые провалы:
- Сценарии с галлюцинирующей памятью включены в тесты извлечения и поиска.
- Оценки уверенности калибруются; сами по себе они не делают факт истинным.
- Авторизация обеспечивается перед извлечением и снова перед представлением данных.
- Задачи хранения и консолидации имеют журналы аудита, обработку сбоев и тесты удаления.
Это чек-лист проектирования, а не доказательство готовности к производству. Статус производства требует доказательств реализации и проверки безопасности/конфиденциальности.
Специализированные инструменты
Заметка о вариантах memory-as-a-service:
Mem0. Слой памяти с открытым исходным кодом. Оцените его текущую документацию и код на соответствие вашим требованиям к персистентности, изоляции и удалению.
Letta (MemGPT). Дизайн памяти, ориентированный на инструменты. Изучите его текущую документацию и операционные границы.
Zep. Хостинговый сервис памяти и контекста. Проверьте его текущую документацию, границы данных и контракт на удаление.
Cognee. Вариант, ориентированный на граф знаний. Оцените зрелость и соответствие, изучив текущую документацию и репозиторий, прежде чем внедрять его.
Эти инструменты могут сократить объем работ по реализации, но добавят зависимости от вендора, безопасности, миграции и жизненного цикла данных. Сравните их с внутренним дизайном, используя те же критерии приемки.
Создавайте минимально обоснованную память
Долговременная память — то, что делает агентов ощутимо умными и непрерывными, а не амнезичными. Это и одна из самых сложных вещей для правильной реализации.
Архитектура слоистая:
- Рабочая память (в контексте).
- Память сессий (недавние сессии).
- Эпизодическая память (конкретные события).
- Семантическая память (стабильные факты).
- Процедурная память (предпочтения и рабочие процессы).
У каждого слоя своя логика хранения, извлечения и угасания. Каждый вносит вклад в полезность агента во времени.
Что важно:
- Консервативное извлечение (не галлюцинировать факты).
- Обучение с учётом уверенности (не учиться из случайных реплик).
- Активное забывание (угасание и прореживание).
- Контроль со стороны пользователя (прозрачность и возможность редактировать).
- Соблюдение приватности (на каждом слое).
Когда память проходит тесты оценки и жизненного цикла, она может сократить необходимость повторного брифинга и сделать подтвержденные предпочтения доступными между сессиями.
Для агентов, требующих непрерывности между сессиями, персистентность является явным продуктовым решением. Создавайте минимально обоснованную память с прослеживаемостью, авторизацией, контролем пользователя и протестированным путем завершения жизненного цикла.
