Четыре типа памяти агента — рабочая, семантическая, эпизодическая и процедурная — решают принципиально разные задачи. Когда разработчик складывает всё в один vector store или держит весь контекст в рабочем окне, агент начинает «забывать» важное или захламляться ненужным. Опубликованный разбор предлагает дерево из пяти вопросов, которое определяет нужный слой памяти для каждой категории данных — без лишней инфраструктуры.
Контекст
Agentic-системы стали мейнстримом в 2025–2026 годах. Claude, GPT, Gemini — у всех крупных провайдеров есть SDK для агентов с инструментами, памятью и многоэтапным планированием. Но если оркестрация (ReAct, chain-of-thought, multi-agent pipelines) получила относительно много внимания от сообщества, память остаётся недодизайненным слоем большинства систем.
Готовые фреймворки — Mem0, Zep, LangGraph Memory — дают инфраструктуру. Они не отвечают на более фундаментальный вопрос: когда и зачем использовать тот или иной слой. Стартап кладёт всю историю клиента в RAG, получает медленный retrieval и галлюцинации на устаревших данных. Корпоративная команда держит всё в рабочем контексте — агент теряет важное при переходе между сессиями.
Фреймворк заимствует четырёхслойную модель из когнитивной науки и переносит её в инженерию LLM. Разделение памяти на рабочую, семантическую, эпизодическую и процедурную — не академическая условность. Те же свойства применимы к AI-системам по тем же причинам, что и к человеческой памяти.
Аналитика
Рабочая память — текущий разговор и токен-бюджет. Семантическая — стабильные факты: имя, тариф, предпочтения. Эпизодическая — история событий: жалобы, решения, транзакции. Процедурная — выученные паттерны: как делать X после N повторений. Один агент поддержки нормально использует все четыре одновременно: текущий тикет в рабочей, подписку — в семантической, историю жалоб — в эпизодической, алгоритм возврата — в процедурной.
Вопрос не в том, какую систему памяти выбрать, — а в том, какой слой нужен для каждой конкретной категории данных.
Ошибка класть всё в одно место имеет конкретные последствия: vector store для стабильных фактов замедляет retrieval и увеличивает риск галлюцинаций; рабочая память для истории клиента делает агента амнезиком при следующей сессии. Правильная архитектура памяти — это одновременно и UX, и экономия токенов, и качество ответов.
Дерево из пяти вопросов последовательно сужает выбор: переживает ли информация текущий ход? текущую сессию? это стабильный факт или событие? какой нужен retrieval? нужно ли дистиллировать процедуру? Запускается один раз для каждой категории данных — не для всего агента целиком. Один агент может получить на выходе все четыре слоя — и это нормальный результат.
Кейсы применения в бизнесе
B2B-SaaS стартап с AI-агентом внутри продукта. Типичная ошибка — один vector store для всего. Правильная схема: рабочая память для текущей сессии, structured profile (Postgres/JSON) для тарифа и настроек, episodic log для истории тикетов с semantic search. Агент перестаёт переспрашивать очевидное и достаёт нужный контекст без галлюцинаций на устаревших данных.
Корпоративный helpdesk с legacy-базой. Регламенты и инструкции — в семантическом слое (vector DB с периодическим обновлением). История обращений сотрудника — в эпизодическом. Повторяющиеся сценарии (сброс пароля, заявка на отпуск) — в процедурном: агент применяет дистиллированный алгоритм, не выводя его каждый раз заново. Знание «этот сотрудник трижды сталкивался с этой проблемой» живёт в эпизодическом слое, а не в семантическом — это принципиально разные хранилища.
Telegram-бот для малого бизнеса в КР/СНГ. Mem0 или Zep как memory layer для предпочтений клиентов (семантический слой). Простой лог в SQLite — для истории заказов (эпизодический). Процедурный слой пока избыточен: задачи недостаточно однородны. Итог: клиент не объясняет адрес доставки каждый раз, агент знает его язык и предпочтения с первого сообщения в новой сессии.
Кейсы в личной жизни
Разработчик, использующий Claude как coding assistant. Семантический слой — сохранённые preferences: стек, стиль кода, правила тестирования — через Claude Projects или настройки редактора. Эпизодический — история изменений по проектам. Процедурный — шаблоны для повторяющихся задач: написать тест, создать PR, провести review по заданному чеклисту.
Контент-мейкер или блогер. Рабочая память — текущий материал. Семантическая — tone-of-voice, brand voice, ключевые тезисы. Эпизодическая — архив опубликованных тем, чтобы не повторяться. На практике: Claude Projects с кастомными инструкциями плюс markdown-файл с историей публикаций как контекст в начале каждой сессии.
Студент или исследователь. Семантический слой — накопленная база знаний по теме (Obsidian с RAG-плагином или NotebookLM). Эпизодический — ход работы над главами, принятые решения по структуре, дедлайны. Процедурный слой в большинстве исследовательских задач избыточен: задачи недостаточно однородны, чтобы дистиллировать паттерн.
Как применить сегодня
- Пройди дерево для каждой категории данных своего агента: переживает ли информация текущий ход, текущую сессию, стабильна ли она, как будет retrieved, нужна ли процедурная дистилляция.
- Разнеси хранилища: structured profile (JSON/Postgres) для стабильных фактов, отдельный episodic log с semantic search для истории событий — не клади всё в один vector store.
- Протестируй Mem0 или Zep как готовый memory layer: оба интегрируются с LangGraph и CrewAI, поддерживают управление временными окнами фактов (Zep использует knowledge graph с validity windows).
- Небольшой profile (5–20 фактов) — читай целиком в начале сессии. Большой episodic log — только semantic search по запросу. Одна стратегия retrieval на всё — частая архитектурная ошибка.
- Если агент повторяет однотипные задачи — добавь процедурный слой: сохраняй не сырые логи, а дистиллированные паттерны успешных шагов, применимые к следующей аналогичной задаче.