Построение памяти для долгоживущих агентов

ИИ-агент, который вас не помнит, принципиально ограничен. Каждый разговор начинается с нуля. Приходится заново представляться, заново объяснять предпочтения, заново уточнять текущую работу. Трение копится; доверие падает.

Это и есть проблема памяти. Контекстные окна обслуживают текущий разговор. Долговременной памяти — между сессиями, между днями, между месяцами — нужна собственная архитектура. И она сложнее, чем кажется.

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

Что означает «память»

Упрощённый взгляд: память = «модель помнит вещи между разговорами». Реальность тоньше. Когнитивная наука различает типы памяти, и память ИИ-агента выигрывает от похожего разграничения:

Рабочая память. Текущий разговор. Удерживается в контекстном окне. Теряется, когда разговор заканчивается (если не сохранена).

Эпизодическая память. Конкретные прошлые события. «В прошлый вторник мы обсуждали X.» «Три месяца назад вы решили Y.»

Семантическая память. Общие факты. «Вас зовут Алиса.» «Вы предпочитаете лаконичные ответы.» «Ваша компания в Таллинне.»

Процедурная память. Как делать вещи. «Когда пользователь просит встречу, используй этот шаблон.» «Когда клиент уровня X, следуй процессу Y.»

Разные типы памяти служат разным функциям. Полная система памяти агента покрывает все из них.

Чего должна добиваться память

До архитектуры — цели:

Непрерывность. Агент продолжает с того места, где остановился. Не нужно представляться заново в каждой сессии.

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

Сохранение контекста. Решения из прошлых разговоров влияют на текущие. «Мы решили X в прошлом месяце» должно помниться.

Накопление навыков. Агент усваивает ваши паттерны и применяет их. После 10 разговоров о коде на Python он должен по умолчанию выбирать Python.

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

Эти цели иногда конфликтуют. Непрерывность хочет помнить всё; приватность — ничего. Архитектура балансирует компромиссы.

Архитектура

Типичная слоистая архитектура:

┌─────────────────────────────────────┐
│ Working memory (in-context)         │  Current conversation
├─────────────────────────────────────┤
│ Session memory (recent)             │  Last N conversations
├─────────────────────────────────────┤
│ Episodic memory (long-term)         │  Specific past events
├─────────────────────────────────────┤
│ Semantic memory (facts)             │  Stable user facts
├─────────────────────────────────────┤
│ Procedural memory (preferences)     │  How to behave for this user
└─────────────────────────────────────┘

У каждого слоя своя логика хранения, извлечения и угасания.

Пройдёмся по каждому.

Слой 1: Рабочая память

Уже разобрана в статье про контекстный инжиниринг. Текущий разговор в контексте. Для многоходовых разговоров — многоуровневый контекст: недавние ходы дословно, более старые — в виде саммари.

Передача в долговременную память происходит в момент завершения сессии. Ключевая информация разговора извлекается и сохраняется.

Слой 2: Память сессий

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

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

{
  "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–5 наиболее недавних саммари. У агента есть контекст того, что происходило.

Это самая доступная форма межсессионной памяти. Легко реализуется, сразу полезна.

Слой 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"
}

Извлечение: когда это релевантно текущему разговору, агент достаёт связанные эпизоды. Через семантический поиск (эмбеддим текущий запрос, ищем подходящие эпизоды), через сопоставление по темам или через темпоральные запросы («что было в прошлом месяце?»).

Сложность: решить, что квалифицируется как «эпизод, достойный запоминания». Не каждый разговор таков. Шаблон: в конце сессии LLM извлекает из разговора заметные события. Решения, обязательства, ключевые точки сохраняются; светская беседа — нет.

Слой 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"
  }
}

Это шаблоны, которым агент следует, когда встают релевантные задачи.

Обновления случаются явно («Алиса, пожалуйста, всегда делай X так») или через распознавание паттернов (после 5 похожих запросов, обработанных одинаково, паттерн добавляется).

Варианты хранения

Где живёт память?

SQL-база. Надёжно, легко запрашивается, хорошо изучено. Каждый тип памяти — таблица. Джойны для извлечения. Хорошо для структурированных шаблонов доступа.

