Гибридные стратегии: Совместное использование Skills и MCP

Updated Jul 2026

Почему гибридный подход?

Skills и MCP имеют сильные стороны, которых нет у другого:

Гибридный подход использует MCP для понимания и Skills для действий.

Стратегия 1: MCP для обнаружения, Skills для выполнения

Паттерн

Фаза 1: Обнаружение (MCP)
  Агент: "Что на этой странице?"
  → browser_snapshot() возвращает дерево доступности
  → Агент определяет: форма входа с #email, #password, button.submit

Фаза 2: Выполнение (Skill)
  Агент: "Теперь я знаю селекторы. Выполнить тест."
  → vibe-check type "#email" "user@test.com"
  → vibe-check type "#password" "secret"
  → vibe-check click "button.submit"

Стоимость токенов

Фаза обнаружения:  ~5 000 токенов (однократное чтение дерева доступности)
Фаза выполнения:   ~500 токенов (5 CLI-команд)
Итого:             ~5 500 токенов

vs. Чистый MCP:    ~25 000 токенов (все шаги через MCP-инструменты)
vs. Чистый Skill:  ~500 токенов (но нужно знать селекторы заранее)

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

• Новые приложения, где вы не знаете структуру DOM
• UI, который часто меняется — фаза обнаружения адаптируется автоматически
• Первый запуск теста новой функции — последующие запуски используют закешированные селекторы

Стратегия 2: Skill по умолчанию, MCP как резерв

Паттерн

# Псевдокод поведения агента
try:
    # Основной: использовать skill (быстро, дёшево)
    vibe-check click "button.submit"
except SelectorNotFound:
    # Резерв: использовать MCP для понимания страницы
    snapshot = browser_snapshot()  # MCP-инструмент
    # Агент рассуждает о дереве доступности
    # Агент находит правильный селектор
    new_selector = agent.reason(snapshot, "find the submit button")
    vibe-check click new_selector  # Обратно к skill

Стоимость токенов

Успешный путь (skill работает): ~130 токенов
Резервный путь (нужен MCP):     ~5 130 токенов (один снимок + повтор)
Среднее (при 90% успехе):       ~630 токенов за шаг

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

• Зрелые тестовые наборы, где большинство селекторов стабильны
• Самовосстанавливающиеся тесты, адаптирующиеся при изменении UI
• Оптимизация стоимости — платить стоимость MCP только когда необходимо

Стратегия 3: Разные инструменты для разных типов тестов

Паттерн

Конфигурация

# test-framework-config.yaml
test_types:
  functional:
    tool: vibe-check
    mode: daemon
    headless: true

  accessibility:
    tool: playwright-mcp
    a11y_analysis: true

  visual:
    tool: vibe-check
    screenshots: true
    comparison_threshold: 0.98

  exploratory:
    tool: playwright-mcp
    snapshot_mode: full
    max_depth: 5

Стратегия 4: Поэтапное внедрение фреймворка

Фаза 1: Только Skills (недели 1-2)

Начните с простейшего подхода:

• Установить навык vibe-check
• Писать тесты с использованием известных CSS-селекторов
• Запускать в режиме daemon для разработки, oneshot для CI

# Простой тестовый скрипт
vibe-check navigate https://app.example.com/login
vibe-check type "#email" "test@example.com"
vibe-check type "#password" "password"
vibe-check click "#submit"
vibe-check wait ".dashboard"
vibe-check text ".welcome" | grep "Welcome"

Фаза 2: Добавить MCP для обнаружения (недели 3-4)

Когда вы сталкиваетесь с тестами, где селекторы неизвестны или нестабильны:

• Добавить Playwright MCP: claude mcp add playwright -- npx @playwright/mcp
• Использовать MCP только для обнаружения страницы и тестирования доступности
• Всё выполнение оставить на vibe-check

Фаза 3: Интеллектуальная маршрутизация (неделя 5+)

Построить логику маршрутизации, выбирающую правильный инструмент:

• Известные селекторы → skill
• Неизвестные страницы → MCP для обнаружения, затем skill для выполнения
• Тесты доступности → всегда MCP
• Запуски CI → только skill (оптимизация стоимости)

Реализация: Простой гибридный тест

Вот как выглядит гибридный тест на практике, как его выполнил бы агент:

Рассуждения агента: "Мне нужно протестировать поток входа на новой
переработанной странице. Я не знаю новые селекторы. Сначала обнаружу."

Шаг 1: Навигация (Skill — дёшево)
  → Bash: vibe-check navigate https://app.example.com/login

Шаг 2: Обнаружение структуры страницы (MCP — дорого, но необходимо)
  → browser_snapshot()
  → Агент получает дерево доступности:
    [role="form" name="Login"]
      [role="textbox" name="Email address" ref=3]
      [role="textbox" name="Password" ref=4]
      [role="button" name="Sign in" ref=5]
      [role="link" name="Forgot password?" ref=6]

Шаг 3: Агент сопоставляет семантические имена с селекторами
  → Агент рассуждает: поле "Email address" = textbox ref=3
  → Использует vibe-check find-all "input" --json для получения CSS-селекторов
  → Сопоставляет: email → "input[aria-label='Email address']"

Шаг 4: Выполнение теста (Skill — дёшево)
  → Bash: vibe-check type "input[aria-label='Email address']" "test@example.com"
  → Bash: vibe-check type "input[aria-label='Password']" "secret"
  → Bash: vibe-check click "button[name='Sign in']"
  → Bash: vibe-check wait ".dashboard"
  → Bash: vibe-check text ".welcome"

Шаг 5: Проверка + скриншот (Skill — дёшево)
  → Bash: vibe-check screenshot -o login-test-result.png

Итого: 1 вызов MCP (~5K токенов) + 7 вызовов skill (~900 токенов) = ~5 900 токенов
vs. Чистый MCP: ~35 000 токенов

Антипаттерны, которых следует избегать

Не надо: Использовать MCP для каждого клика

# ПЛОХО: Каждое действие через MCP
browser_click(ref=5)      # ~5K токенов (включает полное обновление снимка)
browser_type(ref=3, "hi") # ~5K токенов
browser_click(ref=7)      # ~5K токенов
# Итого: 15K+ токенов за 3 действия

Не надо: Использовать Skills для неизвестных страниц

# ПЛОХО: Угадывание селекторов
vibe-check click ".btn-primary"    # Может не существовать
vibe-check click "#submit"         # Неправильный ID
vibe-check click "button"          # Неправильная кнопка
# Потрачено 3 попытки + обработка ошибок

Надо: Соответствие инструмента задаче

# ХОРОШО: MCP для понимания, skill для действия
MCP: Что на этой странице?       → 5K токенов (однократное понимание)
Skill: Теперь нажать правильную кнопку → 130 токенов (точное действие)

Тезис для собеседования

«Наш фреймворк использует гибридный подход. Для известных тестовых потоков со стабильными селекторами мы используем CLI-навык vibe-check — он в 29 раз дешевле по токенам и быстрее. Для новых функций или страниц, где мы не знаем структуру DOM, мы используем Playwright MCP для обнаружения макета страницы через деревья доступности, а затем переключаемся обратно на навык для выполнения. Мы также используем MCP исключительно для аудитов доступности, где семантический анализ страницы — это суть. Это даёт нам эффективность CLI-навыков для 90% нашей работы и богатство MCP, когда оно действительно необходимо.»