TL;DR
Исследователи взяли систему-надзирателя ("харнесс" — программную обвязку, которая решает что модель видит и когда останавливать работу) и добавили ей два простых механизма: следить за повторами (одна и та же неудачная команда, то же чтение без правок) и сжимать старые данные, оставляя подробными только последние шаги. Когда харнесс замечает, что модель гоняет по кругу, он вставляет жёсткое сообщение: "ты повторяешь одно и то же, смени подход" — и модель продолжает работу уже с этой подсказкой.
Главная находка: модель сама не замечает, что застряла. Она не помнит "я это уже пробовал 5 раз" — она просто видит очередной кусок текста и выдаёт похожий ответ на похожий контекст. Особенно это заметно, когда диалог длинный и старые детали забивают всё пространство — модель тонет в собственной истории и продолжает биться в одну стену. На тестах разница разительная: доля исправленных ошибок выросла с 28% до 49%, а число полностью решённых задач — с 43 до 72 из 169.
Метод работает в два параллельных потока. Первый: харнесс проверяет факты выполнения (не текст, а логи команд) — если команда и её результат повторились, это фиксируется как "застревание", и модель получает прямое указание сменить подход. Второй: по мере заполнения контекста старые результаты инструментов урезаются по правилу "чем старше — тем короче" (последние 4 результата остаются полными, дальше объём режется вдвое с каждым удвоением возраста), а новые данные всегда идут целиком.
Схема метода
ШАГ 1 (автоматически, в фоне): Харнесс фиксирует факты выполнения → находит повтор команды/ошибки/чтения без изменений
ШАГ 2: Если найден повтор → вставляется фиксированное сообщение "ты повторяешь то же самое, смени подход"
ШАГ 3 (параллельно, по мере роста диалога): Старые результаты инструментов урезаются по правилу "старше = короче" → новые остаются полными
ШАГ 4: Модель продолжает работу с обновлённым видом контекста → цикл проверки повторяется на каждом шаге
Пример применения
Задача: Вы дебажите Telegram-бота на Python вместе с Claude или ChatGPT. Ассистент три раза подряд предлагает одно и то же исправление кода — и три раза получает ту же ошибку.
Промпт:
Ты уже 3 раза предлагал одно и то же исправление (добавить try/except вокруг вызова API),
и каждый раз я получал одну и ту же ошибку: "ConnectionResetError".
Не повторяй этот подход. Объясни, почему именно он не работает, и предложи принципиально
другое решение — например, проверь, не проблема ли в самом соединении, а не в обработке ошибки.
Результат: Модель прекращает крутиться вокруг одного и того же решения. Она явно анализирует, почему предыдущие попытки провалились, и предлагает другую стратегию — например, проверить настройки таймаута соединения вместо простого перехвата исключения. По данным исследования, такое явное вмешательство в момент "застревания" резко увеличивает шанс, что задача будет решена полностью, а не заброшена на середине.
Почему это работает
Модель не хранит внутренний счётчик повторов. Она не "помнит" в человеческом смысле, что уже пробовала этот путь пять раз — она просто генерирует следующий шаг, глядя на контекст. Если контекст выглядит похожим (та же ошибка, тот же файл), ответ тоже будет похожим.
Зато модель отлично реагирует на прямо сказанные факты. Если написать текстом "ты повторяешь одно и то же", она это учитывает и меняет стратегию — потому что теперь этот факт есть в её видимом контексте, а не только в истории действий.
Метод использует эту силу напрямую: вместо того чтобы ждать, что модель сама заметит цикл, он явно фиксирует факт повторения и вставляет прямое указание. Это не какая-то магия — просто модели дают то, что она сама пропустила бы.
Рычаги управления: - Порог "сколько повторов считать застреванием" — в исследовании это 7 попыток; для простых задач можно снизить до 2-3, чтобы реагировать раньше. - Формулировка вмешательства — можно сделать мягче ("попробуй другой угол") или жёстче ("этот путь точно не работает, забудь про него"). - Что считать "старым" контекстом для сжатия — свои правила, что оставлять подробно (последние правки), что сокращать (старые логи, длинные тексты).
Шаблон промпта
Для ручного применения в чате нет XML-структуры — это принцип, который вы применяете сами, заметив зацикливание:
Ты уже {количество} раз пытался {что делал} и получал {тот же результат/ошибку}.
Не повторяй этот подход. Сначала объясни, почему он не сработал.
Затем предложи принципиально другое решение задачи: {задача}.
Можно также встроить это правило заранее, в начале длинной рабочей сессии:
Работаем над задачей: {задача}.
Если в процессе ты заметишь, что предлагаешь одно и то же решение больше {N} раз подряд
без реального прогресса — остановись сама, скажи об этом прямо и предложи другой путь,
не дожидаясь моего напоминания.
🚀 Быстрый старт — вставь в чат:
Вот принцип разрыва циклов при работе с длинными задачами. Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какая у вас задача и какой сценарий повтора вероятен — потому что формулировка "что считать застреванием" должна совпадать с реальным паттерном вашей работы (код, текст, анализ данных).
Ограничения
⚠️ Эффект слабеет без давления на контекст: когда у модели достаточно места и она не тонет в старой истории, разница между "с напоминанием" и "без напоминания" почти пропадает. Метод особенно ценен в длинных, многошаговых сессиях, где контекст переполняется.
⚠️ Не гарантирует полное решение: на одном из трёх тестов метод чаще помогал продвинуться частично, но не увеличивал число полностью закрытых задач — разрыв цикла убирает застревание, но не компенсирует нехватку навыков у самой модели.
⚠️ Не заменяет качество модели: если модель объективно не понимает задачу, напоминание о цикле просто заставит её сменить одну неверную стратегию на другую неверную.
Ресурсы
Sydney Lewis, "Same Model, Different Harness: Different Coding-Agent Results" (2026). Харнесс Yuj (github.com/sydches/yuj). Тесты: SWE-bench Verified, SWE-bench Pro, FeatureBench. Модель: Qwen3.6-35B-A3B.