Демо завораживают. ИИ проходит сложный процесс бронирования, переключается между приложениями, заполняет государственные формы, автономно выполняет многочасовые задачи. В 2024–2025 годах Anthropic Computer Use, OpenAI Operator, Google Project Mariner и волна стартапов показали агентов, которые управляют компьютерами как люди.
В 2026 году эти инструменты реальны. Они работают. Некоторые компании успешно разворачивают их в продакшене. Но эти развёртывания не похожи на демо. Они уже, жёстче ограничены и окружены ограждениями. Паттерны, которые отличают продакшен от демо, — и есть тема этой статьи.
Основы мы разбирали в статье среднего уровня. Здесь идём глубже: продакшен-паттерны, повторяющиеся сбои, экономика и то, как выкатить computer-use систему, которая действительно полезна в масштабе.
Реальность продакшена
Несколько паттернов, которые мы наблюдаем в реальных продакшен-развёртываниях:
Паттерн 1: доминируют узкие задачи. Продакшен-развёртывания добиваются успеха на конкретных, чётко определённых задачах. Не «делай что угодно». Не «работай с любым сайтом». Конкретные процессы на конкретных сайтах.
Паттерн 2: жёсткое определение рамок. Задачи поставлены узко. Агенту разрешены только определённые действия на определённых сайтах. Всё, что выходит за рамки, вызывает остановку, а не импровизацию.
Паттерн 3: записанные сценарии вместо автономного исследования. Многие продакшен-развёртывания используют записанные сценарии (шаги, определённые один раз и проигрываемые с поправками), а не полностью автономных агентов. Надёжнее, легче поддерживать.
Паттерн 4: подтверждение человеком для значимых действий. Любое действие с финансовыми, юридическими или клиентскими последствиями требует подтверждения человеком.
Паттерн 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 │ Расписания, повторы, эскалации
├─────────────────────────────────────┤
│ Task definition + scope │ Что агент делает и не делает
├─────────────────────────────────────┤
│ Agent runtime (Computer Use SDK) │ Anthropic / OpenAI / Browserbase
├─────────────────────────────────────┤
│ Browser / desktop environment │ Изолированная, sandboxed-среда
├─────────────────────────────────────┤
│ Authentication and session │ Учётные данные, cookies, обработка MFA
├─────────────────────────────────────┤
│ Result handling │ Захват, валидация, хранение
├─────────────────────────────────────┤
│ Monitoring + alerts │ Наблюдаемость в реальном времени
└─────────────────────────────────────┘
Пройдём по каждому.
Определение задачи
Самый важный шаг. Определите, что агент делает, узко.
Хорошее определение задачи включает:
Триггер. Что её запускает? (Расписание, событие, ручной запуск.)
Входы. Какими данными располагает агент? (Конкретная запись, структурированные данные формы.)
Рамки. Какие сайты, какие действия, какие пути по UI.
Критерии успеха. Как выглядит завершение?
Условия остановки. Что прекращает задачу досрочно?
Выход. Какие данные агент возвращает?
Семантика ошибок. Как сбои категоризируются и сообщаются?
Плохо определённая задача: «Подать наш еженедельный отчёт по комплаенсу».
Хорошо определённая задача:
Task: Подать еженедельный отчёт по комплаенсу на портал X.
Trigger: Cron, каждый понедельник в 9:00.
Inputs:
- Файл данных отчёта (CSV) из /reports/weekly.csv
- Данные отправителя из переменных окружения (name, ID).
- Учётные данные из secrets manager.
Scope:
- Site: https://portal.example.gov/submit (и подпути)
- Allowed actions: navigate, click, type, upload, submit, screenshot.
- Forbidden: visit external sites, change account settings, navigate away from submission flow.
Success criteria:
- Получена страница подтверждения с submission ID.
- Захвачен 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 дешевле альтернативы?
Измеряемые затраты: входные и выходные данные модели, снимки экрана, работа браузера, прокси, хранение, повторные попытки, неудачные прогоны, проверка человеком, устранение инцидентов и инженерная поддержка.
Альтернативы:
- Ручная работа: используйте полную стоимость соответствующей роли в своей организации и измеренное время выполнения задачи.
- RPA-инструменты: ниже стоимость прогона, но требуется структурированная автоматизация.
- Прямая API-интеграция: значительно дешевле за вызов, но API должен существовать.
- Аутсорсинг: используйте фактическую цену договора, требования к качеству и срокам, а также ограничения по конфиденциальности.
Экономика говорит «да» computer-use, когда:
- У сайта нет API.
- Задача достаточно длинная, чтобы автоматизация окупила фиксированные затраты.
- Объём достаточно высокий, чтобы человеко-часы накапливались.
- Сайт относительно стабилен (низкая нагрузка на поддержку).
Экономика говорит «нет», когда:
- API есть (просто используйте его).
- Задача короткая и редкая.
- Сайт постоянно меняется.
- Слишком много краевых случаев (высокая нагрузка на поддержку).
Полезное упражнение: оцените стоимость задачи в computer-use vs человек. Умножьте на объём. Сравните.
Продакшен-паттерны, которые работают
Схемы, которые стоит проверить:
Паттерн 1: подход «записанный рецепт»
Для высокообъёмных, узких задач: запишите процесс один раз с явными шагами, потом пусть агент проигрывает его на каждом входе с небольшими поправками.
Это ближе к традиционному RPA, но с гибкостью ИИ, чтобы выдержать небольшие вариации (кнопка чуть сдвинулась, появился дополнительный диалог подтверждения).
Сравните надёжность такого сценария и автономного исследования на одних и тех же тестовых случаях: записанный сценарий не обязательно лучше справится с каждым вариантом.
Паттерн 2: разделение «извлечь и подать»
У многих процессов две фазы:
- Извлечь данные откуда-то.
- Подать данные куда-то.
Разделить их в отдельные прогоны агента (или рецепты) чище. У каждой фазы более чёткие критерии успеха. Сбои в одной не накладываются на другую.
Паттерн 3: паттерн «человеческий чекпойнт»
Агент делает подготовительную работу автономно, потом выводит состояние «готов действовать» на одобрение человеком. Человек смотрит, одобряет, агент выполняет.
Применяется для: платежей, публичных постов, чувствительных подач. Агент экономит время на подготовке; человек ловит ошибки.
Паттерн 4: паттерн «специалист-агент»
Вместо одного универсального агента — специализированные агенты под конкретные задачи. Каждый настроен, протестирован и поддерживается под свой процесс.
Универсальный «работай с любым сайтом» агент тяжело поддерживать. Агент «подавай наш еженедельный отчёт по комплаенсу» — прост.
Паттерн 5: паттерн «откат на RPA»
Для задач, где гибкость ИИ на самом деле не нужна (сайт стабилен, процесс зафиксирован) — откатывайтесь к традиционному RPA (скрипты Playwright, Selenium). Дешевле, быстрее, надёжнее для таких случаев.
Используйте computer-use именно там, где гибкость ИИ добавляет ценность.
Паттерн 6: паттерн «батчевый прогон»
Не запускайте агентов по требованию для высокообъёмных задач. Сложите работу в пакет; запускайте агентов параллельно по расписанию.
Например, вместо «пользователь подал запрос; агент тут же запустился» — складывайте запросы в очередь, запускайте агентов на пакетах в 15 минут. Сглаживает нагрузку, упрощает архитектуру.
Что может пойти не так
Короткий список типовых режимов сбоя:
Сайт изменился. Редизайн может сделать недействительными селекторы, визуальные предположения и записанные шаги. Обнаруживайте это тестовыми прогонами до выполнения клиентских задач.
Защита от ботов нагнала. Сайт внедрил детекцию ботов. Прогоны агента всё чаще падают. В итоге аккаунт банят.
Спираль расходов на застрявшей задаче. Агент зациклился на непонятной странице и продолжает оплачиваемые вызовы модели или браузера. Задайте внешние ограничения на число шагов, время и стоимость.
Не то действие. Агент кликнул не ту кнопку. Отменил заказ вместо подтверждения. Или отправил сообщение не тому человеку.
Застрял на MFA. Агент не может пройти MFA. Продакшен-очередь растёт.
Аккаунт забанили. Сайт детектировал необычную активность, заморозил аккаунт. Все похожие задачи сломаны, пока аккаунт не восстановлен.
Утечка учётных данных. Агент случайно засветил учётные данные в логе или скриншоте. Инцидент безопасности.
Проблема с приватностью. Агент попутно захватил PII в скриншотах, которые попали в логи.
Перечисленные меры снижают риск, но не предотвращают все возможные сбои. Проверьте каждый сценарий отказа и заранее назначьте ответственного за восстановление.
Экономика: разобранная модель
Это смоделированный сценарий, а не клиентский кейс, и мы сознательно называем его именно так: ROI-модель, которую вы можете пересчитать со своими числами, бьёт «анонимизированный кейс», который невозможно проверить.
Задача: подача регулярных отчётов о соответствии в 12 разных порталов ведомств. В Эстонии представьте порталы, которые всё ещё требуют ввода форма за формой: декларации e-MTA, анкеты Департамента статистики и подачи уровня ЕС.
Следующие строки показывают формулу, а не приводят факты об эстонских или европейских порталах.
Ручной вариант: число порталов × измеренное время обработки × полная стоимость труда.
С автоматизацией:
- Успешные прогоны: объём × измеренная стоимость успешного прогона.
- Неудачные прогоны: объём × доля ошибок × совокупная стоимость прогона и восстановления.
- Проверка человеком: проверяемый объём × время проверки × стоимость труда.
- Поддержка и инциденты: фактическое время инженеров и эксплуатации.
- Соответствие требованиям и услуги поставщиков: проверка безопасности, обработка данных, браузерная инфраструктура и договорные обязательства.
Теперь два числа, которые решают, есть ли во всём этом что-то реальное.
Первое — доля успеха и тяжесть ошибок. Выведите допустимый порог из стоимости ручной работы и приемлемого риска: универсального процента окупаемости нет. Измеряйте показатель в репрезентативном теневом режиме.
Второе — изменения интерфейсов и затраты на поддержку. Отслеживайте, как часто меняются целевые системы и сколько занимает восстановление. До начала эксплуатации назначьте ответственного и задайте целевой срок восстановления.
Чек-лист развёртывания
Если разворачиваете computer-use систему в продакшен:
- Задача узкая и чётко определена.
- Рамки принуждаются на уровне runtime, а не только описаны.
- Бюджеты шагов / времени / стоимости на месте.
- Стратегия аутентификации с безопасными учётными данными.
- Учтены меры против ботов (легитимные аккаунты; уважение rate limits).
- Категоризация и обработка ошибок.
- Валидация результата независимо от самоотчёта агента.
- Мониторинг и алертинг.
- Аварийные выключатели.
- Подтверждение человеком для действий со значимыми последствиями.
- Аудит-логирование.
- Обработка приватности / PII.
- Экономика осмыслена против альтернатив.
- План поддержки на случай изменений сайтов.
Каждый пункт нетривиален. Пропуск любого создаёт риск.
Подберите технологию под задачу
Готовая к эксплуатации система требует узких задач, технически принудительных ограничений, мониторинга, контрольных точек с участием человека и измеренной экономики.
Возможные задачи — извлечение данных с сайтов без API, повторяющееся заполнение форм и процессы между несколькими приложениями. Репрезентативное теневое тестирование должно показать, экономит ли система время или деньги, не повышая число ошибок и риск.
Для неправильных задач — открытые суждения, новые UI, высокорисковые единичные действия — они пока не готовы. Не пытайтесь их туда тащить.
Инженерная задача — подобрать технологию под процесс и сохранить детерминированный или ручной резервный путь. Решение о вводе в эксплуатацию должно опираться на критерии приёмки, а не на эффектную демонстрацию.
