Короткий ответ: Память AI-агентов — это механика, которая позволяет агенту переносить информацию между ходами, задачами и сессиями, а не начинать с нуля каждый раз. Она собрана из четырёх слоёв, заимствованных у когнитивной науки: рабочая (in-context) память в живом контекстном окне, эпизодическая память о прошлых событиях, семантическая память о фактах и предпочтениях и процедурная память о том, как что-то делать. Сама модель не имеет состояния и не хранит ничего из этого; каждый момент «он меня запомнил» — это harness, который записывает данные во внешнее хранилище и считывает нужный фрагмент обратно в промпт. В этом различии вся суть. Сделайте дисциплину чтения и записи правильно — и агент остаётся связным и дешёвым неделями; сделайте неправильно — и тот же агент раздувает контекст, теряет точность припоминания и жжёт в три-пять раз больше токенов, чем должен.

Память — это то место, где многие агенты тихо разваливаются между демо и продакшеном. Двухминутное демо никогда не накапливает достаточно истории, чтобы обнажить проблему. Агент, работающий неделями без присмотра, — накапливает: его контекст заполняется устаревшей расшифровкой, модель перестаёт замечать важное, а счёт растёт по причинам, которые никто не отследил. Ниже — что такое память агента на самом деле, чем она отличается от retrieval, как на самом деле устроено запоминание, почему оно ломается под нагрузкой и как мы строим её, чтобы она выживала в продакшене.

Четыре типа памяти агента

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

  1. Рабочая (in-context) память — живое контекстное окно. Оно держит текущий разговор и непосредственную задачу и именно оно сохраняет связность одной сессии. Быстрое и всегда доступное, но маленькое и временное: когда сессия заканчивается — оно исчезает, а пока сессия идёт, это самая дорогая «недвижимость» у агента.
  2. Эпизодическая память — структурированный лог прошлых событий: что произошло, что агент сделал и к чему это привело. Так агент вспоминает: «на прошлой неделе вы просили подготовить продление, и мы решили дождаться юристов». Эпизодическая память делает агента непрерывным между сессиями, а не встречающим вас заново каждый раз.
  3. Семантическая память — устойчивые факты и знания: предпочтения пользователя, доменные правила, реквизиты аккаунта, стабильные истины, которые агент не должен переучивать. Там, где эпизодическая память хранит события, семантическая хранит факты, дистиллированные из этих событий.
  4. Процедурная память — знание «как»: паттерны использования инструментов, протоколы принятия решений, рабочие процессы, которые агент усвоил как работающие. Это память компетентности, а не содержания, и именно её большинство команд игнорируют, пока агент снова и снова не открывает один и тот же подход с нуля.

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

Память агента против RAG: различие, которое имеет значение

Самая частая путаница — считать память агента и retrieval-augmented generation (RAG) одним и тем же. Они пересекаются по механике — оба часто используют эмбеддинги и векторное хранилище, — но отвечают на разные вопросы, и их смешение порождает агентов, которые не хороши ни в том, ни в другом.

RAG — это retrieval без состояния. Он извлекает релевантные фрагменты из общего корпуса в момент запроса и забывает всё, когда сессия заканчивается. Он отвечает на вопрос «что говорит документ?». Память — это персистентность с состоянием. Она хранит то, что агент узнал об этом пользователе, этом проекте, этой истории, и переносит это между сессиями. Она отвечает на вопрос «что агент узнал?». Как гласит часто повторяемое правило: если это описывает конкретного пользователя или проект — это память; если это справочный материал, общий для всех, — это RAG.

Практическое следствие — у них разные пути записи. Контент RAG создаётся один раз и индексируется: база знаний, набор документов, каталог товаров. Память пишет сам агент по ходу работы, решая, что стоит сохранить из каждого взаимодействия. Это решение о записи — самая сложная часть, и именно поэтому память — инженерная дисциплина, а не функция базы данных. Большинство продакшен-систем используют оба: RAG — чтобы знать больше, память — чтобы лучше помнить. Это взаимодополняющие слои, а не конкуренты, и архитектура должна относиться к ним как к раздельным сущностям с раздельными жизненными циклами.

Как агенты на самом деле «помнят»

