Разговор об интеграции старой системы почти всегда начинается одинаково: «API нет». Раньше за этим следовали пауза и смета на ручную работу, а теперь есть ответ, который звучит как универсальный ключ: пусть агент просто кликает вместо человека. Технически это работает, и демонстрация получается убедительной — агент открывает окно, находит поле, вписывает значение, нажимает «Сохранить». Сложный вопрос в другом: что станет с этой автоматизацией через четыре месяца, когда вендор программы перенесёт кнопку на два сантиметра влево.
Ответ зависит от того, на что агент опирается в момент действия — на письменный контракт или на картинку. Способы интеграции выстраиваются в ступени, где каждая следующая даёт больше охвата и меньше опоры. Разумный порядок действий — идти сверху вниз и остановиться на первой ступени, которая закрывает задачу.
Ступени интеграции по возрастанию хрупкости
Первая и самая прочная — документированный API. Вы работаете не с программой, а с её письменным контрактом: какие поля существуют, что возвращается в ответе, что считается ошибкой. Такой контракт тоже меняется, но о его изменениях объявляют: у него есть версии, а у вендора — график поддержки старых. Поломка приходит с предупреждением и с датой.
На второй ступени стоят события и вебхуки, когда платформа сама отправляет вам сообщение об изменении. Контракт здесь ещё есть, а вот доставка уже не гарантирована: Bitrix24 прямо пишет, что повторных отправок событий нет, а Shopify советует вообще не полагаться на доставку вебхуков. Этот класс отказов мы разобрали отдельно в материале «Где заканчивается ваша автоматизация» — ссылка в конце статьи.
Третья — готовый коннектор или iPaaS-платформа между вашими системами. Вы не пишете код, и это настоящая экономия, но между вами и системой появился ещё один вендор со своим графиком релизов. Когда платформа обновляет API, коннектор догоняет её не мгновенно, и в окне между этими двумя событиями живёте вы.
Четвёртая ступень — файловый обмен: выгрузка по расписанию, импорт по расписанию, CSV или XML в папке. Её регулярно пропускают как несовременную, и зря. Обмен файлами не даёт реального времени, зато структура выгрузки в корпоративных системах меняется в разы реже экранных форм, а поломка заметна сразу: файл либо соответствует ожидаемой структуре, либо нет. Если задача терпит задержку в час, эта ступень часто оказывается самой дешёвой из тех, что вообще надёжно работают.
Дальше идёт скрейпинг страницы или обращение к внутреннему недокументированному запросу, который вы подсмотрели на вкладке «Сеть» в браузере. Формально это уже работа без контракта: вы опираетесь на разметку и на адрес, которых вендор вам не обещал и которые вправе изменить в любой вторник.
Шестая, последняя — Computer Use. Опоры нет вообще: агент видит то же, что видит человек, то есть изображение экрана, и каждое его действие — это догадка о том, что нарисовано в этой точке. Всё, что на предыдущих ступенях было записано текстом, здесь приходится каждый раз распознавать заново.
Что показывают замеры
Это направление измеряют публично. Бенчмарк OSWorld от исследователей Гонконгского университета, Salesforce Research, Carnegie Mellon и Университета Ватерлоо сажает агента за настоящую операционную систему и даёт ему рабочие задачи. В первой версии, опубликованной в 2024 году, люди выполняли более 72% заданий, а лучшая модель — 12,24%, причём проваливалась она на самом простом: не могла надёжно понять, куда на экране нажимать.
За два года эту часть проблемы в основном закрыли, и именно поэтому в июне 2026 года вышла вторая версия бенчмарка — со 108 длинными сквозными сценариями вместо коротких операций. Медианная задача занимает у квалифицированного человека около 1,6 часа, почти 70% задач длиннее часа, и на одну такую задачу агент тратит в среднем 318 обращений к инструментам против примерно 30 в первой версии.
Результаты на этих сценариях такие. По основной метрике — задача либо доведена до конца, либо нет — лучший результат показывает Claude Opus 4.8 с максимальным объёмом рассуждений: 20,6% завершённых задач при частичном зачёте 54,8%. GPT-5.5 значительно экономнее по токенам, но выходит на плато около 14%. В таблице лидеров бенчмарка на октябрь 2026 года первым идёт Claude Opus 5: 44,33% завершённых задач на обновлённой версии набора задач v2.1 — более чем вдвое выше, но всё ещё меньше половины.
Доля завершённых задач держится только на коротких сценариях. Разбивку по длительности авторы строили на предыдущем поколении моделей — GPT-5.5 и Claude Opus 4.7, — поэтому общие 20,6% у более нового Opus 4.8 набираются именно на коротких и средних отрезках, а не равномерно по всей шкале. На сценариях короче 45 минут человеческой работы обе модели дают 20–24%, а дальше быстро падают. В интервале 137–163 минуты уже ни одна из протестированных моделей не превышает 10%, а на всём, что длиннее 163 минут, доля завершённых задач равна нулю у каждой из них. Это обрыв, а не плавная деградация. Сценарий для Computer Use нужно резать на короткие отрезки с проверкой между ними, потому что длинная цепочка просто не доезжает до конца.
Агенты ломаются не там, где этого ждут
Интуиция подсказывает, что агент промахнётся мышью. Авторы второй версии бенчмарка фиксируют другое: модели не спотыкаются ни на базовом управлении интерфейсом, ни на коде. Они теряют ограничения, заданные в начале задачи, пропускают информацию, которая приходит уже во время выполнения, угадывают там, где стоило бы переспросить, и не проверяют собственный результат. Хуже всего им даётся работа, которая зависит от скрытого состояния — от того, чего не видно на текущем экране.
Вот шесть строк из распределения сложностей по 108 сценариям:
- визуально-пространственная точность — нужна в 41,7% задач: попасть, выровнять, сверить на уровне пикселей
- вывод о неявном состоянии — 39,8%: нужное значение нигде не написано, его приходится доставать из предыдущих записей или журналов
- отслеживание состояния многих объектов — 39,8%: держать десятки строк, записей или правок согласованными между собой до конца сценария
- разрешение противоречий — 36,1%: два источника говорят разное, и нужно понять, какой из них главный
- работа по инструкции — 20,4%: извлечь процедуру из PDF или видео и применить её к случаю, который в инструкции не описан
- изменение условий на лету — 9,3%: письмо или сообщение в чате посреди задачи меняет требования
Если операция, которую вы собираетесь отдать агенту, держится на том, что исполнитель помнит договорённость трёхнедельной давности и знает, какой из двух прайсов актуален, — вы ставите автоматизацию ровно в ту точку, где она сейчас слабее всего.
Что об этом пишет сам производитель
Anthropic перечисляет ограничения своего инструмента computer use открыто, и на этот перечень стоит посмотреть до того, как вы что-то планируете. Задержка, по формулировке документации, может оказаться слишком большой по сравнению с обычной работой человека за компьютером, поэтому производитель советует сценарии, где скорость не критична: фоновый сбор информации, автоматизированное тестирование — и в доверенной среде. Модель может ошибаться или выдумывать координаты, когда определяет точку клика. Надёжность выбора инструмента падает в нишевых приложениях и тогда, когда в работе несколько программ одновременно. Отдельным пунктом среди ограничений стоит прокрутка: в приложениях, где скролл не срабатывает, документация советует клавиатурные альтернативы вроде Page Down.
Сосредоточьтесь на сценариях, где скорость не критична, — например, фоновый сбор информации или автоматизированное тестирование, — в доверенных средах.
— Anthropic, раздел «Limitations» документации computer use
Отдельно стоит разобраться с тем, что именно покидает ваш контур, потому что здесь легко сделать неверный вывод. Computer use работает как клиентский инструмент: сессия выполняется на вашей стороне, и скриншоты, движения мыши, ввод с клавиатуры и файлы хранятся в вашей среде, а не у поставщика модели. Но изображения экрана всё равно уходят в модель — она обрабатывает их в реальном времени как часть вызова API, и именно за них вы платите входными токенами. Хранение этих запросов регулируется общей политикой хранения данных API, а сам режим совместим с нулевым сроком хранения, потому что место и способ хранения определяет ваше приложение. Если на экране в момент работы агента видны персональные данные клиентов, это предмет для соглашения об обработке данных, а не для галочки «всё остаётся у нас».
Откуда берётся стоимость поддержки
Счёт за Computer Use устроен не так, как за вызов API, и это стоит заложить в смету до старта. Агент видит систему через скриншоты, каждый из которых стоит примерно от тысячи до 1800 входных токенов, и делает такой снимок практически на каждом шаге. Вспомните порядок величин из бенчмарка: 318 обращений на задачу против 30 в коротких операциях. Расход растёт вместе с длиной сценария, а не вместе с его ценностью для бизнеса — именно поэтому две операции с одинаковой пользой могут различаться по себестоимости в десять раз только из-за количества экранов на пути.
Вторая статья расходов — переделки. Интеграция через API живёт до объявленной смены версии. Интеграция через экран живёт до следующего релиза интерфейса, о котором вам никто не сообщит, потому что для вендора перенос кнопки не меняет контракт — контракта с вами у него и не было. Планировать здесь нужно не разовое внедрение, а регулярный пересмотр, привязанный к частоте обновлений той системы.
Третья, самая неприятная — тихая поломка. Упавший скрипт видно сразу. Агент, который после переезда кнопки уверенно нажал соседнюю, продолжает рапортовать об успехе, и разницу вы увидите только в данных, иногда через недели. Поэтому мониторить нужно результат операции в системе-приёмнике, а не сам факт того, что агент отработал без ошибки.
Когда Computer Use оправдан
В сумме условия складываются в довольно узкое окно, и честнее перечислить его полностью:
- верхних ступеней действительно нет — вы проверили не только публичную документацию, но и партнёрский доступ, выгрузку в файл и прямое чтение базы для систем на собственном сервере
- объём держится в десятках операций в день: на тысячах стоимость экранов и доля ошибок перевесят ручную работу
- сценарий короткий — минуты, а не часы, или нарезан на такие отрезки с проверкой между ними
- процесс стабилен — интерфейс той системы обновляется редко, и вы знаете, как часто
- результат можно проверить машинно: есть куда посмотреть и убедиться, что действие действительно выполнено
- ошибка обратима — операция не переводит деньги, не удаляет записи и не уходит клиенту без подтверждения человека
- есть владелец — человек, который разбирает сбои и отвечает за результат
Первый пункт отсеивает больше проектов, чем ожидают. Самая дорогая ошибка в этой теме вообще не техническая: компания строит хрупкую автоматизацию поверх экрана, имея под рукой ночную выгрузку, которой никто не поинтересовался, потому что вопрос вендору никто не задал.
Что сделать до внедрения
Начните с ещё одной попытки найти контракт. Вопрос вендору о партнёрском API или регулярной выгрузке умещается в одно письмо и закрывает тему дешевле любой разработки. Следующий шаг — записать процесс: последовательность экранов, условия ветвления, как выглядит успех и как выглядит сбой. Агенту, который действует по экрану, негде подсмотреть неписаное правило, поэтому всё, что сейчас живёт в голове сотрудника, придётся достать наружу.
Дальше идут четыре вещи, которые стоит описать конкретно, а не просто назвать. Точки проверки: после каждого содержательного шага агент сверяет состояние системы — создал контрагента, значит, читает его карточку и сравнивает ЕГРПОУ с тем, что вписывал. Граница необратимости: агент готовит платёжку, а кнопку «Провести» нажимает человек. План отката: ночной дамп таблицы до запуска сценария плюс имя того, кто выполняет эту работу руками, пока сценарий переделывают. И мониторинг по результату в системе-приёмнике — не «агент отработал без ошибки», а «за вчера в CRM появилось 47 записей, как и в источнике».
Эта работа одинаково нужна и для Computer Use, и для любого способа автоматизации выше по ступеням. Разница лишь в том, что на верхних ступенях без неё можно продержаться дольше, а здесь её отсутствие проявляется в первый же месяц.
Auspex строит автоматизацию и интеграции CRM, и в проектах со старыми унаследованными системами этот разговор возникает постоянно. На практике инвентаризация того, что система умеет отдавать наружу — партнёрский доступ, выгрузки, база, — снимает вопрос о Computer Use чаще, чем подтверждает его. Именно с неё начинается наш аудит CRM и интеграций, ссылка на него ниже.