Для демонстрации достаточно одного Agent в одном окне. В рабочей среде десяткам параллельных задач нужны раздельные окружения, иначе смешиваются сессии, вкладки конкурируют за управление, а сбои трудно диагностировать.
Чтобы показать возможности AI Agent, достаточно одного окна браузера. Но в реальном бизнес-процессе быстро возникает потребность в десятках окон, которые не должны мешать друг другу. Причина не в самом Agent, а в браузерной среде, на которой он работает.
Какие проблемы возникают при совместном использовании одной среды
Самая очевидная проблема — взаимное загрязнение cookies и состояний входа. Если две задачи в одном каталоге данных браузера по очереди входят в разные учетные записи, более поздний вход может перезаписать сессию предыдущей задачи. Если одна задача очистит кэш, другая может потерять состояние страницы.
Далее возникает конкуренция за общие ресурсы. В одном экземпляре браузера вкладки, фокус, каталог загрузок и всплывающие окна используются совместно. Если две задачи одновременно открывают новые вкладки, становится непонятно, какая задача управляет какой страницей. Диалоговое окно одной задачи может заблокировать скрипт другой. Конфликты состояний входа, перезапись данных и взаимные помехи при параллельном выполнении почти неизбежны.
Третья проблема проявляется уже после сбоя. Трудно понять, была ли ошибка в логике скрипта или среда на каком-то шаге была нарушена другой задачей. Когда несколько задач используют один процесс и один журнал, симптомы сбоев могут отличаться, что многократно повышает стоимость диагностики.
Есть и менее очевидный риск: несколько идентичностей, которые долго работают в одной среде, оставляют признаки корреляции. Параметры устройства, состояние хранилища и сетевой выход совпадают, поэтому платформа легко может увидеть в них массовые действия с одного устройства. Если одна учетная запись будет признана аномальной, это может затронуть и другие.
Несколько окон — это еще не изоляция
Частая первая реакция — просто вручную открыть несколько окон. Визуально они разделены, но фактически используют один профиль браузера: общие cookies, локальное хранилище и параметры устройства. Окна могут видеть состояние входа друг друга, а действие в одном окне способно повлиять на другое.
Настоящая изоляция должна охватывать каталог данных и параметры среды. Для каждой среды нужны собственный каталог хранения, собственные параметры устройства — разрешение, язык, часовой пояс, шрифты, Canvas, WebGL и другие — и собственный сетевой выход. Если отсутствует любой из этих трех элементов, изоляция неполна. Даже раздельные среды при общем сетевом выходе могут по-прежнему попадать под корреляционные проверки.
Цена изоляции и ее отдача
Изоляция не бывает бесплатной. За каждой средой стоят отдельный процесс браузера и отдельный каталог данных. По мере роста числа сред первыми ощущают нагрузку память и CPU. Если на одной машине должны работать десятки сред, лучше заранее рассчитать запас ресурсов, а не ждать сбоя.
Есть несколько вариантов компромисса: освобождать редко используемые среды и запускать их снова по мере необходимости; распределять задачи по нагрузке между несколькими машинами, а не складывать все на одну; задавать средам четкий жизненный цикл и не держать сотни экземпляров активными бесконечно. Важна и структура задач. Последовательные задачи в рамках одной учетной записи не нужно разделять по нескольким средам — это только расходует ресурсы.
С другой стороны, есть существенная выгода. При правильной изоляции поведение сбоев становится стабильным: проблема относится к конкретной среде, а не выглядит как непредсказуемая случайность. В масштабе эта предсказуемость намного ценнее небольшой экономии ресурсов от совместного использования.
Три функции, которые при масштабировании должны быть на уровне среды
Первая — пакетное планирование. Среды должны выделяться и освобождаться как вычислительные ресурсы, с созданием по требованию, пакетным запуском, контролем параллелизма, повторными попытками после сбоев и автоматическим освобождением, вместо поштучного создания и завершения внутри скриптов.
Вторая — независимый сетевой выход. Каждая среда должна быть привязана к своему выходу, а его регион должен соответствовать географическим параметрам среды. Этот пункт легко упустить, но он является предпосылкой целостной изоляции.
Третья — доступный для запроса статус. В любой момент должно быть понятно, какие среды работают, какие свободны и какие находятся в ошибочном состоянии. Agents работают без присмотра; если статус среды нельзя запросить, поиск проблемы превращается в догадки.
Эти три возможности неудобно реализовывать внутри скриптов. Для них нужны хранение, конфигурация и планирование на уровне среды. Некоторые инструменты управления множеством сред работают именно на этом уровне. PurpleMark — один из них: он превращает браузерные среды в ресурсы, которые можно изолировать, запускать пакетно и вызывать через интерфейсы.
Когда несколько сред не нужны
Если Agent работает только с одной учетной записью и запускается редко, обычного браузера действительно достаточно, а дополнительная изоляция лишь увеличивает нагрузку на обслуживание. Но если возникает хотя бы одно из следующих условий, уровень среды стоит отделить: задачи должны выполняться параллельно, несколько идентичностей должны обращаться к одной платформе, состояние входа нужно сохранять длительное время или параллелизм будет продолжать расти.
Все эти случаи объединяет одно: вопрос не в том, достаточно ли умен Agent, а в том, достаточно ли чиста и отделена среда под ним.
Границы
Какую бы архитектуру вы ни выбрали, правила не меняются: соблюдайте условия использования и robots-правила каждой платформы, не используйте ложные данные об идентичности, не обходите технические меры защиты, контролируйте частоту запросов и не нарушайте нормальную работу сторонних сервисов.
