Почему нейронка не пользуется отладчиком – и как харнесс перекрывает класс модели

Увидел

Недавно обратил внимание, что агенты у меня почти не используют отладчик. Чаще всего можно увидеть такую схему решения проблем: прочитал ошибку → выдвинул гипотезу → переписал кусок кода → перезапустил тест. И так в цикле, пока не исправят.

А где же отладчик?

Проверил

Проверил выборочно на своих сессиях Claude и Codex на Python и JavaScript и обнаружил, что действительно, в этих эпизодах отладчик не использовался ни разу.

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

Но почему?

Казалось бы, отладчик – базовый инструмент программиста. Почему агент так редко его использует? Или это особенность моих задач?

Разобрался

В debug-gym и других работах нашлись объяснения:

Интерфейс рассчитан на человека. Отладчиком приходится управлять пошагово, а его ответы бывают многословными. Агенту приходится значительно чаще обращаться к модели, а ее контекст заполняется командами и ответами отладчика.
Агенты неохотно используют инструмент. Авторы debug-gym предполагают, что дело в обучающих выборках, в которых много готовых правок кода и мало записей работы с отладчиком. Возможно, поэтому модели охотнее переписывают код, чем исследуют его выполнение.
Прямой доступ работает не всегда. В эксперименте Microsoft (Debug2Fix) Sonnet с прямым доступом к отладчику вызвала его всего в 9% задач, а общий результат оказался хуже, чем без отладчика. Агенту приходится одновременно управлять отладчиком и искать причину ошибки. Вероятно, чем слабее модель, тем труднее ей совмещать эти задачи.

Исследователи пробуют три разных ответа на эту проблему.

Не может? Научим

В SWE-PDB модели сначала показали примеры того, как искать ошибки с помощью отладчика, а затем дали практиковаться, поощряя успешные решения. После такого обучения Qwen3-14B стала исправлять 38% задач вместо прежних 10%. Правда, после такого обучения с подкреплением она научилась лучше чинить код и без отладчика, показав результат в 33,4%. То есть обучение улучшило саму модель, а использование отладчика дало еще прибавку сверху.

Неудобно? Переделаем

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

Не хочет? Заставим

В работе Debug2Fix сделали две вещи:

Спрятали отладчик за субагента. Главному агенту вместо команды pdb или jdb дают один инструмент – “спроси отладочного субагента”. Главный агент задает вопрос на естественном языке: “Какое значение возвращает метод X при таком тесте?”. Субагент в своем изолированном контексте рулит отладчиком, находит ответ и возвращает сухие факты: переменные, стек вызовов, наблюдения. Соответственно, контекст главной модели остается чистым.
Связали руки (tool-limit). Чтобы модель “не ленилась”, ей в харнессе заблокировали редактирование файлов, пока она хотя бы один раз не сходит к субагенту-отладчику. Хочешь чинить код? Сначала выясни в рантайме, что реально сломалось, и только потом трогай файлы.

И на бенчмарке GitBug-Java это дало существенный эффект:

Базовая Claude Sonnet 4.5 без специальной обвязки решила 75,7% задач.
А младшая и легкая Claude Haiku 4.5 с отладочным субагентом и обязательным обращением к нему – 82,3%.

То есть младшая модель обошла старшую того же поколения за счет того, как был организован процесс (к слову, когда тот же харнесс дали самой Sonnet, результат вырос до 85,5%).

Вывод

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