Как один разбор ИИ-агента исправил втрое больше задач, чем прежние методы

Когда ИИ-агент ошибся, искать виноватый шаг уже поздно

С ИИ-агентами есть неприятная правда: сбой почти никогда не случается там, где вы его видите. Финальный ответ может быть неверным, потому что 20 шагов назад агент пропустил ограничение в задаче, не ту запись вытащил из памяти или передал эстафету другому агенту без важного контекста. В журналах вы видите симптом. Причина сидит раньше.

Именно в этот разрыв и целится AgentDebugX — открытый набор инструментов для отладки ИИ-агентов от исследователей из Университета Иллинойса, Торонто, Google и Стэнфорда. Идея простая: не просто показывать трассу выполнения, а замыкать цикл целиком — найти сбой, понять его причину, предложить исправление и сразу же перезапустить задачу с этой правкой.

Для сегодняшних ИИ-агентов это очень практичная вещь. Чем длиннее цепочка действий, чем больше инструментов, памяти, браузера, внешних API и мультиагентной координации, тем сложнее понять, где именно всё пошло не туда. Наблюдаемость без диагностики тут уже мало помогает.

Общая схема AgentDebugX: замкнутый цикл из поиска сбоя, поиска причины, предложения исправления и повторного запуска.

Что такое AgentDebugX

AgentDebugX устроен как замкнутый цикл из четырёх шагов:

Это важное отличие от обычных инструментов наблюдаемости. Те обычно умеют аккуратно собрать следы: вызовы LLM, обращения к инструментам, переходы между агентами, действия в интерфейсе, результаты поиска. Но дальше разработчик остаётся один на один с вопросами: кто ошибся, почему именно это было критично и как теперь это чинить.

Здесь авторы пытаются сделать из отладки не просмотр журнала, а рабочий процесс.

Внутри у системы есть единый переносимый формат трассы. Это тоже не мелочь. Сегодня один агент живёт в одном фреймворке, другой — в другом, третий вообще пишет сырые события. Если вы хотите сравнивать поломки, хранить их, возвращаться к ним и прогонять через разные методы диагностики, нужен общий формат. AgentDebugX именно это и предлагает.

Ещё одна деталь: диагноз не вшивается в исходную трассу. Сама история выполнения остаётся как есть, а поверх неё можно накладывать разные версии анализа. Для инженерной работы это удобно: можно перепроверять спорные случаи, сравнивать методы и собирать регрессионные тесты.

Почему корневая причина так трудно ловится

Авторы очень точно формулируют главную проблему. В ИИ-агентах видимый сбой и причинный шаг часто не совпадают.

Простой пример: агент в конце дал неверный ответ. Но финальная ошибка могла начаться раньше:

Из-за этого просмотр трассы целиком не всегда помогает. Если читать её один раз от начала до конца, модель или человек часто цепляется за самый громкий симптом внизу. Например, за неудачный вызов инструмента. Но причина может быть не в вызове инструмента, а в том, что двумя блоками выше был принят неверный промежуточный вывод.

Отсюда и главный технический ход статьи: диагностика должна быть не одношаговой, а многокруговой.

Как работает DeepDebug

Сердце системы называется DeepDebug. Это отдельный агент-диагност, который не просто читает трассу, а проводит небольшое расследование в несколько проходов.

Логика такая.

Сначала DeepDebug читает всю траекторию целиком и выдвигает первую гипотезу: какой шаг был решающей ошибкой. Это полезно, потому что глобальный просмотр держит в голове цель задачи и общий контекст.

Потом идёт второй проход, но уже более структурный. Если система мультиагентная, DeepDebug идёт по цепочке передач назад: кто кому что передал, где информация исказилась, на каком переходе задача фактически была обречена. Если агент один, применяется что-то вроде деления пополам по шагам: диагност постепенно сужает участок поиска, чтобы не терять фокус.

Дальше — самое интересное. Если две гипотезы совпали, система принимает их. Если нет, запускается перекрёстная проверка: DeepDebug сравнивает двух кандидатов бок о бок и выбирает тот, чьё исправление с наибольшей вероятностью предотвратило бы провал.

На выходе получается не просто метка «ошибка на шаге 17», а структурированный отчёт:

Это хороший инженерный формат. Он пригоден и человеку, и автоматическому контуру повторного запуска.

Как это выглядит в работе

У AgentDebugX есть консольный интерфейс и веб-интерфейс. Сценарий выглядит знакомо для любого, кто хоть раз разбирал провалившийся запуск агента: открыть трассу, перейти от видимого симптома к реальной причине, прочитать диагноз, сделать новую ветку выполнения и сравнить результат с исходной.

Интерфейс AgentDebugX: от выбора неудачного запуска до перехода к причинному шагу и создания новой ветки с исправлением.

Важно, что авторы держат систему «локальной по умолчанию». Все артефакты остаются локально, пока вы сами не решите их экспортировать. Это разумно, потому что в трассах агентов часто лежат чувствительные данные: промпты, аргументы инструментов, снимки экрана, пользовательские файлы, токены доступа.

