Коли автоматизація з Agents починає давати збої зі зростанням масштабу, причина часто не в моделі чи скрипті, а в шарі браузерного середовища. У статті розглянуто чотири типові сценарії збоїв, їхні помітні ознаки та відповідні інженерні підходи.
Створити Agent за допомогою LangChain, AutoGen або CrewAI й дати йому керувати сайтами через Playwright чи Puppeteer не надто складно. Набагато складніше забезпечити його стабільну безперервну роботу.
Одразу після запуску проблеми зазвичай непомітні. Коли обсяг завдань зростає, аномалії починають виникати частіше: сайти блокують завдання, сесії облікових записів раптово завершуються або кілька Agents заважають один одному під час паралельної роботи. Першою реакцією часто стає перевірка коду, а згодом з’ясовується, що з кодом усе гаразд.
Причина нерідко знаходиться в шарі браузерного середовища. У проєктах з великим навантаженням збої зазвичай повторюються в кількох типових формах. Коли їх розпізнати, розв’язання стає значно простішим.
Запуск до готовності середовища
Якщо щойно створене браузерне середовище одразу використати для завдання, типовими наслідками будуть невдалий вхід, неповне завантаження елементів сторінки або запит на перевірку вже на першому кроці. Причина проста: у середовища немає історії відвідувань, cookie чи будь-якої історії перегляду. Для платформи це виглядає як абсолютно невідомий пристрій, тому рівень довіри до нього природно низький.
Помітна ознака полягає в тому, що збої концентруються на перших кількох завданнях після створення середовища. Якщо те саме завдання перенести до середовища, яке використовується вже певний час, воно часто виконується нормально.
Правильний підхід — зробити готовність середовища явним станом, а не припускати, що воно готове за замовчуванням. Після створення середовища варто спочатку дозволити йому певний час виконувати навігацію з низькою інтенсивністю, а реальні завдання призначати лише після стабілізації стану. Планувальник повинен перевіряти цю готовність перед надсиланням завдання, а не використовувати середовище одразу.
Кілька завдань конкурують за одне середовище
Коли паралельність зростає, найпомітніший симптом — накопичення процесів, вичерпання пам’яті та сповільнення системи. Складнішими є приховані проблеми: два завдання послідовно використовують ті самі cookie та локальне сховище, стан входу завдання A витісняє стан завдання B, а в журналах це виглядає так, ніби час від часу випадково падає якесь завдання. Виявити причину непросто.
Тут браузерні середовища варто розглядати як ресурси, які можна виділяти та звільняти. На початку завдання отримує одне середовище, а після завершення повертає його, зберігаючи зв’язок один до одного між завданням і середовищем. Сховища різних середовищ не бачать одне одного, тому стан входу одного завдання не проникає до іншого. При масштабуванні до десятків Agents, що працюють паралельно, різниця порівняно з «просто запустити багато процесів браузера всередині скрипту» стає дуже помітною.
Якщо сценарій передбачає кілька облікових записів, ізоляція має бути ще жорсткішою: кожен обліковий запис повинен мати закріплене середовище, а параметри відбитка та сховище не мають перетинатися з іншими обліковими записами. PurpleMark надає саме цей шар ізоляції середовищ і централізованого планування, щоб між обліковими записами та середовищами зберігався стабільний зв’язок один до одного.
Закінчення сесії залишається непоміченим
Цей тип збою легко пропустити, бо він не обов’язково створює помилку. Завдання продовжує виконуватися, журнали заповнюються, але фактично повертається сторінка входу або порожні дані. Проблему виявляють лише після потрапляння результату до конвеєра даних, і тоді діагностику доводиться вести у зворотному напрямку від наступних етапів, що дорого коштує.
Рішення — явно перевіряти стан входу як попередню умову. Перед запуском завдання потрібно переконатися, що поточна сесія ще дійсна. Якщо вона завершилася, слід пройти повний процес входу, а не дозволяти завданню працювати з недійсним станом. Сам стан має зберігатися в шарі середовища: cookie, локальне сховище та історія перегляду залишаються в середовищі й можуть бути повністю відновлені при наступному запуску, тому завдання облікового запису не потрібно щоразу ініціалізувати заново.
Практичне спостереження: для облікових записів, що працюють тривалий час, часті зміни стану входу самі можуть виглядати для платформи як аномальний сигнал і спричиняти додаткову перевірку. Тому непотрібних повторних входів краще уникати.
Одне блокування зупиняє всю групу
Ще один тип збою виникає раптово серіями: велика кількість завдань одночасно перестає повертати результати. Сайт не завжди показує явну відмову; частіше він повертає спрощений вміст або порожню сторінку, а Agent продовжує працювати з беззмістовними даними, доки проблема не проявиться на етапі обробки даних.
У такій ситуації насамперед потрібно відрізнити блокування від звичайної помилки. Якщо одна й та сама група середовищ стає аномальною приблизно в один час, дуже ймовірно, що проблема знаходиться саме в шарі середовища. Подальші повторні спроби лише розширять вплив, тому спочатку ці середовища варто зупинити й ізолювати, а потім досліджувати причину.
Типові причини можна поділити на три напрями: кілька середовищ використовують надто схожі конфігурації відбитка, наприклад майже однакові WebGL, Canvas, списки шрифтів або версії рушія; вихідна IP-адреса, часовий пояс і мова не узгоджені, наприклад IP США з азійським часовим поясом; або інтервали між діями надто регулярні й сам ритм стає характерною ознакою. Узгоджуйте конфігурацію, контролюйте темп і зберігайте журнали стану середовища та результатів завдань, щоб бачити ранні сигнали до того, як збій охопить всю групу.
Винести цей шар окремо
Зрілі проєкти зазвичай відокремлюють браузерне середовище від Agent і керують ним як окремим шаром: Agent відповідає за планування та рішення, шар середовища — за ідентичність і стан, а шар виконання залишається на Playwright або Puppeteer. Після такого розділення з’являється чітке місце для керування тим, чи виглядає ідентичність правдоподібною, чи можна відновити стан і чи ізольовані завдання одне від одного.
Якщо підсумувати, усі чотири типи збоїв мають спільну рису: вони не знаходяться ані в моделі, ані в логіці скрипту. Модель і код, звісно, потрібно й надалі вдосконалювати, але здатність автоматизації стабільно працювати в довгостроковій перспективі часто визначається саме цим нижчим шаром.
Цей матеріал призначений для технічних досліджень і обміну практиками розробки. Автоматизацію слід використовувати законно та відповідно до правил, дотримуючись умов використання цільової платформи й чинних місцевих законів та нормативних вимог.
