AI agents получают больше пользы от переиспользуемых “skills”, потому что эти инструкции задают надежный рабочий процесс, а не потому, что они существенно расширяют фактические знания модели, говорится в исследовании ученых Princeton University, UC San Diego и других организаций.

Исследование, о котором сообщил The Decoder, основано на 8 135 контролируемых тестовых прогонах, сравнивающих agents с task-specific skills и без них. Оно также выявляет серьезное ограничение для команд, строящих agent-системы: по мере роста библиотеки skills агент гораздо реже находит правильные инструкции. В сообщенных тестах точность retrieval упала с 29,6% при пяти skills до 3,3% при 100.

Эти выводы важны, поскольку разработчики все чаще используют сохраненные инструкции, playbooks и процедуры инструментов для улучшения AI agents без переобучения базовых моделей. Они показывают, что центральная инженерная задача — не просто накапливать больше skills, а надежно выбирать и применять их.

Почему skills улучшают выполнение

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

Это делает skills отличными от обычного хранилища знаний. Вместо того чтобы сообщать новый факт, skill дает agent процедурный путь через задачу. Он может подсказать системе, как подготовить окружение, вызывать инструменты в правильном порядке, проверять промежуточный результат или форматировать финальный вывод.

Исследование показало, что эта процедурная опора объясняла 65,7% случаев, когда agent со skill превосходил agent без него. Напротив, прямое предоставление дополнительных знаний объясняло лишь 4,5% улучшения в протестированных случаях, согласно изложению исследования The Decoder.

Для разработчиков это различие важно. Модель может уже знать нужные концепции, но все равно провалиться, если пропустит шаг настройки, неверно вызовет инструмент или выдаст бесполезный результат. Хорошо спроектированный skill может снизить такие ошибки исполнения, превращая открытый запрос в повторяемый workflow.

Результат также помогает понять, почему skills стали привлекательной альтернативой дообучению модели. Команды могут обновить процедуру, добавить шаг проверки или закодировать повторяющееся исключение, не меняя веса модели. Это может облегчить пересмотр поведения agent по мере изменения продуктов и внутренних процессов.

Доказательства и ограничения исследования

Исследовательская команда сравнивала поведение agents на идентичных задачах с релевантным skill и без него на более чем 8 000 прогонов. Такая контролируемая постановка сильнее анекдотических демонстраций того, как agent просто выполнил задачу, потому что она фокусируется на вкладе самого skill.

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

Skills также породили новые режимы отказа. Примерно в 10% случаев, как сообщается, agent механически применял полезный playbook или использовал его там, где он не подходил. Следовательно, skill может уменьшать один класс ошибок и одновременно создавать другой: agent слишком буквально следует инструкциям вместо того, чтобы понять, что задача требует иного подхода.

Исследование также указывает, что точное совпадение skill не всегда обязательно. Связанный skill может дать достаточно структуры, чтобы помочь agent. Такая гибкость полезна на практике, но усложняет оценку. Командам нужно проверять не только наличие правильного skill, но и то, не вызывают ли похожие или частично релевантные skills неподходящее поведение.

Узкое место retrieval усугубляется с ростом библиотеки

Самое резкое предупреждение касается retrieval. Когда протестированная библиотека выросла с пяти элементов до 100, сообщаемая доля успешных находок упала с 29,6% до 3,3%. The Decoder отмечает, что особенно похожие по звучанию варианты усложняли выбор.

Это создает проблему масштабирования для AI agents. Небольшой библиотекой можно управлять с относительно простым сопоставлением, но production-система может накопить сотни или тысячи skills, охватывающих разные команды, программные инструменты, права доступа и крайние случаи. Тогда большее покрытие может сделать систему менее надежной, если agent не способен отличить нужную инструкцию от близких альтернатив.

Проблема не ограничивается качеством поиска. На то, сработает ли retrieval, влияют названия skills, описания и метаданные. Плохо разделенные процедуры может быть трудно различить и модели, и обычной поисковой системе. Большая библиотека также может содержать устаревшие или перекрывающиеся инструкции, повышая шанс того, что agent выберет технически правдоподобный, но операционно неверный workflow.

Это делает управление skills задачей жизненного цикла. Создание процедуры — лишь первый шаг. Командам также нужны механизмы для тестирования, версионирования, ранжирования, вывода из эксплуатации и retrieval skills. Как следует из исследования, более совершенным self-learning agents потребуются более надежные методы создания, поиска и применения накопленного опыта — а не просто большие его коллекции.

Что означают выводы для разработчиков и компаний

Для продуктовых команд главный вывод — рассматривать skills как исполняемые операционные процедуры, а не как общие дополнения к prompt. Полезный skill должен определять предпосылки, порядок инструментов, контрольные точки и условия, при которых agent должен остановиться или запросить помощь.

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

Корпоративные внедрения поднимают дополнительные вопросы управления. Skills могут кодировать процедуры доступа, политики поддержки клиентов, финансовые workflow или внутренние правила обработки данных. Если agent извлекает не тот skill, сбой может означать не просто плохой ответ; он может привести к неверному действию или раскрытию информации не тому процессу. По мере роста библиотек версия, владение и audit logs становятся практической необходимостью.

Выводы также говорят в пользу избирательных библиотек, а не бездумного накопления. Добавление каждого успешного взаимодействия в долгосрочную память может повышать кажущуюся способность, но ухудшать retrieval. Продуктовые команды могут получить лучшие результаты, если будут объединять дублирующиеся skills, четче разделять процедуры и добавлять явные отрицательные условия, объясняющие, когда skill использовать не следует.

Для поставщиков моделей и разработчиков agent-платформ исследование указывает на retrieval-системы, понимающие контекст задачи, состояние инструмента и процедурное сходство. Оно также повышает ценность fallback-поведения: когда уверенность низка или несколько skills выглядят похожими, agent должен отступить, задать уточняющий вопрос или выполнить более узкий поиск вместо механического выбора.

На что смотреть дальше

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

Разработчикам также стоит следить за тем, добавляют ли agent-фреймворки специализированные реестры skills, версионирование, наборы оценок и retrieval с учетом уверенности. Такие функции покажут, что рынок рассматривает skills как управляемые программные компоненты, а не как статические prompt-файлы.

Еще одним тестом станет способность систем отвергать почти релевантный skill. Сообщенные случаи механического применения делают отказ, уточнение и эскалацию столь же важными, как и сам retrieval. Надежные agents должны будут знать не только, какую процедуру использовать, но и когда ни одну сохраненную процедуру нельзя безопасно применить.

Позиция Creati.ai

Это исследование полезно корректирует предположение, что возможности agent просто масштабируются добавлением памяти. Skills, похоже, особенно ценны, когда они делают исполнение явным, но растущая библиотека может превратить это преимущество в проблему выбора. Для AI-разработчиков качество retrieval и процедурные границы могут быть столь же важны, как и чистая способность модели к рассуждению.

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