TL;DR
Исследование показывает, что агент с памятью, который пишет себе «уроки» из каждого запуска, может записать в память чистое невезение. Модель видит провал и превращает его в совет на будущее. Следующая сессия читает этот совет и меняет решение. Защита простая и лежит в тексте инструкции: заставить автора урока сначала оценить само решение, а не результат, и разрешить ему написать «менять ничего не нужно».
Боль знакома тем, кто настраивал самообучающихся агентов. Есть два взаимозаменяемых инструмента: надёжный (сбои в 10% запусков) и ненадёжный (сбои в 40%). Надёжный один раз упал по случайной причине. Агент пишет урок: «этот способ ломается, используй другой». Следующая сессия видит в логе, что надёжный инструмент лучше. Но урок звучит убедительно, и она в части случаев выбирает худший. Без урока такого выбора практически нет. Модель оценивает решение по исходу, а не по тому, что было известно в момент решения. Урок закрепляет эту ошибку и делает её долгоживущей.
Метод в двух вариантах. Первый: в инструкцию записи уроков добавляют пункт из трёх предложений. «Оцени, было ли решение обоснованным при тех данных, что были до результата. Один исход ничего не доказывает. Советуй другое действие, только если решение было необоснованным». Второй: одна и та же инструкция для успеха и провала, плюс фраза «если ничего менять не нужно — так и скажи». Оба варианта сильно снижают ложные выборы, но не устраняют их полностью.
Схема метода
БЕЗ ЗАЩИТЫ (так ломается):
Запуск → исход (случайный провал) → инструкция "сделай вывод из провала"
→ урок "не используй X" → следующая сессия выбирает худший вариант
С ЗАЩИТОЙ (вариант 1, пункт про оценку решения):
ШАГ 1: Автор урока оценивает решение по данным ДО исхода → вердикт "обосновано / нет"
ШАГ 2: Один исход ≠ доказательство → совет менять действие только при "необоснованно"
С ЗАЩИТОЙ (вариант 2, нейтральная инструкция):
ШАГ 1: Одна инструкция для успеха И провала (без разной "маршрутизации")
ШАГ 2: Явная опция "ничего менять не нужно" → урок может быть пустым
ДОПОЛНИТЕЛЬНО: в лог/контекст читателя — явная фраза, что сбои случайны и независимы
Всё делается в одном промпте-инструкции. Отдельные запросы не нужны.
Пример применения
Задача: Вы ведёте интернет-магазин на Tilda и настроили агента (Claude Code или сценарий в n8n). Он каждую ночь выгружает заказы в Google Таблицу. Есть два способа. API-выгрузка: за последние 300 запусков успешна в 92% случаев. Скрипт на Google Apps Script: успешен в 60%. Агент после каждого запуска дописывает «уроки» в файл LESSONS.md и читает его перед следующим запуском. Вчера API-выгрузка один раз упала с ошибкой «таймаут, повторите позже». Без защиты агент запишет «API нестабилен, используй скрипт», и через неделю половина выгрузок будет идти худшим путём.
Промпт (фрагмент инструкции для записи уроков):
Ты — эксперт по запуску операционных задач. Тебе дан протокол одного запуска.
Извлеки из него до 3 пунктов памяти для будущих запусков: заголовок, краткое описание, содержание.
Перед тем как писать:
- Оцени, было ли решение агента обоснованным, исходя только из того, что было известно ДО исхода.
- Один исход сам по себе не доказывает, что решение было верным или неверным.
- Рекомендуй другое действие, только если решение было необоснованным при тех данных.
Если ничего о том, как нужно выполнять задачу, менять не требуется, так и скажи.
Контекст: ночная выгрузка заказов магазина в Google Таблицу.
Способы: API-выгрузка и скрипт Apps Script. По журналу за 300 запусков
API успешен в 92% запусков, скрипт — в 60%. Стоят они одинаково.
Сбои любого способа — независимые разовые события, прошлый запуск не влияет на следующий.
Результат: Автор урока сначала напишет оценку решения: выбор API был обоснован журналом. Затем сообщит, что один таймаут ничего не меняет. В памяти окажется запись «менять способ не нужно» или нейтральное замечание. Совета «используй скрипт» быть не должно. Следующая сессия увидит в LESSONS.md короткую пометку, а не рекомендацию отказаться от API.
Почему это работает
Слабость. Модель, которой сказали «сделай вывод из провала», ищет, что именно сломалось и что надо менять. Инструкция предполагает, что менять что-то нужно, и модель подчиняется. Урок звучит как опыт, хотя новой информации в нём нет: всё, что в нём есть, уже лежало в логе. Но читатель этого не знает и воспринимает урок как накопленный опыт.
Сильная сторона. Модель умеет различать «решение было разумным» и «результат оказался плохим», если её об этом явно попросить до написания вывода. Умеет она и написать «менять нечего», если такой вариант разрешён.
Как метод это использует. Пункт про оценку решения заставляет модель сначала пройти по данным «до исхода», а потом уже писать совет. Опция «ничего не менять» убирает давление «нужно что-то посоветовать». Фраза в логе «сбои независимы» помогает читателю самому отличить случайность от поломки.
Рычаги управления: - Пункт про оценку решения → добавляй, если уроки пишутся после провалов. Эффект сильный, но не полный. - Опция «ничего менять не нужно» → самый сильный из проверенных рычагов. Используй с одной общей инструкцией для успеха и провала. - Фраза «сбои независимы, это разовые события» в логе/контексте → сильно снижает эффект, но только если это правда для вашей задачи. - Вид инструкции → избегай «разных инструкций для успеха и для провала». Провал-инструкция в оригинале просила «конкретные рабочие процедуры восстановления» и подталкивала к смене действия.
Шаблон промпта
Это шаблон инструкции для агента, который пишет уроки в память (в CLAUDE.md, LESSONS.md, поле памяти кастомного GPT, узел «Запись в память» в n8n).
Ты — эксперт по {область_задачи}. Тебе дан протокол одного запуска: задача, шаги, результат.
Запиши до {число} пунктов памяти для будущих запусков: заголовок, краткое описание, содержание.
Перед тем как писать:
- Оцени, было ли решение агента обоснованным, исходя только из того, что было известно ДО исхода.
- Один исход сам по себе не доказывает, что решение было верным или неверным.
- Рекомендуй другое действие, только если решение было необоснованным при тех данных.
Если ничего о том, как нужно выполнять задачу, менять не требуется, так и скажи.
Справка по задаче: {контекст_и_статистика_по_способам}.
{фраза_про_независимость_сбоев_если_правда}
Подставляйте так:
- {область_задачи} — чем занят агент: выгрузка, рассылка, сборка отчёта.
- {число} — сколько пунктов можно писать (в оригинале до трёх).
- {контекст_и_статистика_по_способам} — что известно о надёжности вариантов: сколько запусков, какие доли успеха.
- {фраза_про_независимость_сбоев_если_правда} — например: «Сбоев-цепочек не было: каждый сбой любого способа — разовое независимое событие».
🚀 Быстрый старт — вставь в чат:
Вот шаблон инструкции для записи уроков агентом. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие способы выполнения есть у агента, как часто каждый срабатывает и можно ли считать сбои независимыми. Это нужно, чтобы автор урока мог оценить решение по данным до исхода, а не по результату.
Ограничения
⚠️ Защита не полная: с пунктом про оценку решения ложных выборов остаётся заметная доля. С нейтральной инструкцией их меньше, но они тоже есть. Авторы не показали, что любая из защит работает у каждой модели.
⚠️ Модели ведут себя по-разному: уроки переносили шанс у части моделей (Gemini, Grok, Qwen, DeepSeek, Mistral, Kimi). У моделей Claude и GPT-6.1 Sol эффект был ограничен сверху (верхняя граница ниже порога), но «ограничен» не значит «нулевой». Для Haiku и GPT-6 Luna оценка была малой, но положительной. Не считай, что твоя модель безопасна.
⚠️ Нейтральный вариант N сравнивали «пакетом»: он отличается от оригинала двумя вещами сразу (нет разной инструкции для успеха и провала плюс есть опция «ничего менять»). Какая из двух частей даёт эффект, неизвестно.
⚠️ Тесты только с «шумными» исходами: защиту проверяли на случаях, где исход не указывал на реальную поломку инструмента. Если инструмент действительно сломался, фраза «ничего менять не нужно» может навредить. Авторы это не проверяли.
⚠️ Сильно зависит от того, что написано в логе: где в логе не было сказано, что сбои независимы, эффект был в разы больше. Если у вашей задачи сбои на самом деле связаны (например, реальная авария API), фразу про независимость писать нельзя.
⚠️ Синтетика и один шаг: лабораторный мир, один выбор из двух инструментов, один урок, прочитанный один раз. Накопление уроков, поиск по памяти и реальные агенты не тестировали. Как часто в реальных агентах возникают такие ситуации, неизвестно.
⚠️ Нет доказательства вреда после «удачи»: после случайного успеха худшего инструмента эффект был ограничен сверху. Это граница, а не доказательство того, что вреда нет.
Как исследовали
Автор построил 256 «миров». Каждый мир — повторяющаяся рабочая задача (выгрузка данных, отправка счетов, пересборка поискового индекса) с двумя одинаковыми по цене инструментами. У надёжного успех 80–93%, у ненадёжного 50–70%, и журнал показывает последние 180–365 запусков. Дальше сценарий «прошлого запуска» задавали вручную: взять надёжный или ненадёжный инструмент, и закончить успехом или случайным сбоем. Одна модель писала по этому запуску «урок» инструкцией из ReasoningBank (метод памяти для агентов). Потом свежая сессия той же модели, у которой на руках полный журнал и результат прошлого запуска, выбирала, какой инструмент взять первым. Ей давали один из восьми кусочков памяти: свой урок, урок из противоположного исхода, нейтральный факт, прямую команду «бери худший» и другие.
Ключевая идея дизайна: читатель видит ровно то, что и без урока, и получает один дополнительный текст. Значит, разницу в выборе можно приписать только уроку. Протокол заморозили и отметили в блокчейне до первого запроса. 11 моделей дали около 90 тысяч ответов.
Результат неожиданный: после случайного сбоя надёжного инструмента урок, написанный из этого сбоя, увёл читателей на худший инструмент в 11,6% запусков. С нейтральным фактом это было 0,4%, с уроком из успеха тоже 0,4%. И урок вредит только вместе с сообщением о сбое: после успеха тот же урок давал 0,2%. Фраза «сбои независимы» в журнале снизила эффект с 0,181 до 0,042. Два дополнительных приёма снизили долю до 7,5% (пункт про оценку решения) и 3,1% (нейтральная инструкция). Но ни один не выполнил заранее заданное правило «вред снижен на каждой модели».
Любопытная деталь: у двух моделей слабый отклик на голую команду «бери худший» сочетался с сильным откликом на уроки. Урок с рассуждением убеждает лучше, чем приказ без причины.
Оригинал из исследования
Полные тексты инструкций ReasoningBank (RB) приведены в приложении A, которого нет во входных данных. Поэтому даю дословно только то, что есть в тексте статьи.
Добавленный пункт RBD (защита №1, три предложения):
Before writing, judge whether the agent's decision was sound given only what was known before the outcome. A single outcome is not by itself evidence that the decision was right or wrong. Recommend a different action only if the decision was unsound given that information.
Добавленная фраза нейтральной инструкции N (защита №2):
If nothing about how the task should be done needs to change, say so.
Фраза-подсказка в журнале (explicit-миры):
There have been no outages: failures of either tool are independent one-off events, and the next run has always started normally.
Контекст: RBD — это RB-инструкция плюс один пункт. N — инструкция успеха из RB, переписанная нейтрально, без разной обработки успеха и провала, плюс одна фраза.
Адаптации и экстраполяции
Это мои переносы идей статьи, авторы их не проверяли.
💡 Адаптация для ручной работы в чате: если вы просите ChatGPT или Claude «сделать выводы» после неудачной рассылки или питча, не спрашивайте «что пошло не так». Спросите: «Оцени, было ли решение разумным при данных, что у меня были до результата. Если ничего менять не нужно, скажи».
🔧 Техника: ввести порог повторений → меньше шума в памяти. В файле инструкций агента можно добавить: «Не записывай рекомендацию отказаться от способа по одному сбою. Записывай факт сбоя без рекомендации; рекомендацию — только если сбой повторился». Идея следует из логики статьи (один исход ≠ доказательство), но порог повторений не тестировался.
🔧 Техника: аудит файла уроков → поймать закрепившиеся «ложные правила». Периодически просите модель: «Пройди по LESSONS.md. Для каждого пункта: основан ли он на одном исходе? Отметь такие». Это не проверено в статье.
Ресурсы
- Название: Lessons from Luck: Do LLM-Written Lessons Carry Chance into an Agent's Next Decision?
- Автор: Kazuki Nakayashiki, Glasp.
- Упомянутые работы: ReasoningBank (Ouyang et al., 2025), Reflexion (Shinn et al., 2023), ExpeL (Zhao et al., 2023), Agent Workflow Memory (Wang et al., 2024), Dynamic Cheatsheet (Suzgun et al., 2025).
- Классика об ошибке «оценка по исходу»: Baron & Hershey (1988), Fischhoff (1975).
- Предрегистрация: депозит на Zenodo (doi:10.5281/zenodo.23253562).