TL;DR
Неявный сбой (implicit failure, IF) — это локальная ошибка агента посреди работы, которая не определила исход: её исправили, обошли или протащили дальше. Идея метода в том, чтобы читать всю трассу (лог шагов агента) и отдельно фиксировать каждый такой сбой: на каком шаге, у какого агента, какого типа, как он был поглощён. Это делает LLM-судья, которому дают таксономию (список типов сбоев и способов их поглощения). Затем из нескольких прогонов выбирают тот, где меньше и легче неявных сбоев.
Главная находка: успех не значит, что процесс был чистым. Неявные сбои есть в 54% успешных и 75% провальных прогонов. Агент мог упереться в сломанный инструмент, выдумать факт или зайти не туда, а потом вывернуться. А мог не вывернуться и просто принять ложный факт как данность, даже когда ответ в итоге совпал. Смотреть только на «получилось или нет» значит не видеть, где система хрупкая. Готовые «оценщики шагов» (process reward models, PRM), обученные на одиночных агентах и математике, на трассах мультиагентных систем почти не лучше случайного выбора.
Метод простой: после каждого прогона судья-LLM читает лог без знания правильного ответа и выписывает все неявные сбои с тяжестью. Из N прогонов берут тот, где «риск» (сумма тяжести, делённая на длину трассы) ниже. Так выбор лучшего прогона стабильно не хуже PRM и в части настроек заметно лучше.
Схема метода
ШАГ 1: Запустить агента N раз на одной задаче → N трасс (логов)
ШАГ 2: Судья-LLM читает КАЖДУЮ трассу (без эталонного ответа) →
список IF: шаг, агент, тип сбоя, механизм поглощения, тяжесть
ШАГ 3: Считать риск трассы = сумма тяжести / длина трассы → число
ШАГ 4: Выбрать трассу с минимальным риском → итоговый результат
(необязательно) ШАГ 5: Точку сбоя в проваленном прогоне исправить локально
и перезапустить с этого места
Шаги 2–4 можно сделать в чате или простой автоматизацией. Шаг 1 — это N обычных запусков агента.
Пример применения
Сильная зона метода: многошаговый агент с инструментами (поиск, браузер, парсинг, код) и логом, где итог трудно проверить автоматически. Для коротких одношаговых запросов метод избыточен.
Задача: Вы руководитель маркетплейс-аналитики. Агент (Claude Code или автоматизация в n8n) собирает цены на 30 товаров конкурентов с Ozon и Wildberries и составляет сводку для закупщика. Вы запустили его 4 раза. Сводки почти совпадают, но в одной цена «нашлась» там, где страница не загрузилась. Читать 4 лога по 300 строк нет времени.
Промпт (судья-аудитор, запускается на каждый лог отдельно):
Ты — аудитор процесса работы агента. Тебе дан лог одного прогона.
Ты НЕ знаешь правильного ответа и не оцениваешь, верен ли итог.
Твоя задача — найти все неявные сбои: локальные ошибки по ходу
работы, которые могли и не повлиять на итог.
Задача агента: собрать актуальные цены на 30 товаров конкурентов
на Ozon и Wildberries и составить сводку для закупщика.
Лог прогона:
{лог}
Просмотри лог шаг за шагом. Для каждого неявного сбоя укажи:
1. Номер шага и какой агент/инструмент задействован
2. Тип сбоя (выбери один):
- Сбой инструмента (вызов не сработал, таймаут, мусор на выходе)
- Неверное действие (действие не подходит к текущему состоянию)
- Лишнее действие (повтор, пустая трата шагов)
- Выдумка (факт, источник или результат инструмента, которых нет в логе)
- Неполное действие (не хватило данных, формата, доведения до конца)
- Ошибка рассуждения (неверный вывод, повтор заведомо плохой стратегии)
- Непонимание (задачи, роли, ограничений)
- Битый вывод (повреждён формат, но работа продолжилась)
3. Как сбой был поглощён (выбери один):
- Самоисправление (агент сам исправил в том же или следующем ходе)
- Обход (агент сам пошёл другим путём, не исправляя ошибку)
- Исправление коллегой (другой агент, не руководитель)
- Вмешательство руководителя (оркестратор перенаправил)
- Не исправлен (ошибочное состояние принято и пошло дальше)
- Мелочь (механический повтор, ошибка без последствий)
4. Тяжесть: 1 (мелочь), 2 (заметно), 3 (ошибка осталась в итоге
или легла в основу следующих шагов). Не исправленные сбои и
выдумки получают тяжесть выше.
Ответ дай таблицей. В конце: число сбоев, сумма тяжести,
число шагов в логе, риск = сумма тяжести / число шагов.
Не придумывай сбои, которых нет в логе: если сомневаешься,
пометь «под вопросом».
Результат: модель вернёт таблицу сбоев по шагам: тип, механизм поглощения, тяжесть. В конце будут итоговые числа и риск. Прогнав так все 4 лога, вы сравниваете риски и берёте сводку из прогона с наименьшим. Сразу видно и конкретные места, где агент «выдумал» цену или молча принял пустую страницу.
Почему это работает
Слабость. Итог «правильно/неправильно» скрывает процесс. Агент мог получить верный ответ случайно, обойдя ошибку, которую потом повторит. Готовые «оценщики шагов» обучены на других данных. Поэтому в мультиагентных логах они дают сигнал не лучше случайного выбора.
Сильная сторона LLM. Чтение длинного текста и поиск в нём конкретных событий по списку категорий. Судье не нужен эталон: он видит, что инструмент вернул ошибку, а агент потом сослался на результат, которого не было. Таксономия сужает поиск до восьми типов и шести способов поглощения, поэтому судья не отвечает вольно.
Как метод связывает одно с другим. Он превращает «ощущение, что процесс шаткий» в число (риск), которым можно сравнивать прогоны. Из двух прогонов с одинаковым итогом надёжнее тот, где меньше неисправленных сбоев.
Рычаги управления: - Веса тяжести → поднимайте для выдумок и неисправленных сбоев, если цена ошибки высока (цены, юридические данные). - Число прогонов N → в исследовании 4, 8 и 16. Больше прогонов — шире выбор, но дороже. - Список типов → урежьте до тех, что реально встречаются у вашего агента. Больше всего сбоев в статье приходится на сбои инструментов, неверные действия, лишние действия и выдумки (около 79% вместе). - Нормировка на длину → без неё длинные прогоны всегда выглядят хуже. - «Под вопросом» → снижает риск, что судья придумает сбой, которого нет.
Шаблон промпта
Это тот же судья-аудитор, обобщённый под любую задачу. Таксономия сохранена как в статье.
Ты — аудитор процесса работы мультиагентной системы (или одного агента).
Тебе дан лог одного прогона. Ты НЕ знаешь правильного ответа и
НЕ оцениваешь итог. Ищешь неявные сбои: локальные ошибки по ходу
работы, которые были исправлены, обойдены или протащены дальше.
Задача агента: {задача}
Лог прогона:
{лог}
Просмотри лог шаг за шагом. Для каждого неявного сбоя укажи:
- Шаг и агент/инструмент
- Тип: {сбой инструмента | неверное действие | лишнее действие |
выдумка | неполное действие | ошибка рассуждения |
непонимание | битый вывод}
- Поглощение: {самоисправление | обход | исправление коллегой |
вмешательство руководителя | не исправлен | мелочь}
- Тяжесть: 1–3 ({правило_тяжести})
- Короткая цитата из лога как доказательство
В конце:
Число сбоев: ...
Сумма тяжести: ...
Число шагов в логе: ...
Риск = сумма тяжести / число шагов: ...
Если не уверен, что это сбой, пометь «под вопросом» и не включай в сумму.
Что подставлять:
- {задача} — что агент должен был сделать (одно-два предложения).
- {лог} — трасса прогона целиком: шаги, вызовы инструментов, ответы.
- {правило_тяжести} — например: «3 — если сбой остался в итоговом результате или стал основой следующих шагов; 2 — исправлен, но стоил нескольких шагов; 1 — мелочь».
После аудита всех N логов добавьте второй запрос:
Вот результаты аудита {N} прогонов: {таблицы}.
Выбери прогон с минимальным риском. Если риски близки,
предпочти тот, где меньше сбоев типа «выдумка» и «не исправлен».
Назови выбранный прогон и коротко объясни почему.
🚀 Быстрый старт — вставь в чат:
Вот шаблон судьи-аудитора для логов агентов. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, что делает ваш агент, какие у него инструменты и что для вас считается тяжёлой ошибкой. Это нужно, чтобы подогнать список типов сбоев и правило тяжести под ваш процесс. Остальную структуру (таблица, риск, выбор прогона) она возьмёт из шаблона.
Ограничения
⚠️ Приросты скромные: выбор прогона по неявным сбоям даёт единицы процентных пунктов точности. Это не «волшебная кнопка», а способ отсеивать шаткие прогоны.
⚠️ Судья — тоже LLM: он пропускает сбои. Люди нашли ещё 21 сбой, которых судья не отметил, а часть найденных судьёй сбоев отвергли. Проблемы в основном с дальними связями (ошибка в начале, последствия в конце) и с границей «ошибка или нормальный этап плана». В исследовании судьёй была сильная модель; на слабой качество аудита, скорее всего, ниже.
⚠️ Цена: нужно N прогонов агента плюс N проходов судьи по длинным логам. Для дешёвых и коротких задач это не окупается.
⚠️ Ремонт точки сбоя нестабилен: в части конфигураций исправление сбоя и перезапуск вернули много провальных прогонов, в других почти ничего. Универсального «починил шаг и всё заработало» нет.
⚠️ Смешивать с готовыми оценщиками шагов не стоит: комбинация «PRM + IF» оказалась не лучше одного IF. Слабый сигнал добавляет шум.
⚠️ Корреляция, не причина: таксономия поглощения описательная. Она не доказывает, что именно этот сбой стал причиной провала.
⚠️ RL-часть статьи не для читателя: IF-GRPO нужен для обучения модели, практику он недоступен.
Как исследовали
Команда собрала 1 828 трасс из девяти связок «мультиагентная система + бенчмарк»: Magentic-One на GAIA, MetaGPT, ChatDev, AG2 MathChat, веб-агенты и другие. На каждую трассу натравили LLM-судью (Gemini 3.1 Pro). Чтобы понять, можно ли ему верить, два человека независимо проверили 45 трасс, а ещё три модели переразметили 90 трасс. Люди сохранили около 88% найденных судьёй сбоев, и ни один не был отвергнут обоими сразу. Но люди нашли и сбои, которых судья не увидел, то есть полнота разметки не доказана.
Дальше по 45 трассам методом открытого кодирования построили две таксономии: 8 типов ошибок и 6 способов поглощения. Затем проверили, что будет, если исправить сбой: берут состояние агента в момент сбоя, подменяют шаг на исправленный и запускают дальше. В четырёх конфигурациях из семи доля «спасённых» провальных прогонов выросла на 23–46 процентных пунктов по сравнению с простым перезапуском. В остальных эффекта не было. Для сравнения с PRM взяли 4, 8 и 16 прогонов на задачу и выбирали лучший. Судья по сбоям не уступил PRM ни в одной из девяти настроек, а на Magentic-One/GAIA выиграл 3–7 пунктов. Готовые PRM, обученные на одиночных агентах и математике, оказались близки к случайному выбору.
Что удивило: больше половины успешных прогонов содержали сбои, а у четверти провальных их не было вообще. Практический вывод: итоговый балл не показывает, насколько процесс надёжен.
Адаптации и экстраполяции
🔧 Техника: добавить требование журнала сбоев в инструкции агента → получить IF-разметку «из первых рук»
Этого в статье нет, это идея по мотивам. Статья разбирает чужие логи постфактум, но можно просить агента вести свой журнал.
## Журнал сбоев (CLAUDE.md / системный промпт)
Каждый раз, когда инструмент вернул ошибку, пустой результат или
ты сменил подход, добавь в конец ответа строку:
[СБОЙ] шаг: ... | что случилось: ... | как поступил: исправил / обошёл / принял как есть
Не продолжай молча. Если принимаешь непроверенные данные — пиши об этом явно.
Это превращает неявные сбои в явные. Судье-аудитору остаётся сверить журнал с логом. Агент может не заметить собственный сбой, поэтому внешний аудит всё равно нужен.
🔧 Техника: ремонт по месту → точечный перезапуск
Если аудит нашёл сбой тяжести 3 в проваленном прогоне, дайте агенту (или другому чату) такой запрос:
Вот лог. На шаге {N} произошёл сбой: {описание}.
Предложи исправленный вариант ТОЛЬКО этого шага — в той же роли и с тем же контекстом, что был до него.
Дальше я продолжу прогон с этого места.
В статье исправление генерировала сильная модель, а затем прогон возобновляли автоматически. Вручную это делается дольше, но логика та же.
Ресурсы
- MASIF: Implicit Failures for Process Observability in Multi-Agent Systems, Yanwei Huang, Arpit Narechania (HKUST), Atanu Sinha (Adobe Research).
- Опирается на MAST (Cemri et al., 2025) — таксономию провалов мультиагентных систем на уровне всей трассы. Бенчмарки: GAIA, WebWalkerQA, BrowseComp-Plus, MMLU, OlympiadBench, GSMPlus, SWE-Bench. Промпты судьи и ремонта приведены в приложениях статьи (Appendix A и D.2).