Память агента: контекст, который не исчезает после перезапуска
У человека есть рабочая, долговременная и процедурная память — у агента должно быть то же самое. В 2026 память перестала быть оптимизацией и стала архитектурным требованием: без неё каждая сессия начинается с нуля, а пользователь объясняет одно и то же третий раз подряд.
ПродвинутыйAI-агенты25 минMem0, JSON file storage, Claude API
1
Короткая, длинная, рабочая — три памяти агента
У человека рабочая память держит текущий разговор, долговременная хранит факты о мире, процедурная — навыки вроде езды на велосипеде. У агента та же структура: контекстное окно = рабочая память, внешнее хранилище = долговременная, системный промпт с правилами = процедурная.
Внутри долговременной памяти — ещё три вида: эпизодическая (что произошло в конкретной сессии), семантическая (устойчивые факты о пользователе или проекте), процедурная (как правильно выполнять задачу). Смешивать их в одном хранилище — классическая ошибка: факт «пользователь предпочитает TypeScript» живёт вечно, а «сегодня чинил баг с аутом» актуален неделю. Разделяйте по типу с первого дня.
Эпизодическая
- Что произошло в сессии
- Пример: «вчера чинили баг с Redis»
- Устаревает быстро
Семантическая
- Устойчивые факты
- Пример: «проект на Next.js 16, pnpm»
- Меняется редко
Процедурная
- Как правильно делать X
- Пример: «перед коммитом — npm run lint»
- Живёт в системном промпте
Путаница между типами — первая ошибка. Храните их отдельно, иначе агент будет смешивать факты и опыт, и процедурные правила растворятся среди устаревших событий.
2
Файл или vector DB? Большинство проектов ошибаются
Контринтуитивно, но факт: для большинства агентов файловая память работает лучше, чем vector retrieval. Причина простая — если вся память помещается в 5–10K токенов, загрузить её целиком дешевле и надёжнее, чем искать релевантные куски. Vector DB добавляет инфраструктуру, риск промаха retrieval и ещё один сервис, который может упасть.
Когда файл — оправдан? Персональный ассистент, коди́нг-агент для одного проекта, бот поддержки с фиксированной базой FAQ. Когда vector DB действительно нужна? Когда у вас тысячи документов, сотни пользователей с разным контекстом, или требование latency ниже секунды. Выбирайте по реальным объёмам, а не «на вырост».
Файловая память или vector DB?
Память < 10K токенов — хватит файла
Один пользователь / один проект
Нужно искать по тысячам документов
Строгое требование latency < 1s
«На вырост» без реальных данных — нет
Mem0 2026 бенчмарк: файловая память даёт 72.9% точности, vector — 66.9%. Но vector — 0.2s vs 17s. Выбор по latency, не по размеру.
3
Индекс вместо свалки: как агент решает что читать
Наивный подход: одна большая memory.md, которая загружается каждую сессию. Через месяц она 30K токенов, половина устарела, агент тратит контекст на шум. Правильный паттерн — индекс: MEMORY.md содержит список файлов и по одной строке на каждый. Детали — в отдельных файлах, загружаются только по необходимости.
Это работает как оглавление книги. Вы не читаете всю книгу, чтобы найти главу про аутентификацию — смотрите в оглавление, открываете нужную страницу. Агент делает так же: читает индекс, по задаче пользователя выбирает 1–2 релевантных файла, загружает только их. Контекст остаётся компактным, а память масштабируется без деградации качества.
Старт сессии
Читаем MEMORY.md (индекс)
Выбираем релевантные файлы
Грузим только выбранные
Работаем с задачей
session_start:
прочитать MEMORY.md (индекс: список файлов + 1 строка на каждый)
по задаче пользователя → выбрать релевантные файлы
загрузить только выбранные → не всё подряд
во время сессии:
узнал новый факт → записал в file.md
добавил ссылку в MEMORY.md (одна строка)4
Что сохранять, а что выжимать
Память — не журнал событий, а выжимка того, что нельзя восстановить из текущего состояния мира. Сохранять стоит четыре типа: профиль пользователя (имя, роль, предпочтения), обратная связь и правки (что пользователь исправил — это учит агента), состояние проекта (стек, конвенции, открытые вопросы), ссылки на внешние ресурсы.
Что НЕ сохранять? Код — он уже в репозитории. Git-историю — `git log` помнит. Промежуточное состояние задачи — после решения оно мусор. Отладочный шум — попытки, ошибки, возвраты. Правило простое: если факт восстанавливается через `grep` или `git log` — не память, а дубль. Сохраняйте то, что живёт только в голове пользователя.
| Сохранять | Не сохранять |
|---|---|
| Профиль: имя, роль, стек | Код — он уже в репозитории |
| Правки пользователя и его «не так» | Git-история — есть в `git log` |
| Конвенции проекта, open questions | Промежуточное состояние задачи |
| Ссылки на внешние ресурсы и docs | Отладочный шум: попытки, возвраты |
Если факт можно восстановить через `git log` или `grep` — не сохраняйте. Память для того, что НЕ в коде.
5
Память устаревает — и это опаснее, чем её отсутствие
Агент без памяти каждый раз уточняет контекст — это медленно, но безопасно. Агент с устаревшей памятью действует уверенно на основе неверных данных — и это в разы хуже. Типичный сценарий: память говорит «файл AuthService.ts содержит логику логина» → агент правит этот файл → но три месяца назад его переименовали в auth/service.ts, логика переехала, старый файл — пустышка. Агент уверенно ломает то, чего уже нет.
Три защиты от устаревания. Первая — верификация перед действием: прежде чем опираться на факт из памяти, проверь его в текущем состоянии (grep, ls, запрос к API). Память — подсказка, а не источник истины. Вторая — периодический review: раз в месяц пройтись по MEMORY.md и удалить то, что больше не актуально. Это не автоматизируется — это ручная гигиена. Третья — немедленное удаление при обнаружении ошибки: если агент нашёл, что в памяти что-то неверное, это надо сразу убрать, а не «поправить потом». Каждый устаревший факт — мина под следующую сессию.
Фундаментальное отличие: текущее состояние кода всегда правее памяти. Память — снимок прошлого, код — правда настоящего. Конфликт? Всегда выбирайте настоящее.
Хорошая привычка — перед использованием факта из памяти проверить его в коде. «Память говорит X существует» ≠ «X существует сейчас».
Результат
Вы понимаете, что память агента — это архитектура из трёх типов (эпизодическая, семантическая, процедурная), почему файл чаще правильнее vector DB, и как индекс с отдельными файлами масштабируется без раздувания контекста. Главное — память устаревает, и верификация перед действием важнее самого факта сохранения.