Долговременная память AI-агентов 2026: проверка

Система уже сохраняет факты о пользователях, но команда не может быстро ответить, кто записал конкретное утверждение, почему оно всё ещё хранится и где его удалить.

Быстрое решение: не открывать автоматическую долговременную запись, пока не проверены семь контуров — правила записи, источник, релевантность, исправление, срок хранения, права доступа и восстановление. Если хотя бы на один из вопросов «кто записал, зачем хранить, кто читает и как отозвать» нет точного ответа, AI Agent должен оставаться в изолированной тестовой среде.

Эта проверка предназначена для трёх групп:

разработчиков продуктов с персонализацией и межсессионным состоянием;
команд, создающих кодирующих или задачных агентов;
платформенных специалистов, отвечающих за приватность, права доступа и жизненный цикл данных.

Что именно считается готовой долговременной памятью

В контексте долговременной памяти AI-агентов 2026 недостаточно проверить, что после перезапуска процесса модель «помнит» предыдущий разговор. Готовность означает, что каждая сохранённая запись имеет управляемый жизненный цикл.

Минимальная структура записи должна позволять определить:

источник — сообщение пользователя, результат инструмента, операторская правка или вывод модели;
субъект — конкретный пользователь, организация, проект, задача или агент;
время создания и время последнего подтверждения;
область действия — где память разрешено использовать;
уровень уверенности или статус проверки;
срок хранения;
основание для удаления или замены.

Это особенно важно для Agent Memory, потому что память становится не только механизмом повышения релевантности, но и самостоятельным хранилищем пользовательских данных. NIST относит прозрачность, объяснимость, приватность, безопасность и устойчивость к характеристикам заслуживающих доверия AI-систем; эти свойства должны учитываться на этапах проектирования, развёртывания и оценки, а не добавляться после запуска. См. официальное описание NIST AI RMF.

Скрытая проблема обычно возникает не в самой базе данных, а на границе между моделью и политикой записи. Модель может принять предположение за факт, сохранить временную инструкцию как постоянное предпочтение или связать информацию одного проекта с другим пользователем. Поэтому память следует рассматривать как отдельный контур данных с собственными правилами, журналом событий и процедурами отката.

До запуска: правила записи и границы доступа

Первая проверка — три класса данных

До открытия автоматической записи команда должна разделить кандидатов на память на три класса.

Класс	Что допускается	Как проверять
Можно записывать	Явно подтверждённые предпочтения, устойчивые настройки, согласованные параметры проекта	Проверить наличие источника и согласие на сохранение
Требует подтверждения	Выводы модели, предполагаемые привычки, приоритеты, сведения с ограниченным сроком действия	Показать пользователю предложение сохранить запись
Запрещено записывать	Пароли, токены, платёжные реквизиты, секреты, лишние персональные данные, временные инструкции	Отбрасывать до обращения к хранилищу и журналировать отказ

Такой список должен существовать не только в документации. Его необходимо превратить в тестовые сценарии. Например, в тестовую сессию вводятся фразы «всегда используй этот формат», «предположительно пользователь работает в такой отрасли» и «сохрани этот ключ». Для каждой фразы ожидаемый результат фиксируется заранее: запись, запрос подтверждения или отказ.

Отдельно проверяется, сможет ли модель сохранить недостоверную информацию, если она сформулирована уверенно. Для этого полезно использовать противоречивые сообщения:

пользователь сообщает, что предпочитает Python;
через несколько сообщений модель делает предположение о другом языке;
пользователь не подтверждает предположение;
выполняется запрос на сохранение.

Правильное поведение — не превращать вывод модели в подтверждённый факт. OWASP описывает prompt injection, раскрытие чувствительной информации и отравление данных как отдельные риски приложений на базе LLM; память расширяет последствия таких ошибок, потому что загрязнённая запись может влиять на будущие сессии. Рекомендации следует сверять с OWASP Top 10 для LLM-приложений и актуальным изданием OWASP Top 10 для LLM Applications.

Важное ограничение: фильтр секретов на этапе ответа не заменяет контроль перед записью. Если токен уже попал в векторный индекс, кэш, журнал событий или резервную копию, последующее скрытие его в интерфейсе не означает удаления.

Проверка субъектов и областей видимости

На этом этапе создаётся матрица разрешений. В ней отдельно указываются:

чтение собственной памяти пользователя;
чтение памяти организации;
чтение памяти проекта;
запись от имени пользователя;
запись от имени автоматического процесса;
просмотр оператором;
удаление пользователем;
удаление администратором;
доступ к резервным копиям.

