How Well Do Agentic Skills Work in the Wild?

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

А вот исследований, чтобы численно померить импакт от скиллов, как делать их эвалы (сейчас в вялом режиме пишу статью для воркшопа на KDD, так что может быть будет пополнение) и, самое главное, как улучшать – пока мало. Исследовательская группа из MIT практично копают в эту тему в своей свежей статье

Разберу основные мысли.

Как бенчмаркать скиллы? В коммьюнити сейчас есть один бенчмарк, чтобы мерить полезность скиллов в разных доменах – SkillsBench. Он завирусился в твиттере (но статью на ICML не взяли – недостаточно новизны), авторы собрали людей, получился бенч на ~100 задач в формате Terminal-Bench тасок: есть текстовое описание задачи, докер среда с окружением, набор скиллов которые должны помочь решить задачу и юнит тесты, чтобы проверить. В статье которую разбираем в этом посте авторы делают эксперименты в основном на этом бенче.

Проблема загрузки скиллов в контекстное окно агента. Любой кто брался за создание своего скилла читал гайд Антропиков как писать хороший скилл. Ключевую роль играет поле description – в момент старта агента только это короткое поле с описанием сути скилла будет загружено в контекст модели. Так можно загрузить сотни скиллов и не перегрузить контекстное окно. Целиком же скилл будет загружен только когда модель понимает, что он ей нужен исходя из контекста. Авторы статьи решают симулировать проблему выбора – пусть у агента будут загружены не только релевантные скиллы, но и скиллы дистракторы. Идеальную модель это не смутит и она разберется какой скилл использовать. На практике оказывается, что дистракторы серьезно влияют, перформанс opus 4.6 падает на 8% (первый график, первые 2 столбца)

Почему так происходит? Оказывается все просто. Модель просто не понимает, что ей нужно использовать скилл. То есть даже в идеализированном сетапе, где есть текст задачи + несколько релевантных скиллов – опус реально будет использовать скилл только в 50% случаев (второй график). Все это поправимо – пост-трейн решает.

Представим недалекое будущее. Это такое, в котором нет необходимости писать свои скиллы принципе. Ну действительно, нет смысла каждому писать свой для документации к какой-нибудь популярной библиотеке. Гораздо быстрее скачать готовый с маркетплейса. Тогда появляется проблема поиска и ранжирования. Авторы скачали скиллы из маркетплейса skills.sh и сделали из него индекс. Теперь протестировали агента на решении задач в двух сетапах: в одном был доступ к индексу с заведомо нужными скиллами, во втором только к индексу. результаты естественно просели еще сильнее, у опуса на 20% (первый график, столбцы 3 и 4).

Как улучшить свой скилл? Это вполне себе резонынй вопрос. Одна стратегия, это просить агента-валидатора как-нибудь его переписать: учитывать гайды антропика, смерджить несколько – короче self-improvement loop. Чтобы померить эффект авторы добавляют еще один бенчмарк – Terminal-Bench 2.0. Ретривят к каждой задаче релевантные скиллы (по мнению ретривера), применяют к ним оптимайзер, и дальше решают задачу с учетом доступа теперь к скиллам. Оптимайзер имеет доступ только к тексту скиллов. Бонусов от такого как правило не наблюдается. Иными словами, не получается улучшить скилл только на основе каких-то чисто синтетических рассуждений.

Другой способ улучшить скилл – это дать агенту доступ к тексту задаче и среде, где он может ее решать – но без доступа к фидбэку о том, правильно ли агент ее решил. В этом случае это тоже self-improvement loop, но теперь есть сама задача, а самое главное возможность попытаться ее решить. Такой оптимайзер часто решает смерджить скиллы или переписать description. От такого оптимайзера толку уже сильно больше и он дает значимые бусты почти во всех сетапах. Но при этом создается, конечно, немного читерская ситуация – все-таки агент видел текст задачи.