Agent принимает решения, Playwright управляет браузером, но слой среды часто остается без внимания. В долгих задачах сбора данных сбои нередко концентрируются именно здесь.
Когда Agent-фреймворк управляет браузером для сбора данных, архитектура обычно состоит из трех слоев: Agent планирует и принимает решения, Playwright отвечает за клики, ввод и извлечение данных, а затем рабочий процесс взаимодействует с целевым сайтом. Короткие задачи обычно выполняются гладко и проходят локальные тесты. Но когда время работы увеличивается и число задач растет, сбои начинают концентрироваться в месте, которому редко уделяют достаточно внимания, — в среде браузера.
Если оглянуться на проблемы из практики, сбои на уровне среды обычно принимают три формы.
Среда признается аномальной, и весь pipeline останавливается
Один из вариантов — платформа реагирует на саму среду. Часто это проявляется не как прямая блокировка, а как деградация: упрощенные страницы, пустые результаты или требование пройти проверку. Скрипт не выбрасывает ошибку, но полученные данные уже не имеют практической ценности. Последующие этапы продолжают выполняться и переносят ошибочные данные вплоть до итоговой таблицы.
Проблема в том, что такие среды часто используются сразу несколькими задачами. Если одна среда выходит из нормального состояния, все связанные с ней задачи могут остановиться. Повторные попытки не помогают, потому что причина находится не в скрипте.
Несколько задач делят одну среду, и состояния сессий смешиваются
Когда задачи выполняются параллельно в одном экземпляре браузера, Cookie, localStorage и IndexedDB могут перезаписывать данные друг друга и вытеснять состояния входа. В коротком запуске это почти незаметно, но через несколько дней могут появиться необъяснимые запросы на повторную авторизацию.
Есть и более скрытый drift. В браузере, который работает долго, кэш, хранилища и даже состояние рендеринга WebGL постепенно меняются. Одна и та же среда сегодня и через три дня может иметь разные характеристики. Часто это принимают за истекшую Cookie, хотя на самом деле изменилась сама среда. Поэтому обычно выгоднее делать среды постоянными и повторно используемыми объектами, чем каждый раз запускать новый браузер.
При возобновлении с checkpoint исходная среда может оказаться непригодной
Задачи сбора данных редко завершаются за один запуск. Продолжать с checkpoint после прерывания — обычная практика, но здесь легко потерять уже выполненную работу: при перезапуске скрипта можно автоматически создать новый экземпляр браузера и потерять состояние входа; либо продолжить использовать старую среду, хотя платформа уже пометила ее, и дальнейшая работа будет лишь расходовать ресурсы.
Ключевой вопрос здесь не в количестве повторов, а в детализации восстановления. Если вне скрипта не сохраняются текущий этап задачи, уже собранные данные и использованная среда, после перезапуска останется только начать с нуля.
Что можно сделать на уровне среды
Если объединить эти три проблемы, подход сводится к трем принципам.
Группируйте среды по задачам. Одной задаче должна соответствовать собственная группа сред, а не несколько задач в одном экземпляре. После разделения для каждой задачи можно отдельно задать сетевой выход, часовой пояс и язык. Надежнее согласовывать эти параметры как единый набор, чем вручную задавать их по отдельности. В такой архитектуре PurpleMark находится на уровне среды: он пакетно создает браузерные среды, привязывает к каждой независимый сетевой выход и через API передает их слою оркестрации задач для планирования.
Изолируйте сбои. Если одна среда признана аномальной, это должно затрагивать только привязанные к ней задачи. Обычно для каждой среды хранят статус здоровья, регулярно его проверяют и при обнаружении проблемы выводят среду из работы, заменяя резервной, вместо того чтобы заставлять верхнеуровневые скрипты бесконечно повторять попытки в той же неисправной среде. Заодно становится проще понять причину: проблема в среде или изменилась структура страницы.
Делайте состояние восстанавливаемым. Прогресс, отпечатки дедупликации и идентификаторы сред нужно постоянно хранить вне скрипта. При перезапуске сначала читаются эти записи, после чего определяется точка продолжения и выбирается среда. Разделение задачи на этапы обнаружения, загрузки и извлечения позволяет обрабатывать сбои отдельно и не терять весь запуск из-за одной ошибки. Важно следить и за ресурсами: в долго работающих экземплярах могут появляться утечки памяти, зависания страниц и тайм-ауты соединения, поэтому недействительные сессии следует регулярно перерабатывать.
Границы, которые нужно четко разделять
Стабильность среды и допустимость сбора данных — разные вопросы. Сначала следует изучить robots-правила и условия использования целевого сайта, поскольку многие сайты прямо ограничивают автоматизированный доступ; частоту запросов нужно удерживать на уровне, который не влияет на чужой сервис; персональные данные собирать не следует; а при наличии технических мер защиты правильный подход — скорректировать стратегию или получить разрешение, а не пытаться их обходить. Техническая стабильность не заменяет оценку соблюдения требований.
Материал предназначен только для технических исследований и обмена опытом разработки. Соблюдайте условия целевого сайта и законодательство, действующее в вашем регионе.
