GUI-автоматизация с AI-агентом на Computer Use

Computer Use AI: где ломается автоматизация интерфейса

Классическая автоматизация интерфейса строится на жёсткой цепочке: найти элемент по селектору, дождаться его, кликнуть, вписать значение, отправить форму. Любое отклонение рвёт цепочку — сдвинулась вёрстка после релиза, поверх кнопки всплыло модальное окно, поменялась тема оформления, форма ушла во вложенный фрейм. Сценарий останавливается не там, где произошла ошибка, а там, где он ждал элемент: в систему попадают частично применённые данные, и разбирать их приходится вручную.

Вторая точка отказа — ручные переносы между системами. Когда надёжного обмена нет, данные переносит человек: выгружает отчёт, сверяет построчно, заводит в учётную систему. Один пропущенный шаг или опечатка в поле — и расхождение расходится по всей цепочке согласований, а ищем мы его уже постфактум, по журналам и выгрузкам.

Автономный агент на computer use ai работает иначе: он оценивает состояние экрана и решает, что делать, на каждом шаге. Агент видит, что окно перекрыло кнопку, — закрывает его и возвращается к задаче; если форму переработали, находит поле по смыслу и подписи, а не по зашитому пути. Поэтому сбои при автоматизации превращаются из остановки процесса в обходной путь, а рутинные операции под ключ закрываются без человека внутри цепочки.

Ниже разбираем, как это устроено: от распознавания состояния интерфейса до протокола, по которому агент сообщает о нештатной ситуации.

Эффект от внедрения агента: скорость, охват, меньше рутины

Агент на Computer Use работает через тот же интерфейс, что и человек: видит экран, наводит курсор, заполняет поля, читает ответ системы. Доступ к внутренним интерфейсам не нужен — поэтому охват сценариев шире: под автоматизацию попадают устаревшие учётные системы, чужие личные кабинеты, десктопные клиенты, до которых интеграция не доходила.

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

Уходит класс механических ошибок: перепутанное поле, пропущенный шаг, неверный статус. Агент идёт по зафиксированному чек-листу и на любом расхождении останавливается, прикладывая лог и снимок экрана. Разбор такого случая занимает минуты вместо поиска по журналам.

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

Показатели фиксируем до внедрения — время на операцию, число обработанных за смену, доля ошибок, глубина очереди — и считаем те же после запуска. Так эффект от внедрения агента виден в сравнении, а не на словах.

Режимы работы агента: браузер, рабочий стол, гибрид

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

Выбор идёт не от удобства разработки, а от самого процесса. Если все шаги укладываются в веб-системы, браузерного режима достаточно; если процесс завязан на установленное приложение, окно или файл на диске, нужен режим рабочего стола. Гибридный запуск закрывает сценарии, где часть шагов браузерные, а часть — локальные, и агент переходит между ними в рамках одной задачи.

Отдельная ветка — закрытый контур: агент и модель работают внутри инфраструктуры заказчика, без обращений во внешние сети. Тогда требования к окружению и мощностям фиксируются заранее, и стенд планируется под них.

На практике режим фиксируется до разработки сценария — от него зависят схема доступов, способ хранения логов и то, как настраивается откат при сбое.

Как мы внедряем агента: от разбора процессов до передачи

Агент, работающий с графическим интерфейсом, ломается не там, где ломается код: сдвинулась вёрстка, всплыло модальное окно, истекла сессия. Поэтому внедрение начинаем не с настройки модели, а с обследования процессов — что оператор делает руками, где принимает решение и по каким признакам понимает, что шаг завершён. Дальше идём по этапам, каждый из которых заканчивается проверяемым артефактом.

1. Обследование процессов. Смотрим записи экрана и журналы действий оператора, разбираем шаги, источники данных, исключения и правила, которые нигде не записаны.
2. Схема сценариев и границ. Фиксируем, что агент делает сам, а что уходит человеку на подтверждение, и где ставим точки возврата задачи оператору.
3. Пилотный сценарий. Берём один узкий сквозной маршрут, прогоняем эталонные кейсы и снимаем базовые метрики: доля успешных проходов, время операции, число ручных вмешательств.
4. Настройка агента. Выдаём минимальные доступы, размечаем опорные элементы интерфейса, задаём правила ожидания, повторов и поведение при расхождении картинки с эталоном.
5. Проверка на отказах. Намеренно сдвигаем элементы, обрываем соединение, подсовываем неожиданные диалоги — агент должен распознать тупик и вернуть задачу человеку, а не действовать наугад.
6. Передача решения. Документация, схема сценариев, журналы прогонов, обучение команды и регламент обновления при изменениях интерфейса.

После передачи ваши специалисты сами правят сценарии и добавляют маршруты — наше участие требуется только при заметных изменениях интерфейса или новых процессах.

Артефакты внедрения: сценарии, доступы, регламенты