Минимальный тест состоит из двух учётных записей, двух проектов и одного общего агента. В первую память записывается уникальная фраза, во вторую — похожая по смыслу, но с другим субъектом. Затем выполняются одинаковые запросы из обоих контекстов. Проверяется не только отсутствие прямой утечки, но и отсутствие семантического намёка: похожая память чужого проекта не должна всплывать из-за близкого embedding.

Такой тест часто выявляет ошибку в фильтрации метаданных. Векторный поиск может найти релевантный текст раньше, чем приложение применит проверку tenant_id, user_id или project_id. Поэтому изоляция должна обеспечиваться на уровне запроса к хранилищу, а не только инструкцией для модели. Перед передачей тестового стенда другой команде полезно заранее определить ответственных за доступ и эскалацию инцидентов; сведения о правилах обработки данных можно сопоставить с внутренними регламентами поставщика, но конкретная матрица разрешений должна оставаться частью собственной архитектуры.

Первый день: проверка источника и ошибочной записи

В первый день тестируется не общий процент успешных ответов, а происхождение каждой конкретной памяти. Для первой десятки или нескольких десятков записей полезно вручную проверить четыре поля:

кто был источником;
к кому или к чему относится запись;
когда она возникла;
в каком сценарии разрешено её использовать.

Если интерфейс не показывает эти сведения оператору, расследование ошибки превращается в просмотр сырых логов и догадки. Для production-системы это слишком слабая позиция: источник должен быть доступен через административный экран, API или диагностический экспорт.

Как Agent Memory не допустить ошибочной записи

Практический тест выполняется по следующей последовательности:

создать тестового пользователя и чистый проект;
отправить утверждение, которое намеренно содержит ошибку;
попросить агента сохранить его как долгосрочный факт;
проверить, был ли создан объект памяти;
выполнить запрос, который может использовать ошибку;
внести корректное значение;
повторить запрос;
удалить исходную запись;
повторить запрос после очистки кэша;
проверить индекс, журнал и резервную копию.

Важен именно порядок. Если сначала исправить запись вручную в основной таблице, а затем проверить выдачу, можно пропустить старую версию в поисковом индексе. Если удалить объект только из интерфейса, могут остаться связанный embedding, материализованный кэш или событие в очереди повторной индексации.

Для оценки удобно использовать пятибалльную шкалу:

5 баллов — ошибка не записалась либо сразу получила статус «не подтверждено», а удаление очистило все проверенные слои;
4 балла — основное хранилище и выдача очищены, но оператору пришлось вручную запускать дополнительную процедуру;
3 балла — исправление работает только после задержки или отдельной пересборки индекса;
2 балла — старая версия иногда возвращается;
1 балл — система продолжает использовать удалённый факт;
0 баллов — команда не может определить, где сохранилась ошибка.

Для запуска с автоматической записью разумным порогом является 5 баллов по удалению и не менее 4 баллов по исправлению. Это не универсальный отраслевой стандарт, а внутренняя инженерная шкала, которая делает решение проверяемым.

Срок хранения и удаление: почему «навсегда» нельзя считать политикой

Сколько должна храниться долговременная память

Срок хранения нельзя назначать одинаковым для всех типов данных. Устойчивое предпочтение интерфейса, временная цель проекта и служебный результат агента имеют разную ценность и разные риски.

Тип памяти	Типичное решение	Обязательная проверка
Настройка интерфейса	Хранить до изменения или удаления пользователем	Срабатывает ли обновление при новом явном выборе
Предпочтение пользователя	Хранить до отзыва или повторного подтверждения	Не превращается ли давняя настройка в безусловное правило
Контекст активного проекта	Хранить до закрытия проекта и ограниченный период после него	Прекращается ли выдача после смены проекта
Вывод модели	Не хранить автоматически либо хранить только после подтверждения	Есть ли видимый источник и статус уверенности
Служебная память задачи	Хранить до завершения процесса и установленного срока очистки	Удаляются ли связанные логи, кэш и индексы

Срок следует задавать как правило, а не как комментарий в документации: «при событии закрытия проекта удалить записи типа X; по истечении срока перевести записи типа Y в архив; после запроса пользователя выполнить каскадное удаление».

NIST Privacy Framework рекомендует управлять рисками приватности через корпоративный процесс, включая управление данными и контроль использования; для Agent Memory это означает, что срок хранения должен быть связан с целью обработки, ответственным владельцем и процедурой удаления. См. официальный NIST Privacy Framework.

