AI Knowledge Base

008. 2026-04-23 - The 5 Types of AI Agent Memory Part 1 - DEV Community

📄 Пять типов памяти AI-агента, которые должен знать каждый разработчик (часть 1)

Краткий обзор

У LLM нет «встроенной памяти»: каждый вывод начинается с чистого листа, а «помнить» может только инфраструктура вокруг модели. Статья вводит пять слоёв памяти агента — от буфера диалога до семантического слоя знаний — и объясняет, почему все решения упираются в конечное контекстное окно (Context Window).

🔗 Оригинал: The 5 Types of AI Agent Memory Every Developer Needs to Know (Part 1) — DEV Community

🏛️ Ключевые идеи

  • Память — это не свойство модели, а инфраструктура: агент «знает» только то, что система успела положить в контекст перед инференсом.
  • Контекстное окно (Context Window) — единственная реальность LLM: всё вне окна для модели не существует; отсюда — бюджеты токенов, стоимость и утечки «памяти» при переполнении.
  • Пять типов памяти закрывают разные дыры: кратковременная связность диалога, долговременная персонализация, рабочий scratchpad для многошаговых циклов, эпизодический журнал событий и семантические факты (часто через RAG).
  • Сложность агентов усугубляет проблему: чат-бот, который «забыл», раздражает; агент, потерявший состояние mid-task, — это сбой; мультиагентная система без общего слоя памяти — архитектурный тупик.
  • Типы не взаимоисключающие: зрелая система обычно комбинирует все пять, выбирая, что хранить, как долго и когда доставать в промпт.

💡 Где использовать (Use Cases)

  • Проектирование каркаса агента: явно разнести буфер сессии, долговременные предпочтения пользователя, рабочее состояние цикла планирования/инструментов и базу знаний домена.
  • Персонализация и continuity: когда нужно возвращаться к проекту через дни и недели без повторного «онбординга».
  • Аудит и объяснимость: эпизодическая память как журнал «что было сделано, с каким входом и исходом».
  • Enterprise RAG: семантическая память для фактов, политик и справочников, которые нельзя «додумывать» из весов модели.

🧩 Структура оригинала (обязательно сохранить)

  • Введение: агент не сломан — у него не было задачи «помнить самому по себе».
  • Роль контекстного окна в каждом решении по памяти.
  • Как проблема памяти обострялась по мере роста сложности приложений.
  • Пять типов: STM, LTM, Working Memory, Episodic Memory, Semantic Memory.
  • Как пять типов работают вместе.
  • Инструменты: LangChain, LlamaIndex, векторные БД, LangGraph, AWS Strands Agents (отсылка к части 2).

Ниже — перевод с сохранением логики и заголовков оригинала; технические примеры оставлены в тех же разделах, где они у автора.

🧠 Основная часть (контекстно близко к оригиналу)

Введение

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

На самом деле ничего не сломано — агент ведёт себя ровно так, как устроен базовый LLM. Жёсткая правда: память агента — это не проблема модели, а проблема инфраструктуры. Ядро на базе LLM по дизайну stateless: каждый вызов инференса начинается заново — без истории, без контекста прошлых шагов, без записи событий. Это не «баг», а основа масштабирования на миллионы пользователей.

Следствие для разработчиков: вы не «даёте модели память» — вы строите память вокруг неё. Агент не помнит; помнит инфраструктура. Агент видит лишь то, что инфраструктура решает поместить перед ним внутри контекстного окна.

Контекстное окно (Context Window): почему оно в центре каждого решения по памяти

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

Каждый токен, о котором модель может рассуждать — ваше сообщение, история диалога, извлечённые документы, выводы инструментов, системные инструкции — должен находиться в окне в момент инференса. Если чего-то там нет, модель не знает, что это существует. Точка.

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

Именно эту систему и называют памятью агента. А поскольку ситуации разные — недавние реплики, предпочтения пользователя, промежуточное состояние рассуждения, история взаимодействий, доменные факты — одного типа памяти недостаточно; автор выделяет пять, каждый из которых отвечает за свой срез задачи доставки информации в нужный момент.

Как проблема памяти стала по-настоящему серьёзной

AI-приложения не начинались с агентов. Сначала были простые request–response системы: сообщение пришло — ответ ушёл, ничего не накапливается, вызовы изолированы.

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

Дальше модели научились вызывать инструменты — API, БД, поиск — и сценарий скачком усложнился: агентные системы с целью, декомпозицией, циклом «действие → наблюдение → коррекция». Потом пришли мультиагентные системы, где специализированные агенты маршрутизируют работу как команда.

Каждый такой шаг ухудшал проблему памяти. Забывчивый чат-бот раздражает. Агент, потерявший состояние посреди задачи, проваливает задачу. Команда агентов, где никто не знает, что решили другие, — ломается как система. Стратегия «запихнуть всё в контекст» на этом уровне перестаёт работать.

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

Пять типов памяти агента

1. Кратковременная память (Short-Term Memory, STM) — буфер разговора

STM — самая простая форма и та, которую вы почти наверняка уже используете: каждое сообщение пользователя и ответ агента кладутся в сессионный буфер, который на следующих запросах собирается в контекстное окно. Так агент понимает уточняющие вопросы: когда вы говорите «сделай короче», модель понимает «что» — потому что предыдущий обмен уже в окне.

