Суть
Когда команда говорит «добавим память», в одну кучу обычно попадают шесть разных вещей: краткоживущий контекст запуска, контекст сессии, профильные предпочтения, проверенные факты, сводки прошлых сессий и артефакты исполнения вроде результатов инструментов.
Если всё это складывается в одно место, хаос начинается быстро — и главное, становится неразрешимым вопрос «можно ли этому доверять», потому что доверие у шести источников разное (Agent Memory).
У каждого слоя свой вопрос
| Слой | На какой вопрос отвечает |
|---|---|
| Краткосрочная | Что происходит в текущем запуске прямо сейчас |
| Долговременная | Что мы знаем устойчиво и проверенно |
| Профильная | Как лучше работать с этим человеком |
Формулировка вопроса и есть критерий, что в слой класть. Запись, не отвечающая на вопрос слоя, в него не идёт, даже если технически туда помещается.
Профильная память — не база знаний
Самая коварная граница, потому что профильная память звучит безобидно: «просто предпочтения пользователя». Сюда относятся язык общения, формат ответов, рабочая роль, допустимые каналы действий, устойчивые предпочтения интерфейса.
Ключевое: профильная память отвечает на вопрос «как работать с этим человеком», а не «что истинно в мире». Как только агент начинает складывать сюда произвольные факты, слой превращается в мутную смесь персонализации, слухов и случайных наблюдений — и при этом сохраняет статус доверенного.
Состояние рантайма — не память
Вторая стираемая граница. У экземпляра агента может быть устойчивое состояние, которое переживает перезапуск и синхронизируется между клиентами. Это возможность рантайма, а не память.
- Состояние отвечает на вопрос «в каком положении этот именованный экземпляр прямо сейчас»: открытый кейс, текущий рабочий процесс, видимые клиенту настройки. Ему нужны экземпляр-владелец, версия схемы, ограничения сериализации и политика синхронизации.
- Память отвечает на вопрос «какую информацию стоит позже извлечь и использовать как знание». Ей нужны класс, происхождение, граница арендатора, правило хранения и семантика извлечения.
Смешение даёт двусторонний дефект: состояние рантайма попадает в извлечение как проверенное знание, а записи памяти начинают использоваться как изменяемое состояние интерфейса (Durable Execution, LangGraph State).
Память как ограниченный сервис, а не сырая база
Производственная память не должна выглядеть как «модель получила доступ к базе и сама придумала стратегию поиска». Более безопасная форма — сервис с маленьким API: ingest, remember, recall, list, forget.
Смысл в переносе ответственности: ingest вызывается на границе уплотнения и извлекает факты из истории, remember сохраняет явно важное, но всё равно проходит правила записи (Memory Write Policy). Модель обращается к возможностям, а не к хранилищу, и потому не может обойти политику, придумав свой запрос.
Общая память между агентами — это контракт, а не «одно хранилище»
Память, используемая несколькими агентными поверхностями сразу, полезна для преемственности, но читается опасно легко как «пусть все читают одно». Зрелая форма описывает такую запись контрактом: producer_surface (кто создал), consumer_surfaces (кто вправе использовать), scope (личный, репозиторий, организация, арендатор), conflict_policy (что делать при противоречии), срок или интервал пересмотра, политика экспорта и удаления.
Разница на примере: помнить «в этом репозитории приняты conventional commits» полезно; запомнить случайный обходной приём из неудачной попытки как устойчивое правило — вредно. Без scope и conflict_policy эти две записи неразличимы.
Связано с
- Agent Memory — виды памяти и механика хранения
- Memory Write Policy — правила, по которым запись попадает в слой
- Memory Poisoning — что происходит при пробитой границе доверия
- Agent Execution Platform — где память стоит среди слоёв платформы
- Context Layers — родственное разделение внутри одной подсказки
- Durable Execution — устойчивое состояние выполнения
- Mem0 — внешний слой фактов поверх диалога
- Multi Tenancy AI — арендатор как обязательное измерение записи