При публикации правил удаления команда также должна сопоставить их с внутренней политикой обработки данных. В частности, важно заранее описать, какие копии считаются рабочими, как обрабатываются резервные версии и когда запись перестаёт быть доступной для новых запросов. Конкретные сроки и процедуры должны соответствовать собственной архитектуре и требованиям организации.

Как пользователь удаляет память AI Agent

Функция удаления должна проверяться как операция с наблюдаемым результатом, а не как кнопка в интерфейсе. Тест включает:

удаление одной записи;
удаление всех записей пользователя;
удаление памяти проекта;
удаление через API;
повторный поиск после удаления;
проверку кэша;
проверку фоновых очередей;
проверку резервных копий и срока их ротации;
проверку журнала: событие удаления сохраняется, но содержимое удалённой памяти не раскрывается без необходимости.

Команда должна заранее определить, что означает удаление из резервной копии. Возможны разные модели: немедленная криптографическая недоступность, исключение при следующем восстановлении, истечение резервной копии по расписанию или отдельная процедура очистки. Нельзя обещать пользователю «удалено везде», если технически удаляется только основная таблица.

Конфликты и изменения: проверка в первую неделю

В течение первой недели создаются сценарии, где факты меняются во времени. Например, проект переносится в другой репозиторий, пользователь меняет язык программирования, а задача получает новый приоритет. Затем система получает запрос, в котором одновременно релевантны старая и новая записи.

Проверяются четыре варианта поведения:

новая запись получает больший вес из-за свежести;
старая запись сохраняется как история;
новая запись заменяет старую только при явном подтверждении;
конфликт передаётся пользователю или оператору.

Опаснее всего тихое перезаписывание. Оно делает текущий ответ удобнее, но уничтожает объяснение того, почему память изменилась. Для важных настроек лучше использовать версионность: новая запись не удаляет старую физически, а связывается с ней отношением «заменяет», «отменяет» или «уточняет».

На этой же неделе полезно измерять не только точность выдачи, но и стоимость обслуживания:

количество записей, которые не использовались;
число повторных или почти одинаковых записей;
количество ручных исправлений;
долю запросов, где память оказалась нерелевантной;
размер индекса и журнала;
время обработки операции удаления.

Если хранилище растёт быстрее, чем полезная память, проблема обычно находится в политике записи, а не в недостаточной мощности сервера. В этом случае сначала меняются фильтры, дедупликация и сроки хранения, и только потом рассматривается масштабирование.

Восстановление после сбоя: память должна вернуться вместе с идентичностью

Как принять резервное копирование и восстановление Agent Memory

Восстановление считается успешным только тогда, когда после сбоя совпадают не одни строки в базе. Необходимо проверить:

количество активных записей;
соответствие пользователей и организаций;
связи с проектами и задачами;
версии памяти;
состояние индекса;
очереди повторной индексации;
права доступа;
отметки времени;
статус незавершённых операций.

Если память хранится в PostgreSQL, официальная документация разделяет SQL-дампы, резервирование файловой системы и непрерывное архивирование; эти методы имеют разные ограничения и сценарии восстановления. Руководство PostgreSQL по резервному копированию и восстановлению следует использовать вместе с документацией к конкретной схеме хранения.

Для переносимого тестового восстановления подходит логический дамп. PostgreSQL указывает, что pg_dump создаёт согласованный снимок базы, а архивные форматы можно восстанавливать выборочно через pg_restore; при этом роли и другие кластерные объекты требуют отдельного внимания. См. официальную документацию pg_dump и pg_restore.

Практическая последовательность выглядит так:

отключить автоматическую запись в тестовом окружении;
зафиксировать контрольный набор пользователей, проектов и записей;
сохранить дамп основной базы;
отдельно сохранить конфигурацию индекса и секреты доступа безопасным способом;
остановить сервис памяти;
восстановить базу в чистое окружение;
пересоздать или восстановить поисковый индекс;
выполнить сверку идентификаторов;
проверить права доступа чужого и собственного пользователя;
выполнить контрольные запросы;
открыть запись только после подтверждения целостности.

Опыт эксплуатации: восстановленная база без восстановленного индекса не является полностью восстановленной памятью. Если приложение молча перестраивает индекс в фоне, часть запросов может временно получать неполные результаты, а команда ошибочно примет это за потерю данных.

Минимальный сценарий отказа включает три разных события: недоступность хранилища, внезапное завершение процесса во время записи и развёртывание в чистой среде. Для каждого сценария должны быть определены допустимая потеря операций, порядок повторной обработки и способ обнаружения дубликатов.