Векторная база. Для семантического извлечения эпизодов («найди воспоминания по этой теме»). Эпизоды эмбеддятся; извлечение по сходству.

Комбинация. Часто оптимальна: SQL для структурированных запросов, векторная — для семантических. Элементы памяти живут в обеих, с согласованными ID.

Специализированные инструменты памяти. Mem0, Letta (бывший MemGPT), Zep. Это специально построенные слои памяти для агентов. Стоит рассмотреть, если хотите абстракцию повыше.

Для большинства команд: простая связка SQL + вектор вполне годится. Специализированные инструменты полезны, но добавляют зависимость.

Шаблоны извлечения

Как агент подтаскивает память в контекст?

Шаблон 1: Автозагрузка при старте сессии

Когда стартует новая сессия, автоматически подтягиваются:

• Семантический профиль пользователя.
• N последних саммари сессий.
• Открытые обязательства и follow-up'ы.

Это базовый контекст, который есть у агента к моменту появления пользователя.

Шаблон 2: Извлечение по запросу

Когда сообщение пользователя намекает на прошлые темы, достаются релевантные эпизоды.

Пример: пользователь спрашивает «к чему мы пришли в обсуждении базы данных?». Агент ищет эпизоды по слову «база данных» и достаёт релевантный.

Реализация: эмбеддим сообщение пользователя, находим похожие эпизоды, включаем в контекст.

Шаблон 3: Явные инструменты памяти

У агента есть инструменты для запроса памяти:

• search_episodes(query): найти конкретные прошлые события.
• get_user_profile(): получить семантический профиль.
• list_open_items(): открытые обязательства.

Агент решает сам, когда их вызывать, исходя из разговора.

Шаблон 4: Фоновое обогащение памяти

Фоновый процесс периодически просматривает память и:

• Консолидирует связанные эпизоды в темы.
• Обновляет уверенность по фактам.
• Угашает старые воспоминания, к которым давно не обращались.

Это «обслуживание памяти» — поддержание хранилища полезным со временем.

Запись памяти

Когда память записывается?

Извлечение в конце сессии

Надёжный шаблон. Когда сессия заканчивается:

1. LLM анализирует разговор.
2. Извлекает: - Саммари сессии. - Заметные события (для эпизодической памяти). - Новые факты (для семантической памяти). - Сигналы предпочтений (для процедурной памяти).
3. Обновляет и сохраняет.

Эта пакетная обработка сохраняет внутрисессионный опыт быстрым (никаких записей памяти во время разговора).

Промпт для извлечения:

Analyze this conversation. Output JSON with:

1. summary: 2-3 sentence summary of what happened.
2. notable_events: array of significant events worth remembering (decisions made, milestones, important context).
3. new_facts: array of stable facts learned about the user (only include if you have high confidence).
4. preference_signals: array of preferences observed (only if expressed clearly or repeated).
5. open_items: array of unresolved items the user might want to revisit.

Be conservative. Only include items with high confidence. Better to miss something than to hallucinate.

Обновления в реальном времени для ценных фактов

Для некоторых фактов ждать конца сессии неправильно. Если пользователь говорит «вообще-то меня зовут Алекс, а не Алиса» — поправку нужно применить немедленно.

Шаблон: научить агента детектировать явные поправки или важные новые факты в реальном времени и обновлять память на лету.

Это требует аккуратной разработки — LLM может «выучить» неправильные факты. Часть команд требует подтверждения от пользователя перед применением онлайн-обновлений.

Обновления по инициативе пользователя

Пользователь может явно сообщить агенту, что запомнить:

• «Пожалуйста, запомни, что я предпочитаю X.»
• «Забудь то, что я сказал про Y.»
• «Всегда делай Z.»

Это должно быть first-class. Уважайте такие команды сразу. Это сигналы максимальной уверенности.

Конкретный инструмент, который агент может предложить:

remember(content: string, type: "fact" | "preference" | "procedure")
forget(content: string)
list_what_you_remember()

Дать пользователю такой контроль — это про доверие.

Забывание и угасание

Память, растущая бесконечно, превращается в шум. Угасание необходимо.

Угасание по времени

