Архив, эпизоды и граф: память агента изнутри

Архив, эпизоды и граф: память агента изнутри

Когда говорят «AI-агент с памятью», многие представляют себе одну векторную БД и магический retrieval. На практике этого почти никогда не хватает.

У Волны, моего Telegram-агента, память устроена как несколько разных слоев. Потому что в реальном диалоге нужно решать сразу три задачи: хранить долгие факты, держать под рукой недавний контекст и не забивать модель лишними токенами.

Условно память Волны состоит из 4 частей:

- Постоянные блоки в Letta. Это два базовых блока примерно по 3 тысячи символов каждый.

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

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

- Архивная память. Это слой для подробных фактов, которые не нужно держать в prompt постоянно, но важно уметь быстро находить. Поиск семантический, поверх него есть переранжирование по свежести, чтобы старый, но похожий факт не перебивал более актуальный.

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

- Граф связей в Neo4j. Отдельно строится сеть сущностей: люди, проекты, компании, темы, инструменты, события. Если я в сообщении упоминаю что-то знакомое, Волна пытается поднять связанные сущности и отношения вокруг него. По сути, это слой не «памяти фактов», а «памяти структуры».

Ключевая идея в том, что эти слои подмешиваются в модель не одинаково.

Когда сессия сбрасывается или контекст ужимается, Волна собирает картину заново. А на обычном ходе она не тащит весь memory dump, а использует базовый кэш и динамический контекст сообщения.

Это важно и для качества, и для скорости. Если всегда скармливать модели всю память целиком, она начинает тонуть в собственном прошлом. Если, наоборот, держать только один короткий summary, теряется ощущение непрерывности общения.

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

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

Еще один важный слой — snapshots сессий. Когда разговор заканчивается, система сохраняет короткий JSON-снимок: summary, последние реплики, число ходов, иногда наблюдения про настроение или поведенческий паттерн. При следующем reset этот снимок можно один раз вернуть в контекст и получить ощущение, что агент не «проснулся с чистого листа».

Отдельно у Волны есть слой рефлексии поверх памяти.

Если вопрос звучит как «как у Влада менялось отношение к работе» или «какая у него траектория по здоровью», простой поиск уже слабоват: он возвращает куски, а не понимание.

Для этого есть memory_reflect. Он сначала поднимает набор релевантных воспоминаний через семантический поиск, затем передает их в модель с отдельной задачей собрать из разрозненных записей связный нарратив. На выходе получается короткая интерпретация на 2-5 абзацев.

Ну и, конечно, память нужно обслуживать. Иначе любая memory system быстро превращается в цифровой чулан. Поэтому отдельный maintenance-процесс.

Если совсем коротко, память Волны — это не один prompt, не одна база и не один retrieval. Это маршрутизация разных типов памяти с разным сроком жизни, разной ценой и разным способом инъекции в контекст.

/ Не запрещена в РФ