Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
WebHarbor позволяет обучать и проверять веб-агентов с графическим интерфейсом, не привязывая испытания к постоянно меняющимся сайтам. Команда Zhaoyang Wang показала сопоставимый с ведущими открытыми GUI-агентами результат на нескольких наборах испытаний, хотя работа не рецензирована и числа в ней получили сами авторы. Для разработки это означает, что сложные сценарии можно воспроизводить в управляемой среде, а не каждый раз заново согласовывать с состоянием живого сервиса.
Живые сайты заменили исполняемыми реконструкциями
Проверять GUI-агента на настоящем сайте неудобно: контент меняется, доступ могут ограничить, а сценарии после входа в учётную запись трудно повторять в одинаковых условиях. Два запуска одного задания способны привести агента к разным страницам не из-за его решения, а из-за состояния самого сервиса.
Синтетические сайты решают проблему стабильности, но часто упрощают интерфейс и логику. Агент может научиться нажимать нужную кнопку в макете, однако такой результат мало говорит о работе с настоящим продуктом, где действие меняет данные и открывает следующий этап процесса.
WebHarbor занимает промежуточное положение. Каждая среда исполняется в контейнере Docker и воспроизводит интерфейс, содержимое и рабочие процессы реального веб-сервиса. При этом команда контролирует состояние среды: одинаковая последовательность действий должна приводить к одинаковому результату.
Такой подход отделяет качество агента от внешних изменений. Команда может закрепить одну сборку среды для сравнения моделей, а затем обновить её вместе с заданиями, когда агенту потребуется новый сценарий. Код и данные WebHarbor доступны публично, поэтому полигон можно изучить и адаптировать, а не только использовать как закрытый набор испытаний.
Задания расширяют среду, а люди проверяют результат
Среды развиваются от задач, а не от попытки заранее скопировать весь веб-сервис. Когда появляется новое задание, команда добавляет только те страницы, состояния и функции, которые нужны для его выполнения. Это ограничивает объём реконструкции, но сохраняет рабочую цепочку целиком.
Изменения реализуют агенты для программирования. Люди затем проверяют три свойства: похож ли интерфейс на исходный сервис, правильно ли работают функции и остаётся ли само задание корректным. Такая схема использует агентов для расширения полигона, но не передаёт им окончательную проверку среды, на которой будут обучаться другие агенты.
В набор вошли 153 исполняемые среды и 3 518 заданий. Среди них есть многошаговые процессы и действия после входа в учётную запись — именно такие цепочки сложно стабильно проверять на живых сайтах.
Для обучения с подкреплением (RL) использовали GUI-агента на базе Qwen уровня 4B. После обучения в WebHarbor он переносил навыки на ранее не встречавшиеся задания и конкурировал с ведущими открытыми веб-агентами на четырёх наборах испытаний.
Проверку проводили на одной указанной размерности модели и нескольких внешних наборах заданий; поскольку этот материал подготовлен по абстракту, из него нельзя восстановить методику сравнения, названия наборов и экономию на обучении.
WebHarbor меняет контур испытаний, но не выбор модели
Работа влияет прежде всего на инфраструктурный план. Если команда проверяет агента прямо на целевом сайте, ей приходится учитывать изменения интерфейса, ограничения доступа и нестабильные данные. Управляемая реконструкция переносит эти риски из каждого запуска в отдельный процесс поддержки среды.
Для продукта с действиями после авторизации это особенно заметно. Можно подготовить состояние учётной записи, провести агента через несколько связанных экранов и проверить конечный результат без обращения к внешнему сервису. Такой полигон подходит и для регрессионных испытаний: новая версия агента получает те же исходные условия, что и предыдущая.
Однако WebHarbor не даёт основания сразу менять выбранную модель. Работа показывает, что небольшой Qwen-агент способен перенести навыки за пределы учебных задач, но не раскрывает результаты по отдельным типам сайтов и сценариев. Перед внедрением всё равно потребуется воспроизвести собственные процессы продукта и проверить на них доступные модели.
Практический вывод касается порядка работ. Сначала стоит описать критические пользовательские цепочки и состояния данных, затем собрать для них управляемые среды и только после этого сравнивать агентов или запускать обучение с подкреплением. Иначе команда измерит не способность модели выполнить процесс, а её удачу при работе с очередной версией живого сайта.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
