Память превращает AI-агента из stateless вызова модели в систему, способную продолжать работу между шагами и сессиями. Но складывать весь диалог в один бесконечный prompt — плохая архитектура: стоимость и latency растут, старые факты конфликтуют с новыми, а чувствительные данные начинают распространяться по контексту без контроля.
Какие виды памяти стоит разделять
Working memory — состояние текущего run: цель, план, промежуточные результаты и открытые tool calls.
Conversation memory — сообщения и compact summaries конкретного thread.
Semantic memory — устойчивые факты: настройки, предпочтения, сущности и знания пользователя или проекта.
Episodic memory — прошлые действия и результаты, полезные как опыт для будущих задач.
Operational state — checkpoints, idempotency keys и machine-readable status; его лучше не смешивать с текстовой памятью модели.
Не храните всё подряд
Перед записью определяйте, имеет ли факт будущую ценность. Одноразовая инструкция для текущего сообщения обычно не должна попадать в long-term memory. Для долговременной записи полезны явные поля: тип данных, owner, scope, confidence, источник, время создания и срок актуальности.
Scopes и изоляция
Разделяйте user, workspace, project, agent и thread scopes.
Не позволяйте памяти одного tenant попадать в retrieval другого.
Project memory должна иметь приоритет только внутри конкретного проекта.
Для shared workspace фиксируйте автора факта и его ACL.
Секреты, токены и пароли не должны становиться обычной semantic memory.
Как записывать память
Memory write лучше делать отдельной политикой, а не побочным эффектом каждого ответа модели. Candidate memory проходит schema validation, deduplication и policy check. Для критичных фактов можно требовать подтверждение пользователя или доверять только authoritative tool/source.
Retrieval: меньше, но точнее
Сначала фильтруйте по scope и permissions, затем применяйте semantic/keyword retrieval.
Используйте recency и confidence как дополнительные сигналы, а не только vector similarity.
Ограничивайте количество memories, попадающих в model context.
Для структурированных фактов предпочтительнее точный lookup по ключу.
Если факты конфликтуют, возвращайте provenance и разрешайте конфликт до генерации ответа.
Обновления, TTL и забывание
Память должна уметь устаревать. Для временных предпочтений и статусов задавайте TTL или revalidation date. Новая подтверждённая запись может supersede старую, а удаление пользователя или проекта должно очищать связанные memory records и индексы.
Безопасность и privacy
Шифруйте чувствительную память at rest и ограничивайте доступ сервисными ролями.
Не используйте memory retrieval для обхода authN/authZ целевой системы.
Санитизируйте данные перед логированием и observability export.
Храните provenance: откуда получен факт и когда он подтверждён.
Поддерживайте удаление и экспорт памяти для персональных данных.
Как оценивать качество памяти
Memory precision: сколько извлечённых фактов действительно полезны задаче.
Memory recall: не пропускает ли система важные ранее сохранённые факты.
Staleness rate: доля устаревших или конфликтующих записей.
Wrong-scope rate: случаи, когда память попала не тому пользователю или проекту.
Token overhead и retrieval latency на длинных сценариях.
Короткий production checklist
Есть отдельные working, conversation и long-term memory layers.
Каждая долговременная запись имеет scope, provenance и время актуальности.
Memory writes проходят policy/validation, а не выполняются автоматически всегда.
Retrieval фильтруется permissions до semantic ranking.
Есть TTL, supersede и delete механизмы.
Качество памяти проверяется evals, а не только визуально на нескольких чатах.