Computer use и браузерные агенты в продакшене

Демо завораживают. ИИ проходит сложный процесс бронирования, переключается между приложениями, заполняет государственные формы, автономно выполняет многочасовые задачи. В 2024–2025 годах Anthropic Computer Use, OpenAI Operator, Google Project Mariner и волна стартапов показали агентов, которые управляют компьютерами как люди.

В 2026 году эти инструменты реальны. Они работают. Некоторые компании успешно разворачивают их в продакшене. Но эти развёртывания не похожи на демо. Они уже, жёстче ограничены и окружены ограждениями. Паттерны, которые отличают продакшен от демо, — и есть тема этой статьи.

Основы мы разбирали в статье среднего уровня. Здесь идём глубже: продакшен-паттерны, повторяющиеся отказы, экономика и то, как выкатить computer-use систему, которая действительно полезна в масштабе.

Реальность продакшена

Несколько паттернов, которые мы наблюдаем в реальных продакшен-развёртываниях:

Паттерн 1: доминируют узкие задачи. Продакшен-развёртывания добиваются успеха на конкретных, чётко определённых задачах. Не «делай что угодно». Не «работай с любым сайтом». Конкретные процессы на конкретных сайтах.

Паттерн 2: жёсткое определение рамок. Задачи поставлены узко. Агенту разрешены только определённые действия на определённых сайтах. Всё, что выходит за рамки, вызывает остановку, а не импровизацию.

Паттерн 3: записанные сценарии вместо автономного исследования. Многие продакшен-развёртывания используют записанные сценарии (шаги, определённые один раз и проигрываемые с поправками), а не полностью автономных агентов. Надёжнее, легче поддерживать.

Паттерн 4: human-in-the-loop для последствий. Любое действие со значимыми последствиями (финансовые, юридические, клиентские) проходит через человеческое подтверждение.

Паттерн 5: агрессивный мониторинг. Каждое действие логируется. Детекция аномалий. Аварийные выключатели. Команда эксплуатации смотрит дашборды.

Паттерн 6: дисциплина по затратам. Экономика важна. Многие теоретические развёртывания «ИИ делает всё» не сводятся по деньгам против человека или RPA.

Паттерн 7: специализированные vs общие. Продакшен-развёртывания обычно используют специализированные модели (или специализированные конфигурации), а не универсальные computer-use модели на всё.

Эти паттерны ложатся на то, как обычно выглядит продакшен-ИИ: рамки уже и ограждения жёстче, чем обещает маркетинг.

Где computer-use агенты сияют в продакшене

Конкретные категории задач, где computer-use — правильный инструмент:

1. Извлечение данных с сайтов без API

У многих корпоративных инструментов, государственных порталов и небольших B2B-сервисов нет API. Или есть API с заметными пробелами. Computer-use агенты могут извлекать данные, управляя UI.

Примеры из продакшена:

• Получение счетов из 50+ порталов поставщиков.
• Извлечение данных по делам из сайтов судебной системы.
• Сбор страниц с ценами конкурентов.
• Агрегация данных из порталов отчётности по комплаенсу.

Когда альтернатива — человек, который скучно кликает, computer-use выигрывает очевидно.

2. Заполнение форм в масштабе

Подача однотипных форм на разные сайты. Каждый сайт чуть-чуть свой; API был бы идеален, но его нет.

Примеры:

• Заявки в государственные ведомства (у каждого свой портал).
• Комплаенс-отчётность.
• Онбординг клиентов в системы поставщиков.
• Настройка аккаунтов в SaaS-инструментах.

3. UI-тестирование и контроль качества

Computer-use агенты — неплохие QA-тестировщики. Они умеют ходить по приложениям, прогонять пользовательские сценарии, сообщать о проблемах.

Примеры:

• End-to-end тестирование веб-приложений.
• Визуальное regression-тестирование.
• Аудиты доступности.
• Проверка пользовательских сценариев на разных устройствах.

Это смежно с RPA, но с гибкостью ИИ, чтобы выдерживать изменения UI.

4. Кросс-приложенческие процессы

Задачи, которые охватывают несколько приложений без единой точки интеграции.

Примеры:

