В обзорной статье про EPIHEN мы коротко упомянули, что у агента четыре слоя памяти. Здесь разберём каждый слой по отдельности: что туда попадает, как долго хранится, кто решает что запомнить и зачем такая сложная схема вообще нужна.
Чтобы было понятнее, представьте человеческую память. У нас есть сенсорная память (то, что мы видели секунду назад), рабочая память (что мы держим в голове в текущей беседе), эпизодическая (события из жизни) и семантическая (знания о мире). Эти системы работают параллельно и независимо. У EPIHEN устроено схоже — четыре независимых слоя, каждый со своей задачей. Если бы их склеили в один, агент либо забывал бы важное, либо тонул в шуме.
Слой 1. Кратковременная память — окно контекста
Самый простой слой. Это всё, что вы написали в текущей сессии, плюс ответы агента, плюс системный промпт. Технически — это «окно контекста» большой языковой модели, которое подаётся ей с каждым новым запросом.
Размер окна зависит от модели. Claude Opus 4.7 — 200K токенов в base-mode, до 1M в long-context. Gemini 2.5 Pro — те же 2M токенов. GPT-5.5 — 400K. Это огромные числа: 200K токенов — это примерно 500-700 страниц текста. То есть в кратковременной памяти умещается несколько часов плотного разговора.
Но кратковременная память исчезает с закрытием сессии. Это её главное ограничение — и именно поэтому нужны остальные три слоя.
Слой 2. Оперативная память — факты текущего чата
Когда вы пишете «меня зовут Аня» или «я работаю над миграцией Postgres 14 → 16», модель в кратковременной памяти, конечно, это видит. Но представьте, что разговор длится три часа, и через два часа вы спрашиваете «какие риски при моей миграции?». В этот момент исходное сообщение «миграция Postgres 14 → 16» может оказаться за пределами окна, особенно если в середине были тяжёлые запросы — длинные коды, PDF-файлы, картинки.
Оперативная память решает именно эту проблему. После каждого сообщения отдельный процесс (мы зовём его таламус) сканирует, не появились ли в реплике факты, важные на уровне всего чата. Если появились — записывает в БД с привязкой к этому чату. При следующем запросе оперативные факты автоматически подмешиваются в системный промпт, поэтому агент помнит «миграция Postgres 14 → 16» даже если оригинальное сообщение уже выпало из окна.
Что обычно попадает в оперативную память:
- Имя пользователя, должность, контекст работы в этом чате.
- Технологии, версии, инструменты, о которых идёт речь.
- Решения и договорённости, принятые в начале разговора.
- Ограничения («у нас бюджет $50», «дедлайн пятница»).
Не попадает: проходные реплики, эмоции, мелкие детали. Это критично — иначе оперативная память бы раздулась за неделю до бесполезного шума.
Слой 3. Долговременная память — что мы знаем про вас как про человека
Долговременная память — главная фишка, отличающая EPIHEN от обычного чата с LLM. Это база знаний, которая живёт между всеми вашими чатами и сессиями. Создали вы её сегодня в чате про код, а завтра спросили в чате про путешествия «какой ноутбук взять в командировку» — агент учтёт, что вы backend-разработчик, потому что это знание уже в долговременной памяти.
Записываются туда не любые факты, а только те, что прошли два фильтра:
- Стабильность. Факт должен быть истинен не только в этом моменте, но и через месяц. «Я люблю горный туризм» — да, стабильно. «Я устал» — нет, ситуативно.
- Полезность. Факт должен помочь агенту лучше отвечать на будущие запросы. «Я веган» — критично полезно для рецептов. «Я родился во вторник» — почти бесполезно, не записываем.
Кроме самих фактов, в долговременной памяти живут предпочтения — что вы хотите видеть и не хотите. Например: «отвечай развёрнуто, не люблю короткие отписки», «не используй смайлики», «когда даёшь код — давай с комментариями». Эти предпочтения подмешиваются в системный промпт на каждом запросе любого чата.
Управление долговременной памятью прозрачное: вы можете в любой момент открыть её и увидеть все сохранённые факты. Можно удалить любой факт вручную, можно сказать агенту «забудь, что я backend-разработчик, я перешёл во фронтенд» — он перепишет соответствующую запись.
Слой 4. Проектная память — изолированные зоны
Проблема предыдущих трёх слоёв: они все «принадлежат пользователю в целом». Если вы используете EPIHEN и для рабочих задач, и для личных, ваша долговременная память будет содержать факты сразу из двух миров. Это и неудобно (агент путает контексты), и небезопасно (если кто-то получит доступ к одному проекту, увидит и второй).
Проектная память — четвёртый слой, в котором каждому проекту выделяется собственная независимая зона. Создали проект «Работа», в нём через пару недель набралась проектная память: имена коллег, технологии, текущие задачи. В проект «Личное» эта память не утекает ни одним фактом.
Внутри проекта работает та же логика, что и в долговременной памяти: таламус сканирует разговоры и решает что записать. Но scope ограничен проектом. Если вы в личном чате обсуждали диету, а потом перешли в рабочий — агент не вспомнит про диету: в рабочем проекте этой информации нет, она в личном.
Подробнее про проектную изоляцию — в отдельной статье.
Кто решает, что запомнить: таламус
Во всех слоях запись управляется одним и тем же модулем — мы зовём его таламус. Это отдельная LLM-инстанция (более лёгкая чем основной агент), которая получает на вход последнее сообщение пользователя и решает: запомнить или нет, и в какой слой записать.
Таламус работает асинхронно. После каждого ответа агента он в фоне обрабатывает реплику, не блокируя ответ юзеру. Если что-то нужно записать — пишет в БД. Если ничего нового нет — игнорирует.
Почему отдельный модуль, а не сам агент решает? Из-за стоимости и качества. Заставлять полноценный Opus 4.7 на каждый ход думать «а не стоит ли это запомнить» — это дорого и медленно. Маленькая модель (типа Haiku или Flash), специально обученная фильтровать факты, делает это за копейки и не тормозит основной диалог.
Как агент использует память при ответе
Когда вы отправляете запрос, EPIHEN не просто шлёт его в Opus с одной системной инструкцией. Реально происходит так:
- Сбор контекста: берётся кратковременная память (текущий чат) + оперативная (факты этого чата) + долговременная (стабильные знания о вас) + проектная (зона текущего проекта).
- Эти слои склеиваются в единый «расширенный системный промпт» с понятной структурой: что юзер любит, что делал, над чем работает.
- Расширенный промпт + сам запрос идёт в выбранную модель (Opus, Sonnet, etc.).
- Модель отвечает уже с пониманием полного контекста, а не из вакуума.
Эффект ощущается с третьего-четвёртого использования. На первом запросе ничего магического: модель просто отвечает. На десятом запросе — она уже «знает» вас, помнит ваши проекты, ваши предпочтения, не задаёт уточняющих вопросов про базовый контекст.
Что насчёт забывания
Память — это не только что записать, но и что забыть. Долговременная и проектная памяти ограничены по объёму (примерно 200 фактов на проект и около 500 на пользователя в общей долговременной). Когда лимит достигнут, таламус начинает прорежать: старые факты, на которые агент давно не ссылался, постепенно вытесняются новыми.
Это намеренное решение. Альтернатива — хранить вечно всё — приводит к тому, что через год использования в долговременной памяти лежат 5000 фактов, половина из которых устарела или вовсе про другого человека (если, например, у пользователя сменилась работа). Качество ответов падает, потому что промпт раздувается шумом.
Вручную можно почистить память в любой момент — это безопасное действие, факты можно восстановить по транскрипту чатов если очень надо.
Как проблему памяти решают вообще: четыре подхода
Прежде чем разбирать нашу схему дальше, полезно понять, что вариантов решения всего четыре, и каждый чем-то платит. Любой AI-агент с памятью использует какой-то из них или их комбинацию.
Подход 1. Просто взять окно побольше. Самый прямой: если контекст 2 миллиона токенов, можно закинуть туда всю переписку и не думать. Работает, пока разговор короче окна. Платите двумя вещами. Во-первых, деньгами: вы оплачиваете все токены на каждом ходу, и разговор на 500 тысяч токенов стоит столько же за одну реплику, сколько сотня коротких. Во-вторых, вниманием модели — про это ниже.
Подход 2. Сжатие истории. Когда переписка перестаёт влезать, старую её часть заменяют кратким пересказом. Так работает большинство чат-интерфейсов. Дёшево и просто, но пересказ необратим: если модель решила, что версия Postgres — незначимая деталь, вы её больше не вернёте. Ошибка сжатия обнаруживается через час, когда агент уже отвечает не про то.
Подход 3. Векторный поиск по истории. Вся переписка складывается в базу, и перед каждым ответом оттуда достаются куски, похожие на текущий вопрос. Ничего не теряется навсегда, объём неограничен. Слабое место — «похожесть» не равна «нужности». Вопрос «а это безопасно?» семантически не близок к сообщению «мы используем Postgres 14», хотя связан с ним напрямую. Поиск вернёт что-то про безопасность вообще и промахнётся мимо контекста.
Подход 4. Явное хранилище фактов. Отдельный процесс читает разговор и выписывает из него утверждения: «пользователь backend-разработчик», «миграция Postgres 14 → 16». Хранится не текст переписки, а выжимка. Дороже в реализации — нужен отдельный модуль, который решает, что считать фактом, — но именно он даёт память, переживающую сессию.
Наши четыре слоя — это комбинация первого и четвёртого подходов. Кратковременная память это окно, остальные три — явное хранилище с разной областью видимости. Сжатие мы не используем сознательно: необратимая потеря деталей в рабочих задачах дороже, чем экономия на токенах.
Что ломается в длинных разговорах
Отдельно стоит сказать, почему большое окно контекста не решает проблему само по себе — это неочевидно и стоит людям много времени.
Модель хуже видит середину. У языковых моделей внимание распределено по контексту неравномерно: начало и конец обрабатываются заметно надёжнее, чем середина. Эффект известен как «lost in the middle». Практический вывод: факт, упомянутый на сороковой минуте трёхчасового разговора, модель может проигнорировать, даже если формально он в окне и никуда не делся. Именно поэтому важные факты лучше держать не в истории, а в системном промпте — там они всегда в начале.
Цена растёт квадратично по разговору. Каждая реплика тянет за собой всю предыдущую переписку. Десятая реплика оплачивает девять предыдущих, сотая — девяносто девять. Разговор, который начинался за копейки, к концу дня стоит ощутимых денег, причём вы за это не делали ничего особенного.
Ответ замедляется. Чем больше входной контекст, тем дольше модель до первого токена. Разница между пустым чатом и чатом на 300 тысяч токенов заметна на глаз.
Выжимка из фактов бьёт по всем трём: в промпт уходит несколько сотен токенов вместо сотен тысяч, они стоят в начале, и разговор не дорожает от собственной длины.
Резюме
Четыре слоя памяти в EPIHEN:
- Кратковременная — окно контекста текущей сессии, исчезает при закрытии.
- Оперативная — факты в рамках одного чата, переживают сессии но не выходят за пределы чата.
- Долговременная — стабильные знания о пользователе, видны во всех чатах и проектах.
- Проектная — изолированная зона для каждого проекта, не утекает между проектами.
Всё это работает прозрачно: вы можете посмотреть и поправить любую запись. Контролируете не вы, что попадает в окно контекста, а вы вместе с таламусом, которому отданы решения «достойно ли это записать».
В следующей статье разбираем проектную изоляцию подробнее — что именно изолируется, как переключаться между проектами и почему это важнее, чем кажется.