Чому AI-агент desktop ламається після оновлення інтерфейсу
Агент, записаний через координати кліку й шлях у дереві вікна, живе рівно до найближчого оновлення робочого застосунку.
Розробники переносять кнопку в іншу панель, змінюють порядок полів, додають проміжний діалог підтвердження — і сценарій, який місяць закривав проведення, перестає знаходити елементи.
Той самий ефект дає зміна роздільної здатності або масштабу на робочій станції: сітка координат зсувається, і клік іде в порожнє місце.
Найгірше те, що така відмова тиха. Агент не падає з помилкою й не пише тривожний рядок: він чекає елемент, повторює крок, відкладає його й переходить до наступного, а частина документів залишається необробленою. Ззовні процес виглядає живим, у звітах — нуль помилок.
Виявляється поломка не в логах агента, а в обліковій системі: розбіжності в реєстрі, завислі заявки, непроведені позиції, які спливають на звірці. На цей момент партія накопичилася, і розбирати її доводиться вручну.
Крихкість сценарію автоматизації — не властивість конкретної програми, а наслідок того, як він побудований.
Агент, який спирається на семантику елементів через UI Automation, перевіряє результат кожного кроку й повідомляє про розбіжність до того, як вона потрапить до реєстру, переживає оновлення інтерфейсу застосунку без переписування з нуля. Розбираємо, як це закривається.
Що дає агентна автоматизація: ефект у вимірюваних числах
Ефект агентної автоматизації рахують не за кількістю запущених сценаріїв, а за часом, який перестає йти на сам потік операцій.
Агент бере на себе перенесення даних між вікнами, вивантаження та заповнення форм — оператор перестає бути ланкою передачі інформації й займається лише рішеннями, які потребують людини.
Швидкість обробки заявок зростає не за рахунок прискорення одного кроку, а за рахунок зняття черги: поки оператор розбирає одну заявку, агент паралельно веде кілька десятків однотипних і не чекає підтвердження щодо кожної.
Вимірюється це часом від надходження заявки до готового результату та часткою заявок, закритих без участі людини.
Частка помилок ручного введення падає зі зрозумілої причини: значення переноситься з джерела в приймач напряму, без набору з клавіатури й без звіряння двох екранів очима. Помилка перестає залежати від утоми наприкінці зміни.
Повторні прогони сценарію теж стають керованою величиною: кожен крок отримує ознаку виконання, і після збою агент продовжує з контрольної точки, а не проходить весь шлях заново.
Це важливо там, де повторний запуск створює дублі — в облікових системах, під час надсилання документів, під час постановки задач.
Окремо рахують клас відмов, який зникає зовсім: незаповнене поле, неправильний формат дати, загублений рядок у вивантаженні. Вони не пом'якшуються, а зникають, тому що перевірка формату відбувається до запису. Залишаються відмови зовнішніх систем — їх обробку проєктують окремими гілками сценарію.
Режими роботи агента: порівняння підходів і обмежень
Сумісність агента визначається не моделлю, а тим, де він виконується.
Режими запуску агента різняться правами облікового запису, активністю сесії, роздільною здатністю екрана та способом оновлення версії — і саме це найчастіше вирішує, запуститься сценарій чи зірветься на середині.
Агент на робочому місці оператора працює в живій користувацькій сесії: бачить ті самі вікна, той самий фокус введення й те саме середовище, що й людина. Обмеження — залежність від стану сеансу: під час блокування екрана або перекритого вікна кроки зриваються.
Виділена машина під агента знімає це постійною сесією та передбачуваним середовищем, але потребує окремого доступу до цільової системи й контролю стану вузла.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| На робочому місці оператора | Розбір пілотного процесу, задачі з підтвердженням людиною | Залежить від активності сесії та налаштувань екрана, конфліктує з паралельною роботою оператора |
| Виділена машина під агента | Регулярний потік однотипних задач без участі людини | Потрібні окремі облікові дані, відстеження доступності вузла та оновлення агента |
| Спільний парк із централізованим управлінням | Десятки агентів і сценаріїв на одну систему | Потребує реєстру задач, розмежування прав між сценаріями та черги на спільні вікна |
На практиці режими комбінують: парк під централізованим управлінням тримає єдині версії агента та спільний журнал кроків, а чутливі операції залишаються за оператором. Опишіть свої сценарії — повернемося з оцінкою, який варіант витримає їх без переробки.
Етапи впровадження: аудит, схема, налаштування, перевірка, передача
Впровадження починається не з показового запуску, а з розбору того, як задача виконується сьогодні.
Ми фіксуємо послідовність кроків, їхню частоту, варіативність вхідних даних і точки відмови: де людина ухвалює рішення, що відбувається за нестандартної відповіді системи, які вікна з'являються рідше одного разу на тиждень.
Автоматизація зазвичай ламається саме на цих рідкісних гілках — тому вони описуються на аудиті, а не спливають у дослідній експлуатації.
- Аудит процесу. Розбираємо поточний сценарій за кроками, збираємо перелік варіацій, окремо виписуємо винятки та правила доступу до облікових записів і довідників.
- Схема сценарію. Погоджуємо карту дій агента: що він робить сам, де зупиняється й передає управління оператору, як реагує на зміну інтерфейсу цільових програм. Схема погоджується письмово — вона стає основою приймання.
- Налаштування та обв'язка. Збираємо середовище в ізольованому контурі, налаштовуємо доступи за принципом мінімальних прав, логування кожної дії та зберігання скріншотів на випадок розбору інциденту.
- Перевірка на реальних прикладах. Прогоняємо сценарій на накопиченій історії операцій і на штучно створених збоях: недоступний ресурс, змінене поле, тайм-аут відповіді. Окремо перевіряємо, як агент завершує роботу при перериванні — без «завислих» вікон і незакритих операцій.
- Дослідна експлуатація. Запускаємо в парі з оператором на обмеженій ділянці: агент виконує роботу, людина звіряє результат. Розбіжності розбираються, правила уточнюються до прийнятної частки ручних втручань.
- Передача регламентів супроводу. Віддаємо опис сценарію, інструкції щодо перезапуску та типових збоїв, порядок оновлення при змінах у цільових програмах.
Після передачі агент залишається керованим: правки проходять той самий контур перевірки, тому оновлення не перетворюється на разовий аврал.
Що залишається у замовника: конфігурації, політики, регламенти
Після здачі у замовника залишається не лише працюючий агент, а й комплект артефактів, за яким команда сама змінює сценарії, видає доступи та розбирає збої без звернення до нас. Комплект розрахований на те, що супровід веде ваша команда, а ми підключаємося точково.
- Конфігурація агента — кроки сценарію, способи пошуку елементів вікна, час очікування та правила повторів винесені в окремі файли: правка кроку не потребує перезбирання коду.
- Схема процесу — як агент проходить сценарій цілком, де розгалуження й які дані переходять між кроками, щоб новий інженер зрозумів логіку за один прохід.
- Політики доступу — під яким обліковим записом працює агент, до яких систем і каталогів звертається, що йому явно заборонено.
- Журнал прогонів — за кожним запуском: номер кроку, результат, тривалість, знімок екрана в момент помилки; інцидент розбирається за записом, а не з пам'яті.
- Набір перевірочних прогонів — сценарії на тестовому стенді, які прогоняються після кожної правки конфігурації та ловлять регресію до робочого контуру.
- Інструкція для операторів — як запустити, поставити на паузу, продовжити з кроку, що впав, і що робити при нестандартному вікні.
- Регламент оновлень — хто править конфігурацію, хто погоджує, як відкотитися на попередній набір кроків при регресії.
Кейс: агент замість ручного введення заявок в облікову систему
Що було
Заявки приходили в пошту та месенджери, а в облікову систему на 1С їх заносили вручну: оператор відкривав форму, переносив реквізити, звіряв контрагента за довідником і підбирав номенклатуру.
На одну заявку йшло 7–9 хвилин, у пікові години черга тягнулася до кінця зміни, а розбіжності в реквізитах знаходилися вже на погодженні — повернення й повторне коло.
Що стало
Агент розбирає вхідне повідомлення, зіставляє контрагента та позиції з довідниками й працює у вікнах облікової системи як людина: кліки, введення полів, перемикання між формами — без правок у конфігурації та прямого доступу до бази. Спірні випадки він не домислює, а відкладає в чергу на розбір оператору.
Метрики знімали в дослідній експлуатації на живому потоці.
Частка ручних доопрацювань після агента — 9% проти 42% до нього, середній час заявки скоротився з восьми хвилин до сорока секунд, а розбіжності реквізитів перестали доходити до погодження: обов'язкові поля агент перевіряє до запису. Оператори переключилися на винятки та конфлікти довідників.
Кожна дія агента логується й відтворюється, екран доступний оператору, і управління можна перехопити в будь-який момент — тому дослідну експлуатацію вели на продуктивному потоці, без дублювального ручного введення.
Чим AI-агент desktop відрізняється від запису макросів
Запис макросу фіксує послідовність дій: координати кліків, паузи, позицію вікна. Такий сценарій відтворюється буквально — зсунулася панель, змінився порядок полів, спливло повідомлення, і ланцюжок розсипається на середині, коли частину даних уже надіслано до системи.
AI-агент desktop працює не з координатами, а зі змістом екрана. Він розбирає стан інтерфейсу — які поля заповнені, що залишилося обов'язковим, яке вікно поверх інших, — і вирішує, яка дія веде до мети.
Розпізнавання стану форми йде за вмістом і структурою елементів, тому перенесення кнопки на інше місце нічого не ламає.
Жорсткі скрипти надійні рівно до першої зміни інтерфейсу або нестандартного стану. Підтримувати їх дорого: кожне оновлення облікової системи перетворюється на правку розгалужень, а непередбачене модальне вікно зупиняє весь процес до ручного втручання.
Окрема відмінність — відновлення після збою. Макрос на неочікуваному діалозі просто чекає або падає з помилкою.
Агент помічає розбіжність з очікуваним станом, повторює крок, закриває зайве вікно й повертається до контрольної точки, а весь шлях дій залишається в журналі для розбору.
Це не означає, що агент замінює все. Там, де послідовність жорстко задана й екран стабільний, детермінований код передбачуваніший. Ми зазвичай збираємо гібрид: агент відповідає за розпізнавання й розгалуження, а повторювані операції виконує перевірений скрипт.
Технічні сумніви: стійкість, доступи, відкати
Агент працює поверх інтерфейсів застосунку, а не через його внутрішні точки інтеграції. Звідси головне питання: що відбувається, коли вікно відкрилося не тим, кнопка переїхала або сесія відвалилася на середині.
Цикл будується з перевіркою стану після кожного кроку — агент підтверджує результат за фактом, а не за натисканням.
Якщо очікуваний стан не настав, крок повторюється обмежену кількість разів, після чого задача позначається як така, що потребує людини: черга не забивається мовчазними помилками.
Права видаємо за мінімумом: окремий обліковий запис, доступ лише до потрібних систем і папок, без адміністраторських повноважень на робочій станції. Кожна дія потрапляє до журналу — що відкрив, що ввів, де зупинився, — за ним відновлюється хід будь-якої задачі.
Впровадження оборотне: агент не витісняє попередню автоматизацію, а стає поруч, частка операцій перемикається маршрутизацією і так само повертається назад. Вимкнення — це зупинка сценарію та зняття доступу, дані залишаються на місці.
Що буде, якщо в застосунку оновлять інтерфейс?
Агент спирається на кілька ознак елемента, а не на координати. При переміщенні він зупиняється на незбігу й повідомляє, який крок зламався, — правку вносимо точково, без переписування сценарію.
Які права потрібні агенту на робочій машині?
Рівно ті, що потрібні для цільових операцій, і жодного зайвого: звичайний обліковий запис, окремий профіль, без доступу до платіжних і кадрових контурів. Обсяг прав погоджуємо до запуску.
Чи можна повернутися до ручного процесу?
Так. Попередній порядок зберігається на час впровадження, перемикання йде частинами. Якщо пробна група показує гірше, ніж було, повертаємо маршрут людям, не переробляючи вже зроблене.
Обговоримо задачу: з чого починаємо і що потрібно від вас
Щоб оцінка була предметною, а не «плюс-мінус», нам потрібен доступ до того, як процес працює зараз. Зазвичай достатньо опису сценарію, тестового контуру з тими самими версіями систем і переліку застосунків, у яких діє агент. Збираємо це за один захід — і повертаємося з планом впровадження за етапами.
- Опис процесу: кроки оператора, точки ухвалення рішень, що вважається успішним завершенням і які помилки критичні.
- Перелік систем: де ведеться робота, як виконується вхід, чи є програмні інтерфейси або лише екранне введення.
- Тестовий контур: копія середовища зі знеособленими даними, облікові записи з потрібними правами, доступ за захищеним каналом.
- Приклади складних випадків: рідкісні сценарії, спливаючі вікна, зміни інтерфейсу, ручні підтвердження — за ними видно, де агент натрапить на перешкоду.
- Регламент та обмеження: які дії потребують підтвердження людини, що агенту заборонено, хто відповідає за підсумкове рішення.
- Відповідальний з вашого боку: людина, яка підтверджує сценарії та приймає результат кожного етапу.
- Цільові показники: час однієї операції, частка сценаріїв без ручного втручання, допустимий рівень помилок.
Далі наш крок: розбираємо матеріали, відтворюємо сценарій на тестовому контурі та повертаємося з оцінкою робіт і планом впровадження. У плані фіксуємо, що пред'являємо після кожного етапу і як відкочуємося, якщо поведінка агента відхиляється від погодженого.