Вот факт, который переупорядочивает всё: модель не имеет состояния. Она не накапливает память между вызовами. Каждый вызов API — это свежее вычисление над тем текстом, который вы поместили в контекстное окно. Поэтому, когда агент будто бы помнит разговор месячной давности, в модели ничего не изменилось — harness сохранил эту информацию где-то надёжно и поместил нужный кусок обратно в промпт перед вызовом модели.

Это делает память задачей context engineering, а не способностью модели. Цикл выглядит так: агент завершает взаимодействие, и harness решает, что (если вообще что-то) записать в хранилище памяти — резюме, извлечённый факт, запись о событии. На последующем ходу, перед вызовом модели, harness извлекает фрагменты памяти, релевантные текущей задаче, и собирает их в контекстное окно рядом с живым разговором. Модель рассуждает над этим собранным контекстом и выдаёт ответ. Затем цикл повторяется: запиши что стоит хранить, извлеки что релевантно, собери, вызови.

Каждая часть этого цикла — проектное решение с последствиями. Что записывать определяет, заполнится ли хранилище сигналом или шумом. Как извлекать определяет, всплывёт ли нужная память в нужный момент или останется погребённой. Как собирать определяет, останется ли контекстное окно компактным или раздуется. Ничем из этого модель не занимается. Это работа harness, и качество harness — это качество памяти.

Почему память агента ломается в продакшене

Сбои памяти редко проявляются на тестах. Они возникают со временем, под накоплением — именно поэтому это продакшен-проблема, а не проблема разработки. Основной урон наносят три механизма.

Первый — токенная экономика. Каждый вызов LLM заново обрабатывает всё контекстное окно. Контекст на 50 000 токенов не стоит дешевле, чем на 10 000, только потому что изменились лишь последние 500 токенов, — модель платит за чтение всего, каждый вызов. Наивные схемы памяти, которые сваливают всю историю или чрезмерно извлекают данные в промпт, делают дороже каждый вызов. Продакшен-системы на полном контексте или наивном RAG регулярно жгут в три-пять раз больше токенов, чем нужно, по данным анализа Mem0. Перерасход незаметен на одном вызове и разорителен в масштабе.

Второй — контекст как RAM, а не хранилище. Контекстное окно ведёт себя как оперативная память, а не картотека: оно конечно, изменчиво и предназначено держать активное, а не всё когда-либо сказанное. Трассы непрерывно работающих агентов часто показывают раздувание контекста до 80 000–120 000 токенов в течение двух-трёх недель работы, по мере накопления сырой расшифровки. Это тот сбой, которому больше всего подвержены долгоживущие агенты с durable execution, потому что они работают достаточно долго, чтобы это накопить.

Третий — «потеря в середине». Даже когда релевантная информация есть в контексте, модели плохо замечают материал, погребённый в середине длинного промпта. Факт, помещённый глубоко внутрь контекста на 80 000 токенов, может стать функционально невидимым — присутствует, но не прочитан. Так что раздувание контекста «на всякий случай» даже не покупает надёжность; оно активно ухудшает припоминание, повышая стоимость. Больше контекста — не больше памяти. После определённого порога — меньше.

Забывание — это фича, а не баг

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

Здесь слоистая модель окупается. Рабочая память должна держать только активную задачу. Эпизодические детали следует резюмировать и постепенно вытеснять — вы оставляете решение и исход, а не полную расшифровку, которая их породила. Факты, которые стоит хранить постоянно, дистиллируются в семантическую память, где их дёшево извлекать и где нет окружающего шума. Ограниченное извлечение — подтягивание только памяти, релевантной текущей задаче, а не всего хранилища — и есть то, что держит контекст компактным, а стоимость — ограниченной. Забывание, сжатие и ограничение охвата — не деградации памяти. Это то, что вообще заставляет память работать на длинном горизонте.

Ландшафт инструментов памяти агентов в 2026

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


Одна оговорка проходит через все из них. Библиотека памяти даёт примитивы — хранить, извлекать, резюмировать. Она не даёт политику: что именно ваш агент должен помнить, как долго, с каким охватом и когда забывать. Эта политика и есть настоящая инженерия, и она зависит от того, что делает агент. Выбор слоя памяти — решение того же рода, что и выбор агентского фреймворка или слоя durable execution: правильный ответ зависит от длины сессий, потребностей в персонализации и того, сколько инфраструктуры вы можете эксплуатировать.

Как к этому подходит Moai Team

