TL;DR
Исследование показывает, что высокая точность «предсказателей провала агента» в основном измеряет сложность задачи, а не то, что происходит в текущем запуске. Предсказатель, который вообще не смотрит на ход работы агента и просто знает «эта задача обычно проваливается», получает почти тот же высокий балл. Ключевой вывод для практики: сложность задачи видна до старта, а ранние шаги конкретного запуска почти не говорят, провалится он или нет.
Боль знакома тем, кто гоняет агентов в Claude Code или Cursor: на третьем шаге агент мечется, ошибается, и хочется всё оборвать и начать заново. Но по первым шагам нельзя отличить запуск, который выправится, от запуска, который развалится. Метрики качества мониторов (AUROC, где 0,5 — «монетка», а 1 — «идеально») складывают задачи вместе. Поэтому монитор выглядит умным, хотя он просто отличает «лёгкую задачу» от «тяжёлой». Внутри одной задачи он почти не лучше монетки.
Практический вывод из экспериментов с фиксированным бюджетом токенов состоит из двух частей. Деньги и усилия выгоднее распределять между задачами: сложным давать сильную модель, больше попыток или человека. Обрывать запуск по раннему сигналу выгодно только при очень точном мониторе, а таких в исследовании не нашлось. Сигнал проваливающегося запуска заметно усиливается ближе к концу, и у слабых агентов он виден лучше.
Схема метода
Это не техника, а правило принятия решений:
РЕШЕНИЕ 1 (до запуска): оцени сложность ЗАДАЧИ → выбери модель / бюджет / человека
РЕШЕНИЕ 2 (в начале запуска): ранние шаги ≠ надёжный сигнал → НЕ обрывай по ним
РЕШЕНИЕ 3 (позже в запуске): сигнал сильнее → контрольные точки позже
ПРОВЕРКА монитора: сравнивай успешные и проваленные запуски ОДНОЙ задачи, а не всех подряд
Пример применения
Задача: Разработчик маркетплейса вечером ставит Claude Code на бэклог из 30 тикетов: от «поправить текст кнопки» до «перенести оплату на новый эквайринг». Токенов хватает не на всё. Раньше он следил за ранними шагами и убивал запуски, которые «выглядят плохо». Теперь он сортирует задачи заранее.
Промпт:
Ты — тимлид, который распределяет работу между агентами. Ниже 30 тикетов из бэклога.
Для каждого оцени СЛОЖНОСТЬ ЗАДАЧИ ДО ЗАПУСКА, только по тексту тикета и затронутым модулям.
Признаки сложности: размытое описание, нет воспроизводимого шага, затронуто много файлов,
нужны знания о внешней системе (эквайринг, ЦБ, ЕГРЮЛ), нет тестов.
Для каждого тикета выдай строку:
ID | сложность (низкая/средняя/высокая) | почему (1 фраза) | рекомендация
Рекомендации:
- низкая → дешёвая модель, 1 попытка
- средняя → сильная модель, до 2 попыток
- высокая → сначала разбей на подзадачи или передай человеку
Не оценивай «как пойдёт запуск». Оценивай только саму задачу.
Тикеты:
{список_тикетов}
Результат: Модель выдаст таблицу по каждому тикету: уровень сложности, короткое обоснование и рекомендацию по ресурсам. Сложные тикеты будут отмечены для разбиения или передачи человеку. Бюджет разработчик тратит по этой таблице, а не по впечатлению от первых шагов запуска.
Почему это работает
Слабость: по первым шагам запуска почти не видно, куда он идёт. Агент, который пробует и ошибается, выглядит так же, как агент, который вот-вот выправится. Судить по этому сигналу — всё равно что угадывать исход матча по первой минуте.
Сильная сторона: задачи различаются устойчиво. Тикет с размытым описанием и множеством затронутых файлов проваливается чаще, чем правка копирайта, и это видно до старта. Сложность предсказуема по тексту задачи и метаданным.
Как использовать: решение о ресурсах привязывай к тому, что реально различимо. До запуска — к задаче, внутри запуска — к сигналам из его поздней части. Рычаги: - Момент проверки. Чем позже контрольная точка, тем надёжнее сигнал, но тем больше потрачено токенов. - Тип агента. У слабых моделей сбой заметнее, у сильных он хуже виден. - Цена ошибки при обрыве. Если обрыв ломает запуск, который бы справился, ложные срабатывания дороже, чем кажется. Одна из цитируемых работ показала, что критик с хорошими офлайн-цифрами может снизить долю успехов, когда прерывает удачные траектории.
Шаблон промпта
Готовых промптов в статье нет. Ниже сборка по её выводам: триаж задач по сложности до запуска.
Ты — {роль_распределителя}. Перед запуском агента оцени сложность каждой задачи
ТОЛЬКО по её описанию и контексту. Не угадывай, как пойдёт выполнение.
Критерии сложности: {критерии}.
Для каждой задачи:
ЗАДАЧА | сложность (низкая/средняя/высокая) | причина | действие
Правила действия:
- низкая → {действие_для_простых}
- средняя → {действие_для_средних}
- высокая → {действие_для_сложных}
Задачи:
{список_задач}
Подставляйте:
- {роль_распределителя} — тимлид, руководитель проекта.
- {критерии} — что у вас делает задачи тяжёлыми: нет тестов, внешняя интеграция, неясные требования.
- {действие_для_…} — ваши ресурсы: какая модель, сколько попыток, нужен ли человек.
Ограничения
⚠️ Ранний обрыв не «бесполезен вообще»: сигнал провала усиливается позже в запуске. Статья говорит только, что ранние мониторы слабы. Поздние контрольные точки могут работать.
⚠️ Старые и узкие модели: значительная часть данных — модели Llama-3 и Qwen в задачах по исправлению кода. Для новейших агентов в других доменах вывод может сместиться.
⚠️ Результат не про промпты: вывод относится к решениям о ресурсах и остановке, а не к формулировке запросов. Из промпта в статье берётся только триаж, и он собран по выводам, а не проверен авторами.
⚠️ Внутризадачный анализ неполный: его можно посчитать лишь для задач, где были и успех, и провал. Таких примерно от пятой до двух пятых задач, поэтому цифры описывают именно эту часть.
Как исследовали
Идея была простой: взять наборы данных, где один и тот же агент пытается решить одну и ту же задачу много раз. Тогда можно честно сравнить успешный и проваленный запуск, держа задачу и модель неизменными. Авторы проанализировали четыре коллекции запусков: SWE-agent (три модели Llama-3), SWE-rebench (Qwen3-Coder), LiveClawBench (17 моделей) и Latent Programming Horizons (две модели с доступом к скрытым состояниям).
Сначала они разложили общий AUROC на два вида сравнений: «успех против провала внутри одной задачи» и «между разными задачами». Оказалось, что более 99,93% всех пар сравниваются между разными задачами. Поэтому «оракул сложности», который не видит запуск вообще и выдаёт лишь исторический процент провалов задачи, получает AUROC до 0,945. Внутри задачи у него ровно 0,5.
Простой пример из статьи. Две задачи из Django по 10 попыток: одна решается 9 раз, другая 1 раз. Предсказатель «просто назови процент провалов задачи» даёт AUROC 0,9 по всем 20 запускам и 0,5 внутри каждой задачи.
Затем авторы проверили поведенческие предсказатели, опубликованные мониторы и пробы по скрытым состояниям на ранних шагах. Результат: внутризадачное различение стабильно слабое, около 0,50–0,55. Это удивило: цифры из прошлых работ (0,85–0,94) выглядели куда внушительнее. В конце авторы проиграли реплеем решения при фиксированном бюджете токенов. Распределение ресурсов по задачам оказалось лучше, чем только обрыв. Ранний обрыв начинает выигрывать, когда внутризадачный AUROC достигает примерно 0,84–0,93, то есть намного выше, чем у существующих мониторов.
Практический инсайт: не принимай высокую точность за пригодность для решения. Сначала спроси, какое именно решение монитор должен поддерживать.
Адаптации и экстраполяции
🔧 Техника: контрольные точки позже и с пересмотром, а не мгновенный обрыв → меньше потерянных запусков, которые бы выправились.
Это экстраполяция выводов статьи, а не проверенный метод. Фрагмент для CLAUDE.md или AGENTS.md:
Правила самоконтроля:
- Первые {N} шагов не меняй стратегию и не сдавайся из-за единичных ошибок.
- После {N} шагов и далее каждые {M} шагов сделай контрольную точку:
1) что уже проверено тестами, 2) что осталось, 3) есть ли прогресс.
- Если прогресса нет на двух подряд контрольных точках — остановись,
опиши блокер и передай человеку. Не продолжай тратить токены.
Подставляйте {N} и {M} под длину ваших задач, например 15 и 10 шагов.
Ресурсы
- Disentangling Task Difficulty from Run-Level Failure in Agent Failure Prediction
- Авторы: Mohsen EsfandyariDoulabi, Lawrence Arkoh, Biruk Tadesse, Vaishvi Patel, Mehul Sharma, Marcelo d'Amorim, Wesley Assunção — North Carolina State University, USA
- Связанные работы из статьи: Ge et al. (оценка сложности задач по IRT), Bulut (пулованный AUROC отражает сложность вопросов), Mehtiyev & Assunção (ассоциации траекторий зависят от условий сравнения), Vasudev et al. (критик может ухудшить результат)
- Использованные наборы данных: SWE-agent, SWE-rebench, LiveClawBench, Latent Programming Horizons