Проект заканчивается не показом работающего агента, а набором артефактов, с которыми команда заказчика остаётся один на один. Ниже — что передаём и зачем каждый элемент нужен в эксплуатации.

• Описание сценариев. По каждому: точка входа, шаги, ожидаемый результат, типовые ошибки и действие при них. Раньше это знание жило в голове инженера и уходило вместе с ним.
• Схемы процессов. Как агент связан с учётной системой, почтой и файловым хранилищем, где остаётся ручной шаг и куда возвращается управление при сбое.
• Политика доступа агента. Отдельная учётная запись с минимальными правами, перечень запрещённых операций (платежи, удаление, смена реквизитов), порядок ротации секретов и поведение при истечении сессии.
• Журналирование действий. Для каждого шага — время, инициатор, результат, снимок экрана при отказе. Журнал выгружается для разбора инцидента и хранится столько, сколько требует внутренний регламент.
• Регламент эскалации. Какие ситуации агент не решает сам, кому передаёт управление и за какое время человек обязан ответить.
• Инструкции для поддержки. Разбор частых отказов: изменилась вёрстка целевой системы, не найден элемент интерфейса, зависла сессия — что перезапускать и какие записи смотреть.

Артефакты обновляются вместе с изменениями в целевых системах — иначе описание расходится с реальностью за пару месяцев и поддержка снова идёт к нам.

Кейс: обработка заявок в учётной системе без операторов

Заказчик — сервисная компания: заявки приходят из формы на сайте, почты и мессенджеров, а разбирают их вручную операторы — сверяют клиента, заводят обращение в учётной системе, прикладывают файлы и ставят задачу ответственному. В пиковые часы очередь доходила до сотен обращений, ночные заявки ждали утра, а на ручном вводе терялось около 4% данных: опечатки в реквизитах всплывали уже на этапе согласования.

Программного интерфейса у учётной системы не было — только окно оператора. Поэтому автоматизацию строили на Computer Use: агент открывает те же экраны, читает карточку обращения, распознаёт поля, заполняет форму, прикладывает вложения и передаёт заявку дальше по маршруту. Набор операций ограничен белым списком, спорные случаи уходят человеку с пометкой, а весь сеанс пишется в журнал — по каждой заявке видно, что именно сделал агент и на каком шаге остановился.

Метрики до и после проекта:

• доля обращений, обработанных без оператора — с 0 до 82%;
• время от появления заявки до постановки в работу — с 6 часов до 4 минут;
• ошибки при вводе данных — с 4% до 0,6%;
• ночные и выходные заявки перестали ждать начала смены;
• пропускная способность в пик выросла примерно втрое без расширения штата.

Что это значит для похожих задач

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

Чем Computer Use отличается от классических сценариев?

Классическая автоматизация — это записанная цепочка шагов: найти элемент, дождаться окна, вписать значение, отправить форму. Каждый шаг привязан к селектору, координате или заголовку окна, поэтому отклонение от ожидаемого состояния обрывает сценарий на середине. Computer Use как подход в AI-автоматизации идёт от цели: агент видит экран и сам решает, куда нажать и что ввести, сверяя результат с задачей.

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

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

Технические сомнения перед стартом: разбираем по пунктам

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

Куда попадают учётные данные и какие права получает агент?

Логины и пароли живут в отдельном хранилище секретов: в сценарии и журнале остаются только ссылки на них, значения подставляет исполнитель в момент запуска. Агент работает под отдельной учётной записью с минимальным набором прав и только на время сеанса, а действия вроде записи в базу или платежей либо вынесены за пределы сценария, либо требуют подтверждения человека.

Что происходит при ошибке в середине процесса?

Шаги проектируем повторяемыми: сначала автоматический повтор, затем фиксация состояния и остановка. Половинчатых состояний не остаётся — есть точка возврата, с которой процесс запускается заново.

Можно ли развернуть это в закрытом контуре?

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

Обсудим задачу: что прислать и как мы отвечаем

Чтобы вернуться с оценкой внедрения, а не с общими словами, нам достаточно вводных по процессу — оформлять требования по шаблону не нужно. Пришлите то, что уже есть: описание сценария, примеры данных и доступ к тестовому контуру, если он есть. Остальное уточним сами — на созвоне или в переписке, в зависимости от того, как удобнее вашей команде.

• Пошаговое описание процесса: какие окна, формы и кнопки участвуют, в каком порядке и что считается завершением шага.
• Запись экрана реального прохода — 5–10 минут живого сценария показывают тайминги ожидания и нестабильные места лучше любого текста.
• Примеры входных данных в том виде, в каком они приходят: выгрузки, сканы, письма, таблицы, вложения.
• Перечень исключений и ручных решений — где формальное правило ломается и что оператор делает вместо него.
• Ограничения среды: операционная система, права учётной записи, доступность тестового контура и расписание, когда можно занимать рабочие места.
• Критерии успеха пилота: какую долю сценариев или какое время прохода вы считаете приемлемым результатом.

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