Anthropic Computer Use: где ломается автоматизация интерфейсов
Сценарий на Anthropic Computer Use выглядит надёжным, пока крутится на том же стенде, где его собирали. Инструмент получает снимок экрана, распознаёт элементы и кликает по ним — поэтому автоматизация интерфейсов работает там, где у системы нет внутреннего программного интерфейса. Проблемы начинаются в реальной эксплуатации, где вёрстка обновляется еженедельно, а данные приходят в неполном виде.
Ломаются два класса сценариев. Первый привязан к координатам: клик по вычисленной позиции промахивается при смене разрешения, масштаба или шрифта. Второй опирается на найденный элемент — обновление вёрстки меняет разметку, и модель уверенно кликает по соседнему блоку, а ошибка всплывает через несколько шагов. Отдельно хрупкие сценарии с модальными переходами и жёсткими паузами вместо проверки состояния экрана.
Дорого обходится не само падение, а способ его обнаружения. Ручные операции никуда не исчезают: сотрудник добирает исключения, сверяет результаты, разбирает зависшие запуски. Доля успешных прогонов снижается тихо, без явной ошибки, — пока не выяснится, что часть данных записана не в то поле. Каждое обновление вёрстки превращается в повторную отладку всей цепочки.
Разбираем, как это закрывается: проверки состояния экрана вместо координат и пауз, изоляция точки отказа, наблюдаемость каждого шага.
Что меняется после внедрения: измеримые эффекты
Доля ручных операций, снятых с сотрудников
Агент на базе Anthropic Computer Use работает в том же интерфейсе, что и человек: распознаёт экран, ведёт курсор, вводит текст, проверяет результат. На наборе типовых операций — выгрузка отчёта, сверка двух систем, заполнение карточки — с людей снимается 70–80% шагов. Человек остаётся на подтверждениях и спорных случаях, где нужно решение, а не повторение одного и того же действия.
Время прохождения сценария и доля успешных прогонов
Метрику считаем на фиксированном наборе сценариев, иначе сравнение нечестное: время от старта до последнего проверенного экрана и доля прогонов без вмешательства оператора. Сценарий, который человек проходил за 12–15 минут, после отладки ожиданий и повторных попыток закрывается за 2–3 минуты, а доля успешных прогонов выходит на 9 из 10. Остальные — не сбои, а корректные остановки с передачей человеку.
Устранённые классы отказов и загрузка команды
Главный источник потерь — тихая ошибка: интерфейс изменился, шаг формально отработал, данные ушли не туда. Агент сверяет состояние экрана с ожидаемым после каждого действия: при расхождении останавливается и сохраняет запись шагов. Класс «ошибка без сигнала» исчезает, а пиковая загрузка сотрудников сглаживается — время уходит на разбор исключений, а не на рутину.
Anthropic Computer Use и альтернативы: какой режим выбрать
Выбор режима определяется не столько возможностями модели, сколько стабильностью интерфейса и наличием программного доступа. Anthropic Computer Use работает через скриншот-цикл: модель видит экран, находит элементы и кликает по координатам. Это снимает зависимость от API, но добавляет задержку на каждый шаг и чувствительность к разрешению, теме оформления и всплывающим окнам.
Программный доступ через API даёт детерминированный результат: вызов возвращает структуру, а не пиксели, и повторяется без отклонений. Ограничение — покрытие: у части систем публичного интерфейса нет, и без визуального слоя задачу не закрыть.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Визуальное управление (Computer Use) | Интерфейс есть, программного доступа нет: устаревшие системы, рабочие места с графическим интерфейсом | Задержка на каждый шаг, чувствительность к вёрстке и разрешению, нужен контроль сессий |
| Программный доступ (API, протоколы) | У системы документированный интерфейс и стабильный контракт | Не покрывает закрытые системы, требует сопровождения версий контракта |
| Готовые коннекторы | Типовая система с поддержкой из коробки | Жёсткие рамки сценариев, кастомизация ограничена |
| Гибрид: программный путь и визуальный резерв | Критичные операции идут через API, редкие — через интерфейс | Нужен единый слой логирования и отката |
Режим выбираем по двум критериям — стабильность интерфейса и цена ошибки. Там, где сбой операции дорог, идём программным путём, а визуальное управление оставляем резервом на случай исключений.
Как мы внедряем: этапы инженерной работы
Прежде чем поручать агенту живые операции, мы разбираем, что именно он делает за человека и где цена ошибки выше выгоды. Работа идёт итерациями: аудит процессов, пилот на копии системы, и только потом вывод в рабочий контур. Ниже — путь, который проходит каждая интеграция Anthropic Computer Use.
- Аудит сценариев. Проходим по задачам вместе с их исполнителями, отбираем повторяемые операции с формализуемыми шагами и отсекаем те, где почти каждый случай нештатный.
- Схема взаимодействия. Фиксируем экраны, формы и переходы, которые видит агент, источники данных и поведение при отклонении от ожидаемого. Отдельно отмечаем точки, где решение обязан принять человек.
- Настройка окружения. Собираем изолированный стенд с копией интерфейсов и теми же правами доступа. Агент работает в отдельном профиле, каждый шаг пишется в журнал со снимком экрана.
- Проверка на копии системы. Прогоняем сценарии сериями, включая пограничные: медленная загрузка, всплывающие окна, правки вёрстки. Смотрим на стабильную долю успешных прогонов, а не на один удачный запуск.
- Пилот на узком контуре. Включаем агента на части операций рядом с оператором. Сверяем результат с ручной работой, разбираем расхождения и правим логику, пока они не уйдут.
- Передача в сопровождение. Отдаём регламенты: как читать журналы, что делать при сбое, как обновлять сценарии после правок интерфейса. Настраиваем оповещения и порог, при котором агент останавливается сам.
Что остаётся у вас: комплект документации и конфигураций
Интеграцию сдаём так, чтобы она жила без нас: ваша команда получает тот же набор конфигураций, политик и журналов, по которому сценарии работают у нас. Отдельно фиксируем, что агент Anthropic Computer Use выполняет сам, а что требует подтверждения человека.
- Конфигурации сценариев — пошаговые описания задач: точки ожидания интерфейса, условия перехода, обработка всплывающих окон и изменившейся вёрстки.
- Политики доступа — под какими учётными записями работает агент, какие разделы ему закрыты, где обязательна ручная проверка перед отправкой.
- Журналы прогонов — по каждому запуску: длительность шагов, точка и причина остановки, снимок состояния на момент сбоя.
- Карта отказов — типовые ситуации: интерфейс изменился, элемент не найден, сессия прервалась — и что делать в каждой.
- Регламенты сопровождения — кто и как обновляет шаги, как проходит приёмка правок, с какой периодичностью пересматриваются политики.
- Тестовый набор — сценарии проверки после правки интерфейса или обновления модели, чтобы приёмка шла без нашей поддержки.
Передача идёт с разбором: проходим по конфигурациям вместе с вашими инженерами и запускаем сценарии уже в вашей среде. Комплект самодостаточен — сопровождение дальше возможно, но не обязательно.
Кейс: как сократили ручные операции в учётной системе
Отдел обработки заявок работал в учётной системе без внешнего программного интерфейса: письма, формы с сайта и сканы договоров операторы переносили в карточки вручную. На смену приходилось около 1 200 операций по 6–8 минут каждая — найти контрагента в справочнике, сверить реквизиты, заполнить полтора десятка полей, приложить файл.
Что было до внедрения
Цена ручного ввода — не время, а класс ошибок, который не отловить на входе. Около 4% карточек уходили в работу с опечаткой в реквизитах или сумме, и каждая возвращалась на переделку уже после согласования. Отдельный источник сбоев — дубли: заявка с сайта и письмо того же клиента заводились как две записи, потому что оператор не успевал проверить историю.
Что изменили
Агент на базе Anthropic Computer Use работает в том же окне учётной системы, что и человек: видит экран, наводит курсор, заполняет поля, прикладывает файлы — переписывать систему и открывать в ней программный доступ не потребовалось. Перед сохранением карточки проходят сверку с реестром контрагентов, проверку обязательных полей и поиск дублей по сумме и дате. Если данных не хватает или значения конфликтуют, заявка уходит оператору с описанием расхождения.
Что стало после
| Показатель | До | После |
|---|---|---|
| Операций вручную за смену | ~1 200 | ~180 |
| Доля ошибок ввода | ~4% | 0,4% |
| Время обработки заявки | 6–8 мин | 40–50 сек |
| Заявок без участия человека | 0% | 78% |
Операторы перешли на разбор исключений и сверку спорных карточек — доля рутинного переноса данных в смене упала примерно в шесть раз. Из повторяющихся сбоев ушли расхождения справочников, дубли заявок и пропущенные обязательные поля: проверки выполняются до записи, а не после.
Чем отличается управление браузером от управления рабочим столом?
Управление браузером работает с содержимым страницы: агент находит поля, кнопки и ссылки по их роли и подписи, а не по координатам на экране. Сценарий не ломается при смене разрешения и масштаба, а запуск обходится дешевле — графическую оболочку поднимать не нужно, и несколько сессий уживаются на одной машине. Ограничение одно: агент видит ровно то, что страница отдала в разметку.
Рабочий стол приложений — другой уровень. Агент получает изображение экрана и управляет курсором и клавиатурой, поэтому ему доступны окна и диалоги, которых в браузере нет: системный выбор файла, предупреждения безопасности, нативные клиенты учётных систем. Так устроен подход Anthropic Computer Use — модель ведёт агента по экрану, а не по внутренним интерфейсам программ. Плата — чувствительность к расположению элементов: сдвинули панель или сменили тему, и координаты приходится пересчитывать.
Выбор области применения сводится к одному вопросу: упирается ли маршрут в границу страницы. Пока весь путь укладывается в веб-интерфейс, управление браузером дешевле и надёжнее — с него и начинаем. Как только появляются файловые операции с локальными папками, работа в нативном клиенте или подтверждение в системном окне, без рабочего стола сценарий не закрыть.
На практике чаще нужен гибрид: часть шагов идёт по странице, часть — через окна и диалоги системы. Мы размечаем маршрут, оставляем браузерные шаги браузеру, а к рабочему столу обращаемся только там, где веб-интерфейса физически нет.
Сомнения инженера: частые возражения и ответы
Сомнения у инженеров на этапе оценки одни и те же: что будет при изменении интерфейса, допустим ли запуск в закрытом контуре, кто и как ограничивает доступ агента и чем подтверждается результат. Ниже — ответы по существу, без маркетинговых обещаний.
Интеграция Anthropic Computer Use строится так, чтобы сбой был виден до продакшена, а не после. Ниже — четыре технических вопроса, которые чаще всего задают на разборе архитектуры.
Что произойдёт, когда интерфейс изменится?
Сценарий опирается на смысловые ориентиры — подписи, заголовки, структуру формы, а не на координаты и порядок элементов. Переехавшая кнопка или переименованный раздел ломают прогон на проверке, а не в рабочей очереди. Критичные шаги дополнительно сверяются с состоянием системы, поэтому изменение ловится на этапе теста, а доля сценариев, которые сами сигналят о расхождении, растёт с каждым релизом.
Можно ли развернуть в закрытом контуре?
Да. Контур собирается внутри периметра заказчика: агент работает с тем сегментом сети, где ему разрешено находиться, а наружу не уходит ничего сверх согласованной политики. Обычно внешний обмен не нужен вовсе — журнал прогонов и постановка задач остаются у вас.
Как ограничивается доступ агента?
Агент работает под отдельной учётной записью с минимально достаточными правами: только нужные разделы, только те операции, которые предусмотрены сценарием, короткое время жизни сессии. Разрушающие действия выполняются с явным подтверждением, а каждое обращение попадает в журнал с привязкой к сценарию и человеку, который его запустил.
Чем подтверждается результат и что после запуска?
Успех фиксируется не по факту нажатия, а по итоговому состоянию: запись создана, статус изменён, документ совпал с ожидаемым. Расхождения уходят в очередь на разбор, а не теряются. После ввода в работу мы сопровождаем контур: разбираем падения, обновляем сценарии под релизы интерфейса и держим покрытие критичных маршрутов.
Обсудим задачу: пришлём оценку и план внедрения
Чтобы вернуться с оценкой, а не с общими формулировками, нам нужно от вас немного: описание процесса, который хотите закрыть автоматизацией, доступ к тестовому контуру и перечень ограничений — что агенту нельзя делать на живом интерфейсе ни при каких условиях. Этого достаточно, чтобы разобрать постановку задачи, понять, где Anthropic Computer Use действительно даёт выигрыш, а где надёжнее обычный обмен данными между системами.
После разбора задачи возвращаемся с конкретным набором документов:
- оценка объёма работ: какие сценарии закрываем в первой очереди и в каком порядке, что осознанно выносим за её пределы;
- план внедрения с этапами, ролями, точками контроля и пилотным сценарием на одном процессе;
- схема взаимодействия агента с интерфейсами, включая поведение при нештатных состояниях и правила отката;
- перечень рисков: где вёрстка или логика экрана меняется и ломает сценарий, как мы это отслеживаем;
- критерии приёмки — по каким измерениям видно, что автоматизация работает, а не имитирует работу;
- требования к доступам, стендам и данным, которые нужно подготовить с вашей стороны к старту проекта.
Опишите задачу в свободной форме — вернёмся с оценкой и планом. Если уже есть тестовый контур или наработки, разберём их и не будем изобретать заново.
