TL;DR
REM — схема памяти для агента, который чинит код. После каждой задачи весь длинный ход работы сворачивается в короткий документ из четырёх фаз: где искал (localize), что понял (understand), как починил (fix), чем проверил (verify). Такой документ кладут агенту в контекст в начале новой похожей задачи. Подробные правки из старого прогона показывают только когда агент застрял (провалил проверку) и убирают сразу после одного показа.
Главная находка: форма хранения опыта важнее его релевантности. Если дать агенту нужную прошлую задачу как обычное саммари или как сырой лог, решённых задач не становится больше. Это верно даже тогда, когда нужный опыт выбрал сам исследователь вручную. Лог на сотни тысяч символов агент читает вполсилы, а в обычном саммари «размыты» имена файлов и функций. Тот же опыт в виде компактного документа по фазам агент использует почти полностью, и задач решается чуть больше при меньших затратах.
Суть метода в трёх решениях. Что хранить: структурированный документ вместо лога и вместо россыпи фактов. Когда подсказывать: кратко в начале, подробно только при провале. Что забывать: подробности убираем после первого показа, чтобы они не тянули агента к чужому решению.
Схема метода
ЗАПИСЬ (после каждой завершённой задачи):
Лог работы агента → один вызов LLM → поля (файлы, функции, причина, способ починки, тесты)
→ документ из 4 фаз: localize / understand / fix / verify (~270 токенов)
ЧТЕНИЕ (новая задача):
Поиск 5 ближайших документов → LLM выбирает один → кладём в начало контекста
(документ остаётся в контексте до конца работы)
ВНУТРИ ЦИКЛА:
Агент провалил проверку? → да → подмешиваем "запись реализации"
(правки и проверки из старого прогона, до 12K символов) → один показ → удаляем
Шаги записи и чтения — отдельные вызовы LLM. Третий шаг (сигнал «застрял») встроен в цикл работы агента и требует кода.
Пример применения
Задача: Вы ведёте магазин на Ozon и Wildberries, а интеграцию остатков поддерживаете с Claude Code. Месяц назад агент полтора часа искал, почему остатки на WB обнуляются после ночной синхронизации. Нашёл: неверная обработка пустого ответа API. Теперь похожий баг случился с Ozon. Нужно сохранить опыт так, чтобы агент им воспользовался.
Промпт (в конце старой сессии):
Сессия по багу закончена. Сверни её в документ для будущих агентов.
Строго четыре раздела, всего не больше 300 слов:
где искал и где оказался баг: файлы, функции, по каким признакам нашёл
первопричина одной-двумя фразами
как чинили: общий приём, не построчный diff
какие тесты и команды подтвердили починку
Тупиковые ветки не включай. Имена файлов и функций пиши точно.
Результат: Модель выдаст короткий документ из четырёх блоков с точными путями к файлам и именами функций. Сохраните его в репозитории, например в notes/sync-stock-bug.md. Перед новой похожей задачей скажите агенту прочитать эту заметку. Она занимает пару абзацев и не вытесняет рассуждения агента, как это сделал бы лог на десятки тысяч токенов.
Почему это работает
Слабость: агент использует только часть того, что ему дали. Сырой лог — это в основном тупики и пробы, а нужные имена файлов в нём тонут. Обычное саммари короче, но и оно размывает идентификаторы и связи «где искал → что понял → как починил». Лишний контекст ещё и вытесняет собственные рассуждения агента. Поэтому «просто дать релевантный опыт» не помогает.
Сильная сторона: модель хорошо следует структуре. Когда опыт разложен по знакомым фазам диагностики (найти, понять, починить, проверить), она легко сопоставляет его со своей задачей. В исследовании агент ссылался на идентификаторы из фазового документа заметно чаще, чем из саммари и особенно из лога. Организация, а не объём, определяет, прочитан ли документ.
Как метод это использует: каждое решение убирает свой вид вреда. Короткий документ оставляет структуру решения и отбрасывает поиск. Подробности в начале только отвлекают, поэтому их дают в момент провала. Через один показ их убирают, иначе они тянут каждый следующий ход к чужому решению.
Рычаги управления: - Поля документа (файлы, функции, причина, способ, тесты) → меняйте под свою область: для SQL-ремонта или разбора инцидентов фазы те же, поля другие. - Размер документа → 200–500 токенов; больше — теряется эффект «читается целиком». - Условие «застрял» → в исследовании это первый провал проверки. Можно заменить на «два провала подряд» или «N шагов без прогресса». - Удаление после показа → в исследовании это самый стабильный выигрыш среди трёх решений.
Шаблон промпта
Точный промпт авторов в доступной части текста не приведён. Состав полей и четыре фазы описаны, ниже шаблон по этому описанию.
Вот ход работы над завершённой задачей: {лог_или_описание_сессии}
Сверни его в документ для будущих агентов. Четыре раздела, не больше {число_слов} слов:
Где искали. Файлы: {файлы}. Функции: {функции}. По каким признакам нашли место проблемы.
Первопричина — одной-двумя фразами.
Общий приём починки (не построчный diff).
Какие тесты и команды {тесты} подтвердили результат.
Правила: тупиковые ветки не включай. Имена файлов и функций — точно, как в коде.
Не пересказывай ход работы — только структуру решения.
Подставьте:
- {лог_или_описание_сессии} — выжимка сессии или сама сессия;
- {число_слов} — 200–300 слов;
- поля в
🚀 Быстрый старт — вставь в чат:
Вот шаблон фазового документа памяти (REM). Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, из каких этапов состоит ваша работа и какие данные идентифицируют решение (файлы, таблицы, источники, команды). Это нужно, чтобы поля документа совпали с вашей областью. Тогда документ сохранит то, по чему решение находят потом.
Ограничения
⚠️ Эффект небольшой и статистически неуверенный: прирост решённых задач — около трёх пунктов. Авторы сами говорят, что в паре сравнений на 99 задачах он не достигает значимости. Надёжнее всего выиграли поиск нужного опыта и стоимость запуска.
⚠️ Сильным моделям память вредит: на самых сильных агентах любая память снижала долю решённых задач, у одной из топовых моделей — заметно. Помогает она средним по возможностям агентам. Если модель и так справляется, не подсовывайте ей опыт по умолчанию.
⚠️ Подробная запись почти не нужна: без второго уровня (только документ) результат почти тот же. Главный выигрыш даёт форма хранения. Ворота «застрял» и удаление в основном не дают подробностям навредить.
⚠️ Полная версия требует кода: сигнал «провалил проверку», подмена контекста посреди работы, векторный поиск и переранжирование — это инженерия. В чате и в Claude Code вы повторите только форму документа и ручное правило «читай подробности, когда застрял».
⚠️ Проверено на узкой области: исправление багов в репозиториях, один бенчмарк и фактически одна основная модель. Для текстов, продаж или аналитики перенос — ваша догадка.
Как исследовали
Команда Amazon и Йеля взяла 99 реальных багов из SWE-ContextBench Lite. К ним прилагался пул из 300 уже решённых траекторий и разметка: какая траектория относится к какой задаче. Один и тот же агент (Claude Sonnet 4.5) решал все задачи в разных режимах: без памяти, с саммари, с сырой траекторией, с фазовым документом. Часть режимов гоняли с «оракулом», то есть агенту вручную давали правильную траекторию. Так отделили качество поиска от эффекта самого опыта.
Результат удивил. Саммари и сырой лог не добавили решённых задач, даже когда лежал нужный опыт. Фазовый документ из той же траектории добавил. REM нашёл нужную траекторию в 68,7% случаев против 55,6% у лучшей из готовых систем памяти (Mem0, LangMem и др.), решил 27,6% задач против 24,9% без памяти и потратил на 17% меньше токенов. В каждом из трёх повторов REM был не хуже, но статистической значимости на одном сравнении нет.
Затем измерили, что агент реально берёт из подсказки: какие имена файлов и функций из неё он потом упоминает. Фазовый документ использовался на ~69%, саммари на 46–53%, сырая траектория на ~27%. Документ в 270 токенов читается лучше саммари в 390. Значит, роль играет организация, а не объём.
Отдельно разобрали второй уровень. Подсказка «по сигналу застрял» лучше, чем «сразу всё», а удаление после показа лучше, чем оставить. Пять моделей показали разное: слабым и средним память помогала, сильным вредила.
Адаптации и экстраполяции
🔧 Техника: двухуровневые заметки → короткое «всегда», подробное «по требованию». Это не метод авторов, а перенос принципа в инструкции агента (CLAUDE.md или AGENTS.md):
Перед задачей прочитай notes/{тема}.md (короткий фазовый документ).
Файл notes/{тема}.detail.md не открывай, пока тесты не упали дважды.
Если открыл — используй как подсказку, затем не опирайся на него в следующих шагах.
Принцип тот же: краткое — в начале, подробное — только при реальной трудности. Нигде не проверено, что текстовое «забудь» работает как настоящее удаление из контекста. Для реального удаления нужен код или новая сессия.
🔧 Техника: не давать память сильной модели → проверить A/B. Прогоните одну типовую задачу с заметкой и без неё на самой мощной доступной модели. Если качество не растёт, не раздувайте контекст.
Ресурсы
- REM: What to Store, When to Recall, What to Forget in Experience Memory for Coding Agents — Xinyi Lisa Chen (Yale University), Pedro Herrero-Vidal, Xiaohan Chen, Xiaojing Yu, Cris Liu, Bingqing Song, Bin Xu, Suleiman A. Khan, You-Lin Chen (Amazon). NeurIPS 2026 Workshop: Continual Learning for Enterprise AI Agents.
- Бенчмарк: SWE-ContextBench Lite (Zhu et al., 2026).
- Сравнивали с системами памяти: Mem0, LangMem, Supermemory, OpenViking.
- Фреймворк агента: Strands; модели семейства Claude.