Modern QA2026Agent Skills для управления браузером в автоматизации UI-тестирования: Полное руководство QA-инженера
Join

Course01 Agent Skills for Browser Automation

Cutting-edge · Chapter 01

Agent Skills для управления браузером в автоматизации UI-тестирования: Полное руководство QA-инженера

Updated Jul 2026

Подготовлено для: мягкого введения QA-инженера в роли, предполагающие активное использование ИИ. Фокус: Управление браузером через agent skills (не MCP-серверы), построение ИИ-расширенного фреймворка автоматизации тестирования и способность грамотно обсуждать это с разработчиками уровня архитектора.

Содержание

1. Основы: Как работают Agent Skills

2. Глубокое погружение в Vibium

3. Skills vs MCP: Когда и почему

4. Построение ИИ-фреймворка автоматизации тестирования

5. Протокол WebDriver BiDi

6. Подготовка к собеседованию

7. Конкурентный ландшафт

1. Основы

Подпапка: Foundations

Что такое Agent Skills?

Agent skills — это переиспользуемые пакеты возможностей для ИИ-агентов, работающих с кодом. В отличие от MCP-серверов, которые предоставляют схемы инструментов через протокол (добавляя тысячи токенов в контекст), навыки внедряют процедурные знания — markdown-файл, который учит агента как выполнять предметно-специфичные задачи, используя существующие инструменты (Bash, Read, Write и т.д.).

Ключевое понимание: Skills не добавляют новые инструменты. Они учат агента, как использовать существующие инструменты для конкретной предметной области.

Контракт SKILL.md

Каждый навык определяется одним файлом SKILL.md с двумя секциями:

---
name: vibe-check        # Нижний регистр, только дефисы, макс. 64 символа
description: |           # Сигнал для выбора — Claude читает это, чтобы решить, подходит ли навык
  Browser automation via CLI. Navigate pages, click elements,
  fill forms, take screenshots, extract text.
allowed-tools: Bash      # Какие инструменты навык может использовать
---

# Инструкции для агента (содержимое в формате markdown)
The `vibe-check` CLI automates Chrome via the command line...

Как работает выбор навыка

Алгоритмической маршрутизации нет. Claude получает форматированный список всех доступных навыков внутри описания инструмента Skill. Когда пользователь просит что-то вроде «сделай скриншот этой страницы», языковая модель Claude сопоставляет намерение с описаниями навыков через свой прямой проход — без эмбеддингов, без классификаторов, только понимание.

Как работает вызов навыка

Когда Claude решает вызвать навык:

  1. Пользователю показывается сообщение о загрузке
  2. Содержимое SKILL.md внедряется как скрытое системное сообщение в контекст разговора
  3. Разрешения на инструменты из allowed-tools временно предоставляются
  4. Claude выполняет инструкции навыка, используя доступные инструменты (преимущественно Bash для CLI-навыков)
  5. Разрешения возвращаются к исходным после завершения работы навыка

Ключевые файлы для чтения

  • 01-foundations/01-skill-anatomy.md — Полный разбор структуры SKILL.md с аннотированными примерами
  • 01-foundations/02-skill-lifecycle.md — Обнаружение, выбор, вызов, выполнение, завершение
  • 01-foundations/03-token-economics.md — Почему навыки стоят десятки токенов против тысяч для MCP

2. Глубокое погружение в Vibium

Подпапка: Vibium Deep Dive

Что такое Vibium?

Vibium — это инфраструктура автоматизации браузера, созданная создателем Selenium и Appium. Это единый бинарный файл Go (~10 МБ), который:

  • Запускает и управляет Chrome через WebDriver BiDi
  • Предоставляет 22 CLI-команды для управления браузером
  • Работает как daemon (браузер сохраняется между командами) или в режиме oneshot (новый браузер для каждой команды)
  • Также предоставляет MCP-сервер и клиентские библиотеки на JS/Python

Навык vibe-check