Старые воспоминания реже извлекаются. Реализация:

• Оцениваем извлечение как relevance * recency_decay.
• Старые воспоминания фактически исчезают, если на них прямо не сослаться.

Удержание по важности

Важные эпизоды держатся дольше; тривиальные угасают быстрее.

• Помечаем эпизоды важностью в момент записи.
• Критические события: бессрочное хранение.
• Рутинные события: угасание за месяцы.

Забывание по инициативе пользователя

Пользователь может запросить удаление конкретных воспоминаний.

• Конкретные факты.
• Конкретные временные периоды.
• Конкретные темы.

Реализация: операция удаления, которая убирает (или помечает как удалённые) соответствующие элементы.

Удаление по требованию соответствия

Юридические требования (GDPR-право на забвение, законы о хранении данных) иногда обязывают удалять.

• Удаление аккаунта пользователя → все воспоминания удалены.
• Удаление данных по запросу → удаляются конкретные воспоминания.
• Лимиты хранения → автоматическое удаление через N месяцев.

Это должно быть встроено с самого начала. Доделывать постфактум мучительно.

Соображения приватности

Память чувствительна. Агент знает о пользователе много. Что учитывать:

Шифрование на хранении

Данные памяти шифруются. Стандартная практика.

Контроль доступа

Кто может видеть память пользователя? Только он, только система, поддержка при определённых условиях? Определите чётко. Аудитируйте доступ.

Обработка PII

Персональные идентифицирующие данные (настоящие имена, адреса, финансовая информация) должны помечаться и обрабатываться аккуратно. Особый контроль доступа, особые процедуры удаления.

Видимость для пользователя

Пользователь должен иметь возможность видеть, что агент о нём помнит. Это и этически правильно, и хороший UX. Сделайте «дашборд памяти».

What the agent remembers about you:

Profile:
- Name: Alice Tamm
- Role: CEO at Acme Corp
- Communication style: concise, direct

Recent sessions:
- 2026-05-14: Drafted proposal for Acme
- 2026-05-12: Reviewed Q1 results
- ...

Preferences:
- Prefers concise responses
- Uses Notion, Slack, Linear

[Edit] [Delete specific items] [Delete all]

Эта прозрачность строит доверие. Скрытая память — это жутковато.

Шеринг между контекстами

Если у пользователя несколько «режимов» (рабочий агент, личный агент), он может хотеть, чтобы воспоминания были раздельны. Не делитесь между режимами автоматически, если об этом не попросили.

Типичные провалы

Несколько шаблонов:

Провал 1: Галлюцинированные воспоминания

Агент утверждает, что помнит то, чего не было. «На прошлой неделе мы договорились про X» — но X никогда не обсуждался.

Причина: LLM «дорисовывает» правдоподобно звучащие воспоминания при извлечении или вынимании.

Исправление: операции с памятью опираются на реальные данные разговора. LLM извлекает; верификация идёт по фактической стенограмме. Галлюцинированные факты должны помечаться.

Провал 2: Выучены неправильные факты

Агент уверенно сообщает неправильные факты. «Вы сказали, что предпочитаете Python», когда вы на самом деле сказали, что вынуждены использовать Python на работе.

Причина: неверная интерпретация при извлечении.

Исправление: пороги уверенности. Учиться только из явных, повторяющихся или подтверждённых заявлений. Пользователь может поправить.

Провал 3: Утечки приватности

Память одного пользователя всплывает в разговоре другого. Катастрофа.

Причина: баги в логике скоупа пользователя.

Исправление: жёстко обеспечивайте скоуп пользователя на уровне хранения и извлечения. Аудитируйте. Никогда не доверяйте фильтрацию LLM.

Провал 4: Раздувание памяти

Через год память — это мегабайты на пользователя. Извлечение тормозит. Расходы растут.

Причина: нет угасания или прореживания.

Исправление: агрессивное угасание. Большая часть памяти становится недоступной (с низким приоритетом извлечения) через месяцы. Периодическая компакция.

Провал 5: Устаревшие факты

Пользователь сменил роль 6 месяцев назад. Агент по-прежнему ссылается на старую роль.