Технически это часто скользящий буфер по токенам: при приближении к лимиту старые реплики сжимаются (summary) или отбрасываются. Новые входы перезаписывают старые. После завершения сессии буфер очищается.

Аналогия — RAM: быстро, актуально сейчас, но при «выключении» исчезает.

  • Решает: связность диалога в одной сессии, уточнения, локальная преемственность контекста.
  • Не решает: всё за пределами текущей сессии; завтра агент снова «пустой», если нет других слоёв.

2. Долговременная память (Long-Term Memory, LTM) — персистентность между сессиями

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

Типовая реализация — векторная база (Pinecone, Weaviate, ChromaDB и аналоги): событие «стоит запомнить» → эмбеддинг + метаданные → сохранение; при новом входе — similarity search, top‑k воспоминаний → тихая инъекция в контекст. Для модели это выглядит как «я и так это знал(а)», хотя на самом деле знание подгрузили.

Практический поток:

  1. Пользователь делится чем-то переиспользуемым (предпочтения, цели, ограничения, структура проекта).
  2. Информация эмбеддится и кладётся в векторное хранилище.
  3. В будущих сессиях запрос триггерит поиск похожих воспоминаний.
  4. Найденное подмешивается в окно до обработки нового сообщения.
  5. Память обновляется, когда появляется новая важная информация.
  • Решает: персонализацию между сессиями, удержание предпочтений, длинную непрерывность проекта.
  • Пример: ассистент помнит имя, формат отчётов команды и то, что в trade-off вы всегда ставите стоимость выше скорости — даже если вы вернулись через недели.

3. Рабочая память (Working Memory) — черновик рассуждения

Working Memory — временное хранилище пока агент ведёт сложную многошаговую задачу. Пример: «исследуй пять конкурентов, вытащи цены, сравни с нашим продуктом, дай рекомендацию» — это цепочка шагов, где результат шага N кормит шаг N+1. Рабочая память держит промежуточные результаты между итерациями, чтобы агент не потерял нить.

Без неё каждый проход цикла начинался бы «с нуля»: риск зацикливания и повторения уже сделанного.

Реализация — обычно in-memory структура (словарь/JSON), которую фреймворк ведёт между шагами; на каждом шаге состояние подмешивается в промпт вместе с новой подзадачей. После завершения задачи рабочая память очищается.

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

4. Эпизодическая память (Episodic Memory) — журнал взаимодействий

Episodic Memory — способность вспоминать конкретные прошлые события: не только «что вам нравится» (это ближе к LTM), а что произошло — с контекстом и исходом.

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

Когда вы спрашиваете «над чем мы работали на прошлой неделе?» или «что решили по ценовой модели?», система ищет в эпизодическом хранилище по времени/ключевым словам/семантике, достаёт эпизоды, сжимает в краткое резюме и кладёт в окно.

Отсюда же фразы в духе: «в прошлый раз при таком документе вы сначала отмечали юридический раздел — начать снова оттуда?».

  • Решает: recall конкретных прошлых кейсов, continuity долгих проектов, поведение «учимся на опыте», опора на прошлые решения вместо повторения ошибок.
  • Пример: «в прошлый раз вы выбрали вариант A вместо B из‑за бюджета — применить ту же логику здесь?»

5. Семантическая память (Semantic Memory) — слой знаний о мире

Semantic Memory — факты, концепции, доменные знания и отношения между сущностями независимо от конкретной истории с пользователем. Это не «наш прошлый чат», а «что в мире считается истинным/полезным для задачи»: что Python — язык программирования; какая ставка налога; что JWT истекает и требует обновления.

Часть живёт в претрейновых весах, но для актуальных и доменных знаний практичнее внешняя база, доступная через RAG (Retrieval Augmented Generation): по фактическому вопросу делается семантический поиск, в окно подмешиваются проверенные фрагменты, ответ строится опираясь на них.

  • Решает: фактическую точность, экспертизу в узких доменах, опору на знания после training cutoff, enterprise knowledge bases, где галлюцинации недопустимы.
  • Пример: вопрос «более ли населённый Bangalore, чем Amaravathi?» — не угадывание из дообучения, а запрос к семантической памяти и ответ по извлечённым данным.

Как пять типов работают вместе

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

🛠️ Технические детали и реализация

Инструменты и фреймворки (по оригиналу)

Это не абстракция: стек уже production-ready.

  • LangChain — из коробки буферная/сводная память и векторная LTM, гибкая точка сборки нескольких типов в одном агенте.
  • LlamaIndex — сильнее заточен на подключение внешних источников (PDF, API, БД, графы знаний) → типичный выбор для семантической памяти через RAG.
  • Pinecone / Weaviate / ChromaDB — векторные сторы для LTM и Semantic Memory с быстрым similarity retrieval.
  • LangGraph — графовая оркестрация для stateful многошаговых агентных процессов; автор отсылает ко второй части, где связывает все пять типов в рабочую систему.
  • AWS Strands Agents — пример «облачной» инфраструктуры агента с памятью в масштабе (также во второй части, по заявлению автора).

🔗 Связи

Теги: ai agents memory architecture rag

Вид графа

Обратные ссылки