Есть и ещё одна любопытная часть — хранилище ошибок. В AgentDebugX можно сохранять очищенные пакеты вида «поломка — диагноз — исправление» и потом переиспользовать их как память отладки. Это уже похоже на базу инцидентов для ИИ-агентов. Одна команда починила редкий случай, другая потом может наткнуться на похожий.

Авторы, правда, честно отмечают: эффект такой памяти они пока не измеряли. Механизм есть, но его вклад в качество ещё не доказан.

Что показали эксперименты

У статьи два главных вопроса.

Первый: может ли система точнее находить виновный шаг и виновного агента?

Второй: помогает ли это реально исправлять неудачные запуски, а не только писать красивые отчёты?

Для первого вопроса использовали бенчмарк Who&When. В нём у каждой трассы размечено, кто ошибся и когда именно произошёл решающий сбой. Это хороший тест, потому что он требует не просто заметить проблему, а локализовать её причинный источник.

На модели qwen3.5-9b метод DeepDebug показал лучший на данный момент результат среди сравниваемых подходов. По самой строгой метрике — нужно правильно назвать и агента, и точный шаг — он получил 28,8%. Лучший одношаговый базовый метод набрал 21,7%.

На первый взгляд цифры могут показаться скромными. Но здесь как раз важно не ждать магии. Задача действительно трудная: длинные трассы, много промежуточных действий, причинная связь часто размыта. На таком фоне разница в несколько процентных пунктов означает заметный прирост в реальной диагностике.

Точность поиска виновного агента и точного шага в зависимости от длины трассы: преимущество DeepDebug особенно заметно на длинных траекториях.

Интереснее другое: выигрыш DeepDebug особенно проявился на длинных трассах, где больше 40 событий. Это логично. На коротких задачах часто хватает и одного внимательного прочтения. На длинных уже нужен второй проход, структурный поиск и сверка гипотез.

По токенам многокруговая схема оказалась не такой дорогой, как можно подумать. Один глобальный проход в среднем требовал 8,1 тысячи токенов, DeepDebug — 12,8 тысячи. То есть примерно в 1,6 раза больше, а не в 5–10 раз. Причина в том, что последующие шаги читают уже не всю трассу, а узкие окна вокруг подозрительных мест.

Помогает ли это чинить задачи

Самая прикладная часть статьи — эксперимент на GAIA. Здесь авторы взяли агента Open-Deep-Research на qwen3.5-9b, который с первого раза решил 55,8% задач валидации, а 73 задачи провалил. Затем каждый неудачный запуск попытались диагностировать и переиграть один раз.

Результат получился наглядный.

Базовые методы исправления самой себя, которые просто получают общий разбор провала, смогли починить от 4 до 6 задач из 73.

DeepDebug с локализацией причины и конкретной правкой починил 13 задач.

Общая точность выросла с 55,8% до 63,6%.

Это разговор о том, меняет ли диагностика итоговый ответ. В данном случае — да.

Особенно заметен рост на задачах средней сложности, где нужно сделать несколько логических и инструментальных шагов подряд. Там точная локализация ошибки особенно полезна, так как агент получает указание, где именно была неверная развилка.

Важно и то, с чем здесь сравнивают DeepDebug. Базовые подходы к исправлению видят общий контекст провала, но не получают точную локализацию причинного шага, доказательства и сформулированную правку. То есть, если вы знаете, где ошибка, исправлять её заметно легче.

Где здесь границы

У работы есть ограничения, и их стоит держать в голове.

И это, пожалуй, правильная постановка. Авторы не обещают автоматическую отладку как волшебную кнопку. Они предлагают инфраструктуру, где диагностика становится системной, проверяемой и повторяемой.

Почему это важно

Если вы строите ИИ-агентов, проблема уже не в том, как собрать длинную трассу. Проблема в том, как из этой трассы извлечь ответ на три вопроса:

AgentDebugX показывает, что эти три вопроса можно связать в один инженерный цикл. И это важнее, чем кажется. Пока отладка ИИ-агентов часто живёт как кустарное ремесло: кто-то посмотрел журнал, догадался, поправил промпт, забыл. Такой процесс плохо масштабируется, плохо проверяется и почти ничего не оставляет после себя.

Здесь предлагается другой подход: хранить поломки как артефакты, писать для них диагнозы, строить повторный запуск как новую ветку, собирать память об ошибках и постепенно превращать надёжность агентов в обычную инженерную дисциплину.

Вывод

ИИ-агенты проваливают задачи не там, где это видно. Поэтому одной наблюдаемости уже мало. Нужна система, которая умеет пройти путь от симптома к причине, от причины к исправлению, а затем проверить исправление в новом запуске.

AgentDebugX строит именно такой цикл. DeepDebug ищет не просто сбойный шаг, а причинный шаг. На бенчмарке Who&When это даёт более точную атрибуцию, особенно на длинных трассах. На GAIA эта точность превращается в дополнительные исправленные задачи после одного повторного запуска.

По сути, работа двигает отладку ИИ-агентов в режим воспроизводимой инженерной процедуры. А по мере того как агенты получают больше инструментов, памяти, браузера и мультиагентной координации, именно такая процедура становится базовой необходимостью.