Асимметрия в проектировании памяти
Стеки памяти агентов обычно оценивают так же, как поисковые системы: бенчмарки полноты, качество эмбеддингов, задержка реранжирования. Путь записи получает гораздо меньше внимания. Однако у каждого сбоя извлечения есть причина выше по потоку, и в большинстве производственных инцидентов, которые мы разбираем, причина в том, что было записано то, что никогда не следовало хранить, или сохранено без метаданных, необходимых для решения, что с этим делать позже.
Извлечение бенчмаркируют, потому что его легко бенчмаркировать. Фиксированный корпус, набор запросов, метрика ранжирования. Приём данных сложнее оценить, потому что корректность зависит от контекста: одно и то же предложение в одном ходе — устойчивое предпочтение, в другом — мимолётное замечание. Поэтому команды реализуют приём данных как тонкий вызов добавления и откладывают суждение до момента извлечения, когда информация, необходимая для этого суждения, уже отброшена.
Последствия упорядочены иначе, чем ожидает большинство команд. Агент, который помнит слишком много, ухудшает свою позицию по приватности раньше, чем ухудшает точность. Хранение случайного раскрытия пользователя не сразу меняет качество ответов; оно меняет масштаб последствий будущей утечки, повестки в суд, выгрузки для поддержки или лога провайдера модели. Эрозия точности наступает медленнее, когда устаревшие и противоречивые записи конкурируют при извлечении.
Удаление — самый явный симптом. Большинство инструментов памяти относятся к удалению как к второстепенной задаче — удаление строки в векторном хранилище, без гарантии, что эмбеддинг исчез из сегмента индекса, что сводка, производная от записи, исчезла, или что нижестоящий кэш инвалидирован. Там, где удаление не поддерживается, срок хранения становится случайным, а не выбранным.
Интерфейс политики записи
Решение — сделать путь записи границей политики, а не добавлением. Три свойства делают основную работу.
Происхождение при каждой записи
Каждая запись памяти должна нести запись о происхождении: какой ход диалога её породил, какой вызов инструмента её предоставил, какое согласие пользователя её покрывает и какая идентичность агента её записала. Это не украшение для аудита. Происхождение — это то, что позволяет точно ответить на последующий запрос на удаление — вы можете найти производные записи, а не только оригинал — и что позволяет проследить устаревшую запись до хода, который её ввёл, когда она начинает искажать решения.
Минимальная схема, выраженная как шаг валидации перед сохранением:
MemoryWrite = {
"content": str,
"provenance": {
"turn_id": str,
"tool_call_id": str | None,
"consent_ref": str | None,
"writer": str, # agent or component identity
"written_at": datetime,
},
"sensitivity": Literal["public", "internal", "personal", "restricted"],
"retention": {
"expires_at": datetime | None,
"basis": Literal["session", "consent", "contract", "indefinite"],
},
"redaction": {
"state": Literal["none", "applied", "required"],
"fields": list[str],
},
}
Записи, не прошедшие валидацию, отклоняются на границе. Это самое дешёвое место для их отклонения: запись ещё не была преобразована в эмбеддинг, проиндексирована, суммирована или реплицирована.
Классы чувствительности с сроком хранения для каждого класса
Срок хранения должен быть функцией класса, а не глобальным значением по умолчанию. Публичный факт, извлечённый из документации, и личная деталь, добровольно сообщённая в разговоре, не нуждаются в одинаковом времени жизни. Назначение срока хранения для каждого класса позволяет один раз проверить политику и применять её везде, а не пересматривать в каждой функции.
Компромисс реален. Детализированные классы увеличивают число решений, которые должен принять путь записи, и каждое дополнительное решение — это место, где агент может ошибиться. Консервативное значение по умолчанию — более короткий срок хранения, более высокая чувствительность — снижает экспозицию, но также снижает способность агента вспоминать контекст, который пользователи ожидают, что он запомнит. Нет настройки, которая избегает этого напряжения; смысл в том, чтобы сделать напряжение явным и проверяемым, а не неявным в вызове добавления.
Редактирование и истечение срока в схеме
Редактирование и истечение срока обычно реализуются как периодические задания, которые прочёсывают хранилище. Прочёсывание плохо подходит для памяти, потому что оно ретроспективно: запись существует, была прочитана, возможно, была суммирована и могла повлиять на решение до запуска прочёсывания. Перенос обоих в
Конкретно, истечение срока может быть предикатом, вычисляемым во время чтения, и триггером компакции во время записи, так что просроченная запись никогда не возвращается и освобождается при следующем проходе. Редактирование может быть переходом состояния, который перезаписывает сохранённое содержимое и инвалидирует производные сводки, ключом которых является идентификатор записи. Ни то, ни другое не требует отдельной системы; оба требуют, чтобы схема их предусматривала.
Честная оценка памяти
Оценка памяти должна измерять свойства, которые политика записи заявляет как обеспечиваемые.
Точность полноты, а не объём. Система памяти, которая возвращает больше контекста, не лучше; она больше. Измеряйте долю извлечённых записей, которые были релевантны решению, и долю решений, которые изменились бы, если бы извлечённая запись была удалена. Метрики объёма вознаграждают избыточное запоминание, что и является рассматриваемым режимом отказа.
Поведение после удаления, а не только после вставки. Наборы тестов для памяти обычно вставляют, запрашивают, утверждают. Они редко удаляют, затем запрашивают, затем утверждают, что удалённое содержимое отсутствует в прямом извлечении, в сводках и в любом кэшированном контексте. Тест удаления, который проверяет только основное хранилище, пройдёт, в то время как производные артефакты сохранят содержимое.
Влияние устаревших записей. Отслеживайте, влияют ли записи, пережившие свой полезный срок, на текущие выходы. Один рабочий механизм — контрфактический зонд: повторно запустите выборку решений с замаскированными просроченными записями или записями с низкой уверенностью и сравните. Расхождение указывает на то, что срок хранения выполняет работу, которую должна выполнять свежесть.
Эти тесты медленнее и менее приятны, чем бенчмарк полноты, и они дают результаты, требующие изменений политики, а не изменений модели. Это честный компромисс: работа над политикой записи находится выше по потоку, сквозная и её труднее отнести к одной метрике, что и является причиной, по которой её обычно откладывают, пока инцидент не заставит её сделать.
Что это меняет на практике
Рассмотрение памяти как проблемы политики записи смещает направление инженерных усилий. Граница приёма данных становится валидированным интерфейсом с происхождением, чувствительностью и сроком хранения в качестве полноправных полей. Удаление становится поддерживаемой операцией с определённой семантикой для производных данных. Оценка охватывает полный жизненный цикл, а не только путь чтения.
Ничто из этого не требует новой архитектуры памяти. Это требует решения в момент сохранения: что сохраняется, от чьего имени, на какой срок и как это будет удалено. Агенты, которые хорошо помнят, — это не те, у кого самые большие хранилища; это те, чьи хранилища содержат только записи, которые система может обосновать сохранением.