Автоматическая отладка улучшила ИИ-агентов на 10%

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

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

По данным авторов, такой подход поднял успешность на трёх сложных бенчмарках на 8,4–10 процентных пунктов относительно исходных систем. Код проекта обещают опубликовать на [странице AutoSaddler](https://aka.ms/AutoSaddler-website).

Почему промта уже недостаточно

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

В длинных задачах проблема накапливается:

🟠 Агент неправильно понял один параметр и продолжил работу с неверными данными.

🟠 Инструмент вернул неполный результат, но агент не заметил ограничение.

🟠 Системный промт дал слишком общее правило, которое сработало и в подходящем, и в неподходящем контексте.

🟠 Исправление одной ошибки случайно испортило сценарии, которые раньше работали.

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

AutoSaddler превращает эту работу в обучение обвязки без обновления весов модели. Модель не обновляет свои веса. Вместо этого система постепенно меняет внешние компоненты, используя накопленные траектории выполнения и результаты задач.

Что такое AutoSaddler

У AutoSaddler есть три специализированных ИИ-компонента:

🟣 Компонент диагностики и исправлений читает неудачные траектории, изучает код обвязки и ищет первопричину ошибки.

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

🟣 Компонент эволюции выбирает основу для следующей версии. Он может продолжить текущую ветку, вернуть полезное изменение из прошлого кандидата или объединить исправления из разных веток.

Вместо обычного списка изменений система хранит историю в ориентированном ациклическом графе EvoDAG. В его узлах находятся версии обвязки, оценки, описания исправлений и выводы о том, что сработало. Связи показывают, какой набор изменений породил следующий кандидат.

Цикл AutoSaddler: проверка на мини-пакете задач, диагностика, исправление, повторная проверка, оценка обобщения и выбор следующей версии обвязки.

Одна итерация выглядит так:

🟠 Текущая обвязка запускается на небольшом мини-пакете задач.

🟠 Система собирает результаты и полные траектории: вызовы инструментов, ответы, рассуждения и состояние среды.

🟠 Для проваленных сценариев формулируется гипотеза о первопричине.

🟠 Генерируется структурированное исправление. Оно может менять промт, инструмент или управляющую логику.

🟠 Новая версия снова запускается на том же мини-пакете.

🟠 Если результат улучшился, кандидат проверяется на отложенном наборе разработки.

🟠 Итоги сохраняются в EvoDAG и используются для следующей итерации.

Авторы сравнивают этот процесс с обучением на мини-пакетах. Вместо численного градиента здесь используется связка диагностика → исправление → проверка. Она играет роль текстового направления обновления: система должна не просто заметить ошибку, а предложить проверяемое изменение.

Какие части обвязки меняются

AutoSaddler не разрешает агенту редактировать всё подряд. Пространство изменений разделено на три слоя:

🟣 Промт — правила поведения и инструкции для модели.

🟣 Инструменты — новые вызовы, параметры, описания и реализация функций.

🟣 Промежуточное ПО — перехватчики перед вызовом инструмента, цикл агента, настройки среды и управление временем выполнения.

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

Поиск идёт в два этапа. Сначала система ищет исправления способностей. Это позволяет устранить структурные ограничения. Затем переходит к более точным изменениям поведения.

Распределение исправлений: без ограничений система почти всегда меняет текстовые инструкции, а AutoSaddler чаще исследует инструменты и управляющую логику.

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

В экспериментах исправления способностей находили примерно столько же локальных решений, сколько текстовые изменения, но вызывали меньше побочных эффектов: 8% регрессий против 17%.

Результаты

Авторы проверили AutoSaddler на трёх наборах задач:

🟠 GAIA2 моделирует работу помощника в цифровой среде смартфона.

🟠 SWE-Bench Pro содержит длинные задачи по исправлению программного кода в реальных репозиториях.

🟠 Terminal-Bench 2.0 проверяет работу агента в командной строке: администрирование, машинное обучение и безопасность.

Для проверки обобщения задачи разделили по группам. Например, в SWE-Bench Pro обучение шло на одних репозиториях, разработка — на других, а тестирование — на третьих. В GAIA2 группы соответствовали разным виртуальным мирам и персонам.

Сравнение эффективности поиска на GAIA2: AutoSaddler достигает более высокой точности при меньшем числе запусков задач.

Итоги на тестовых наборах выглядят так:

🟣 На GAIA2 исходная система получила 53,0%, а AutoSaddler — 62,0%. Прирост составил 9,0 процентного пункта.

🟣 На SWE-Bench Pro базовый агент достиг 37,3%, а оптимизированная обвязка — 46,9%. Прирост составил 9,6 процентного пункта по основному сравнению авторов.

🟣 На Terminal-Bench 2.0 результат вырос с 40,0% до 50,0%, то есть на 10 процентных пунктов.

На GAIA2 AutoSaddler также обошёл два автоматических метода, которые меняют промты или обвязку целиком. Наиболее заметная разница проявилась в эффективности поиска. Лучший результат на наборе разработки был достигнут после примерно 147 траекторий, использованных для обучения. Для сравнения, Meta-Harness потребовал около 1400 — почти в десять раз больше.

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

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

Почему важна глубокая диагностика

Самое показательное сравнение — с упрощёнными версиями системы. В одной из них убрали глубокий разбор траекторий и оставили один вызов модели с просьбой назвать причину сбоя. Результат на GAIA2 упал с 62,0% до 57,8%.

В приложении авторы разбирают несколько случаев.

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

В задаче с файлами агент создал каталог не внутри `Documents/benchmarks`, а в корне файловой системы. Поверхностный анализ назвал причиной ошибочный относительный путь. Проверка журналов и состояния файловой системы показала другое: агент вообще не проверил расположение родительского каталога. Исправление добавило автоматический поиск существующего родительского пути перед операциями создания и перемещения.

В задаче с поездками агент увидел только одну подходящую поездку и сразу оформил заказ. Глубокая диагностика просмотрела всю историю, нашла вторую поездку в тот же день и добавила инструмент поиска с фильтрами по дате и маршруту.

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

Где система может ошибиться

Главное ограничение AutoSaddler — зависимость от размеченных задач и понятного критерия успеха. В бенчмарках легко определить, решена ли задача. В реальном продукте ответ пользователя часто нельзя проверить простой отметкой «верно» или «неверно».

Есть и другие ограничения:

⚫ Оптимизация рассчитана на независимые задачи без долговременного состояния и памяти.

⚫ Работа самой обвязки требует много вызовов LLM и доступа к журналам выполнения.

⚫ Два запуска могут дать разные траектории из-за случайности модели, поэтому причинность между изменением и улучшением не всегда очевидна.

⚫ Автоматические изменения кода, промтов и перехватчиков нужно проверять человеком и отдельно тестировать на безопасность.

Авторы также показывают, что AutoSaddler способен переносить часть улучшений на более слабую модель: при замене Claude Opus 4.6 на Claude Haiku 4.5 прирост на GAIA2 сохранился и составил 5,6 процентного пункта относительно исходной обвязки. Но это пока один сценарий переноса, а не доказательство универсальности метода.

Траектория поиска AutoSaddler: система переживает регрессию, возвращается к удачной версии и объединяет проверенные исправления.

Вывод

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

Полезный процесс выглядит так:

🟣 Сначала собрать полную траекторию выполнения.

🟣 Затем найти первопричину, а не просто назвать симптом.

🟣 После этого внести небольшое структурированное изменение.

🟣 Проверить его на исходной задаче и на отложенных сценариях.

🟣 Сохранить обобщаемый вывод и не принимать локальный успех за улучшение всей системы.

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