Для демонстрації достатньо одного Agent в одному вікні. У робочому середовищі десяткам паралельних завдань потрібні окремі середовища, інакше змішуються сесії, вкладки конкурують за керування, а збої важко діагностувати.
Щоб показати, що вміє AI Agent, достатньо одного вікна браузера. Але в реальному бізнес-процесі потреба швидко зростає до десятків вікон, які не повинні заважати одне одному. Причина не в самому Agent, а в браузерному середовищі, на якому він працює.
Які проблеми виникають, коли одне середовище спільне
Найочевидніша проблема — взаємне забруднення cookies і станів входу. Якщо два завдання в одному каталозі даних браузера по черзі входять у різні облікові записи, пізніший вхід може перезаписати сесію попереднього. Якщо одне завдання очистить кеш, інше може втратити стан сторінки.
Далі виникає конкуренція за спільні ресурси. В одному екземплярі браузера вкладки, фокус, каталог завантажень і спливаючі вікна є спільними. Якщо два завдання одночасно відкривають нові вкладки, стає незрозуміло, яке завдання керує якою сторінкою. Діалогове вікно одного завдання може заблокувати скрипт іншого. Конфлікти входу, перезапис даних і взаємні перешкоди майже неминучі за паралельного виконання.
Третя проблема з’являється після збою. Важко зрозуміти, чи помилка була в логіці скрипту, чи середовище на певному кроці змінило інше завдання. Коли кілька завдань спільно використовують один процес і один журнал, симптоми збоїв можуть відрізнятися, що суттєво підвищує вартість діагностики.
Є й менш очевидний ризик: кілька ідентичностей, які довго працюють в одному середовищі, залишають ознаки кореляції. Параметри пристрою, стан сховища та мережевий вихід однакові, тому платформа легко може розцінити їх як масові операції з одного пристрою. Якщо один обліковий запис буде визначено як аномальний, інші також можуть постраждати.
Кілька вікон — це ще не ізоляція
Перша реакція часто полягає в тому, щоб вручну відкрити кілька вікон. Вони виглядають окремими, але насправді використовують той самий профіль браузера: ті самі cookies, локальне сховище й інформацію про пристрій. Вікна можуть бачити стан входу одне одного, а дія в одному здатна вплинути на інше.
Справжня ізоляція має охоплювати каталог даних і параметри середовища. Кожному середовищу потрібні власний каталог зберігання, власні параметри пристрою — роздільна здатність, мова, часовий пояс, шрифти, Canvas, WebGL тощо — і власний мережевий вихід. Якщо немає хоча б одного з цих трьох елементів, ізоляція неповна. Навіть за окремих середовищ спільний вихід може й далі активувати кореляційні перевірки.
Вартість ізоляції та її користь
Ізоляція не безкоштовна. За кожним середовищем стоять окремий процес браузера й окремий каталог даних. Зі зростанням кількості середовищ першими відчувають навантаження пам’ять і CPU. Якщо десятки середовищ працюють на одній машині, краще заздалегідь розрахувати запас ресурсів, а не чекати на збій.
Є кілька можливостей для компромісу: звільняти рідко потрібні середовища й запускати їх знову на вимогу; розподіляти завдання за навантаженням між кількома машинами, а не складати все на одну; визначати чіткий життєвий цикл середовищ, щоб сотні екземплярів не працювали безперервно. Важлива й структура завдань. Послідовні завдання в одному обліковому записі не потребують різних середовищ — це лише марнує ресурси.
Натомість користь суттєва. Коли ізоляцію налаштовано правильно, поведінка збоїв стає стабільною: проблема належить конкретному середовищу, а не виглядає як незрозуміла випадковість. У масштабі ця передбачуваність значно цінніша за невелику економію ресурсів від спільного використання.
Три функції, які після масштабування мають бути на рівні середовища
Перша — пакетне планування. Середовища повинні виділятися й звільнятися як обчислювальні ресурси, з підтримкою створення на вимогу, пакетного запуску, контролю паралельності, повторних спроб після збоїв і автоматичного звільнення, а не створюватися та завершуватися по одному в скриптах.
Друга — незалежний мережевий вихід. Кожне середовище має бути прив’язане до власного виходу, а його регіон повинен відповідати географічним параметрам середовища. Цей пункт легко пропустити, але він є передумовою повної ізоляції.
Третя — стан, який можна запитувати. У будь-який момент має бути зрозуміло, які середовища працюють, які вільні, а які мають аномалії. Agents працюють без нагляду; якщо стан не можна перевірити, пошук проблем перетворюється на здогадки.
Ці три можливості незручно реалізовувати всередині скриптів. Для них потрібні зберігання, конфігурація та планування на рівні середовища. Деякі інструменти керування багатьма середовищами працюють саме на цьому рівні. PurpleMark — один із них: він перетворює браузерні середовища на ресурси, які можна ізолювати, планувати пакетно та викликати через інтерфейси.
Коли кілька середовищ не потрібні
Якщо Agent використовує лише один обліковий запис і запускається рідко, звичайного браузера справді достатньо, а додаткова ізоляція лише збільшує навантаження на обслуговування. Але якщо виникає хоча б одна з таких ситуацій, рівень середовища варто відокремити: завдання мають виконуватися паралельно, кілька ідентичностей повинні працювати з однією платформою, стан входу треба підтримувати тривалий час або паралельність продовжуватиме зростати.
Усі ці випадки мають одну спільну рису: питання не в тому, чи достатньо розумний Agent, а в тому, чи достатньо чисте й відокремлене середовище під ним.
Межі
Яку б архітектуру ви не обрали, правила не змінюються: дотримуйтеся умов використання та robots-правил кожної платформи, не використовуйте неправдиві дані про ідентичність, не обходьте технічні засоби захисту, контролюйте частоту запитів і не порушуйте нормальну роботу сторонніх сервісів.
