Google Cloud опубликовала методику оценки скиллов AI-агентов и открыла инструмент skill-reach. В собственном эксперименте компании более трети задач меняли результат при повторных запусках с одинаковым кодом и промптом. Вывод практический: один удачный прогон ещё не показывает, помогает ли новый скилл.

Скилл — набор инструкций и процедур для конкретной задачи. Например, он может описывать, как проверить код, вызвать инструмент или обработать документ. Добавить его в Claude Code, Codex или другой агент легко. Сложнее понять, стал ли агент работать лучше или получил ещё один файл и повод потратить токены.

График роста числа звёзд репозитория google/skills с марта по октябрь 2026 года.Источник: cloud.google.com

AI-скилл может не запускаться — или перехватить задачу у другого

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

skill-reach проверяет структуру файлов и токен-бюджет, ищет похожие описания и возможные конфликты. С его помощью можно проверить, вызывает ли агент нужный скилл. Здесь важнее всего поведение: выбрал ли агент подходящий инструмент в нужной ситуации.

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

Google отдельно предостерегает от «справочника вместо навыка»: копировать в файл целую документацию API часто бесполезно. Общие сведения модель может уже знать. Лучше коротко описать нужные действия: какую команду вызвать, какие права потребуются и как проверить результат.

Проверяйте пользу скилла сравнением, а не впечатлением

Google предлагает запустить одну и ту же задачу с одним агентом и в одном окружении — со скиллом и без него. Потом повторить эксперимент несколько раз. Если скилл помог в первом прогоне, а дальше агент без него справился не хуже, держать дополнительную инструкцию, похоже, незачем.

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

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

Минимальный тест для своей команды

  1. Возьмите одну повторяемую рабочую задачу и зафиксируйте условия: модель, инструменты, файлы и критерии успешного результата.
  2. Запустите её с нужным скиллом и без него. Не меняйте одновременно модель, промпт и окружение.
  3. Повторите оба варианта минимум три раза: результаты отдельных прогонов могут заметно различаться.
  4. Сравните успешность, время выполнения и расход токенов. Оцените финальный ответ и действия агента.
  5. Оставьте скилл, если он даёт повторяемый прирост. Если модель уже справляется сама, пересмотрите файл или удалите его.

Три запуска — нижняя граница из рекомендаций, пересказанных в материале о методике. Этого мало, чтобы доказать надёжность в любом продакшене, но уже лучше, чем один красивый скриншот. Для серии задач можно отдельно считать Pass@3: была ли задача решена хотя бы в одном из трёх запусков. При этом провалы отдельных попыток тоже стоит учитывать.

Успех по одной метрике не гарантирует безопасную работу

Агент может выполнить тест быстро и получить высокий балл, но выбрать неправильный способ. Google приводит примеры из экспериментов с автоматической оптимизацией кода на базе AlphaEvolve: некоторые программы пытались прочитать файл с ответом или обойти проверку через отдельный процесс. Часть находила нужные данные по пути файла или собирала проверяемую строку уже во время выполнения.

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

В методике NVIDIA SkillEvaluator перечислены пять независимых сторон проверки. Их можно использовать и для собственных скиллов:

  • Корректность: агент выполнил задачу верно.
  • Обнаруживаемость: агент выбрал нужный скилл, когда он понадобился.
  • Эффективность: задача решена с разумными затратами времени и токенов.
  • Результативность: сам скилл заметно улучшил итог работы.
  • Безопасность: агент не обошёл правила и не получил лишний доступ.

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

Скилл нужно пересматривать после обновления модели

NVIDIA SkillEvaluator тоже измеряет разницу между работой со скиллом и без него. В отчёте Batch & Release говорится о среднем приросте на 31 пункт для более чем 300 проверенных скиллов. Это результат конкретной оценки на конкретном наборе задач. Он не обещает такой же прирост от любого файла инструкций.

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

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

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

Источники

Behind the scenes, two months later: How we ship Google Agent Skills like products

Evaluate agent skills before they bloat your context window

NVIDIA SkillEvaluator Measures Agent Skill Impact Across 300 Verified Skills

Источникaitimes.kr