TL;DR
Исследователи проследили, как агент, который хранит знания в файлах (скрипты и текстовые заметки), живёт при смене задачи. Старые скрипты почти не вызываются повторно: в них зашиты числа текущей задачи, и на следующей они ломаются. Агент вместо этого пишет новый скрипт заново, оставляет общие правила, а детали прежней задачи выбрасывает. Из скриптов, написанных до смены задачи, 74% он бросил и не использовал больше.
Самая дорогая ошибка: значение, которое верно в одной задаче и неверно в следующей. Агент записал «кнопка влево сближает маркеры», на уровне 5 всё поменялось, а он по инерции сделал по-старому. Журнал действий эту ошибку не выдаёт: на первом уровне она была правдой. Заметки агента только пухнут. Поправка дописывается под ложной фразой, и обе остаются в файле.
Фикс, который агент нашёл сам: превратить константу в параметр, который надо задавать заново для каждой задачи. Вместо DIRECTION = -1 в коде стоит solve(direction, ...). Агент вынужден явно подставить значение или перебрать оба варианта. Вторая опора — сырой журнал всех действий, который агент не редактирует. По нему разрешаются противоречия в заметках.
Схема метода
ШАГ 1: Значение зависит от уровня/клиента/периода?
→ не константа в коде, а аргумент функции/скрипта
ШАГ 2: Новая задача → значение передаётся заново
(или проверяются оба варианта за пару действий)
ШАГ 3: Заметки — датированный журнал убеждений, а не «истина»
→ спорное сверяется с сырым журналом, который не редактируется
ШАГ 4: Скрипты можно смело выбрасывать:
раз журнал цел, знание восстановимо
Всё это можно закрепить в одной инструкции агенту. Шаги не требуют отдельных запросов.
Пример применения
Задача: Вы руководите небольшим селлером на Wildberries. Агент (Claude Code) каждый месяц собирает отчёт по юнит-экономике. В марте он написал скрипт со строкой COMMISSION = 0.17 и колонками из мартовской выгрузки. В апреле у категории другая комиссия, а в выгрузке сдвинулись столбцы. Скрипт молча считает по старым числам, и маржа в отчёте красивая, но неверная.
Промпт (в CLAUDE.md или в начале сессии):
Правила для скриптов, которые ты пишешь в этом проекте:
1. Любое значение, которое может отличаться между месяцами, категориями
или кабинетами (комиссия WB, ставка НДС, логистика, названия и порядок
колонок, диапазон дат), не пиши константой в коде.
Делай аргументом: def calc_margin(commission, vat, columns, ...).
Значения передавай при каждом запуске явно.
2. Перед запуском на новом месяце выпиши список таких параметров
и откуда ты взял каждое значение (файл, строка выгрузки, моё сообщение).
Если источника нет — спроси меня, не подставляй значение с прошлого месяца.
3. Файл notes.md — журнал, а не истина. Новые факты дописывай с датой.
Если факт опровергнут, пометь старую строку «ОТОЗВАНО (дата, причина)»,
не оставляй её без пометки.
4. Если заметки противоречат друг другу, не выбирай по памяти.
Сверься с исходной выгрузкой (raw/*.csv): она всегда главнее заметок.
Исходные файлы не редактируй.
Результат: Агент вместо скрипта с зашитыми числами напишет функцию с параметрами. Перед апрельским расчётом он покажет список параметров с источниками и спросит про те, где источника нет. В заметках появятся датированные записи и пометки «ОТОЗВАНО». Расхождения он будет проверять по исходной выгрузке.
Почему это работает
Слабость. Агент пишет скрипт под текущую задачу, и числа этой задачи оказываются прямо в коде. В статье 229 из 273 используемых повторно скриптов вшивали пять и более чисел. На следующей задаче такой скрипт либо ломается сразу, либо тихо врёт. Хуже всего второй случай: проверка по журналу первой задачи ничего не покажет, там значение было верным. Переписывание «в лоб» эту ошибку не лечит: новая версия просто заново перепечатывает старую константу.
Сильная сторона. Модель хорошо пишет код с аргументами и умеет быстро перебрать два варианта. Параметр не даёт ей молча унаследовать значение: оно должно прийти снаружи. В игре m0r0 два запуска сделали направление параметром. На новом уровне они проверили оба значения и справились за несколько действий. Третий запуск хранил значение в словаре, правил его и ошибся снова.
Рычаги. - Список параметров, которые надо «задавать заново» (комиссия, период, клиент), задаёт, что считается меняющимся. Чем он шире, тем меньше тихих ошибок. - Строгость пункта «нет источника — спроси» определяет, будет ли агент догадываться или останавливаться. - Пометка «ОТОЗВАНО» лечит то, что в статье агент не делал: ложные строки в заметках оставались без отметки. - Неизменяемые исходные данные дают арбитра. Агент может безбоязненно выбрасывать скрипты, потому что знание можно вывести заново.
Шаблон промпта
Важно: в статье готового промпта нет. Системный промпт в эксперименте описывал только интерфейс игры. Шаблон ниже — перенос находки в инструкцию, авторы его не проверяли.
Правила работы со скриптами и заметками в проекте {проект}:
1. Параметры, а не константы.
Всё, что может отличаться между {единицы_смены: уровни/клиенты/месяцы/кабинеты},
— аргумент функции, не значение в коде.
К таким значениям относятся: {список_меняющихся_значений}.
2. Перед запуском на новой {единице_смены} выпиши все параметры
и источник каждого. Нет источника — спроси, не переноси старое значение.
3. Если не уверен в значении — проверь оба варианта на малом примере,
прежде чем делать полный прогон.
4. {файл_заметок} — датированный журнал убеждений.
Опровергнутые строки помечай «ОТОЗВАНО ({дата}, {причина})», не оставляй без отметки.
5. Источник истины — {исходные_данные}. Их не редактируй.
Заметки противоречат друг другу — решай по исходным данным.
6. Скрипт можно выбросить и написать заново, если исходные данные целы.
Что подставлять. {единица_смены} — что у вас меняется от задачи к задаче. {список_меняющихся_значений} — конкретные числа и названия из вашей работы. {исходные_данные} — папка с сырыми файлами, которую агент только читает.
Ограничения
⚠️ Одна среда, не бизнес: Все выводы получены на играх ARC-AGI-3, где правила скрыты и меняются между уровнями. Перенос на отчёты, код и автоматизации — наша экстраполяция.
⚠️ Фикс подтверждён на узком материале: Работу параметра наглядно показала одна игра (m0r0) в трёх запусках. Это наблюдение, а не контролируемое сравнение.
⚠️ Запуски несопоставимы: Семь запусков различались моделью, промптом и режимом. Авторы сами не ранжируют их, не приписывают эффект одному фактору и не дают доверительных интервалов.
⚠️ Параметр не гарантирует правильное значение: В одном запуске Qwen параметр, наоборот, «закрыли» обратно в таблицу констант. Если агент подставит старое значение вручную, защита не сработает.
⚠️ Часть выводов требует харнесса: Журнал всех действий создавал сам каркас агента. В обычном чате или в Claude Code его придётся вести отдельно, например сохранять исходные файлы и сессии.
⚠️ Пометки «ОТОЗВАНО» не проверялись: В статье агент заметки не чистил. Что пометки помогут, это логичное предположение, а не результат.
Как исследовали
Команда сделала агента, у которого вся «память» — папка с файлами. Он пишет скрипты на Python и текстовые заметки, а каркас складывает каждое действие и ответ игры в logs.txt, куда агент только заглядывает. Агента пустили в ARC-AGI-3: интерактивные игры без инструкций, где правила нужно вычислять самому. Каждый уровень — по сути новая задача, и граница между уровнями никак не объявляется.
Прогнали семь запусков на трёх моделях двух семейств (Opus 4.7, Opus 5 и локальная Qwen). Они прошли от 34 до 183 из 183 уровней. Потом авторы прочитали все файлы: 4 786 скриптов на 689 границах. Каждый скрипт привязали к уровню, на котором он родился, и посмотрели, что с ним случилось дальше: вызван, скопирован, переписан или брошен.
Результаты оказались необычными. Повторное использование через вызов почти не пересекает границу: 33 из 630 ссылок. Ссылались в основном внутри одного уровня, потому что скрипты вшивали параметры уровня, например ROWS=19 и COLS=19. Переписывая скрипт, агент выбрасывал 38–74% функций и сохранял те, что кодировали правила игры. Так он сам отделял закон от частного случая. Заметки не правились вообще: поправки только дописывались. В wa30 «поправка» оказалась ошибочной, а исходная формулировка была верной. Обе версии лежали в файле в 65 строках друг от друга без пометки. Спасал лог: его нельзя переписать, и он решал спор.
Практический вывод: ошибка опасна, когда она верна в прошлой задаче. Её спасает только изменение формы хранения знания: из константы в параметр.
Адаптации и экстраполяции
🔧 Техника: добавить обязательный «паспорт значений» → заметить тихую ошибку до запуска
Это наше добавление, не из статьи.
Перед каждым запуском скрипта на новой {единице_смены}
выведи таблицу: параметр | значение | источник | чем отличается от прошлого раза.
Если «чем отличается» не заполнено — запуск не делай.
Таблица заставляет агента явно сравнить новую задачу со старой. Это то, что в статье делал только параметр.
Экстраполяция: журнал убеждений + выжимка для чата. Комбинация идеи «сырой журнал + заметки» с обычной практикой веб-чата. Это тоже не проверялось авторами.
В конце сессии сохрани raw_log.md: что я просил, что ты сделал и какие значения подставил (без правок).
Отдельно напиши summary.md — только актуальные правила, с датой.
В новой сессии читай summary.md, а при сомнении — raw_log.md.
Выжимке не верь, если она расходится с журналом.
Выжимку можно переписывать смело: исходный журнал остаётся, и потери восстановимы.
Ресурсы
- Tracing the Thoughts of a Coding Agent Playing ARC-AGI-3: Lessons for Continual Learning — Chen Wu, Josh Passenger, Yin Song (AWS), NeurIPS 2026, Workshop: Continual Learning in the Era of Foundation Models and Embodied Agents
- ARC-AGI-3 — ARC Prize Foundation (интерактивный бенчмарк), метрика RHAE
- PRO-LONG — Fox et al., 2026 (дизайн агента с программируемой памятью, на котором построена работа)
- Strands Agents — каркас для запуска агентного цикла ReAct
- CL-Bench — Asawa et al., 2026 (полный контекст часто бьёт специализированные системы памяти)