Навык vibe-check (из skills/vibe-check/SKILL.md) — это единственный файл SKILL.md, который обучает ИИ-агента всем 22 CLI-командам. При установке агент может управлять Chrome через Bash:

# Агент выполняет эти команды через инструмент Bash
vibe-check navigate https://app.example.com/login
vibe-check type "input[name=email]" "user@test.com"
vibe-check type "input[name=password]" "secret123"
vibe-check click "button[type=submit]"
vibe-check wait "h1"
vibe-check text "h1"                    # → "Welcome, User"
vibe-check screenshot -o dashboard.png

Архитектура: Sense → Think → Act

Дорожная карта Vibium следует циклу управления из робототехники:

Уровень Компонент Статус Назначение
Act Clicker Выпущен (V1) Автоматизация браузера через BiDi
Sense Retina Планируется V2 Расширение Chrome, наблюдающее за всем
Think Cortex Планируется V2 Память на SQLite + планирование навигации

Пять проверок интерактивности

Перед любым взаимодействием Vibium выполняет проверки на стороне сервера (в Go, не в клиентском коде):

  1. Visible — Элемент имеет ненулевой размер, не display:none и не visibility:hidden
  2. Stable — Позиция не изменилась за 50 мс (отлавливает анимации)
  3. ReceivesEvents — Элемент не перекрыт другим элементом (проверка elementFromPoint)
  4. Enabled — Не disabled, не aria-disabled и не внутри отключённого <fieldset>
  5. Editable — (только для type) Принимает текстовый ввод, не readonly

Проверки выполняются в цикле опроса с интервалом 100 мс, пока все не пройдут или не истечёт тайм-аут (по умолчанию 30 с).

Daemon и Oneshot

Режим Как Подходит для
Daemon (по умолчанию) Фоновый процесс поддерживает браузер работающим Интерактивные сессии, цепочки команд
Oneshot Новый браузер для каждой команды, закрывается после CI-пайплайны, изолированные запуски тестов

Ключевые файлы для чтения

  • 02-vibium-deep-dive/01-cli-command-reference.md — Все 22 команды с примерами и граничными случаями
  • 02-vibium-deep-dive/02-actionability-checks.md — Пять проверок с реальным исходным кодом на JavaScript
  • 02-vibium-deep-dive/03-daemon-architecture.md — Модель процессов, очистка, предотвращение зомби-процессов
  • 02-vibium-deep-dive/04-extension-commands.md — Как работают vibium:find, vibium:click, vibium:type через BiDi

3. Skills vs MCP: Когда и почему

Подпапка: Skills vs Mcp

Ключевой компромисс

Аспект Skills (CLI) MCP-сервер
Стоимость токенов Десятки (SKILL.md ~200-500 строк) Тысячи (схемы инструментов + деревья доступности)
Управление состоянием Без состояния между командами (daemon управляет состоянием браузера) Постоянное соединение с богатой интроспекцией
Настройка npx skills add <repo> claude mcp add <name> -- <command>
Как агент взаимодействует Инструмент Bash выполняет CLI-команды Выделенные MCP-инструменты (browser_click и т.д.)
Обработка ошибок Коды выхода + stderr Структурированные JSON-ответы об ошибках
Лучше для Высокопроизводительных агентов, балансирующих множество задач Исследовательской автоматизации, циклов самовосстановления

Когда использовать Skills (CLI-подход)

  • Ваш агент выполняет не только браузерную работу (пишет код, запускает тесты, читает файлы)
  • Вам нужно минимизировать потребление контекстного окна
  • Вы хотите простые, компонуемые команды, которые сочетаются с другими CLI-инструментами
  • Вы в CI/CD-пайплайне, где стоимость токенов имеет значение
  • Документация Playwright сама признаёт, что CLI+Skills более эффективна по токенам

