Почему AI-агент браузера ломается на реальных интерфейсах
Записанный сценарий держится на жёстких путях к элементам: клик по третьему полю формы, XPath до кнопки, идентификатор, который разметка генерирует заново при каждой сборке. Пока интерфейс не менялся, AI-агент браузера проходит маршрут за минуты. Стоит переставить блоки, добавить баннер над формой или переименовать кнопку — шаг не находит цель, сценарий обрывается на середине, и очередь заявок встаёт до ручного разбора.
Отдельный класс — интерфейсы без программного интерфейса, где единственный канал — сама страница: внутренняя система, портал поставщика, кабинет банка. Выборка идёт только через разметку, а она живая — асинхронная подгрузка, ленивая отрисовка, модальные окна поверх полей, разные ветки для разных ролей. Фиксированная пауза тут не спасает: на быстром ответе робот бьёт по пустому месту, на медленном уходит дальше, не дождавшись данных.
Сбои на этапе ввода данных почти никогда не выглядят как ошибка. Поле перерисовалось после автодополнения, маска отбросила часть символов, невидимый слой перехватил клик — значение не записалось, но шаг формально завершён. Робот идёт дальше и оставляет заявку с пустым обязательным полем или суммой не из той строки; ловит это уже человек при сверке с первичкой.
Отсюда и сопровождение роботов: после каждой правки интерфейса инженер проходит шаги заново и чинит селекторы. Хрупкие сценарии автоматизации забирают время не на развитии процесса, а на латании. Ниже разбираем, как это закрывается.
Что даёт адаптивное управление интерфейсом вместо скриптов
Скрипт автоматизации держится на координатах и жёсткой последовательности действий: сдвинулась кнопка, поменялся порядок полей — сценарий падает. Агент читает интерфейс так же, как человек: разбирает разметку, подписи и визуальные признаки. Ниже — что это меняет в эксплуатации.
Устойчивость к правкам интерфейса
Адаптивное управление интерфейсом опирается на смысл элемента, а не на его координаты. Переименованный блок, новый баннер, изменённый порядок полей не ломают сценарий, поэтому пакет доработок на стороне сайта перестаёт превращаться в отдельный проект по переписыванию автоматизации.
Сокращение времени обработки
Компьютерное зрение в автоматизации позволяет реагировать на появление элемента, а не выжидать фиксированную паузу «на всякий случай». На поточных сценариях это сокращает прохождение цепочки в 2–3 раза и убирает простои на шагах, где данные грузятся дольше обычного.
Ушедший класс отказов
Исчезает пласт инцидентов: «элемент не найден», «окно перекрыло кнопку», «изменился порядок полей». Агент сам распознаёт всплывающее окно, дожидается загрузки и подбирает нужный элемент по смыслу. Интерфейсы, собранные с учётом WCAG, агент проходит стабильнее — роли и подписи элементов дают ему надёжные опоры.
Восстановление после сбоя шага
Агент ведёт журнал шагов и снимки экрана, поэтому сбой в середине цепочки не требует прогона с начала: выполнение возвращается к последней удачной точке. Разбор инцидента занимает минуты — видно состояние экрана в момент отказа, а сопровождение сводится к правке описания шага, а не к переписыванию логики.
Режимы работы: сценарий, автономный обход и гибрид
Режим работы — это ответ на вопрос, кто принимает решение на каждом шаге: заранее записанный маршрут или модель прямо в момент выполнения. От этого зависят устойчивость к изменениям интерфейса, объём ручных доработок и то, как проектируется обработка исключений.
Классические RPA-роботы умеют только первый способ, поэтому правка вёрстки ломает весь прогон. Ниже — три режима, между которыми реально выбирают на старте проекта.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Записанный сценарий | Повторяемые операции с одинаковой последовательностью шагов, стабильный интерфейс, требования к предсказуемости и разбору каждого действия | Ломается при смене разметки или порядка шагов; отклонение закрывается вручную и требует правки сценария |
| Автономный обход шагов | Много источников, заранее неизвестен полный маршрут до данных, разметка различается от раздела к разделу | Прогон дольше и затратнее по вычислениям, результат требует проверки; не годится для необратимых действий |
| Гибридная схема | Длинный процесс со стабильным ядром и нестандартными участками: вариативные формы, неполные данные | Сложнее проектирование и отладка: нужно решить, где управление переходит от сценария к модели и как фиксируется каждое решение |
Выбор режима работы фиксируем до разработки. Если отложить его, обработка исключений проектируется по факту — и агент останавливается на первой нестандартной ситуации вместо того, чтобы вернуться с понятным отчётом о том, где именно процесс отклонился.
Этапы внедрения: от разбора процессов до передачи
Агент не запускается сразу на рабочих системах — сначала разбираем, где ручной труд упирается в потолок. Так снимается главный риск внедрения: автоматизация шага, который узким местом не был.
- Аудит процессов. Разбираем, какие операции сотрудник повторяет, с какой частотой и объёмом, где копятся задержки и ошибки. На выходе — список шагов, ранжированный по выигрышу от автоматизации.
- Карта шагов. Фиксируем переходы между системами, точки ветвления, места с подтверждением и источники данных. Карта показывает, где агенту нужны права на запись, а где достаточно копии.
- Настройка агента. Собираем сценарий: распознавание экранов, правила ввода, проверки на входе. Права на запись подключаем только после того, как агент совпадёт с ручным результатом.
- Тестовый контур. Копия интерфейсов и обезличенные данные: прогон со сверкой с работой сотрудника шаг за шагом. Ошибки правим здесь, а не в рабочей среде.
- Разбор исключений. Отдельно проходим случаи, где агент не уверен: нестандартный документ, изменившееся поле, обрыв связи. Он останавливается, помечает случай и передаёт человеку.
- Передача в сопровождение. Отдаём регламенты, журналы прогонов, точки контроля и порядок обновления сценария при смене интерфейсов. Первое время ведём вместе с вашей командой.
Этапы идут не строго друг за другом: разбор исключений начинается уже на тестовом контуре, регламенты пишутся параллельно настройке. Неизменным остаётся одно — сверка с ручным результатом до выхода в рабочую среду.
Комплект поставки: схемы, роли доступа, регламенты
Комплект поставки — не отчёт «для галочки», а набор артефактов, по которым ваша команда сможет эксплуатировать агента и менять сценарии без нас. Всё описанное проверено на стенде: документация совпадает с тем, как система ведёт себя в рабочем контуре.
- Схема интеграций. Какие системы агент читает и куда пишет, через какие учётные записи, где точки отказа и как они обходятся без ручного вмешательства.
- Политики доступа. Матрица ролей: кто запускает сценарий, кто видит журнал, кто правит правила. Принцип минимальных прав действует на каждом шаге — агент не получает больше, чем нужно для задачи.
- Регламент обработки сбоев. Что делать при недоступности целевой системы, изменении разметки страниц, неоднозначном ответе модели. Отдельно зафиксировано, в каких случаях агент останавливается и передаёт задачу человеку.
- Журнал действий. Каждое решение агента с основанием, снимком состояния и ссылкой на источник. Журнал выгружается, фильтруется и разбирается по конкретному инциденту.
- Инструкции для команды. Запуск и штатная остановка, обновление сценария, типовые проверки после изменений на стороне внешних сервисов.
- Карта развёртывания. Где живут компоненты, как поднимается тестовый контур и чем он отличается от рабочего.
- Порядок изменений. Как новая версия сценария проходит проверку на стенде и как возвращается предыдущая, если метрики просели.
Передаём всё это с разбором: проходим по каждому документу вместе с вашими инженерами, отвечаем на вопросы и фиксируем ответственных. Дальше команда ведёт агента сама — либо остаёмся на поддержке.
Кейс: заявки в личном кабинете без ручных операций
Обработка заявок в личном кабинете — это около 1 800 обращений в неделю. Оператор открывал карточку, сверял данные с вложением, переносил поля в учётную систему, менял статус и отправлял ответ. Восемь-девять действий на заявку, среднее время — порядка шести минут, и любая пропущенная галочка возвращалась повторным письмом.
Что сломалось на первом подходе
Первый вариант собрали на скриптах, привязанных к элементам страницы: робот находил поле по селектору и подставлял значение. Схема держалась до первого обновления интерфейса — после переезда портала на Bitrix24 разметка изменилась, и половина шагов потеряла опору. Прогоны падали на формах с динамической подгрузкой, а сканы вложений разной вёрстки скрипт не читал вовсе.
Как переделали и что изменилось
Агент с компьютерным зрением работает не с разметкой, а с тем, что видно на экране: находит поле по подписи и расположению, а языковая модель решает, какое значение туда подходит. Вложение распознаётся и сверяется с полями карточки, спорные случаи уходят оператору.
Доля ручных операций упала со 100% до 12%, среднее время обработки — с шести минут до сорока секунд, ошибки ввода — с 3% до 0,4%. Обновление личного кабинета больше не останавливает поток: сценарий ищет элементы заново на каждом запуске.
Чем AI-агент браузера отличается от классического RPA
Классический RPA — это записанный сценарий: селектор кнопки, координаты клика, фиксированный порядок шагов. Пока интерфейс не меняется, он работает быстро и предсказуемо. Но стоит переименовать поле или поменять разметку — шаг падает, и процесс стоит до ручной правки.
AI-агент браузера не хранит последовательность действий. Он получает цель — «собрать позиции из личного кабинета в таблицу», — смотрит на страницу и как на изображение, и как на структуру элементов, и сам решает, куда нажать на каждом шаге. Правка вёрстки для него не отказ, а новое наблюдение.
| Критерий | Классический RPA | AI-агент браузера |
|---|---|---|
| Поиск элемента | Селектор, координаты клика | Визуальные и смысловые признаки |
| Правка вёрстки | Шаг падает, нужна правка | Подстраивает способ действия |
| Настройка процесса | Быстрее при стабильном интерфейсе | Дольше вывод на стабильный результат |
| Сопровождение | Правка после каждого релиза | Уточнение правил и проверок |
Отличие в трудозатратах видно не на запуске, а на дистанции. Сценарий на Selenium собирается быстрее, но каждое обновление интерфейса возвращает его в работу. Агент дороже на отладке, зато сопровождение смещается к уточнению правил, и этот объём не растёт с каждым релизом внешнего портала.
Выбор зависит от контура. Внутренняя система с предсказуемыми релизами остаётся вотчиной классического RPA. Внешние порталы с частыми обновлениями и динамическими окнами агент проходит устойчивее. Рабочий вариант — гибрид: критичные шаги детерминированы, нестабильные участки отданы агенту.
Технические сомнения: доступы, безопасность, отказоустойчивость
Возражения у инженерных команд обычно одни и те же: куда агент получает доступ, что он делает в закрытом контуре и как ведёт себя, когда сценарий ломается. Ниже — короткие ответы по каждому пункту.
Какие права нужны агенту?
Отдельная сервисная учётная запись с минимальным набором прав — только те разделы и операции, что описаны в сценарии. Расширение прав идёт через обычное согласование, а отзывается доступ одной операцией.
Может ли агент работать без выхода наружу?
Да. Контур разворачивается внутри периметра: браузер, модель и очередь задач не обращаются во внешнюю сеть, а обмен с внутренними системами идёт через согласованный шлюз с журналом запросов.
Что происходит, если шаг сценария упал?
Сценарий разбит на идемпотентные шаги с точками сохранения: при сбое агент возвращается к последней успешной и повторяет её в том же контексте. Платежи, удаление и отправка документов останавливаются на подтверждении оператора.
Кто отвечает за корректность действий?
На каждое действие пишется журнал: снимок экрана, слепок разметки, значения полей, время и результат. По нему восстанавливается причина любого расхождения, а правила валидации задаёт заказчик — агент исполняет сценарий и не решает за бизнес.
Такой контур проходит внутренний аудит без исключений: у каждого действия есть автор, время и подтверждение.Что нужно для старта и как мы оцениваем объём работ
Чтобы вернуться с оценкой, а не с очередью уточняющих вопросов, нам нужен минимальный набор входных данных. Ниже — то, что обычно запрашиваем на старте проекта.
- Целевые сценарии: какие операции передаём агенту, в каком порядке они идут сейчас и сколько времени занимают у людей — это база для оценки объёма работ.
- Доступы и стенды: тестовый контур с той же конфигурацией и правами, что в рабочем, отдельные учётные записи для агента, копия данных без персональных сведений.
- Системы-источники: интерфейсы, выгрузки, форматы файлов и правила, по которым данные попадают в процесс и уходят из него.
- Ограничения: что агенту делать нельзя — обязательные согласования, регламенты, участки, где нужна подпись или решение человека.
- Ответственные на вашей стороне: кто отвечает на вопросы по предметной области и принимает результат на каждом этапе.
- Критерии приёмки: чем измеряем результат — доля автоматизированных операций, время обработки одной заявки, доля ошибок на контрольной выборке.
С этим набором мы разбираем поток операций, отмечаем участки, где требуется компьютерное зрение, а где достаточно обращения к интерфейсам, и возвращаемся с оценкой и планом внедрения: этапами, сроками и точками контроля. Если часть данных пока недоступна, это не блокирует старт — обсуждаем задачу, фиксируем допущения и снимаем их по ходу работ.
