Суть
Разница между ошибкой в ответе и ошибкой в памяти — во времени жизни. Плохой ответ виден сразу и стоит одного запуска. Плохая запись невидима, участвует в десятках следующих ответов и к моменту обнаружения уже не восстанавливается по одной трассе.
Типичная механика отказа: пользователь однажды написал «не тратьте время на уточнения, сразу эскалируйте», агент сохранил это как устойчивое предпочтение — и через две недели, когда ситуация требовала как раз уточнения, уверенно эскалировал.
Самый опасный путь — запись в горячем пути
Модель ответила, рантайм тут же вызывает сохранение в память. На короткой дистанции выглядит красиво. Системные проблемы этого пути:
- запись происходит под давлением задержки, поэтому проверять некогда;
- никто не валидирует, что вообще достойно сохранения;
- нет шага нормализации и удаления лишнего;
- нет отдельной политики изоляции арендаторов;
- потом невозможно объяснить, почему факт оказался в памяти.
Скучное правило, которое это закрывает: запись в долговременную память по умолчанию либо явно разрешена политикой, либо вынесена в фоновый конвейер (Context Compaction).
В горячем пути разумно оставить минимальное состояние сессии, короткие рабочие заметки, временные записи с понятным сроком жизни и то обновление, без которого текущий процесс действительно ломается.
Хорошая память пишет меньше, чем хочется
Отбор важнее объёма. В память стоит писать только то, что пригодится в будущих запусках, имеет понятного владельца и арендатора, объяснимо человеку, не тащит лишних чувствительных данных и не превращает подсказку в свалку.
Проверка перед каждой записью формулируется одним вопросом:
Если этот фрагмент всплывёт через три недели в другом контексте, мне будет комфортно объяснить, почему он здесь?
Неуверенный ответ означает, что запись не нужна.
Но «меньше» — не та ось для рабочих артефактов
Правило строгого отбора верно для профильной памяти и проверенных фактов: там лишняя запись переживает запуск и начинает влиять на решения. Для объёмных рабочих данных ось другая — не «сколько писать», а «что именно хранить».
Кейс из Agent Memory: наивный агент-химик израсходовал 20 млн токенов там, где агент с указателями обошёлся 1234 — разница около 16 000×. Экономия достигнута не отказом от записи, а тем, что в контексте остался короткий идентификатор, а содержимое ушло во внешнее хранилище и подтягивается по запросу.
Отсюда уточнение к правилу: перед тем как решать «писать или нет», стоит проверить третий вариант — записать ссылку. Он снимает главное возражение против записи (раздувание подсказки), сохраняя доступность данных, и потому для результатов инструментов, длинных документов и промежуточных артефактов почти всегда предпочтительнее обеих крайностей (Context Compaction).
Минимальная политика
memory:
allowed_kinds:
- profile_preference
- validated_fact
- session_summary
deny_sources:
- raw_user_prompt
- external_html
- unvalidated_tool_output
require_tenant_id: true
reject_if_contains:
- secrets
- access_tokens
- payment_card_data
write_mode:
profile_preference: background_review
validated_fact: immediate_if_trusted
session_summary: background_onlyЦенность не в «уме» правил, а в том, что они видимы и поддаются аудиту. Обратите внимание на deny_sources: сырой пользовательский промпт и непроверенный вывод инструмента запрещены как источники — именно они дают большинство плохих записей.
Правила чтения и записи почти никогда не совпадают
Если развести только хранилище, но не пути, система скатывается в странную логику: всё, что однажды записалось, потом читается почти откуда угодно.
Разведение выглядит так:
- запись в долговременную память требует проверки, происхождения и фонового разбора;
- чтение из неё разрешено только через фильтры извлечения (Agent Retrieval Policy);
- запись в профильную память требует явного сигнала или высокой уверенности;
- чтение профильной памяти разрешено слою персонализации, но не движку политик (Agent Control Plane).
Последняя строка — самая важная: если непроверенная память участвует в решении политики, персонализация превращается в канал влияния на права.
Происхождение хранится по умолчанию
Для каждой записи, живущей дольше одного запуска, минимальный набор полей: source_type, source_id, writer_identity, tenant_id, written_at, confidence или validation_state.
Выглядит бюрократией ровно до первого спора о том, откуда взялся «факт», который агент уверенно повторил в другом контексте.
Импорт сначала staged, потом durable
Чужой каталог памяти, transcript или backup не должен сразу попадать в автоматический context injection. Безопасный путь: импортировать во временную область, показать preview с provenance, проверить tenant/чувствительные данные и только затем явно повысить записи до durable. До promotion они доступны разбору, но не влияют на обычные ответы.
Тот же provenance ограничивает обещание «забыть». Система может надёжно удалить записи и производные, для которых сохранилась lineage; она не может честно гарантировать удаление копий без происхождения, внешних backup и уже экспортированных данных. Поэтому forget возвращает область выполненного удаления и известные остаточные границы, а не безусловное «всё забыто».
Связано с
- Agent Memory — какие вообще бывают виды памяти
- Memory Poisoning — что происходит, когда политика записи отсутствует
- Memory Boundaries — разные слои с разными правилами
- Context Compaction — фоновый конвейер, куда выносится запись
- Agent Retrieval Policy — фильтры на чтении
- Agent Control Plane — почему память не должна влиять на решения политики
- Multi Tenancy AI — изоляция арендаторов в записи
- Mem0 — внешний слой, извлекающий факты из диалога