Когда использовать MCP

  • Исследовательское тестирование, где агенту нужна богатая интроспекция страницы
  • Самовосстанавливающиеся тестовые потоки, требующие итеративного рассуждения над структурой DOM
  • Длительные автономные рабочие процессы с непрерывным контекстом браузера
  • Вам нужен анализ дерева доступности для семантического понимания

Ключевые файлы для чтения

  • 03-skills-vs-mcp/01-architectural-comparison.md — Глубокое сравнение с диаграммами
  • 03-skills-vs-mcp/02-token-budget-analysis.md — Реальные цифры: сколько токенов стоит каждый подход
  • 03-skills-vs-mcp/03-hybrid-strategies.md — Совместное использование обоих в одном фреймворке

4. Построение ИИ-фреймворка автоматизации тестирования

Подпапка: Building Test Framework

Обзор архитектуры фреймворка

┌─────────────────────────────────────────────────────┐
│                    Test Runner                      │
│  (pytest / Jest / custom orchestrator)              │
├─────────────────────────────────────────────────────┤
│              AI Agent Layer (Claude Code)           │
│  ┌─────────────┐  ┌──────────────┐  ┌────────────┐  │
│  │ vibe-check  │  │ Test Skills  │  │ Reporting  │  │
│  │ skill       │  │ (custom)     │  │ skill      │  │
│  └──────┬──────┘  └──────┬───────┘  └─────┬──────┘  │
├─────────┼────────────────┼────────────────┼─────────┤
│         │    Bash Tool   │                │         │
│         ▼                ▼                ▼         │
│  ┌─────────────┐  ┌─────────────┐  ┌────────────┐   │
│  │ Vibium CLI  │  │ Test Utils  │  │ Report Gen │   │
│  │ (vibe-check)│  │ (scripts)   │  │ (scripts)  │   │
│  └──────┬──────┘  └─────────────┘  └────────────┘   │
│         │                                           │
│         ▼                                           │
│  ┌─────────────┐                                    │
│  │  Chrome     │                                    │
│  │  (BiDi)     │                                    │
│  └─────────────┘                                    │
└─────────────────────────────────────────────────────┘

Основные принципы проектирования

  1. Агент как оркестратор, а не исполнитель — ИИ-агент решает, что тестировать и как взаимодействовать, фреймворк обеспечивает механику
  2. Определения тестов на естественном языке — Тесты описывают намерение («проверить, что логин работает с валидными учётными данными»), а не реализацию
  3. Самовосстанавливающиеся селекторы — Когда селектор не срабатывает, агент использует vibe-check find-all и vibe-check text для поиска альтернатив
  4. Отладка через скриншоты — Каждый сбой создаёт скриншот + текст страницы для анализа агентом

Ключевые файлы для чтения

  • 04-building-test-framework/01-architecture-decisions.md — ADR для фреймворка
  • 04-building-test-framework/02-test-patterns.md — Паттерны для ИИ-управляемых тестов (навигация, формы, утверждения, извлечение данных)
  • 04-building-test-framework/03-ci-cd-integration.md — Запуск в GitHub Actions, безголовый режим, артефакты
  • 04-building-test-framework/04-reporting-and-observability.md — Что собирать, как представлять результаты
  • 04-building-test-framework/05-self-healing-strategies.md — Как агенты восстанавливаются после сломанных селекторов

5. Протокол WebDriver BiDi

Подпапка: Webdriver Bidi

Почему это важно для собеседования

WebDriver BiDi — это стандарт W3C, на котором построен Vibium. Его понимание показывает, что вы знаете уровень ниже инструментов — критически важно для разговоров на уровне архитектора.

Эволюция: WebDriver → CDP → BiDi

Протокол Год Транспорт Направление Владелец
WebDriver 2018 (W3C) HTTP+JSON Запрос/Ответ W3C
CDP 2017 WebSocket Двунаправленный Google
BiDi 2021+ WebSocket+JSON Двунаправленный W3C

BiDi объединяет лучшее из обоих: стандартизован как WebDriver, двунаправлен как CDP, кросс-браузерный по дизайну.