• Вытащить данные из CRM, оформить, загрузить в аналитический инструмент.
• Взять обращения в поддержку, создать задачи в проектном инструменте, обновить статус в CRM.
• Собрать отчёты из нескольких внутренних инструментов.

Когда вы не можете или не хотите интегрировать приложения напрямую, агент даёт гибкий мост.

5. Повторяющиеся многошаговые процессы

Задачи, которые один и тот же человек делает снова и снова.

Примеры:

• Онбординг новых клиентов через 30-шаговый процесс.
• Еженедельная сверка данных между двумя системами.
• Регулярные отчёты, требующие сведения из нескольких источников.

Если процесс чётко определён, повторяется часто и сейчас выполняется людьми, которые кликают — это кандидат.

Где они пока проваливаются

Обратная сторона: задачи, для которых computer-use агенты ещё не готовы в продакшене.

1. Задачи, требующие суждения

«Найди мне хорошего поставщика». Агенты умеют ходить по сайтам поставщиков; они не могут судить, кто из них хорош для именно ваших нужд.

2. Задачи с новыми UI-паттернами

Новый сайт, которого никто раньше не видел. Агентам тяжело разобраться в необычных UI-конвенциях. Они лучше работают на распространённых паттернах (формы, списки, меню навигации), чем на самобытных дизайнах.

3. Задачи с сильной защитой от ботов

Многие сайты активно детектируют и блокируют автоматизацию. Иногда агенты обходят защиту (с усилием), но это вечная игра в кошки-мышки. Часто не стоит того.

4. Высокорисковые единичные действия

Отправка платежа, подписание юридического документа, публикация в публичном пространстве от чьего-то имени. Зона поражения от неверного действия большая; человеческая проверка обязательна.

5. Задачи, требующие реального контекста

Агент видит только то, что на экране. Он не знает ваши отношения с клиентом, недавний контекст команды, политическую обстановку. Задачи без контекста проваливаются.

6. Открытые исследования

«Найди лучшую сделку» или «изучи этого человека внимательно» — задачи без чётких критериев завершения. Агенты либо крутятся бесконечно, либо останавливаются слишком рано.

Архитектура

У продакшен-системы computer-use есть такие слои:

┌─────────────────────────────────────┐
│ Orchestration                       │ Schedules, retries, escalations
├─────────────────────────────────────┤
│ Task definition + scope             │ What the agent does and doesn't do
├─────────────────────────────────────┤
│ Agent runtime (Computer Use SDK)    │ Anthropic / OpenAI / Browserbase
├─────────────────────────────────────┤
│ Browser / desktop environment       │ Isolated, sandboxed
├─────────────────────────────────────┤
│ Authentication and session          │ Credentials, cookies, MFA handling
├─────────────────────────────────────┤
│ Result handling                     │ Capture, validate, store
├─────────────────────────────────────┤
│ Monitoring + alerts                 │ Real-time observability
└─────────────────────────────────────┘

Пройдём по каждому.

Определение задачи

Самый важный шаг. Определите, что агент делает, узко.

Хорошее определение задачи включает:

Триггер. Что её запускает? (Расписание, событие, ручной запуск.)

Входы. Какими данными располагает агент? (Конкретная запись, структурированные данные формы.)

Рамки. Какие сайты, какие действия, какие пути по UI.

Критерии успеха. Как выглядит завершение?

Условия остановки. Что прекращает задачу досрочно?

Выход. Какие данные агент возвращает?

Семантика ошибок. Как сбои категоризируются и сообщаются?

Плохо определённая задача: «Подать наш еженедельный отчёт по комплаенсу».

Хорошо определённая задача:

Task: Submit weekly compliance report to portal X.

Trigger: Cron, every Monday at 9 AM.

Inputs:
- Report data file (CSV) from /reports/weekly.csv
- Submitter info from environment variables (name, ID).
- Credentials from secrets manager.

Scope:
- Site: https://portal.example.gov/submit (and subpaths)
- Allowed actions: navigate, click, type, upload, submit, screenshot.
- Forbidden: visit external sites, change account settings, navigate away from submission flow.

Success criteria:
- Receive confirmation page with submission ID.
- Capture submission ID.

Stop conditions:
- Confirmation received: success.
- CAPTCHA: escalate to human.
- Login failure: escalate to human.
- Form validation error: report and stop.
- Timeout 5 minutes: report and stop.

