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 справді дає виграш, а де надійніший звичайний обмін даними між системами.
Після розбору завдання повертаємося з конкретним набором документів:
- оцінка обсягу робіт: які сценарії закриваємо в першій черзі і в якому порядку, що свідомо виносимо за її межі;
- план впровадження з етапами, ролями, точками контролю і пілотним сценарієм на одному процесі;
- схема взаємодії агента з інтерфейсами, включно з поведінкою при нештатних станах і правилами відкату;
- перелік ризиків: де верстка або логіка екрана змінюється і ламає сценарій, як ми це відстежуємо;
- критерії приймання — за якими вимірюваннями видно, що автоматизація працює, а не імітує роботу;
- вимоги до доступів, стендів і даних, які потрібно підготувати з вашого боку до старту проєкту.
Опишіть завдання у вільній формі — повернемося з оцінкою та планом. Якщо вже є тестовий контур або напрацювання, розберемо їх і не будемо винаходити заново.