Как Vibium использует BiDi

Client (JS/Python/CLI)
    │
    ▼ WebSocket
Clicker (Go binary) ← BiDi Proxy
    │
    ▼ WebSocket
Chrome (BiDi endpoint)

Бинарный файл Go Vibium выступает как прокси между клиентами и Chrome. Он:

  • Направляет стандартные BiDi-команды напрямую в Chrome
  • Перехватывает пользовательские команды vibium:* и обрабатывает их на стороне сервера
  • Реализует проверки интерактивности, отправляя команды выполнения JavaScript в Chrome

Ключевые файлы для чтения

  • 05-webdriver-bidi/01-protocol-overview.md — Формат сообщений, сессии, команды и события
  • 05-webdriver-bidi/02-evolution-from-selenium.md — Исторический контекст от WebDriver до BiDi
  • 05-webdriver-bidi/03-vibium-extension-commands.md — Как vibium:find/click/type расширяют протокол

6. Подготовка к собеседованию

Подпапка: Interview Preparation

О чём будут спрашивать архитекторы

  1. «Почему бы просто не использовать Playwright/Selenium напрямую?» — Вам нужно сформулировать преимущество агентно-нативного подхода
  2. «Как вы обрабатываете нестабильные тесты с ИИ?» — Самовосстанавливающиеся селекторы, интеллектуальные повторы, анализ скриншотов
  3. «Какова ваша стратегия CI/CD?» — Безголовый режим, oneshot daemon, сбор артефактов, параллелизация
  4. «Как это масштабируется?» — Стоимость токенов, пулинг daemon, изоляция тестов
  5. «А как с поддержкой тестов?» — Ключевое преимущество: тесты на естественном языке + рассуждения агента снижают нагрузку на поддержку на 60-85%

Ключевые тезисы (Фреймворк «Три уровня»)

При обсуждении вашего фреймворка структурируйте ответы на трёх уровнях:

Уровень 1 — Что (для PM и нетехнических стейкхолдеров):

«Мы используем ИИ-агентов, которые могут управлять реальным браузером точно так же, как это сделал бы человек. Они читают страницы, нажимают кнопки, заполняют формы и проверяют результаты — но делают это через инструкции на естественном языке вместо хрупкого кода.»

Уровень 2 — Как (для старших инженеров):

«Агент использует CLI-навык vibe-check, который предоставляет 22 браузерные команды через Bash. Команды автоматически ожидают интерактивности элементов с помощью пяти серверных проверок. Браузер работает как daemon для скорости или в режиме oneshot для изоляции. Под капотом это WebDriver BiDi по WebSocket к Chrome.»

Уровень 3 — Почему (для архитекторов):

«Мы выбрали CLI skills вместо MCP для управления браузером из-за экономики токенов — SKILL.md стоит десятки токенов против тысяч для схем MCP-инструментов. Подход через навыки означает, что контекстное окно нашего агента остаётся доступным для рассуждений о логике тестов, анализа сбоев и написания кода. Протокол BiDi стандартизован W3C, что избавляет от привязки к вендору CDP. Проверки интерактивности реализованы на стороне сервера в Go, что обеспечивает единообразие для всех клиентских языков.»

Ключевые файлы для чтения

  • 06-interview-preparation/01-architect-qa-scenarios.md — 20 вопросов с подробными ответами
  • 06-interview-preparation/02-framework-presentation.md — Как презентовать ваш фреймворк за 5, 15 и 30 минут
  • 06-interview-preparation/03-buzzword-decoder.md — Что на самом деле подразумевают под «агентным тестированием», «самовосстановлением», «паттерном ReAct»

7. Конкурентный ландшафт

Подпапка: Competitive Landscape

Текущая карта (2026)