Output:
- Submission ID.
- Screenshot of confirmation page.
- Timestamp.

Errors:
- Validation: log, notify owner, do not retry.
- Auth: log, notify ops, do not retry.
- Network: retry once, then escalate.

Вот так выглядит уровень конкретики в продакшене. «Подать отчёт» — это уровень демо.

Принуждение к рамкам

Рамки — это не описание; это то, что принуждается во время выполнения.

Allowlist URL. Агент может переходить только на URL, соответствующие заданному шаблону. За пределами allowlist навигация заблокирована.

Фильтрация действий. Разрешены только определённые типы действий. Общее «управляй компьютером» уступает место конкретному списку разрешённых действий.

Фильтрация элементов. На некоторых страницах есть элементы, с которыми агент не должен взаимодействовать (настройки, выход, опасные кнопки). Их можно отфильтровать на уровне восприятия.

Лимиты времени. У задач есть жёсткий максимум. Не закончил за N минут — прерываем.

Лимиты шагов. У задач есть максимум шагов. Та же логика, что и у агентских циклов.

Реализация зависит от платформы — у Anthropic Computer Use, OpenAI Operator, Browserbase разные механизмы. Принцип универсален: принуждать рамки на уровне runtime, а не просто описывать их в промпте.

Аутентификация

Постоянный вызов. Продакшен-развёртываниям нужно аутентифицировать сессию агента.

Предварительно аутентифицированные сессии. Человек логинится один раз; cookies/токены сессии захвачены; агент работает внутри этой сессии. Обновляется при необходимости.

Сервисные аккаунты. Отдельные аккаунты для агента (если сайт это поддерживает). Ограниченные права, аудит-лог.

Инъекция учётных данных. Агент получает учётные данные во время выполнения, логинится, затем отбрасывает их. Нужно безопасное хранение и обращение.

Обработка MFA. Настоящий вызов. Варианты:

• Использовать TOTP-секреты, которые агент может посчитать.
• Маршрутизировать MFA на человека для подтверждения.
• Использовать аккаунты/сайты, где разрешены API-токены вместо MFA.

OAuth. Для современных сайтов OAuth-флоу работают хорошо — агент получает токен из флоу, одобренного человеком один раз.

Паттерн: у агентов никогда не должно быть человекоподобного доступа к вашим аккаунтам. У них должны быть ограниченные, аудируемые, отзываемые учётные данные.

Валидация результата

Когда агент рапортует об успехе — проверяйте.

Собирайте артефакты. Скриншоты, скачанные файлы, выходные данные. Не доверяйте отчёту агента; проверьте улики.

Проверяйте условия успеха. Форма действительно отправилась? Есть подтверждение? Данные были корректны?

Перекрёстная проверка. Если успех можно проверить по другому каналу (API, email-подтверждение, проверка по БД) — сделайте это.

Детекция аномалий. Этот прогон был необычно долгим, необычно коротким, необычно дорогим? Расследуйте выбросы.

Паттерн: предполагайте, что агент может быть неправ. Имейте проверку независимую от самоотчёта агента.

Обработка ошибок

Задачи computer-use падают по-разному. Категоризируйте и обрабатывайте каждый случай:

Сетевые ошибки. Сайт лежит, таймаут. Retry с backoff.

Сбои аутентификации. Логин не удался, сессия истекла. Обновить учётные данные или эскалировать.

Изменения UI. Сайт изменился; ожидаемый элемент не найден. Остановиться, оповестить сопровождение.

Ошибки валидации. Ввод формы отвергнут. Залогировать, оповестить, не повторять вслепую.

Детекция ботов. CAPTCHA, блокировки. Эскалировать; возможно, занести сайт в чёрный список.

Запутанность агента. Агент застрял, зациклился, ушёл в сторону. Убить, залогировать, расследовать.

Квоты / rate limit. Сайт прижал агента по rate limit. Backoff и retry или отложить.

У каждой категории своя семантика ответа. Плохой паттерн: «агент упал, retry». Хороший паттерн: «агент упал в категории X, действуем по рецепту X».

Мониторинг

Каждое действие залогировано, каждый прогон отслежен, каждая аномалия поднята.

Логи на прогон:

