Когда автоматизация с Agents начинает давать сбои по мере масштабирования, причина часто находится не в модели или скрипте, а на уровне браузерной среды. В статье разобраны четыре распространённых сценария, их наблюдаемые признаки и соответствующие инженерные меры.
Собрать Agent на LangChain, AutoGen или CrewAI и дать ему управлять сайтами через Playwright или Puppeteer не так сложно. Гораздо сложнее обеспечить его стабильную непрерывную работу.
Сразу после запуска проблемы обычно почти незаметны. Когда объём задач растёт, сбои начинают появляться всё чаще: сайты блокируют задачи, сессии аккаунтов внезапно истекают, а несколько Agents при параллельной работе мешают друг другу. Первая реакция часто — вернуться к коду и проверить его, но в итоге выясняется, что с кодом всё в порядке.
Причина нередко находится на уровне браузерной среды. В проектах с большим объёмом запусков сбои обычно сводятся к нескольким повторяющимся формам. Если научиться их распознавать, справляться с ними становится значительно проще.
Запуск до готовности среды
Если только что созданную браузерную среду сразу использовать для задачи, типичными последствиями будут неудачный вход, неполная загрузка элементов страницы или запрос на проверку уже на первом шаге. Причина проста: у такой среды нет истории посещений, Cookie и следов браузинга. Для платформы она выглядит как совершенно незнакомое устройство, поэтому уровень доверия к ней изначально низкий.
Наблюдаемый признак — сбои концентрируются в первых нескольких задачах после создания среды. Если перенести ту же задачу в среду, которая используется уже некоторое время, она часто завершается нормально.
Правильный подход — сделать готовность среды явным состоянием, а не считать по умолчанию, что её можно сразу использовать. После создания стоит дать среде некоторое время на низкоинтенсивный браузинг и назначать реальные задачи только после стабилизации состояния. Планировщик должен проверять эту готовность перед выдачей задачи, а не использовать новую среду немедленно.
Несколько задач конкурируют за одну среду
С ростом параллельности самый очевидный симптом — процессы накапливаются, память заполняется, система замедляется. Гораздо неприятнее скрытые проблемы: две задачи последовательно используют одни и те же Cookie и локальное хранилище, состояние входа задачи A вытесняет состояние B, а в логах выглядит так, будто время от времени случайно падает какая-то задача. Найти причину трудно.
В такой ситуации браузерные среды нужно рассматривать как ресурсы, которые можно выделять и освобождать. При старте задача получает одну среду, а после завершения возвращает её, сохраняя отношение один к одному между задачей и средой. Хранилища разных сред не видны друг другу, поэтому состояние входа одной задачи не попадает в другую. При масштабировании до десятков Agents, работающих параллельно, разница с подходом «просто запускать много браузерных процессов внутри скрипта» становится очень заметной.
Если сценарий включает несколько аккаунтов, изоляцию нужно усилить: каждому аккаунту следует закрепить отдельную среду, а параметры fingerprint и хранилище не должны пересекаться с другими аккаунтами. PurpleMark предоставляет уровень изоляции сред и централизованного планирования, чтобы между аккаунтами и средами сохранялось стабильное соответствие один к одному.
Истечение сессии остаётся незамеченным
Этот тип сбоя легко пропустить, потому что он может не выдавать ошибку. Задача продолжает выполняться, логи продолжают записываться, но фактически возвращается страница входа или пустые данные. Проблему замечают только после того, как результат уже попал в конвейер данных, и диагностику приходится вести назад от нижележащих этапов, что обходится дорого.
Решение — явно проверять состояние входа как предварительное условие. Перед началом задачи нужно убедиться, что текущая сессия всё ещё действительна. Если она истекла, следует выполнить полный процесс входа вместо продолжения работы с недействительным состоянием. Само состояние должно храниться на уровне среды: Cookie, локальное хранилище и история браузинга остаются в среде и могут полностью восстанавливаться при следующем запуске, поэтому задачи аккаунта не приходится каждый раз инициализировать заново.
Практическое наблюдение: для долго работающих аккаунтов частые изменения состояния входа сами по себе могут выглядеть для платформы как аномальный сигнал и вызывать дополнительную проверку. Поэтому ненужных повторных входов лучше избегать.
Одна блокировка останавливает весь пакет
Ещё один тип сбоя возникает внезапно и массово: множество задач одновременно перестают возвращать результат. Сайт не обязательно выдаёт явный отказ; чаще он возвращает урезанный контент или пустую страницу, а Agent продолжает работу с бессмысленными данными, пока проблема не проявится уже на этапе обработки данных.
В такой ситуации сначала нужно отличить блокировку от обычного сбоя. Если одна и та же группа сред становится аномальной примерно в одно и то же время, очень вероятно, что причина находится на уровне среды. Продолжение повторных попыток только увеличит масштаб последствий, поэтому сначала эти среды стоит остановить и изолировать, а затем исследовать триггер.
Типичные триггеры можно разделить на три направления: несколько сред используют слишком похожие fingerprint-конфигурации, например почти одинаковые WebGL, Canvas, списки шрифтов или версии движка; выходной IP, часовой пояс и язык не соответствуют друг другу, например американский IP сочетается с азиатским часовым поясом; либо интервалы между действиями настолько регулярны, что сам ритм становится отличительным признаком. Нужно согласовать параметры, контролировать темп и записывать в логи как состояние среды, так и результаты задач, чтобы замечать ранние признаки до того, как сбой охватит весь пакет.
Выделить этот уровень отдельно
Зрелые проекты обычно отделяют браузерную среду от Agent и управляют ею как самостоятельным уровнем: Agent отвечает за планирование и решения, уровень среды — за идентичность и состояние, а уровень исполнения по-прежнему использует Playwright или Puppeteer. После такого разделения становится понятно, где управлять достоверностью идентичности, восстановлением состояния и изоляцией задач друг от друга.
Если посмотреть на четыре типа сбоев вместе, у них есть общая черта: они находятся не в модели и не в логике скрипта. Модель и код, конечно, нужно продолжать улучшать, но возможность автоматизации стабильно работать в долгосрочной перспективе часто определяется именно этим более низким уровнем.
Материал предназначен для технических исследований и обмена практиками разработки. Автоматизацию следует использовать законно и с соблюдением правил, учитывая условия использования целевой платформы и применимые местные законы и нормативные требования.
