Прокси для AI-агентов browser-use и computer-use (руководство 2026)

2026-й — год, когда AI-агенты перестали быть демками. browser-use, агенты в духе OpenAI Operator, computer use от Anthropic и десяток фреймворков на базе Playwright теперь управляют настоящими браузерами на настоящих сайтах — бронируют, покупают, исследуют, мониторят. И все они упираются в одну и ту же стену: сайты, на которых они работают, считают их ботами, потому что они и есть боты.

Это руководство покрывает слой прокси конкретно для AI-агентов, управляющих браузером. Если ваш агент использует HTTP-библиотеки вместо браузера (инструменты LangChain, парсеры внутри CrewAI), смотрите Прокси для AI-агентов: LangChain, AutoGPT и CrewAI — эта статья про агентов, которые управляют полноценным браузером.

Почему браузерные агенты блокируются быстрее парсеров

Контринтуитивно, но факт: LLM-агент, управляющий настоящим Chrome, часто блокируется быстрее, чем простой Python-парсер. Три причины:

1. Дата-центровый IP + идеальный браузер = несоответствие. Фингерпринт браузера говорит «настоящий Chrome на настоящем железе», но IP принадлежит AWS или GCP — где большинство агентов и работают. Антибот-вендоры сильно взвешивают ASN IP; резидентного уровня фингерпринт на дата-центровом ASN — хрестоматийная подпись автоматизации.
2. Агенты ретраят как машины. Когда действие проваливается, цикл LLM мгновенно повторяет его, с того же IP, с почти идентичным таймингом. Три быстрых одинаковых ретрая — это азбука поведенческого детектирования.
3. CDP оставляет следы. Большинство фреймворков агентов управляют браузером через Chrome DevTools Protocol. Сайты прощупывают navigator.webdriver, специфичные для CDP артефакты тайминга и признаки headless. В сочетании с помеченным IP оценка мгновенно переходит порог блокировки.

IP — самое дешёвое из трёх для починки, и одно его исправление снимает большинство блокировок: пропустите агента через резидентные прокси, чтобы история IP совпадала с историей браузера.

Настройка: browser-use с резидентными прокси

browser-use построен на Playwright, так что поддержка прокси нативная. Паттерн: одна sticky-сессия на задачу агента, чтобы IP оставался стабильным, пока агент работает, и свежий IP на следующую задачу.

from browser_use import Agent, Browser, BrowserConfig
from langchain_openai import ChatOpenAI
import uuid

task_id = uuid.uuid4().hex[:8]

browser = Browser(config=BrowserConfig(
    proxy={
        "server": "http://us.jibaoproxy.com:913",
        "username": f"USERNAME-session-{task_id}",   # sticky: один IP на эту задачу
        "password": "PASSWORD",
    },
))

agent = Agent(
    task="Find the current price of the Sony WH-1000XM6 on the three largest US retailers.",
    llm=ChatOpenAI(model="gpt-4o"),
    browser=browser,
)
result = await agent.run()

Ключевая деталь: суффикс session-{task_id}. Без него ротационный шлюз может выдать агенту новый IP посреди задачи — содержимое корзины исчезает, сессии входа рвутся, а агент тратит вызовы LLM на переделку шагов. С ним задача выполняется на одном IP от начала до конца, а следующая получает чистый.

Настройка: чистый Playwright / циклы computer-use

Если вы построили собственный цикл агента на Playwright (паттерн за большинством реализаций в духе Operator и computer use), прокси идёт на контекст браузера:

from playwright.async_api import async_playwright

async with async_playwright() as p:
    browser = await p.chromium.launch(headless=False)
    context = await browser.new_context(
        proxy={
            "server": "http://us.jibaoproxy.com:913",
            "username": "USERNAME-session-agent42",
            "password": "PASSWORD",
        },
        viewport={"width": 1366, "height": 768},
        locale="en-US",
        timezone_id="America/Chicago",   # совпадает со страной прокси
    )
    page = await context.new_page()
    # ... цикл агента: скриншот -> LLM -> действие -> повтор