Постоянный контроль после запуска

После первой недели проверка превращается в регулярную эксплуатационную процедуру. Минимальный набор метрик включает:

ошибки записи;
обращения к памяти без разрешённого субъекта;
долю нерелевантных воспоминаний в выборочной проверке;
количество конфликтов;
число удалений и повторных появлений;
рост хранилища;
время ответа поиска;
количество ручных исправлений;
успешность тестовых восстановлений.

Нельзя ограничиваться средней точностью ответов. Среднее значение скрывает редкие, но критичные события: чужая память в ответе, возвращённый секрет или использование давно отменённого правила. Поэтому выборка должна включать негативные сценарии, а не только обычные пользовательские запросы.

Итоговый чек-лист перед открытием автоматической записи

[ ] Определены данные, которые можно записывать без подтверждения.
[ ] Определены данные, требующие подтверждения пользователя.
[ ] Определены данные, которые запрещено отправлять в память.
[ ] Каждая запись содержит источник, субъекта, время и область действия.
[ ] Выполнен тест с ошибочным утверждением модели.
[ ] Проверена изоляция двух пользователей и двух проектов.
[ ] Выполнено исправление, удаление и повторный поиск.
[ ] Проверены кэш, индекс, очереди и журналы после удаления.
[ ] Заданы правила конфликта между старой и новой записью.
[ ] Установлены сроки хранения для разных типов памяти.
[ ] Пользовательский запрос на удаление проверен через интерфейс и API.
[ ] Выполнено восстановление в чистой среде.
[ ] После восстановления проверены идентичность, права и состояние задач.
[ ] Есть метрики ошибочной записи, нерелевантной выдачи и ручных исправлений.
[ ] Назначены условия очистки, выборочного аудита и пересмотра архитектуры.

Оценку можно проводить по четырём этапам жизненного цикла:

Этап	Главный вопрос	Минимальный результат
До запуска	Что разрешено сохранять и кто имеет доступ	Утверждённая политика записи и матрица прав
Первый день	Можно ли объяснить происхождение и удалить ошибку	Рабочий контур исправления и удаления
Первая неделя	Что происходит при изменении фактов и сбое	Проверенные конфликты, сроки хранения и восстановление
Постоянная эксплуатация	Не ухудшаются ли качество и стоимость	Метрики, выборочный аудит и условия пересмотра

Текущая схема против изолированного Mac-окружения для тестов

Запуск проверок на единственной рабочей машине часто создаёт несколько ограничений: окружение занято текущими задачами, восстановление приходится выполнять вручную, фоновые процессы мешают воспроизводимости, а повторный тест после изменения конфигурации требует заново собирать зависимости.

Для коротких испытаний разумнее отделить production-данные от временного окружения и зафиксировать сценарии в виде повторяемых прогонов. Если команде нужен удалённый Mac для проверки локального агента, сборки или сценария восстановления, можно изучить планирование облачной тестовой среды Mac. Перед началом удалённой проверки полезно также сверить требования к доступу, сетевому подключению и передаче файлов в руководстве по поддержке Mac-сред.

Аренда у Zilmac не заменяет проектирование Memory Framework и не решает проблемы прав доступа сама по себе, но может быть удобнее для временного изолированного стенда: не требуется надолго закреплять физическую машину за экспериментом, проще отделить тестовые данные от основной инфраструктуры, а повторный прогон можно проводить в отдельной среде. Для постоянной тяжёлой нагрузки, требований к физическим интерфейсам или длительной эксплуатации одной неизменной конфигурации собственная инфраструктура может оказаться рациональнее.

До передачи тестовых данных внешней среде следует проверить внутренние требования к конфиденциальности, сроки хранения, порядок удаления и перечень сотрудников с доступом к стенду. Если окружение используется несколькими подразделениями, правила доступа и ответственности необходимо зафиксировать в отдельном регламенте, а не оставлять только в настройках проекта. При привлечении временного внешнего окружения также стоит заранее согласовать требования к уровню доступа, журналированию и обработке данных, не передавая в тестовый контур реальные секреты и необезличенные пользовательские данные.

Перед коммерческим запуском следует сначала подготовить обезличенный набор данных и выполнить два обязательных сценария — ошибочную запись с полным удалением и восстановление после прерывания процесса. Только после этого тестовая среда действительно помогает принять решение, а не маскирует незакрытые риски долговременной памяти.