Перш ніж доручати AI Agent роботу з вебсайтами, перевірте ланцюг між середовищем і Agent на чотирьох рівнях: одноетапний smoke-тест, багатокрокові завдання, паралельне навантаження та ін’єкція збоїв, із власними метриками для кожного рівня.
Один успішний запуск у демонстраційному середовищі не означає, що той самий ланцюг можна надійно використовувати щодня.
Для коректної оцінки тести треба розділити: середовище перевіряти на його рівні, Agent — на його рівні, а потім перевірити, чи залишаються обидві частини стабільними після з’єднання.
Одноетапний smoke-тест: чотири дії окремо
Smoke-тест містить лише чотири дії, які виконуються по одній і не з’єднуються в послідовність: відкрити вказану сторінку; знайти елемент на сторінці; натиснути на нього; отримати текст цього елемента. Якщо всі чотири дії проходять успішно, базові механізми з’єднання, сесії та доступу до елементів працюють.
Чотири ізольовані дії звужують область пошуку несправності. Якщо сторінка не відкривається, проблема зазвичай у мережевому egress або правах доступу. Якщо сторінка відкрилась, але елемент не знаходиться, можливо, завантаження ще не завершилося або locator надто залежить від поточного макета. Якщо елемент знайдений, але його не можна натиснути, перевірте, чи він не перекритий і чи не перебуває в iframe. Якщо повернутий текст порожній, спочатку переконайтеся, що читається відрендерений вміст, а не початковий HTML.
Стежте за трьома показниками: успішністю одного кроку, часом одного кроку та розподілом типів помилок. Вони мають бути стабільними вже на етапі smoke-тесту. Якщо успішність окремого кроку коливається лише на рівні 80–90%, подальші тести малоінформативні.
Багатокрокові завдання: розгалуження важливіші за кількість кроків
Об’єднайте чотири дії в реальне завдання, наприклад заповнення форми, перехід кількома сторінками, фільтрацію за умовами та локальний запис результату. Більша кількість кроків — лише кількісна зміна; справжня складність полягає в розгалуженнях: з’являється повідомлення, зникає цільовий елемент, сторінка сама перенаправляє або виникає перевірка, що потребує підтвердження людиною.
Тут важливий показник завершення завдання, а не успішність окремих кроків. Після збою важливіше, чи може Agent скоригувати маршрут і визначити, коли треба зупинитися та чітко повідомити про проблему, ніж просто дійти до кінця.
Ще один показник, який легко пропустити, — кількість втручань людини. Якщо те саме завдання запустити двадцять разів, число втручань і крок, на якому кожен запуск зупинився, можуть краще показати зрілість ланцюга, ніж загальний відсоток завершення.
Паралельність та ін’єкція збоїв
Коли один ланцюг став стабільним, додайте паралельність. Запустіть кілька середовищ одночасно із завданнями одного типу й спостерігайте, чи заважають середовища одне одному та чи зростає частка помилок зі збільшенням паралельності. Збої на цьому етапі часто спричинені не логікою Agent, а тиском на ресурси або сесії.
Ін’єкція збоїв — один із тестів, які найчастіше пропускають, хоча він особливо потрібний. Навмисно створюйте timeout, зникнення елемента під час виконання, завершення сесії та CAPTCHA й дивіться на реакцію: чи спрацьовує повторна спроба після timeout, чи процес зависає; чи з’являється чітка помилка після завершення сесії, чи ланцюг продовжує роботу з недійсними обліковими даними.
Фіксуйте три метрики: криву частки помилок за паралельного виконання, успішність відновлення після збою та додатковий час, який спричиняє один збій. Низька успішність відновлення означає, що ланцюг працює лише за сприятливих умов.
Рівень середовища перевіряйте окремо
Попередні тести виконуються в одному середовищі, але при спільній роботі кількох середовищ потрібно окремо перевірити ще один рівень. Кожне середовище має запускатися незалежно, зберігати власну сесію й cache та використовувати власний egress IP.
Команди, що працюють із багатьма акаунтами, зазвичай розділяють середовища за акаунтами. Інструменти на кшталт PurpleMark забезпечують ізоляцію середовищ, щоб кожен акаунт мав незалежний простір виконання. Під час тесту запустіть кілька середовищ паралельно й переконайтеся, що Cookies, cache та egress не змішуються між ними.
Для цього рівня дивіться на три показники: успішність запуску середовища, перетікання даних між середовищами (у нормі має дорівнювати нулю) та можливість продовжити сесію після перебудови середовища.
Як визначити причину збою
Коли ланцюг дає збій, поширена помилка — одразу змінювати скрипт Agent. Раціональніший порядок: спочатку перевірити, чи запускається середовище й чи не завершилася сесія, потім перевірити мережевий egress і вузли, і лише після цього підозрювати локалізацію елементів та планування завдань Agent. Зворотний порядок призводить до повторних змін не в тому місці.
Чотири дії одноетапного smoke-тесту також є інструментом пошуку причини. Після будь-якого збою знову виконайте їх окремо й подивіться, яка ланка обривається першою. У більшості випадків причина стає зрозумілою вже на цьому етапі.
