TL;DR
Когда агент сам разбирает свои запуски и переписывает свою «обвязку» (harness — программа вокруг модели: что модель видит, что помнит, какие шаги делает), улучшение на разобранных задачах почти не переносится на новые. На тех пяти играх, по которым агент правил систему, качество выросло в среднем на 8,4 пункта. На двадцати новых играх, которых он не видел, рост составил только 2,8 пункта. Статистически это неотличимо от нуля. Исследование называет эту разницу «разрывом адаптации» (harness adaptation gap).
Боль знакома каждому, кто правит промпт по трём неудачным диалогам: на этих трёх стало лучше, а на остальных то лучше, то хуже. Причина простая. Правка подгоняется под те примеры, которые модель видела. Заодно она может сломать то, что раньше работало. В исследовании 15 из 27 цепочек правок улучшили результат на новых играх, а 12 ухудшили. Разброс по отдельным играм достигал +20 и −15 пунктов. Процесс при этом выглядел идеально: каждая правка опиралась на данные, каждая прошла проверки.
Метод в исследовании такой: модель строит обвязку, играет на 5 «учебных» играх, дважды переписывает себя, а потом все три версии проверяют на 20 отложенных играх. Для практика отсюда следует правило. Любая правка инструкции или агента, особенно сделанная самим агентом, должна проходить проверку на примерах, по которым её не делали. Качество и стоимость нужно смотреть вместе: удешевление часто покупается потерей качества.
Схема метода
ШАГ 0: Модель строит с нуля обвязку (код-решатель) → проверка, что запускается (до 10 починок)
ШАГ 1: Версия H0 играет на 5 учебных играх → логи, действия, оценки, стоимость
ШАГ 2: Модель правит всю обвязку по этим логам → версия H1 (без подсказок человека)
ШАГ 3: Повтор: H1 играет на тех же 5 играх → правка → версия H2
ШАГ 4: Все три версии играют на 20 отложенных играх → считаем разрыв
(рост на учебных) − (рост на отложенных)
Каждый шаг — отдельная сессия модели в среде для кода. Для читателя главное в шагах 1–4: учебный набор и отложенный набор разделены жёстко.
Пример применения
Сначала про границы. Исследование не доказывает, что «агент не умеет улучшать себя». Оно показывает, что на двух ревизиях выигрыш ненадёжен и завышен. Поэтому пример взят из зоны, где вывод работает прямо: человек или агент правит инструкцию по разбору ошибок.
Задача: Владелец магазина на Ozon держит агента, который отвечает на отзывы покупателей. Три грубых ответа на жалобы про доставку СДЭК. Он просит модель переписать системную инструкцию по этим кейсам. Нужно понять, стало ли лучше в целом, а не только на этих трёх жалобах.
Промпт:
Ты ревизор системной инструкции агента поддержки магазина на Ozon.
<Данные>
Текущая инструкция: {инструкция}
Учебные кейсы (по ним ты правишь): {5 проблемных диалогов}
Отложенные кейсы (ТЫ ИХ НЕ ВИДИШЬ ПРИ ПРАВКЕ, они нужны для проверки): {20 диалогов, хранятся у меня}
<Задача>
Шаг 1. По учебным кейсам назови причину каждой ошибки. Укажи, какой фрагмент инструкции к ней привёл.
Шаг 2. Предложи новую версию инструкции. После текста перечисли: что изменено, что оставлено нетронутым и почему.
Шаг 3. Для каждого изменения напиши, какие ТИПЫ отложенных диалогов оно может испортить (возврат, брак, оплата, вежливые отзывы).
Шаг 4. Если доказательств мало, напиши «оставить как есть». Не меняй то, что работало.
После этого я отдельно прогоню обе версии на отложенных кейсах и верну тебе результат. Дальше решим, принимать версию или откатить.
Результат: Модель выдаст разбор причин по учебным кейсам и новую версию инструкции со списком «изменено / не тронуто». Отдельным блоком будет перечень рисков для типов диалогов, которых в учебных кейсах не было. Если доказательств мало, она, скорее всего, пометит часть правок как «не менять». Вы прогоняете старую и новую версии на отложенных 20 диалогах. Принимаете только ту, что не просела там, где раньше было хорошо.
Почему это работает
Слабость: модель правит систему по тому, что видела. Каждый учебный провал выглядит как причина, которую нужно устранить. Правка закрывает именно эти провалы, а побочный эффект на остальные случаи не виден. Поэтому на учебных играх прирост сильнее, чем на новых. Плюс «правильный» процесс (разбор логов, ссылка на данные, прогон проверок) не гарантирует итогового улучшения: в исследовании все 54 ревизии прошли такие проверки, а результаты разошлись.
Сильная сторона: модель хорошо находит причины сбоев и пишет большие аккуратные правки. Её ревизии заметно меняли стратегию: 22 из 27 первых ревизий поменяли приоритеты управления, память или распределение вызовов.
Как метод обходит слабость: отложенный набор работает как независимый тест. Он показывает, что именно перенеслось. Рычаги: - Размер отложенного набора → больше примеров, меньше шума. У исследователей один и тот же финальный вариант на одних и тех же играх давал разброс около 4 пунктов между прогонами, так что мелкие сдвиги ничего не значат. - Выбор версии → не «всегда берём последнюю». Правило «взять версию с лучшим результатом на учебных» дало +4,5 вместо +2,8. Но это проверено задним числом, потом нужно проверять заново. - Стоимость рядом с качеством → у удешевлённых версий качество падало почти так же часто, как и сохранялось. - Разрешение «ничего не менять» → авторы подчёркивают, что хороший обновитель должен уметь воздержаться, когда доказательств мало.
Шаблон промпта
В статье готовых промптов нет. Ниже — перенос принципа в промпт для ревизии инструкции или файла агента (CLAUDE.md, системный промпт). Это производный шаблон, а не авторский.
Ты ревизор инструкции для агента.
<Данные>
Текущая инструкция: {инструкция}
Учебные кейсы (видны тебе): {кейсы_для_правки}
Отложенные кейсы (скрыты, нужны для проверки): {я прогоню их сам}
<Задача>
1. Для каждого учебного провала укажи причину и фрагмент инструкции, который к нему привёл.
2. Предложи новую версию. Отдельным списком: что изменено / что НЕ тронуто и почему.
3. Для каждого изменения укажи, на каких других типах кейсов оно может навредить.
4. Если доказательств мало, предложи оставить фрагмент без изменений.
<Критерий приёмки>
Версия принимается, только если на отложенных кейсах она не хуже старой по {метрика} и не дороже по {стоимость}. Иначе — откат.
Подставлять: {инструкция} — текущий системный промпт или файл агента. {кейсы_для_правки} — 3–5 разобранных провалов. {метрика} — понятный вам критерий (доля верных ответов, оценка по чек-листу). {стоимость} — токены или рубли за прогон.
🚀 Быстрый старт — вставь в чат:
Вот шаблон ревизии инструкции с отложенной проверкой. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие у вас кейсы, какая метрика качества и что считать стоимостью. Это нужно, чтобы разделить кейсы на учебные и отложенные и чтобы критерий приёмки был измеримым. Остальное она возьмёт из структуры шаблона.
Ограничения
⚠️ Одна среда: все результаты — на играх ARC-AGI-3, где агент исследует незнакомые головоломки. Перенос на поддержку, тексты или разработку не проверялся.
⚠️ Правит код, а не промпты: модели переписывали программу-обвязку. Ревизию текстовых инструкций авторы не измеряли. Шаблон выше — перенос принципа, а не проверенная техника.
⚠️ Только две ревизии: что будет после пяти или десяти правок, неизвестно. Средний выигрыш в 2,8 пункта не отличим от нуля: интервал от −1,4 до +7,3.
⚠️ Неточные внутренние метки: часть показателей аудита правок (диагноз, защита рабочего, расчёт ресурсов) оказалась ненадёжной между двумя прогонами судьи-модели. Выводы про «широкие правки лучше узких» или «лишние доработки вредят» авторы сами называют неопределёнными.
⚠️ Правило выбора версии не проверено вперёд: «брать версию с лучшим результатом на учебных» оценено задним числом на тех же данных.
⚠️ Дорого: программа стоила не менее $18 тысяч. Повторить в таком виде на своём проекте нереально, но принцип отложенной проверки дешёвый.
Как исследовали
Исследователи взяли 9 комбинаций «модель + уровень рассуждения» из семи семейств. Каждую запускали трижды независимо, итого 27 цепочек. Модель сама строила обвязку для ARC-AGI-3 и проверяла, что она запускается. Потом играла на 5 учебных играх, по логам правила себя, играла снова и правила ещё раз. Получилось 81 замороженная версия и 2025 оценок по играм. Все версии прогнали на 20 играх, которые никогда не участвовали в правке.
Метрика — RHAE: доля пройденных уровней с учётом того, сколько ходов потрачено по сравнению с человеком. Деньги тоже считали отдельно. Это закрывает вопрос «а не стало ли просто дороже».
Результат: на учебных +8,42, на новых +2,80, разрыв 5,62 (интервал от 1,8 до 9,8). Повторный замер одной версии даёт шум около 4 пунктов, поэтому мелкие сдвиги читать нельзя. Из 27 версий 9 стали лучше и дешевле, 6 лучше и дороже, 9 хуже и дешевле, 3 хуже и дороже. Яркий пример: одна цепочка Sol выросла с 29 до 54 без роста стоимости. Другая упала с 44 до 22, потому что сэкономила со $31 до $7 за игру.
Удивило то, что идеальный процесс не гарантирует результат. Все 54 правки шли по логам, затрагивали реальные проблемы и прошли тесты. Но ширина правки и «дошлифовка» после неудачной проверки не давали предсказуемого эффекта. Вывод для практики: процесс самопроверки не заменяет внешнего теста на примерах, по которым не правили.
Адаптации и экстраполяции
🔧 Техника: хранить версии и добавить откат → быстро вернуть рабочее
Перед каждой правкой инструкции сохраняйте старую версию и дату. В промпте ревизору добавьте:
Если новая версия хуже старой хотя бы на одном типе кейсов из списка {критичные_типы}, верни старую.
Это ручная замена правилу «защити то, что работало»: авторы считали такую защиту признаком хорошего обновителя.
Экстраполяция: ревизия с независимым судьёй. Правит один чат, на отложенных кейсах отвечает второй чат со старой и новой версиями, а оценивает третий по чек-листу. Так оценка не зависит от ревизора, которому хочется «показать улучшение». Это идея из этого исследования, но сама схема трёх чатов в нём не проверялась.
Ресурсы
- Работа: Can LLMs Improve Their Own Harness? A Controlled Study on ARC-AGI-3 (препринт)
- Авторы: Jens Lehmann (Amazon, работа вне Amazon; Technische Universität Dresden), Sahar Vahdati (Universität Hannover; TIB — Leibniz Information Centre for Science and Technology)
- Бенчмарк: ARC-AGI-3, пример игры FT09 — arcprize.org/tasks/ft09
- Среда для кода: OpenCode (аналог Claude Code и Codex)
- Похожие работы из статьи: Meta-Harness, Agentic Harness Engineering, SEAGym, HarnessOptBench, Terminal-Bench