Свежий аудит 2465 публично доступных «навыков» (skills) ИИ-агентов показал, что более половины из них нарушают опубликованную спецификацию, а 7,8% агенты даже не могут выбрать из-за отсутствия необходимых метаданных. Эти дефекты ставят под угрозу надежность любой системы, которая автоматически обнаруживает и загружает такие навыки.
Почему этот аудит важен
Реестры навыков агентов позволяют разработчикам публиковать многоразовые возможности — пакеты кода, которые автономный агент может вызывать по требованию. Агент сканирует реестр, считывает YAML-frontmatter каждого навыка (небольшой блок структурированного текста, который должен содержать как минимум название и описание) и решает, соответствует ли навык его целям. Если frontmatter отсутствует или сформирован некорректно, навык исчезает из меню агента. В мире, где автономные агенты планируют встречи, устраняют неполадки на серверах и многое другое, неисправный навык нарушает весь рабочий процесс.
Что показывают цифры
- 57,8% навыков имеют хотя бы одно нарушение спецификации.
- 29,2% указывают имя, которое не совпадает со slug реестра (идентификатором в URL).
- 18,1% содержат неверные пути к пакетам или битые ссылки.
- 7,8% (192 навыка) вообще не имеют YAML-frontmatter, оставаясь безымянными и неописанными.
- 3,8% содержат абсолютные пути к файлам, которые существуют только на машине автора.
- 2,4% неправильно используют поле
allowed-tools, из-за чего оно становится нечитаемым для агентов. - 2,1% раскрывают API-ключи через переменные окружения, что является серьезным риском безопасности.
- 1,3% вызывают внешние инструменты командной строки без их объявления, нарушая правило переносимости.
Чаще всего встречается проблема переносимости. Абсолютный путь, такой как /home/USER/.local/bin/tool, работает у разработчика, написавшего навык, но не работает у любого другого пользователя, вызывая ошибки во время выполнения, которые статические проверки никогда не отлавливают.
Более глубокий анализ: случай openclaw
Аудит также затронул 46 навыков, входящих в репозиторий openclaw. После доработки скрипта тестирования для подавления ложных срабатываний ревьюер обнаружил 59 реальных дефектов — напоминание о том, что слишком агрессивные линтеры могут давать обратный эффект. Когда инструмент помечает слишком много безобидных проблем, разработчики перестают им пользоваться, и реальные проблемы проскакивают мимо.
Два дефекта openclaw указывали на файлы, которых больше нет в репозитории. Мейнтейнер объединил исправление, которое восстанавливает недостающие ссылки, показав, как один pull request может очистить разорванную цепочку зависимостей.
Реакция разработчиков
Аудитор открыл issue в оригинальных репозиториях навыков. Один отчет был отклонен: мейнтейнер аргументировал это тем, что «неисправность» следует оценивать по фактическому поведению во время выполнения, а не по статической проверке файлов. Аудитор согласился, что строгое определение неисправности должно соответствовать тому, как навык исполняется на практике. Другой issue был принят, и соответствующее исправление уже опубликовано.
Кто выиграет, а кто проиграет
- Агенты и конечные пользователи получают более плавное и предсказуемое поведение, когда реестр содержит только соответствующие стандартам и переносимые навыки.
- Авторы навыков получают более четкие правила валидации, которые отлавливают ошибки до публикации, сокращая количество переписки при разборе issue.
- Операторы реестров должны создавать или интегрировать более строгие конвейеры валидации; без них экосистема рискует потерять доверие.
Слабая валидация поощряет подход «быстро и грязно», что может привести к поломке агентов в рабочей среде, потенциально вызывая дорогостоящие простои или угрозы безопасности.
Контраргумент: все ли нарушения критичны?
Some argue that certain “errors” are harmless. Несовпадение имени может не повлиять на агента, который выбирает навыки по slug, а не по отображаемому имени. Чтение API-ключей из окружения может быть осознанным проектным решением для локальной разработки. Однако проценты в аудите рассматривают любое отклонение от спецификации как нарушение, что может преувеличивать практическую значимость некоторых проблем.
На что обратить внимание в будущем
- Улучшенные линтеры, которые отделяют реальные ошибки переносимости от безобидных особенностей.
- Хуки валидации на стороне реестра, которые отклоняют заявки без необходимого frontmatter или с абсолютными путями.
- Аудиты силами сообщества, выявляющие скрытые дефекты до того, как они попадут к рабочим агентам.
- Потенциальные пересмотры спецификации, уточняющие неоднозначные поля, такие как
allowed-tools, и определяющие допустимое использование переменных окружения.
Следующая волна инструментов, вероятно, внедрит эти проверки в конвейеры непрерывной интеграции (CI), превращая соблюдение стандартов из ручного дополнения в автоматический фильтр.
Итог
Большинство публично доступных навыков ИИ-агентов не проходят базовые проверки на соответствие, а значительная их часть вообще не может быть выбрана. Полученные результаты подчеркивают острую необходимость в более строгой валидации, улучшенных инструментах линтинга и культуре сообщества, в которой соблюдение спецификации является обязательным условием для публикации. Пока эти защитные механизмы не будут внедрены, агенты по-прежнему будут спотыкаться о хрупкие и непереносимые навыки.