Скиллы для ИИ-агентов: почему работают и где ломаются

Главный миф о скиллах разрушен

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

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

Процедура важнее знания

Ключевой вывод исследования: скиллы помогают прежде всего за счет процедурного заземления - они дают агенту надежную последовательность действий, а не недостающие факты. На долю этого эффекта приходится 65,7% случаев, когда агент со скиллом обходил агента без него. Прямая передача знаний - то, ради чего скиллы чаще всего и пишут, - объясняла лишь 4,5% улучшений.

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

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

Механическое следование как новый источник багов

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

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

Парадокс растущей библиотеки

Самый неожиданный результат - то, что происходит при масштабировании. Когда библиотека скиллов расширялась с 5 до 100 записей, точность извлечения нужного скилла падала с 29,6% до 3,3%. Агент почти перестал выбирать правильный скилл для задачи.

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

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

Ловушка самообучения без меток

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

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

Что это меняет на практике

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

Для команд, строящих агентные системы прямо сейчас, три вывода практически применимы уже сегодня:

Первое - ревизия библиотеки. Если скилл описывает "как работает наш стек", а не "что агент делает неправильно", он с высокой вероятностью не окупается. Такие записи стоит либо удалить, либо переписать под конкретный паттерн ошибки.

Второе - метки исходов обязательны. Любая система автосбора опыта без записи "задача выполнена / провалена" - это риск, а не актив.

Третье - не гонитесь за размером библиотеки. Рост с 5 до 100 скиллов не купил ничего в части успешности задач, зато почти уничтожил точность выбора. Меньше и точнее - лучше, чем больше и размыто.

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

Информация подтверждена несколькими независимыми публикациями, опирающимися на оригинальное исследование "Demystifying Agent Skills: Why They Work - Until They Don't" (arXiv:2608.14036).