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

Агенты для управления компьютером (computer-use agents) теперь умеют кликать мышью, вводить текст, просматривать веб-страницы, редактировать файлы, работать с десктопными приложениями и выполнять впечатляющие многошаговые задачи. Поэтому успешные демоверсии легко воспринимаются и легко переоцениваются. Однократное выполнение рабочего процесса лишь доказывает, что агент способен добиться успеха в этих конкретных условиях. Это не показывает, как часто он достигает цели, как ведет себя при изменении среды, проверяет ли результат и насколько безопасно действует в ситуациях с неоднозначными целями.

Почему демо — это простейший из возможных тестов на надежность

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

Это различие критически важно, поскольку агенты для управления компьютером работают через интерфейсы, созданные для людей, а не через детерминированные API. Цикл их действий зависит от восприятия, интерпретации состояния, планирования, тайминга взаимодействия и отклика среды. Небольшие изменения могут сбить траекторию, даже если цель пользователя осталась прежней.

Исследование WAREX от Microsoft Research наглядно демонстрирует эту проблему: агенты из бенчмарков, выглядящие способными в контролируемых условиях, существенно теряют в успешности задач при возникновении реалистичной нестабильности веба. Причина сбоя не обязательно в том, что «модель поглупела». Дело в том, что среда перестала быть детерминированной.

Возможность, доля успеха, надежность и безопасность — это разные утверждения

Лестница надежности управления компьютером

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

Уровень 1 — Возможность выполнения: вопрос уровня демо

Возможность выполнения определяет, способен ли агент в принципе решить задачу. Это ценно. Системы управления компьютером развиваются стремительно, и современные агенты могут выполнять рабочие процессы, которые прежние системы не могли реализовать надежно.

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

Уровень 2 — Повторяемость: остается ли та же задача решенной?

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

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

Уровень 3 — Устойчивость к среде: что происходит, когда веб ведет себя как реальный веб?

Реальные веб-сайты — это не статичные стенды бенчмарков. Запросы завершаются с ошибками, элементы загружаются с задержкой, сессии истекают, страницы меняются, появляются баннеры согласия на обработку файлов cookie, серверы возвращают ошибки, а условия сети постоянно меняются.

WAREX оценивает этот разрыв, внедряя реалистичную нестабильность веба в существующие среды бенчмарков, и фиксирует значительное падение успешности выполнения задач. Это критически важный вывод для продакшена: бенчмарк может оценивать способность решать задачи, недооценивая при этом устойчивость к восстановлению после сбоев среды.

Уровень 4 — Долгосрочное управление: результаты меняются, когда задача превращается в реальную работу

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

Бенчмарк OSWorld 2.0 был специально разработан для оценки долгосрочных реальных рабочих процессов. У пользователей-людей выполнение его задач занимает в среднем около 1,6 часа и требует значительно больше вызовов инструментов, чем в более ранних бенчмарках взаимодействия с компьютером. Согласно его основной метрике завершения, даже самые мощные из протестированных систем все еще далеки от полной надежности.

WeaveBench приходит к аналогичному выводу с другой стороны. Он оценивает гибридные рабочие процессы с использованием GUI, CLI и кода и показывает, что лучшая протестированная связка модели и среды выполнения успешно проходит лишь 41,2% задач. Важный результат заключается не в конкретной цифре в таблице лидеров, а в том, что реалистичная координация между интерфейсами выявляет сбои, скрытые более простыми задачами в рамках одного интерфейса.

Уровень 5 — Отслеживание состояния: среда может измениться прямо во время выполнения плана

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

Авторы бенчмарка SentinelBench от Microsoft утверждают, что многие длительные задачи вообще не следует решать с помощью непрерывных действий. Правильным поведением может быть мониторинг, ожидание внешнего события и действие лишь после изменения состояния. Это принципиально иной навык, нежели более быстрые клики или планирование большего числа шагов.

Поэтому надежный агент для взаимодействия с компьютером должен различать состояния: «можно действовать сейчас», «ожидание изменения состояния», «состояние изменилось» и «предположение не подтвердилось».

Уровень 6 — Проверка результата: сработало ли действие на самом деле?

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

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

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

Уровень 7 — Безопасная обработка целей: агент должен знать, когда не продолжать

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

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

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

Стресс-тест перехода от демо к продакшену

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

Успех в бенчмарке имеет границу валидности

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

Число становится вводящим в заблуждение, когда эти условия исчезают из утверждения. «Агент X набирает 80%» слабее, чем «Агент X набрал 80% в бенчмарке Y в среде Z с судьёй J и бюджетом шагов N». Второе утверждение сохраняет границу, которая говорит вам, переносится ли число на ваше приложение.

Успех процесса и успех результата должны оцениваться отдельно

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

Надёжность в продакшене — это распределение, а не единичная доля успеха

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

Надёжности нужен бюджет отказов, а не совершенство

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

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

Практическая матрица надежности для сценариев управления компьютером

Что логировать при сбоях сценариев управления компьютером

• Цель пользователя и явные ограничения.
• Версия модели и тестовой обвязки (harness).
• Версии окружения и приложений.
• Скриншоты или структурированные наблюдения, относящиеся к сбою.
• Выполненные действия с временными метками.
• Результаты вызова инструментов, кликов, ввода с клавиатуры и навигации.
• Переходы между состояниями и периоды ожидания.
• События согласования, отказа или передачи управления человеку.
• Внешние ошибки и сетевые сбои.
• Итоговое наблюдаемое состояние окружения.
• Результат, о котором сообщил агент.
• Результат верификатора и оценка того, мог ли агент предотвратить сбой.

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

Безопасность — неотъемлемая часть надежности агентов управления компьютером

Агенты управления компьютером не просто читают ненадежный контент — они могут совершать действия на его основе. Это превращает инъекции промптов, вредоносное содержимое страниц и фишинг в риски на пути выполнения.

Текущие рекомендации OpenAI по управлению компьютером советуют изолировать окружение, использовать белые списки сайтов и действий, рассматривать содержимое экрана как ненадежное, подтверждать критически важные действия, ограничивать время выполнения и проверять фактический результат. Агент ChatGPT аналогично использует подтверждения, мониторинг инъекций промптов и контролируемые режимы для чувствительных контекстов.

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

Что могло бы изменить эти выводы?

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

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

Ограничения

Приведенные бенчмарки оценивают различные среды, и их не следует ранжировать относительно друг друга так, будто они измеряют одно и то же. WAREX тестирует устойчивость к ненадежности веба; WeaveBench нацелен на гибридную работу с длинным горизонтом; OSWorld 2.0 ориентирован на реалистичные протяженные рабочие процессы; BLIND-ACT фокусируется на обработке целей в условиях неопределенности и невыполнимости.

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

Заключение

Агенты для управления компьютером уже достаточно функциональны, чтобы приносить реальную пользу. Именно поэтому фокус оценки изменился. Главная задача теперь состоит не просто в том, чтобы агент мог пройти по заданному сценарию. Важно то, сохраняет ли система надежность, когда идеальные демонстрационные условия перестают действовать.

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

Часто задаваемые вопросы

Глоссарий

Первоисточники и литература для дальнейшего чтения