Причина: факты не обновляются при их вытеснении.

Исправление: детектируйте противоречия. Когда новый факт конфликтует со старым, побеждает новый (с подтверждением, если не уверены).

Провал 6: Дезориентирующая консолидация

Фоновая консолидация памяти временами переписывает воспоминания так, что теряется информация.

Причина: агрессивное обобщение без сохранения ключевых фактов.

Исправление: консолидация должна явно сохранять факты. Тестируйте консолидацию на реальных стенограммах памяти.

Разобранный пример: личный ассистент с памятью

Реальный кейс: личный ИИ-ассистент для индивидуальных пользователей.

Слои памяти:

1. Рабочая: текущий разговор.
2. Сессионная: последние 7 сессий в виде саммари.
3. Эпизодическая: 100 самых недавних заметных событий с семантическим поиском.
4. Семантическая: профиль пользователя (имя, роль, предпочтения, инструменты).
5. Процедурная: явные воркфлоу, которые задал пользователь.

Хранение:

• SQL (Postgres): структурированный профиль, сессии, эпизоды, процедуры.
• Векторная БД (pgvector): семантический поиск по эпизодам.

Операции:

• Старт сессии: автозагрузка семантического профиля + 3 последних сессий + открытых пунктов.
• В середине сессии: извлечение эпизодов триггерится релевантностью темы.
• Конец сессии: извлечение через LLM; пользователь может пересмотреть, что было выучено.
• Фон: еженедельная консолидация (объединение связанных эпизодов, угасание устаревших).

Контроли пользователя:

• Дашборд памяти, показывающий, что помнится.
• Редактирование/удаление отдельных элементов.
• Кнопка «забудь последний час».
• Полное удаление аккаунта (стирает всё).

Результаты:

• Непрерывность: пользователи отмечают, что агент «ощущается постоянным» между сессиями.
• Персонализация: стиль ответов совпадает с предпочтениями без повторных промптов.
• Приватность: явные контроли дают пользователю уверенность.
• Стоимость: память — это ~5–15% от использования токенов в сессии. Стоит того.

Закрытые провалы:

• Галлюцинированные воспоминания ловятся верификацией при извлечении.
• Неправильные факты ловятся порогами уверенности.
• Приватность обеспечивается в каждой точке хранения и извлечения.
• Раздувание управляется угасанием и консолидацией.

Это продакшен-уровень системы памяти. Не тривиально; вполне посильно для сфокусированной команды.

Специализированные инструменты

Заметка о вариантах memory-as-a-service:

Mem0. Open-source, хорошо спроектирован. Покрывает многие из перечисленных шаблонов. Стоит рассмотреть, если не хотите строить с нуля.

Letta (MemGPT). Другая парадигма — LLM сама управляет памятью через вызовы инструментов. Мощно, но сложнее.

Zep. Хостед-слой памяти. Лёгкая интеграция.

Cognee. Новее; память на основе графа знаний.

Эти инструменты экономят время на разработку. Они же добавляют зависимость и ограничивают кастомизацию. Для зрелых продакшен-систем строить память часто разумно; для прототипов или меньших команд использование инструмента оправдано.

Ключевая мысль

Долговременная память — то, что делает агентов ощутимо умными и непрерывными, а не амнезичными. Это и одна из самых сложных вещей для правильной реализации.

Архитектура слоистая:

• Рабочая память (в контексте).
• Память сессий (недавние сессии).
• Эпизодическая память (конкретные события).
• Семантическая память (стабильные факты).
• Процедурная память (предпочтения и воркфлоу).

У каждого слоя своя логика хранения, извлечения и угасания. Каждый вносит вклад в полезность агента во времени.

Что важно:

• Консервативное извлечение (не галлюцинировать факты).
• Обучение с учётом уверенности (не учиться из случайных реплик).
• Активное забывание (угасание и прореживание).
• Контроль со стороны пользователя (прозрачность и возможность редактировать).
• Соблюдение приватности (на каждом слое).

Сделанная хорошо, память превращает ИИ из «нового незнакомца в каждом разговоре» в «непрерывного, полезного партнёра». Это разница между ИИ как инструментом и ИИ как коллегой.

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