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