Computer Use AI: де ламається автоматизація інтерфейсу
Класична автоматизація інтерфейсу будується на жорсткому ланцюжку: знайти елемент за селектором, дочекатися його, клікнути, вписати значення, надіслати форму.
Будь-яке відхилення розриває ланцюжок — зсунулася верстка після релізу, поверх кнопки з'явилося модальне вікно, змінилася тема оформлення, форма пішла у вкладений фрейм.
Сценарій зупиняється не там, де сталася помилка, а там, де він чекав на елемент: у систему потрапляють частково застосовані дані, і розбирати їх доводиться вручну.
Друга точка відмови — ручні перенесення між системами. Коли надійного обміну немає, дані переносить людина: вивантажує звіт, звіряє порядково, заводить в облікову систему.
Один пропущений крок або друкарська помилка в полі — і розбіжність розходиться по всьому ланцюжку погоджень, а шукаємо ми її вже постфактум, за журналами та вивантаженнями.
Автономний агент на computer use ai працює інакше: він оцінює стан екрана й вирішує, що робити, на кожному кроці.
Агент бачить, що вікно перекрило кнопку, — закриває його й повертається до завдання; якщо форму переробили, знаходить поле за змістом і підписом, а не за зашитим шляхом.
Тому збої під час автоматизації перетворюються з зупинки процесу на обхідний шлях, а рутинні операції під ключ закриваються без людини всередині ланцюжка.
Нижче розбираємо, як це влаштовано: від розпізнавання стану інтерфейсу до протоколу, за яким агент повідомляє про нештатну ситуацію.
Ефект від впровадження агента: швидкість, охоплення, менше рутини
Агент на Computer Use працює через той самий інтерфейс, що й людина: бачить екран, наводить курсор, заповнює поля, читає відповідь системи.
Доступ до внутрішніх інтерфейсів не потрібен — тому охоплення сценаріїв ширше: під автоматизацію потрапляють застарілі облікові системи, чужі особисті кабінети, десктопні клієнти, до яких інтеграція не доходила.
Пропускна здатність операцій зростає завдяки безперервності, а не прискоренню однієї дії: агент тримає один темп усю зміну, забирає нічні та пікові черги, не перемикається між завданнями. Там, де оператор закриває десятки звернень за зміну, агент обробляє сотні — зокрема в години піку.
Зникає клас механічних помилок: переплутане поле, пропущений крок, невірний статус. Агент іде за зафіксованим чек-лістом і на будь-якій розбіжності зупиняється, додаючи лог і знімок екрана. Розбір такого випадку займає хвилини замість пошуку за журналами.
Розвантаження операторів — наслідок: люди перестають бути виконавцями рутини й переходять на винятки, нетипові випадки, спілкування з клієнтом. Частка ручних операцій скорочується в рази, а ті, що залишилися, потребують рішення, а не механічних дій.
Показники фіксуємо до впровадження — час на операцію, кількість оброблених за зміну, частка помилок, глибина черги — і рахуємо ті самі після запуску. Так ефект від впровадження агента видно в порівнянні, а не на словах.
Режими роботи агента: браузер, робочий стіл, гібрид
Режим запуску визначає, до чого агент отримує доступ, наскільки стійко він повторює процес і що доведеться підготувати на боці замовника.
Один і той самий сценарій можна зібрати по-різному, і різниця проявиться не в демо, а в стабільності повторних прогонів і у вимогах служби безпеки.
Вибір іде не від зручності розробки, а від самого процесу. Якщо всі кроки вкладаються у веб-системи, браузерного режиму достатньо; якщо процес зав'язаний на встановлений застосунок, вікно або файл на диску, потрібен режим робочого столу.
Гібридний запуск закриває сценарії, де частина кроків браузерні, а частина — локальні, і агент переходить між ними в межах одного завдання.
Окрема гілка — закритий контур: агент і модель працюють усередині інфраструктури замовника, без звернень до зовнішніх мереж. Тоді вимоги до середовища й потужностей фіксуються заздалегідь, і стенд планується під них.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Браузерний режим | Процеси повністю у веб-системах: галузеві портали, особисті кабінети, веб-панелі, вивантаження звітів | Не дістає до локальних застосунків і файлової системи; чутливий до змін розмітки сторінок |
| Режим робочого столу | Програми, встановлені на машині: облікові та банківські клієнти, робота з файлами, друк документів | Залежить від роздільної здатності екрана й розкладки вікон; потрібен окремий стенд, де агент не заважає співробітникам |
| Гібридний запуск | Процес іде в браузері, але потребує завантаженого файлу, локальної програми або вивантаження на диск | Складніше налагоджувати: збій може бути і на боці веб-частини, і в локальній системі |
| Закритий контур | Персональні дані, комерційна таємниця, пряма заборона на звернення до зовнішніх мереж | Модель і агент розміщуються на своїх потужностях; вищі вимоги до обладнання й супроводу |
На практиці режим фіксується до розробки сценарію — від нього залежать схема доступів, спосіб зберігання логів і те, як налаштовується відкат у разі збою.
Як ми впроваджуємо агента: від розбору процесів до передачі
Агент, який працює з графічним інтерфейсом, ламається не там, де ламається код: зсунулася верстка, з'явилося модальне вікно, минула сесія.
Тому впровадження починаємо не з налаштування моделі, а з обстеження процесів — що оператор робить руками, де ухвалює рішення і за якими ознаками розуміє, що крок завершено. Далі йдемо за етапами, кожен з яких закінчується перевірюваним артефактом.
- Обстеження процесів. Дивимося записи екрана й журнали дій оператора, розбираємо кроки, джерела даних, винятки та правила, які ніде не записані.
- Схема сценаріїв і меж. Фіксуємо, що агент робить сам, а що йде людині на підтвердження, і де ставимо точки повернення завдання оператору.
- Пілотний сценарій. Беремо один вузький наскрізний маршрут, проганяємо еталонні кейси й знімаємо базові метрики: частка успішних проходів, час операції, кількість ручних втручань.
- Налаштування агента. Видаємо мінімальні доступи, розмічаємо опорні елементи інтерфейсу, задаємо правила очікування, повторів і поведінку при розбіжності картинки з еталоном.
- Перевірка на відмовах. Навмисно зсуваємо елементи, обриваємо з'єднання, підсовуємо несподівані діалоги — агент має розпізнати глухий кут і повернути завдання людині, а не діяти навмання.
- Передача рішення. Документація, схема сценаріїв, журнали прогонів, навчання команди й регламент оновлення при змінах інтерфейсу.
Після передачі ваші фахівці самі правлять сценарії та додають маршрути — наша участь потрібна лише при помітних змінах інтерфейсу або нових процесах.
Артефакти впровадження: сценарії, доступи, регламенти
Проєкт закінчується не показом працюючого агента, а набором артефактів, з якими команда замовника залишається один на один. Нижче — що передаємо і навіщо кожен елемент потрібен в експлуатації.
- Опис сценаріїв. По кожному: точка входу, кроки, очікуваний результат, типові помилки та дія за них. Раніше це знання жило в голові інженера й ішло разом з ним.
- Схеми процесів. Як агент пов'язаний з обліковою системою, поштою та файловим сховищем, де залишається ручний крок і куди повертається управління при збої.
- Політика доступу агента. Окремий обліковий запис з мінімальними правами, перелік заборонених операцій (платежі, видалення, зміна реквізитів), порядок ротації секретів і поведінка при завершенні сесії.
- Журналювання дій. Для кожного кроку — час, ініціатор, результат, знімок екрана при відмові. Журнал вивантажується для розбору інциденту й зберігається стільки, скільки вимагає внутрішній регламент.
- Регламент ескалації. Які ситуації агент не вирішує сам, кому передає управління і за який час людина зобов'язана відповісти.
- Інструкції для підтримки. Розбір частих відмов: змінилася верстка цільової системи, не знайдено елемент інтерфейсу, зависла сесія — що перезапускати й які записи дивитися.
Артефакти оновлюються разом зі змінами в цільових системах — інакше опис розходиться з реальністю за пару місяців і підтримка знову йде до нас.
Кейс: обробка заявок в обліковій системі без операторів
Замовник — сервісна компанія: заявки надходять із форми на сайті, пошти й месенджерів, а розбирають їх вручну оператори — звіряють клієнта, заводять звернення в обліковій системі, прикладають файли й ставлять завдання відповідальному.
У пікові години черга сягала сотень звернень, нічні заявки чекали ранку, а на ручному введенні втрачалося близько 4% даних: друкарські помилки в реквізитах спливали вже на етапі погодження.
Програмного інтерфейсу в облікової системи не було — лише вікно оператора. Тому автоматизацію будували на Computer Use: агент відкриває ті самі екрани, читає картку звернення, розпізнає поля, заповнює форму, прикладає вкладення й передає заявку далі за маршрутом.
Набір операцій обмежений білим списком, спірні випадки йдуть людині з позначкою, а весь сеанс пишеться в журнал — по кожній заявці видно, що саме зробив агент і на якому кроці зупинився.
Метрики до і після проєкту:
- частка звернень, оброблених без оператора — з 0 до 82%;
- час від появи заявки до постановки в роботу — з 6 годин до 4 хвилин;
- помилки при введенні даних — з 4% до 0,6%;
- нічні та вихідні заявки перестали чекати початку зміни;
- пропускна здатність у пік зросла приблизно втричі без розширення штату.
Що це означає для схожих завдань
Підхід працює там, де немає програмного інтерфейсу, але є стабільні екрани й зрозумілі правила обробки. Обов'язкові журнал дій агента, точки ескалації на людину й відкат у ручний режим за один крок.
Перші тижні заявки йшли паралельно з операторами: розбіжності розбирали, правила уточнювали — і лише потім ручний контур вимкнули.
Чим Computer Use відрізняється від класичних сценаріїв?
Класична автоматизація — це записаний ланцюжок кроків: знайти елемент, дочекатися вікна, вписати значення, надіслати форму. Кожен крок прив'язаний до селектора, координати або заголовка вікна, тому відхилення від очікуваного стану обриває сценарій на середині.
Computer Use як підхід в AI-автоматизації йде від мети: агент бачить екран і сам вирішує, куди натиснути і що ввести, звіряючи результат із завданням.
| Що порівнюємо | Класичний сценарій | Агент на Computer Use |
|---|---|---|
| Опора | селектори, координати, порядок вікон | вміст екрана й мета завдання |
| Правка інтерфейсу | крок не знаходить елемент, процес падає | дія перебудовується за контекстом |
| Поріг впровадження | потрібні ідентифікатори елементів і доступ до розмітки | достатньо облікового запису з потрібними правами |
| Підтримка | сценарій правлять після кожного релізу форми | уточнюють інструкцію, а не ланцюжок кроків |
Відмінності від скриптів помітні саме на змінах: перейменована кнопка, нова модалка або інший порядок полів ламають жорсткий сценарій, і його розбирають вручну.
Агент пробує інший шлях до тієї самої мети — стійкість до змін дається не запасами в коді, а розумінням завдання й перевіркою результату.
У підходу є зворотний бік: агент повільніший за покроковий сценарій і потребує контролю — журналу дій, підтвердження на незворотних операціях, звірки підсумку на виході.
Тому ми комбінуємо: на стабільних ділянках з масовими операціями залишається класична автоматизація, а рідкісні процеси з частими змінами віддаємо агенту, і підтримка сценаріїв зводиться до правки інструкцій.
Технічні сумніви перед стартом: розбираємо по пунктах
Перед пілотом інженерні команди задають одні й ті самі питання: що буде при зміні інтерфейсу, куди потраплять облікові дані, що агенту дозволено і як він поводиться при збої. Нижче — короткі відповіді по кожному пункту.
Інтерфейс оновився — сценарій зламається?
Агент шукає елементи за змістом — текст, роль, підпис поруч, — а не за координатами на екрані: перейменування кнопки або зсув блоку його зазвичай не ламають.
На критичних кроках стоїть перевірка очікуваного стану: якщо екран не збігся, агент зупиняється й віддає знімок у журнал, а не дожимає сценарій навмання.
Куди потрапляють облікові дані й які права отримує агент?
Логіни й паролі живуть в окремому сховищі секретів: у сценарії та журналі залишаються лише посилання на них, значення підставляє виконавець у момент запуску.
Агент працює під окремим обліковим записом з мінімальним набором прав і лише на час сеансу, а дії на кшталт запису в базу або платежів або винесені за межі сценарію, або потребують підтвердження людини.
Що відбувається при помилці в середині процесу?
Кроки проєктуємо повторюваними: спочатку автоматичний повтор, потім фіксація стану й зупинка. Половинчастих станів не залишається — є точка повернення, з якої процес запускається заново.
Чи можна розгорнути це в закритому контурі?
Так: розгортаємо у вашій мережі або на виділеному контурі, дані й трафік не виходять назовні. Оновлення приїжджають усередину контуру за погодженим регламентом.
Обговоримо завдання: що надіслати і як ми відповідаємо
Щоб повернутися з оцінкою впровадження, а не із загальними словами, нам достатньо вступних по процесу — оформлювати вимоги за шаблоном не потрібно. Надішліть те, що вже є: опис сценарію, приклади даних і доступ до тестового контуру, якщо він є. Решту уточнимо самі — на дзвінку або в листуванні, залежно від того, як зручніше вашій команді.
- Покроковий опис процесу: які вікна, форми й кнопки задіяні, у якому порядку і що вважається завершенням кроку.
- Запис екрана реального проходу — 5–10 хвилин живого сценарію показують тайминги очікування й нестабільні місця краще за будь-який текст.
- Приклади вхідних даних у тому вигляді, у якому вони надходять: вивантаження, скани, листи, таблиці, вкладення.
- Перелік винятків і ручних рішень — де формальне правило ламається і що оператор робить замість нього.
- Обмеження середовища: операційна система, права облікового запису, доступність тестового контуру й розклад, коли можна займати робочі місця.
- Критерії успіху пілоту: яку частку сценаріїв або який час проходу ви вважаєте прийнятним результатом.
За цими вступними ми збираємо план робіт: розбиваємо процес на стійкі та ризиковані ділянки, відзначаємо, де потрібен контроль людини, і фіксуємо терміни пілоту з точками перевірки. Якщо частина даних закрита, запропонуємо, чим її замінити на першому етапі, — це не гальмує старт. Опишіть завдання у вільній формі — повернемося з оцінкою, планом і межами пілоту.