Инструмент Подход Лучше для Ограничение
Vibium CLI skill + BiDi Интеграция с ИИ-агентами, экономия токенов Молодая экосистема, только Chrome (V1)
Playwright MCP MCP-сервер + дерево доступности Глубокое понимание страницы, исследовательское тестирование Высокая стоимость токенов, раздувание контекста
browser-use Python-библиотека + модели зрения Визуальное тестирование, сложные интерфейсы Медленно (вызовы API зрения), дорого
agent-browser (Vercel) Snapshot + Refs Минимальное использование контекста (93% сокращение) Новый, ограниченная экосистема
Selenium 4+ WebDriver + поддержка BiDi Интеграция с корпоративным наследием Тяжеловесный, сложная настройка
testRigor NL-first коммерческая платформа Нетехнические тестировщики Привязка к вендору, стоимость

Ключевые файлы для чтения

  • 07-competitive-landscape/01-tool-comparison-matrix.md — Детальное сравнение по функциям
  • 07-competitive-landscape/02-when-to-use-what.md — Фреймворк принятия решений для выбора подходящего инструмента
  • 07-competitive-landscape/03-future-directions.md — Куда движется индустрия (ИИ-локаторы, Cortex/Retina, запись видео)

Краткий справочник: Команды навыка vibe-check

Навигация

Команда Назначение
vibe-check navigate <url> Перейти на страницу
vibe-check url Вывести текущий URL
vibe-check title Вывести заголовок страницы

Чтение контента

Команда Назначение
vibe-check text Получить весь текст страницы
vibe-check text "<selector>" Получить текст конкретного элемента
vibe-check html Получить HTML страницы
vibe-check find "<selector>" Информация об элементе (тег, текст, ограничивающий прямоугольник)
vibe-check find-all "<selector>" Все совпадающие элементы
vibe-check eval "<js>" Выполнить JavaScript и вывести результат
vibe-check screenshot -o file.png Сделать скриншот

Взаимодействие

Команда Назначение
vibe-check click "<selector>" Кликнуть по элементу
vibe-check type "<selector>" "<text>" Ввести текст в поле
vibe-check hover "<selector>" Навести курсор на элемент
vibe-check scroll [direction] Прокрутить страницу
vibe-check keys "<combo>" Нажать клавиши (Enter, Ctrl+a и т.д.)
vibe-check select "<selector>" "<value>" Выбрать вариант из выпадающего списка

Ожидание

Команда Назначение
vibe-check wait "<selector>" Ожидать элемент (visible/hidden/attached)

Вкладки

Команда Назначение
vibe-check tabs Список открытых вкладок
vibe-check tab-new [url] Открыть новую вкладку
vibe-check tab-switch <index|url> Переключить вкладку
vibe-check tab-close [index] Закрыть вкладку

Daemon

Команда Назначение
vibe-check daemon start Запустить фоновый браузер
vibe-check daemon status Проверить статус работы
vibe-check daemon stop Остановить daemon

Рекомендуемый порядок чтения

Для эффективной подготовки читайте в следующем порядке:

  1. Начните здесь: 01-foundations/01-skill-anatomy.md — поймите, с чем вы работаете
  2. Затем: 03-skills-vs-mcp/01-architectural-comparison.md — ключевое архитектурное решение
  3. Затем: 02-vibium-deep-dive/01-cli-command-reference.md — сам инструмент
  4. Затем: 02-vibium-deep-dive/02-actionability-checks.md — «как это работает под капотом», что впечатляет архитекторов
  5. Затем: 04-building-test-framework/01-architecture-decisions.md — дизайн вашего фреймворка
  6. Затем: 05-webdriver-bidi/01-protocol-overview.md — стандарт, лежащий в основе всего
  7. Затем: 06-interview-preparation/01-architect-qa-scenarios.md — практика ответов
  8. В завершение: 07-competitive-landscape/01-tool-comparison-matrix.md — знание альтернатив

Исходный репозиторий

Весь анализ основан на: VibiumDev/vibium (Apache 2.0, 2.6K+ звёзд, v0.1.7)

Ключевые первоисточники:

Дополнительные источники: