TL;DR
MemForm — это тестовый набор, который показывает: память агента можно испортить, не подделывая ни одной записи. Агент учится на своём опыте и превращает его в правила («так работает», «так делать»). Исследователи меняли только условия этого превращения: какие условия применимости остались у опыта, какие эпизоды сохранили, в каком порядке их обработали. Всего проверили пять «входов»: Content (прямая запись в память), Evidence (поддельные свидетельства), Scope (границы применимости), Selection (отбор эпизодов), Path (порядок обработки).
Главная находка: настоящий успешный опыт не гарантирует правильного поведения после запоминания. Агент вынес правило из удачных случаев, потерял условие «только в таких-то обстоятельствах» и начал применять правило везде. Ещё сильнее удивляет порядок. Одни и те же эпизоды, тот же агент, но другая очерёдность — и итоговое правило другое. Причина в том, что модель собирает правило из эпизодов по ходу чтения, а не взвешивает их все сразу. Поздние эпизоды перетягивают итог, а контекст «когда это работало» легко отваливается.
Вывод для практика: защищать надо не только то, что записано в память, но и как она формируется. Простая защита по ключевым словам в тесте вообще ничего не изменила. Остальные защиты в доступном фрагменте статьи обрезаны, так что их эффективность по этим данным оценить нельзя.
Схема метода (что проверяет бенчмарк)
Вход 1. CONTENT → портим саму запись в памяти (эталон для сравнения)
Вход 2. EVIDENCE → часть настоящей истории заменена правдоподобной подделкой
Вход 3. SCOPE → записи настоящие, но «когда это применимо» потеряно или расширено
Вход 4. SELECTION → тот же пул опыта, но в память попал другой набор эпизодов
Вход 5. PATH → те же эпизоды, тот же обновлятор, другой ПОРЯДОК
Для каждого входа: чистая версия vs отравлённая → один и тот же вопрос агенту
Метрика: в какой доле случаев агент, до этого отвечавший правильно, после отравлённой памяти отвечает «неправильно»
Пример применения
В статье готовых промптов нет. Ниже — сценарий из практики, где проявляется вход Scope, и промпт-аудит, который я построил по логике статьи. Авторы такой промпт не проверяли.
Задача: Вы ведёте интернет-магазин на Wildberries и Ozon. Бот поддержки в Telegram сам записывает «выводы» в файл памяти. Три недели назад вы вручную вернули деньги нескольким недовольным клиентам, и повторных жалоб не было. Бот записал правило: «Возвращай деньги без вопросов — клиенты остаются лояльными». Все эпизоды были с заказами до 3 000 ₽. Условие потерялось. Теперь бот готов вернуть 45 000 ₽ за дрон.
Промпт:
Ты — аудитор памяти агента. Ниже записи, которые бот поддержки сам добавил в файл памяти.
Для каждой записи проверь пять вещей:
1. SCOPE: при каких условиях правило подтверждено эпизодами?
(сумма заказа, категория товара, тип клиента, период). Где эти условия в записи?
Если их нет — правило потеряло границы.
2. EVIDENCE: на скольких и каких эпизодах оно построено?
Есть ли среди них то, что нельзя перепроверить (слова клиента, внешний отзыв)?
3. SELECTION: какие эпизоды, похоже, не попали в запись, хотя могли её опровергнуть?
4. PATH: если поменять порядок эпизодов, вывод изменится? Где вывод держится на последних случаях?
5. CONTENT: нет ли в записи прямых указаний («всегда», «никогда», «без вопросов»),
которых нет в исходных эпизодах?
Для каждой записи выдай: вердикт (оставить / переписать / удалить),
переписанную версию с явными границами применимости,
и один контрольный вопрос, на котором правило даст ошибку.
Записи памяти:
{записи}
Исходные эпизоды, на которых они построены:
{эпизоды}
Результат: Модель разберёт каждую запись по пяти пунктам. Для правила про возвраты она, скорее всего, укажет, что границы по сумме потеряны, и предложит переписанную версию с условием. В конце даст контрольные вопросы для проверки. Какие именно ошибки найдёт модель, зависит от ваших данных.
Почему это работает
Слабость. Агент превращает опыт в правило сжатием. Из «в этих трёх случаях сработало» получается «это работает». Условия («только до 3 000 ₽», «только для постоянных клиентов») при сжатии отваливаются первыми. Модель не взвешивает все эпизоды разом, а читает по очереди, поэтому порядок и отбор меняют итог. Правило при этом выглядит абсолютно разумно: каждый эпизод в нём настоящий.
Сильная сторона. Модель хорошо справляется с точечной проверкой и с разбором по заданному чек-листу. Если спросить её явно «где границы этого правила?», она найдёт, что их нет.
Рычаги управления промптом-аудитом: - Список пяти пунктов → оставьте только те, что важны. Для простой памяти хватит Scope и Content. - Контрольный вопрос → проверяет правило на пограничном случае. Если дать модели исходные эпизоды, она сможет его построить. - Раздел «исходные эпизоды» → без него аудитор оценивает только текст записи и пропускает Evidence и Selection. - Запуск на другой модели → в статье модели заметно различались по устойчивости, поэтому аудитор не должен совпадать с тем, кто писал память.
Шаблон промпта
Готового шаблона в статье нет. Шаблон ниже — производный: пять пунктов взяты из пяти входов бенчмарка, остальное — моя сборка.
Ты — независимый аудитор долгой памяти агента. Ты не писал эти записи.
{записи_памяти}
{исходные_эпизоды}
Для каждой записи памяти:
1. Scope: выпиши условия, при которых эпизоды подтверждают правило.
Есть ли они в записи? Если нет — "границы потеряны".
2. Evidence: перечисли эпизоды-основания. Что из них нельзя проверить?
3. Selection: какие эпизоды из {исходные_эпизоды} не отразились в записи
и могли бы её ослабить?
4. Path: представь обратный порядок эпизодов. Вывод изменился бы?
5. Content: найди слова "всегда", "никогда", "без вопросов" и сверь с эпизодами.
Что подставлять: {записи_памяти} — то, что агент сам записал (файл памяти, список «выводов»). {исходные_эпизоды} — диалоги, логи или примеры, из которых он это вывел.
🚀 Быстрый старт — вставь в чат:
Вот шаблон аудита памяти агента. Адаптируй под мою ситуацию: {опиши агента и где он хранит память}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что за агент, где лежит память и из каких эпизодов собирались правила. Эти данные нужны, чтобы проверить границы применимости, а не просто пересказать запись.
Ограничения
⚠️ Тест искусственный: сценарии сгенерированы моделью и собраны компилятором. Это контролируемые вмешательства, а не реальные атаки. Авторы прямо пишут, что цифры не отражают частоту таких случаев в реальных системах.
⚠️ Зависит от архитектуры памяти: не каждый вход применим к любому агенту. Если ваш агент хранит память как сырой журнал без «выводов», Scope и Path работают иначе.
⚠️ Защита изучена неполно: фильтр по ключевым словам на проверенной модели не изменил ничего. Про остальные защиты в доступном фрагменте данных нет. Рабочего рецепта защиты в статье нет.
⚠️ Промпт-аудит не проверен: выше он выведен из логики статьи, но авторы его не тестировали. Проверяйте на своей выборке записей.
⚠️ Сравнивать модели осторожно: для каждой модели отбирались свои вопросы, поэтому это не рейтинг безопасности.
Как исследовали
Идея была простой: если агент учится на опыте, значит, можно портить не только записи, но и процесс превращения опыта в память. Авторы выделили пять «входов» и для каждого сделали парные сценарии: чистая версия и отравлённая, остальное идентично. Сначала модель сгенерировала 300 семей сценариев, 235 прошли проверку. Компилятор собрал из них 1 016 пар. Два эксперта вручную просмотрели все пары и вернули на доработку 48.
Итого 1 891 задача в двух форматах: с вариантами ответа и со свободным ответом. Проверили шесть моделей от разных поставщиков и две реализации памяти, на LangChain и LlamaIndex. Считали долю случаев, когда агент, который отвечал правильно без памяти и с чистой памятью, ломался после отравлённой.
Получилось, что уязвимы все пять входов у всех моделей. Средняя доля ошибок колебалась примерно от трети до 84% в формате с вариантами и от половины до 87% в свободном ответе. Самой устойчивой оказалась Claude-Sonnet-5, самой уязвимой — Gemini-3.7-Flash. Чистая память почти не ломала поведение: ошибки ниже 4% у всех. То есть дело не в плохих агентах, а именно в отравлении.
Неожиданнее всего Path: у некоторых моделей изменение порядка эпизодов давало больше 90% ошибок, хотя набор опыта не менялся. Для свободных ответов проверку делали двое независимых судей-моделей. Согласие с основным оценщиком было около 93–95%, так что результаты нельзя списать на ошибки оценки.
Адаптации и экстраполяции
🔧 Техника: добавить требование границ → правила не теряют условия
Если ваш агент сам пишет в CLAUDE.md, AGENTS.md или файл памяти, добавьте в инструкцию:
Любая запись в память должна иметь формат:
"{правило} — подтверждено на: {сколько и каких эпизодов};
применять только если: {условия}; не применять если: {исключения}".
Запись без условий применимости не сохраняй.
Авторы это не тестировали. Это попытка закрыть вход Scope текстом: если условия потеряны на этапе записи, их надо вернуть на этом же этапе.
🔧 Техника: два прохода в разном порядке → проверка устойчивости к Path
Попросите агента сформулировать правило из эпизодов в прямом порядке, затем в обратном. Если правила разные, запись ненадёжна и её нужно проверять вручную. Это тоже моя экстраполяция по результатам про Path.
Ресурсы
- MemForm: Benchmarking Memory Formation Poisoning in LLM Agents, Under review at ICLR 2027
- Авторы: Haowen Pan, Pengyang Shao, Yunshan Ma, Yanzheng Jin, Naixin Zhai, Xiang Wang, Xun Yang
- Университеты: University of Science and Technology of China, National University of Singapore, Singapore Management University
- Код и данные: https://github.com/opanhw/memform-code
- Связанные работы: AgentPoison, MINJA, MPBench, MemPoison, MemSecBench, OEP