Мы относимся к памяти как к архитектурному решению, принятому на этапе scoping, а не как к функции, добавленной после того, как агент начал забывать или переплачивать. Первые вопросы, которые мы задаём, — о нагрузке: как долго длятся сессии? Нужно ли агенту узнавать возвращающегося пользователя или каждая задача самодостаточна? Что стоит помнить постоянно, а что — на час? Эти ответы решают, какие из четырёх слоёв памяти агенту реально нужны, — и многим агентам нужно меньше, чем предполагают команды.

Когда персистентная память оправдана, мы проектируем политику записи-и-забывания явно. Мы решаем, что извлекается в семантическую память, что остаётся как резюмированные эпизодические записи, а что вытесняется, чтобы хранилище заполнялось сигналом, а не расшифровкой. Мы держим извлечение ограниченным задачей, чтобы контекстное окно оставалось компактным, и разделяем память и RAG, чтобы у общих знаний и пользовательского обучения были свои жизненные циклы. Затем мы связываем это с остальным продакшен-стеком: записи и извлечения памяти — именно те операции, которые нужно трассировать и наблюдать, чтобы видеть, всплыла ли нужная память и остался ли контекст ограниченным, а «вспоминает ли агент нужное после недели использования» становится кейсом в eval-харнессе, а не тем, на что вы надеетесь. Память, context engineering и evals — одна дисциплина под разными углами: держать агента связным, доступным по цене и корректным на тысячном реальном взаимодействии, а не только на первом.

Часто задаваемые вопросы

Что такое память AI-агента?

Память AI-агента — это механика, которая позволяет агенту удерживать и переиспользовать информацию между ходами, задачами и сессиями, а не начинать с нуля каждый раз. Она охватывает четыре слоя: рабочая память в живом контекстном окне, эпизодическая память о прошлых событиях, семантическая память о фактах и предпочтениях и процедурная память об усвоенных паттернах «как». Модель не имеет состояния и не хранит ничего из этого — harness пишет информацию во внешнее хранилище и считывает релевантный фрагмент обратно в промпт, поэтому память — инженерная дисциплина, а не функция модели.

В чём разница между памятью агента и RAG?

RAG — это retrieval без состояния, который извлекает фрагменты из общего корпуса в момент запроса и забывает их по окончании сессии; он отвечает «что говорит документ?». Память — это персистентность с состоянием, которая хранит то, что агент узнал о конкретном пользователе или проекте, и переносит это между сессиями; она отвечает «что агент узнал?». Практическое правило: если это описывает конкретного пользователя или проект — это память; если это общий для всех справочный материал — это RAG. Большинство продакшен-агентов используют оба как взаимодополняющие слои с раздельными жизненными циклами.

Почему AI-агенты забывают или дорожают со временем?

Потому что каждый вызов модели заново обрабатывает всё контекстное окно, а наивные схемы памяти позволяют этому контексту расти без границ. Непрерывно работающие агенты часто раздуваются до 80 000–120 000 токенов в течение двух-трёх недель, а подходы на полном контексте или наивном RAG обычно жгут в три-пять раз больше токенов, чем нужно. Хуже того, модели плохо замечают информацию, погребённую в середине длинных промптов, так что раздутый контекст ухудшает припоминание, одновременно повышая стоимость. Лечится намеренным забыванием, сжатием и ограниченным извлечением, а не бо́льшим контекстом.

Какой инструмент памяти выбрать — Mem0, Letta или Zep?

Зависит от нагрузки. Mem0 — сильный open-source выбор по умолчанию для персонализации и памяти о предпочтениях пользователя в чат-ботах и ассистентах. Letta (MemGPT) подходит сложным, долгоживущим агентам, которым полезна многоуровневая, самоуправляемая подкачка на длинных прогонах. Zep годится агентам, которым нужно реляционное рассуждение о том, как факты меняются во времени, на темпоральном графе знаний. Но инструмент даёт лишь примитивы; политика того, что помнить, с каким охватом и когда забывать, — это настоящая инженерия, и она зависит от того, что именно делает ваш агент.

Moai Team строит AI-агентов с памятью, заложенной на этапе scoping, — правильные слои, явная политика записи-и-забывания и ограниченное извлечение, — чтобы они оставались связными и доступными по цене неделями реального использования, а не только в демо. Запланируйте звонок.