Agent Browser дає моделі змогу самій вирішувати, як діяти на вебсторінці, замість виконання жорстко заданих кроків. Ключові відмінності стосуються ухвалення рішень, розуміння сторінки, виконання дій і нинішніх меж надійності.
Автоматизація браузера за допомогою скриптів добре знайома: знайти елементи, прописати маршрути, додати обробку винятків — і все працює стабільно, доки сторінку не перероблять. Якщо зміна зачіпає ключову точку, увесь скрипт може довестися переписувати, адже код розпізнає конкретну структуру, а саме структура змінюється найпростіше.
Agent Browser використовує інший підхід. Він дає моделі змогу дивитися на вміст сторінки й вирішувати, що робити далі. Саме тому він менш чутливий до змін дизайну.
Відмінність 1: хто вирішує, що робити далі
У традиційному скрипті маршрут задає людина. Куди натиснути спочатку, що заповнити потім і скільки чекати після цього — усе визначається заздалегідь. Під час виконання скрипт лише дотримується цих інструкцій.
Agent Browser передає ухвалення рішень моделі. Ви описуєте мету, наприклад упорядкувати в таблиці вміст із певного джерела за заданими умовами. Яку сторінку відкрити, чи спочатку фільтрувати, чи переходити між сторінками та як обробити спливне вікно — усе це визначається під час виконання.
Цю різницю легко недооцінити. Витрати на підтримку зміщуються від написання коду до чіткого опису вимог. Технічна складність знижується, але якість формулювання мети стає важливішою.
Відмінність 2: як він розуміє, що є на сторінці
Скрипти розпізнають елементи за допомогою селекторів. XPath- і CSS-селектори вказують на позицію вузла у структурі. Коли позиція змінюється, селектор перестає працювати.
Agent Browser натомість передає моделі інформацію про структуру сторінки або знімок екрана. Модель визначає, що один елемент — кнопка входу, інший — поле пошуку, а ще одна область показує ціну товару. Вона орієнтується більше на зміст, ніж на координати.
За це є відчутна ціна. Щоб модель зрозуміла сторінку, їй потрібно передати структуру DOM або знімки екрана; що складніша сторінка, то більше даних потрібно. Для довгих завдань ці витрати можуть бути суттєвими. До того ж кожен крок очікує на результат інференсу моделі, тому весь процес помітно повільніший за жорстко запрограмований скрипт.
Відмінність 3: як виконуються дії
Після рішення дію ще треба реально виконати. Такі інструменти зазвичай оформлюють можливості браузера як набір викликаних дій: відкрити сторінку, натиснути, заповнити форму, увійти, завантажити файл, прокрутити або перейти далі й витягти дані. Модель вказує, яку дію викликати та з якими параметрами. Браузер її виконує й повертає результат моделі як вхідні дані для наступного циклу.
На цьому ж рівні відбуваються декомпозиція завдання та виправлення помилок. Мета розбивається на кілька кроків, які виконуються послідовно. Якщо модель помічає, що пішла неправильним шляхом, вона може спробувати іншу точку входу, а не одразу зупинятися з помилкою. Це особливо важливо на сторінках із нерегулярною структурою, де успішність значною мірою залежить від здатності відновитися після помилки.
Що вже працює сьогодні
Завдання з високою визначеністю та чіткими кроками вже можна виконувати: збирати відкриту інформацію за заданими умовами й перетворювати її на структуровані дані; виконувати повторюване введення та форматоване надсилання у власних системах; або стежити за визначеною сторінкою й повідомляти про зміни ціни, наявності чи оголошень. У цих сценаріїв спільні риси: маршрут передбачуваний, помилки можна повторно обробляти, а людина здатна перевірити результат.
Де стабільності ще бракує
Найлегше проблеми виникають там, де потрібне семантичне розуміння. Щоб вирішити, чи слід натискати кнопку, модель спочатку має зрозуміти її бізнесове значення. За складної структури сторінки або нетипових формулювань з’являються помилки: обирається неправильна точка входу або витягується не те поле. Що довший ланцюжок кроків, то легше накопичуються відхилення. Невелика помилка на початку може стати невиправною пізніше.
Сильне протистояння ще складніше. CAPTCHA, блокування систем ризик-контролю та завершення сесії залежать переважно від базового середовища, а не від самої моделі. Якою б розумною не була модель, вона не може перетворити відхилений запит на успішний. Виконання в хмарі та проксі, якими керує постачальник, можуть вирішити частину проблеми, але додають оплату за використання й залежність від сторонньої інфраструктури.
На що дивитися під час вибору
Можливість спостерігати та відтворювати виконання часто ігнорують, але під час проблеми це основний спосіб діагностики. Варто також перевірити спосіб виправлення помилок: інструмент зупиняється чи пробує інший шлях? З’ясуйте, чи можна контролювати вибір моделі й витрати, адже довгі завдання часто коштують більше, ніж очікується. Перевірте інтеграцію власних інструментів і процесів та нарешті спосіб збереження стану входу. Повторювати всю роботу через втрату сесії дуже незручно.
Спочатку визначте правила використання
Технічна можливість не означає наявність дозволу. Насамперед потрібно перевірити, чи дозволяють умови цільової платформи автоматизований доступ і чи не створює частота запитів зайвого навантаження на сервіс. Використання таких інструментів для масової реєстрації акаунтів або автоматичного виконання завдань платформи за винагороду порушує правила платформи. Сервіси дедалі краще визначають ритм операцій, поведінкові маршрути та узгодженість середовища, а заходи часто зачіпають одразу групу акаунтів.
Якщо саме завдання відповідає правилам, але кільком акаунтам потрібні ізольовані стани входу, важливою стає ізоляція середовищ. PurpleMark, наприклад, надає незалежні середовища, щоб сесія та сховище кожного акаунта не були видимі іншим.
Практичний спосіб перевірки — вибрати невелике знайоме завдання з чіткими кроками, дати інструменту виконати його повністю, порівняти результат із ручною роботою, записати реакцію на помилки та порахувати фактичний час. Якщо невелике завдання проходить добре, масштаб можна поступово збільшувати. Спроба одразу автоматизувати весь процес зазвичай закінчується тим, що він застрягає на одному з проміжних кроків.