• Время начала/конца.
• Все предпринятые действия.
• Все скриншоты.
• Исход (успех/неуспех/эскалация).
• Стоимость.
• Метрики производительности.

Дашборд прогонов: команда эксплуатации видит активные прогоны, недавние сбои, глубину очереди.

Агрегированные метрики:

• Доля успеха по типу задачи.
• Распределение латентности.
• Стоимость прогона.
• Частота аномалий.

Алерты:

• Доля успеха просела ниже порога.
• Стоимость прогона скакнула.
• Растут конкретные типы сбоев.
• UI сайта мог измениться (несколько недавних сбоев на одном шаге).

Этот мониторинг ловит проблемы до того, как они станут инцидентами.

Экономика

Грубый вопрос: computer-use дешевле альтернативы?

Затраты:

• Стоимость прогона: обычно €0.50-€5 в зависимости от сложности задачи (вызовы vision-модели дороги).
• Инфраструктура: managed runtime (Browserbase и т. п.) или self-hosted.
• Поддержка: задачи ломаются, когда меняются сайты. Постоянная работа.

Альтернативы:

• Человек за €30/час: задача на 10 минут — €5. Задача на 1 минуту — €0.50.
• RPA-инструменты: ниже стоимость прогона, но требуется структурированная автоматизация.
• Прямая API-интеграция: значительно дешевле за вызов, но API должен существовать.
• Аутсорс офшор: €5-10/час, та же математика, что и со своим персоналом.

Экономика говорит «да» computer-use, когда:

• У сайта нет API.
• Задача достаточно длинная, чтобы автоматизация окупила фиксированные затраты.
• Объём достаточно высокий, чтобы человеко-часы накапливались.
• Сайт относительно стабилен (низкая нагрузка на поддержку).

Экономика говорит «нет», когда:

• API есть (просто используйте его).
• Задача короткая и редкая.
• Сайт постоянно меняется.
• Слишком много краевых случаев (высокая нагрузка на поддержку).

Полезное упражнение: оцените стоимость задачи в computer-use vs человек. Умножьте на объём. Сравните.

Продакшен-паттерны, которые работают

Несколько паттернов из успешных развёртываний:

Паттерн 1: подход «записанный рецепт»

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

Это ближе к традиционному RPA, но с гибкостью ИИ, чтобы выдержать небольшие вариации (кнопка чуть сдвинулась, появился дополнительный диалог подтверждения).

Гораздо надёжнее, чем чисто автономная работа.

Паттерн 2: разделение «извлечь и подать»

У многих процессов две фазы:

• Извлечь данные откуда-то.
• Подать данные куда-то.

Разделить их в отдельные прогоны агента (или рецепты) чище. У каждой фазы более чёткие критерии успеха. Сбои в одной не накладываются на другую.

Паттерн 3: паттерн «человеческий чекпойнт»

Агент делает подготовительную работу автономно, потом выводит состояние «готов действовать» на одобрение человеком. Человек смотрит, одобряет, агент выполняет.

Применяется для: платежей, публичных постов, чувствительных подач. Агент экономит время на подготовке; человек ловит ошибки.

Паттерн 4: паттерн «специалист-агент»

Вместо одного универсального агента — специализированные агенты под конкретные задачи. Каждый настроен, протестирован и поддерживается под свой процесс.

Универсальный «работай с любым сайтом» агент тяжело поддерживать. Агент «подавай наш еженедельный отчёт по комплаенсу» — прост.

Паттерн 5: паттерн «откат на RPA»

Для задач, где гибкость ИИ на самом деле не нужна (сайт стабилен, процесс зафиксирован) — откатывайтесь к традиционному RPA (скрипты Playwright, Selenium). Дешевле, быстрее, надёжнее для таких случаев.

Используйте computer-use именно там, где гибкость ИИ добавляет ценность.

Паттерн 6: паттерн «батчевый прогон»

Не запускайте агентов по требованию для высокообъёмных задач. Сложите работу в пакет; запускайте агентов параллельно по расписанию.

Например, вместо «пользователь подал запрос; агент тут же запустился» — складывайте запросы в очередь, запускайте агентов на пакетах в 15 минут. Сглаживает нагрузку, упрощает архитектуру.

Что может пойти не так

Короткий список сбоев, которые мы видели:

Сайт изменился. Агент идеально работал 6 месяцев. Редизайн сайта всё ломает. Без мониторинга вы узнаёте об этом от злых пользователей.

Защита от ботов нагнала. Сайт внедрил детекцию ботов. Прогоны агента всё чаще падают. В итоге аккаунт банят.

Спираль расходов на застрявшей задаче. Агент крутится на запутанной странице. Каждый цикл — вызов vision-модели. €100 за час.

Не то действие. Агент кликнул не ту кнопку. Отменил заказ вместо подтверждения. Или отправил сообщение не тому человеку.

Застрял на MFA. Агент не может пройти MFA. Продакшен-очередь растёт.

Аккаунт забанили. Сайт детектировал необычную активность, заморозил аккаунт. Все похожие задачи сломаны, пока аккаунт не восстановлен.

Утечка учётных данных. Агент случайно засветил учётные данные в логе или скриншоте. Инцидент безопасности.

Проблема с приватностью. Агент попутно захватил PII в скриншотах, которые попали в логи.

Большинство из этого предотвращается паттернами выше. Но каждый случался в реальных развёртываниях. Стройте защиту соответственно.

Реалистичный пример ROI

Продакшен-развёртывание, реальные числа (анонимизированы):

Задача: подача еженедельных регуляторных отчётов в 12 разных порталов государственных агентств.

Без автоматизации: 1 человек × 6 часов/неделя × €30/час = €180/неделя. В среднем 90 минут на портал.

С computer-use автоматизацией:

• Стоимость прогона на портал: ~€2 (vision-модель + инфраструктура).
• 12 порталов × €2 = €24/неделя.
• Инженерная поддержка: ~2 часа/месяц × €100/час = €200/месяц ≈ €50/неделя.
• Итого: ~€74/неделя.

Экономия: €106/неделя ≈ €5,500/год. Плюс человеческое время освободилось под более ценную работу.

Надёжность: ~92% успеха на автономных прогонах. Остальные 8% эскалируются человеку. Человек обычно решает за 10 минут.

Итог:

• Экономика в плюсе.
• Быстрее завершение (параллельная обработка).
• Аудит-след (каждое действие залогировано).
• Стоит поддерживать.

Так выглядит продакшен-успех. Не магическое «ИИ делает всё», а измеряемое, мониторящееся, с ясным ROI.

Чек-лист развёртывания

Если разворачиваете computer-use систему в продакшен:

• [ ] Задача узкая и чётко определена.
• [ ] Рамки принуждаются на уровне runtime, а не только описаны.
• [ ] Бюджеты шагов / времени / стоимости на месте.
• [ ] Стратегия аутентификации с безопасными учётными данными.
• [ ] Учтены меры против ботов (легитимные аккаунты; уважение rate limits).
• [ ] Категоризация и обработка ошибок.
• [ ] Валидация результата независимо от самоотчёта агента.
• [ ] Мониторинг и алертинг.
• [ ] Аварийные выключатели.
• [ ] Human-in-loop для существенных действий.
• [ ] Аудит-логирование.
• [ ] Обработка приватности / PII.
• [ ] Экономика осмыслена против альтернатив.
• [ ] План поддержки на случай изменений сайтов.

Каждый пункт нетривиален. Пропуск любого создаёт риск.

Главный вывод

Computer-use и браузерные агенты в продакшене выглядят иначе, чем вирусные демо. Узкие задачи. Сильные ограждения. Плотный мониторинг. Человеческие чекпойнты. Реалистичная экономика.

Для правильных задач они действительно полезны. Извлечение данных с сайтов без API, заполнение форм в масштабе, кросс-приложенческие процессы, повторяющаяся UI-работа. Реальные продакшен-развёртывания экономят реальное время и деньги.

Для неправильных задач — открытые суждения, новые UI, высокорисковые единичные действия — они пока не готовы. Не пытайтесь их туда тащить.

Навык — в подборе технологии под задачу. Сделано хорошо — computer-use агенты полезный инструмент в продакшен-стеке ИИ. Сделано плохо — это дорогой способ завести себе новые виды отказов.

Выбирайте узкие задачи. Стройте ограждения. Мониторьте безостановочно. Поддерживайте последовательно. Так computer-use агенты зарабатывают своё место в продакшен-системах.