Что именно нужно тестировать в Agent Skill?
Проверяйте два независимых слоя: triggering — выбрал ли агент нужный skill, и output quality — улучшил ли он результат. Навык может отлично работать при ручном запуске, но не выбираться автоматически, или выбираться без пользы.
| Слой | Главный вопрос |
|---|---|
| Discovery | Видит ли клиент правильную версию skill? |
| Triggering | Выбирается ли skill на целевых и не выбирается на чужих запросах? |
| Execution | Выполняются ли инструкции и scripts без скрытой ошибки? |
| Outcome | Проходит ли результат наблюдаемые критерии? |
Если skill вообще не виден или не запускается, сначала пройдите пошаговую диагностику.
Как составить первые eval-кейсы?
Начните с двух-трёх реальных задач. Для каждой сохраните prompt, входные файлы и человеческое описание успешного результата; добавляйте assertions после первого прогона, когда увидите фактический выход.
- Используйте естественные формулировки из работы, а не ключевые слова description.
- Меняйте уровень детализации, стиль и порядок вводных.
- Подкладывайте обезличенные, но реалистичные файлы.
- Фиксируйте версию skill, модели, клиента и окружения.
- Не подгоняйте один тест под случайный удачный ответ.
Официальная методика Agent Skills предлагает хранить кейсы в `evals/evals.json`. Это удобный формат, но важнее воспроизводимость и полные входы, чем конкретное имя файла.
Какие trigger-тесты нужны?
Добавьте прямые позитивные запросы, близкие отрицательные и пограничные случаи. Сильный negative test использует похожую лексику, но требует другого процесса — именно он показывает, насколько точно работает description.
| Тип | Ожидание |
|---|---|
| Позитивный | Skill выбирается и загружает правильную версию |
| Близкий негативный | Похожая задача выполняется без этого skill |
| Пограничный | Агент уточняет вход, а не угадывает |
| Явный вызов | Изолирует discovery от автоматического выбора |
Для настройки коротких метаданных используйте формулу description в SKILL.md.
Зачем сравнивать with-skill и without-skill?
Одинаковый кейс без skill показывает базовую способность модели. Сравнение помогает не приписать навыку результат, который агент и так получает, и увидеть цену улучшения во времени и токенах.
- Запускайте сравнение в изолированных сессиях.
- Используйте одинаковые входы, модель и настройки.
- Не показывайте baseline результат второй конфигурации.
- Повторяйте нестабильные кейсы несколько раз.
- Считайте не только pass rate, но и стоимость успешной задачи.
Для продуктового решения свяжите evals с общей методикой оценки эффективности Agent Skill.
Как написать хорошие assertions?
Assertion должен быть наблюдаемым и связанным с задачей: файл существует, JSON валиден, строк ровно N, обязательные разделы заполнены. Формулировки «ответ хороший» или точное совпадение всей фразы слишком слабы.
| Слабая проверка | Проверяемая замена |
|---|---|
| Отчёт качественный | Есть три рекомендации с источником и следующим действием |
| Формат правильный | Файл проходит JSON Schema |
| Ответ выглядит красиво | Заголовок, подписи и единицы измерения присутствуют |
| Текст совпал с образцом | Смысловые поля заполнены, формулировка может отличаться |
Механические условия проверяйте script. Стиль, полезность и уместность оставляйте человеческому ревью либо слепому сравнению по заранее заданной рубрике.
Какие доказательства сохранять?
Для каждого assertion записывайте PASS или FAIL и ссылку на конкретный артефакт, строку, размер или измерение. Сводный процент без evidence не помогает понять, что исправлять.
- Исходный prompt и входные файлы.
- Фактически загруженная версия skill.
- Полный результат и созданные артефакты.
- Assertion, решение и конкретное evidence.
- Время, токены и число повторных попыток.
- Комментарий человека по качествам, которые трудно автоматизировать.
Для детерминированного подтверждения результата можно добавить validator и evidence.
Как улучшать skill по результатам evals?
Исправляйте повторяющийся корень ошибки, а не конкретную формулировку одного кейса. После изменения запускайте весь набор в новой итерации и сравнивайте pass rate, разброс, время и токены.
- 1. Сгруппируйте сбои
Отделите trigger, инструкцию, script, окружение и неверный assertion.
- 2. Сделайте одно изменение
Уточните границу, добавьте пример или упростите лишний шаг.
- 3. Перезапустите весь набор
Локальная победа не должна сломать соседние кейсы.
- 4. Сравните с baseline
Проверьте, сохранился ли реальный вклад skill.
- 5. Проведите human review
Assertions не покрывают неожиданные дефекты и общий смысл.
Какой тестовый гейт нужен перед выпуском?
Выпускайте версию, когда целевые запросы стабильно активируют skill, близкие негативные не активируют его, обязательные assertions проходят с evidence, baseline сравнение показывает полезный вклад, а человек проверил реальные артефакты.
- Версии модели, клиента, skill и fixtures зафиксированы.
- Positive, negative и boundary кейсы пройдены.
- With-skill сравнивается с without-skill.
- Каждый PASS имеет доказательство.
- Время и токены не скрыты.
- Есть regression-набор для следующего обновления.
- Результат проверен человеком на реальной полезности.
Автоматическую часть гейта подключите к CI-проверке Agent Skills.