Задайте locale и timezone_id в соответствии со страной прокси. Агент, сёрфящий с американского IP с часами UTC+8 — это несоответствие, которое поведенческие системы зачтут вам в минус.

Прокси на каждый контекст также дают вам один браузер, много агентов: каждый new_context() может нести свой суффикс session, так что десять параллельных задач агентов работают на десяти разных резидентных IP без десяти процессов Chrome.

Стратегия сессий для нагрузок агентов

Нагрузка агента	Стратегия сессии	Почему
Ресёрч / проверка цен (без входа)	Sticky, 10 мин, новая сессия на задачу	Стабильно в рамках задачи, свежий IP между задачами
Работа в авторизованном аккаунте	Sticky 30 мин, тот же ID сессии каждый запуск	Сайты помечают аккаунты, прыгающие между странами при входах
Оформление заказа / бронирование	Sticky 30 мин	Смена IP посреди оформления убивает сессию и запускает антифрод
Высокообъёмный мониторинг (сотни страниц)	Ротация, без закрепления сессии	Максимум разнообразия IP, нет состояния для сохранения

Контроль расходов: агенты жгут трафик

Резидентный трафик тарифицируется по ГБ, а браузерный агент тянет полные страницы — картинки, шрифты, трекеры — в отличие от HTTP-парсера. Без управления одна задача агента может съесть 20–50 МБ. Три решения, по убыванию эффекта:

1. Блокируйте тяжёлые ресурсы, которые не нужны LLM:

   await context.route("**/*.{png,jpg,jpeg,webp,gif,woff,woff2,mp4}",
                       lambda route: route.abort())

   Если ваш агент читает скриншоты, оставьте картинки на целевой странице, но всё равно блокируйте видео и шрифты. Если он читает DOM/дерево доступности, блокируйте и картинки — это срезает трафик на 60–80%.
2. Маршрутизируйте только то, что нужно маршрутизировать. Вызовы LLM API (OpenAI/Anthropic) НЕ должны идти через резидентный прокси — это чисто потраченные ГБ и лишняя задержка. Проксируйте контекст браузера, а не сам процесс-хост.
3. Ограничьте ретраи на уровне фреймворка. Максимум два ретрая, с бэк-оффом и свежим ID сессии на втором — новый IP чинит больше блокировок, чем третья идентичная попытка.

С блокировкой картинок и точечной маршрутизацией типичные задачи браузерного агента укладываются в 2–8 МБ — при $6.8/ГБ это несколько центов на сотню задач.

Что прокси не чинят

Раздел честности. Резидентный IP чинит несоответствие ASN и репутацию IP — самый весомый отдельный сигнал в антибот-оценке 2026 года. Он не чинит:

• Детект CDP/headless — используйте stealth-опции вашего фреймворка (browser-use поставляется с пропатченными флагами запуска; для чистого Playwright смотрите патчи в духе rebrowser) и предпочитайте headed-режим для ценных сценариев.
• TLS-фингерпринтинг — для настоящих браузерных агентов не проблема (TLS браузера подлинный), но именно поэтому вы не можете просто «переиграть» запросы агента через requests позже. См. JA3/JA4 простыми словами.
• Поведенческую оценку потока действий — добавляйте небольшие рандомизированные задержки между действиями и избегайте попиксельно одинаковых координат кликов между прогонами.

Сложите все три на резидентном IP — и браузерные агенты проходят те же проверки, что и реальные пользователи. Для самых сложных целей (DataDome, PerimeterX) смотрите наше руководство по DataDome/PerimeterX.

Итог

• Агенты на дата-центровых IP сами себя выдают; резидентные IP заставляют историю IP совпадать с историей браузера.
• Одна sticky-сессия на задачу агента; один и тот же ID сессии навсегда для авторизованных аккаунтов; ротация для мониторинга без состояния.
• Согласуйте timezone_id/locale со страной прокси.
• Блокируйте картинки/шрифты/видео и никогда не пускайте вызовы LLM API через резидентный трафик.
• Ретрайте с новым ID сессии, а не на том же IP.