Что такое hwatu и какую проблему он решает
hwatu - открытый инструмент с лицензией MIT, написанный на Rust, для верификации браузерных AI-агентов. Он использует headless WebKit вместо Chromium, анализирует DOM и выполняет pixel-diff с точным процентным совпадением скриншотов. Инструмент создан для разработчиков, которые запускают локальных кодинг-агентов и нуждаются в быстрой, легковесной проверке их визуального вывода.
Проблема очевидна: количество AI-агентов, генерирующих HTML, CSS и JavaScript, растёт экспоненциально. Тестировать их вывод в браузерном окружении сложно. Playwright и Puppeteer - мощные инструменты, но они заточены под end-to-end тестирование веб-приложений и кросс-браузерную совместимость. Для задачи «сгенерировал ли агент корректную страницу и совпадает ли она с эталоном» эти фреймворки избыточны. Они требуют Chromium, который тянет за собой сотни мегабайт зависимостей и потребляет значительный объём памяти. hwatu предлагает альтернативу: минималистичный, сфокусированный инструмент, который делает ровно то, что нужно для верификации.
Ключевая ценность - сочетание трёх компонентов: headless WebKit, который уже присутствует в macOS и доступен через WebKitGTK на Linux; попиксельное сравнение скриншотов с настраиваемым порогом совпадения; и анализ DOM-дерева для структурной проверки. Всё это упаковано в быстрый бинарник на Rust без внешних зависимостей.
Архитектура hwatu: Rust, headless WebKit и pixel-diff
Архитектурно hwatu состоит из трёх слоёв: управляющий слой на Rust, слой рендеринга через headless WebKit и слой верификации, который включает DOM-анализ и pixel-diff. Управляющий слой отвечает за запуск браузерного движка, загрузку страницы, ожидание завершения рендеринга и передачу результата в слой проверки. Rust здесь даёт контроль над памятью и предсказуемую производительность без сборщика мусора - критичное свойство для CI/CD пайплайнов, где важна каждая секунда.
Почему Rust и WebKit, а не Chromium
Playwright и Puppeteer используют Chromium в качестве браузерного движка. Chromium - полнофункциональный браузер с поддержкой расширений, синхронизации, мультимедиа и десятков других подсистем. Для задачи «отрендерить HTML и сделать скриншот» это избыточно. Установка Chromium в CI-окружении требует дополнительных зависимостей на уровне ОС, а размер образа контейнера увеличивается на 300-500 МБ.
WebKit - легковесный движок, который встроен в macOS и доступен на Linux через пакет WebKitGTK. Он не требует отдельной установки браузера. В macOS headless-режим WebKit работает через системные фреймворки, на Linux - через минимальный набор библиотек GTK. Размер контейнера с hwatu и WebKitGTK получается в 3-4 раза меньше, чем с Chromium.
Rust дополняет картину: отсутствие рантайма, компиляция в нативный код и нулевые накладные расходы на управление памятью. Инструмент стартует мгновенно, без прогрева JIT-компилятора, что важно при запуске сотен тестов в пайплайне. Для сравнения: Puppeteer на Node.js тратит 1-2 секунды только на загрузку рантайма перед первым действием.
Как работает pixel-diff в hwatu
Pixel-diff в hwatu реализован как попиксельное сравнение двух скриншотов - эталонного и текущего. Алгоритм проходит по каждому пикселю обоих изображений, вычисляет разницу в цветовых каналах и агрегирует результат в процент несовпадающих пикселей. Разработчик задаёт порог: например, 99% означает, что допустимо не более 1% различающихся пикселей. Если реальный процент совпадения ниже порога, тест считается проваленным.
Типовой сценарий: вы сохраняете эталонный скриншот страницы, которую должен сгенерировать AI-агент. При каждом запуске теста hwatu загружает вывод агента в headless WebKit, делает скриншот и сравнивает его с эталоном. Если агент изменил вёрстку, сломал CSS или добавил лишний элемент - процент различий превысит порог, и пайплайн сообщит о регрессии.
В отличие от поверхностных проверок на наличие элемента через селекторы, pixel-diff ловит визуальные дефекты, которые не видны в DOM: смещение на 1px, изменение шрифта из-за отсутствующего файла, неправильный цвет фона. Это критично для кодинг-агентов, которые генерируют пользовательские интерфейсы - Pre2Prod и аналогичные инструменты часто допускают визуальные артефакты, незаметные при беглом просмотре кода.
Сравнение hwatu с Playwright и Puppeteer для верификации AI-агентов
Прямое сравнение помогает понять, когда выбирать hwatu, а когда - проверенные фреймворки. Все три инструмента умеют запускать headless-браузер и делать скриншоты. Различия - в деталях.
| Критерий | hwatu | Playwright | Puppeteer |
|---|---|---|---|
| Движок | WebKit | Chromium, WebKit, Firefox | Chromium, Firefox |
| Язык | Rust | JavaScript, Python, .NET, Java | JavaScript |
| Размер контейнера | ~100 МБ (с WebKitGTK) | ~500 МБ (с Chromium) | ~450 МБ (с Chromium) |
| Время холодного старта | < 100 мс | 1-3 с | 1-2 с |
| Точность pixel-diff | Попиксельное, процент совпадения | Скриншотные снапшоты (toHaveScreenshot) | Отсутствует (только ручное сравнение) |
| Симуляция действий | Минимальная (фокус на верификации) | Полная (клики, ввод, навигация) | Полная (клики, ввод, навигация) |
| Лицензия | MIT | Apache 2.0 | Apache 2.0 |
Playwright и Puppeteer - фреймворки для автоматизации браузера. Они предоставляют высокоуровневые API для симуляции пользовательских действий: клики, ввод текста, навигация по страницам, работа с iframe, перехват сетевых запросов. Это необходимо для E2E-тестирования веб-приложений, где сценарий включает аутентификацию, заполнение форм и проверку ответов сервера.
hwatu не пытается конкурировать в этой нише. Его задача - загрузить HTML-страницу, дождаться рендеринга и проверить результат. Никаких кликов, никакой навигации. Это осознанное ограничение, которое делает инструмент проще и быстрее.
Когда выбрать hwatu, а когда - Playwright
Выбирайте hwatu, если:
- Вы тестируете локального кодинг-агента, который генерирует статические HTML/CSS/JS-страницы
- Вам нужна быстрая проверка визуального вывода в CI/CD с минимальным размером образа
- Вы работаете на macOS или Linux и хотите использовать системный WebKit без установки браузера
- Критичен точный процент визуального совпадения, а не булево «похоже/не похоже»
Выбирайте Playwright, если:
- Вам нужно полноценное E2E-тестирование с пользовательскими сценариями
- Требуется кросс-браузерная проверка (Chromium, WebKit, Firefox)
- Сценарий включает аутентификацию, работу с куками, перехват и модификацию сетевых запросов
- Вы пишете тесты на JavaScript, Python или другом языке с готовыми биндингами Playwright
Инструменты не исключают друг друга. Типичный пайплайн для тестирования AI-агентов может использовать Playwright для сложных сценариев взаимодействия и hwatu для быстрой валидации визуального вывода на каждом коммите.
Практические сценарии: тестирование локальных кодинг-агентов в 2026
Тренд 2026 года - запуск AI-агентов полностью локально, без облачных API. Модели с открытыми весами достигли уровня, достаточного для генерации качественного фронтенд-кода. Разработчик запускает кодинг-агента на своей машине или в корпоративном кластере, агент генерирует HTML/CSS/JS, и этот вывод нужно проверить до того, как он попадёт в прод. Здесь и нужен hwatu.
Сценарий: агент на базе локальной модели (например, DeepSeek Coder V3 или Qwen 3.5 Coder) получает задачу «создать страницу дашборда с графиком». Агент генерирует index.html, styles.css и app.js. hwatu запускает headless WebKit, загружает index.html, ждёт выполнения JavaScript и отрисовки графика, делает скриншот и сравнивает с эталоном. Если график не отрисовался из-за ошибки в app.js - pixel-diff покажет значительное расхождение. Если вёрстка поехала на 2 пикселя - расхождение будет небольшим, но заметным при пороге 99%.
DOM-анализ добавляет структурную проверку: наличие всех требуемых элементов, правильную вложенность, отсутствие мусорных тегов. Агент может сгенерировать визуально похожую страницу с совершенно другой структурой DOM - pixel-diff пропустит, а DOM-проверка отловит.
Интеграция hwatu в CI/CD пайплайн
Пример конфигурации для GitHub Actions на Linux-раннере:
name: Verify agent output
on: [push]
jobs:
visual-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Install WebKitGTK
run: sudo apt-get install -y libwebkit2gtk-4.1-dev
- name: Download hwatu binary
run: curl -L https://github.com/user/hwatu/releases/latest/download/hwatu-linux -o hwatu && chmod +x hwatu
- name: Run visual verification
run: ./hwatu verify --html agent-output/index.html --baseline baselines/dashboard.png --threshold 99
Ключевые моменты для production-пайплайна: кэшируйте эталонные скриншоты между запусками, чтобы не загружать их заново; запускайте тесты параллельно для разных страниц, если агент генерирует несколько файлов; храните эталоны в репозитории или артефактах CI.
Подход с верификацией каждого вывода агента перекликается с паттернами, описанными в архитектуре LLM-агентов с верификацией: контур проверки должен быть встроен в процесс, а не добавлен постфактум. hwatu даёт готовый строительный блок для такого контура в задачах фронтенд-генерации.
Ограничения и когда hwatu не подходит
Честно обозначим границы. hwatu не заменяет Playwright или Puppeteer для задач автоматизации браузера. У него нет API для симуляции кликов, ввода текста или навигации. Если ваш сценарий тестирования требует «залогиниться, перейти на страницу профиля, нажать кнопку редактирования», hwatu не подойдёт.
Второе ограничение - только WebKit. Кросс-браузерное тестирование на Chromium и Firefox невозможно. Если ваш продукт должен работать во всех браузерах, hwatu может быть частью пайплайна для быстрой проверки, но не заменит полный набор тестов.
Третье - язык. Расширение функциональности требует написания кода на Rust. Для команд, которые работают на Python или TypeScript, это дополнительный порог входа. Готовые биндинги для других языков пока отсутствуют.
Лицензия, сообщество и планы развития
hwatu распространяется под лицензией MIT. Исходный код открыт, репозиторий доступен на GitHub. Лицензия MIT разрешает свободное использование, модификацию и распространение, включая коммерческие проекты, без обязательства открывать производный код.
Проект находится в активной разработке. Текущий фокус - стабилизация core-функциональности: pixel-diff, DOM-анализ и интеграция с WebKitGTK на Linux. В дорожной карте заявлены:
- Поддержка Windows через WebKit для Windows
- Расширение API для базовой симуляции действий (загрузка страницы с параметрами, ожидание селекторов)
- Интеграция с популярными тестовыми фреймворками через формат JUnit XML
- Дифференциальные скриншоты - подсветка различающихся областей на итоговом изображении
Проект приветствует контрибьюторов. Основной стек - Rust и системные биндинги к WebKit. Если вы работаете с локальными AI-агентами и сталкивались с проблемами верификации их вывода, присоединение к разработке hwatu - способ получить инструмент, заточенный именно под вашу задачу. Пул реквесты, баг-репорты и предложения по API принимаются в репозитории проекта.