Что такое управление компьютером и почему оно важно? Управление компьютером — простая идея с далеко идущими последствиями: вместо ответов на вопросы модели автономно работают с программами — переходят по сайтам, заполняют формы, проходят рабочие процессы и выполняют задачи от начала до конца.
Это открывает путь к широкому классу практических задач, которые сейчас разрознены по разным интерфейсам: от полного цикла бронирования, оформления интернет-покупок и многоэтапного планирования поездок до внутренних рабочих процессов без полноценного аналога в виде API. Эти проблемы не новы. Новым стало то, что теперь их можно решать с помощью моделей общего назначения.
Недавние системы Anthropic и OpenAI продемонстрировали агентов, способных не только действовать, но и рассуждать о состоянии, восстанавливаться после ошибок и на ходу создавать решения для конкретных задач. Браузер становится универсальной средой выполнения для агентов, но сразу возникает вопрос проектирования: какую часть этой среды следует открыть модели?
Первые системы помещали браузер в обёртку с фиксированным набором безопасных предопределённых действий. Как мы покажем в этой статье, такой подход исчерпывает свои возможности.
При создании браузерных агентов часто срабатывает знакомый инстинкт: не стоит слишком доверять модели.
Поэтому мы помещаем браузер в обёртку. Мы предоставляем предопределённые инструменты: click, type, scroll, select и read_text. Мы упрощаем объектную модель документа (DOM). Мы сокращаем пространство действий. Мы пытаемся сделать поведение понятным и управляемым с помощью разработанных нами абстракций.
Для начала это разумный подход. Но в долгосрочной перспективе это всё чаще оказывается неверной архитектурой.
По мере совершенствования передовых моделей проблема уже не сводится к нехватке инструментов у модели. Проблема в том, что мы заставляем её работать через абстракции, отбрасывающие слишком много информации о базовой системе. Мы сжимаем сложную динамическую среду до фиксированного интерфейса действий, а затем требуем от модели эффективно работать в условиях этой потери информации.
Такой компромисс становится всё менее привлекательным.
Исследуемый нами переход легко описать, но его последствия значительны. Вместо того чтобы рассматривать агента как средство выбора предопределённых действий, мы относимся к нему как к синтезатору программ, работающему в ограниченной среде выполнения.
Модели стали действительно хороши, и им больше не нужны ваши абстрактные ограждения. Им необходимо полное пространство действий, чтобы проектировать, выполнять и совершенствовать решение задачи, пока цель не будет достигнута.
Эта статья посвящена переходу от перегруженной абстракциями автоматизации браузера к управлению компьютером с ограничениями и тому, что меняется при таком подходе к проектированию систем.
Проблема не в том, что фиксированные интерфейсы действий концептуально неверны. Проблема в том, что веб им не подчиняется.
Современные интерфейсы создаются на React, Vue и Angular. В них используются асинхронные обновления состояния, системы синтетических событий и встроенные сторонние виджеты, размещённые в междоменных iframe со своими жизненными циклами. Обёртка с командой «ввести текст в это поле» работает правильно, только если представление страницы о вводе текста совпадает с вашим. Часто это не так. Прямая установка значения часто полностью обходит механизм обнаружения изменений во фреймворке. Поле выглядит заполненным. Проверка не запускается. Форма остаётся неработоспособной.
Это можно исправить заплаткой. Можно добавить особые случаи для полей React, отправлять события blur после получения фокуса и ждать прекращения сетевой активности перед чтением состояния. Каждая такая заплатка решает конкретную проблему. Но вместе они образуют систему, которую всё сложнее поддерживать и которая всё сильнее привязана к уже знакомым вам сайтам.
Более глубокая проблема в том, что вы закладываете в слой абстракции предположения о правильном устройстве взаимодействий, а затем обнаруживаете, что веб устроен иначе.
Рассмотрим платёжную форму Stripe или Adyen, встроенную в междоменный iframe. Ваша обёртка не может обратиться к ней напрямую, поскольку та находится в другом источнике. Инструмент read_text не может получить её внутреннее состояние. Инструмент type не может обратиться к её полям ввода. Здесь агент на основе обёртки упирается в стену. Абстракция была разработана для основного документа. Но фактическая задача находится там, куда абстракция не видит.
Подобное несоответствие встречается и в менее очевидных процессах. Управляемый фреймворком раскрывающийся список может вообще не реагировать на прямые щелчки, поскольку видимый элемент не является настоящим элементом управления. Для запуска изменения внутреннего состояния может потребоваться последовательность событий клавиатуры. Со стороны кажется, что элемент интерфейса можно нажать. Абстракция говорит: «Нажми». Ничего не происходит.
Другой пример — многоэтапный процесс в модальном окне, где обновления видимой DOM отстают от изменений внутреннего состояния. Правильное следующее действие зависит от изменения состояния, которое ещё не отражено в элементах, доступных обёртке. Агент на основе обёртки действует слишком рано или считывает устаревшее состояние, поскольку видит систему не полностью.
В каждом случае абстракция скрывает сигналы, которые на самом деле нужны агенту.
Модель, работающая на более низком уровне — анализирующая актуальную DOM, учитывающая границы фреймов и синтезирующая последовательность взаимодействий для конкретного интерфейса, — способна справиться с такими ситуациями. Дело не в том, что модель сама по себе умнее. Просто ей доступна информация, которая ранее отбрасывалась.
Изменение, к которому мы стремимся, легко описать: вместо выбора предопределённых действий мы предоставляем модели низкоуровневый исполнительный интерфейс и ограничиваем его политиками среды выполнения, а не архитектурой абстракций.
Такой подход отражает более широкий сдвиг в отрасли в сторону низкоуровневых инструментов-примитивов. Они опираются на естественную способность агента корректировать свои действия во время выполнения и создавать качественный код, в отличие от надёжных жёстко заданных специализированных инструментов, которые лишают модель возможности адаптироваться к разным средам.
Об этом свидетельствуют успех Claude Code, ставшего одним из основных инструментов многих разработчиков, и общий переход отрасли к агентам на базе терминала. Главное преимущество Claude Code — не сама модель, а низкоуровневая обвязка. Если предоставить модели меньшее число более модульных низкоуровневых инструментов — то есть терминал, — она эффективнее вызывает инструменты. Главным образом потому, что агент может рассуждать и создавать специализированные скрипты для текущей задачи, а не пытаться применять универсальные инструменты, засоряющие контекстное окно.
Применительно к автоматизации браузера это означает, что модель может напрямую анализировать актуальное состояние страницы, переходить между фреймами и создавать специализированный код взаимодействия для текущего интерфейса, а не сводить всё к фиксированному набору готовых действий.
Модель ведёт себя не столько как средство выбора, сколько как автор логики времени выполнения. Она анализирует текущее состояние, рассуждает об интерфейсе и синтезирует логику взаимодействия для конкретной ситуации. Она может создавать многоэтапные последовательности, адаптироваться к необычным процессам и проверять результаты перед продолжением. Если действие завершается неудачей, модель видит исходную ошибку и самостоятельно корректирует свои действия. Это даёт больше возможностей и создаёт больше рисков, но гораздо точнее соответствует реальной природе задачи.
Важно, что удаление слоя абстракции не делает систему менее строгой. Строгость просто переносится в другое место.
Работа, ранее выполнявшаяся при проектировании обёрток и обработке пограничных случаев, переносится в три области: промпт, который становится формой практического обучения; среду выполнения, которая обеспечивает соблюдение границ, включая область навигации, чувствительные действия и правила повторных попыток; а также слой оценки, который проверяет не только успех всей задачи, но и правильность промежуточных шагов. Меньше хрупких абстракций. Надёжнее окружающие системы.
Одно из следствий этого перехода — код продукта часто становится проще, хотя система в целом приобретает больше возможностей. Вместо того чтобы кодировать шаблоны взаимодействия в виде многократно используемых обёрток, агент синтезирует поведение во время выполнения. Вместо постоянно растущего набора специализированных инструментов и логики для пограничных случаев вы поддерживаете небольшой набор мощных примитивов и ограниченную среду выполнения.
Это также меняет способность системы к обобщению. Агент на основе обёрток хорошо справляется с новыми задачами, похожими на те, для которых уже созданы обёртки. Агент в ограниченной среде выполнения обобщает задачи с общей исполнительной основой, даже если их видимые интерфейсы различаются.
Например, на уровне пользовательского интерфейса взаимодействие с формой поиска, процессом бронирования и страницей настроек может выглядеть совершенно по-разному. Но в основе лежат общие шаблоны: чтение состояния, запуск событий, проверка результатов и обработка асинхронных обновлений. Система, работающая на этом уровне, естественнее переносит навыки между задачами.
Повторно используется не список действий, а способность модели анализировать состояние, безопасно действовать и проверять результаты.
Главный вывод из этой работы: надёжность достигается не за счёт дополнительных вспомогательных функций для модели. Зачастую для неё достаточно меньшего числа более мощных примитивов, ограниченных правильным образом. Чрезмерная помощь жёстко закрепляет предположения о том, как следует выполнять задачу. Ограничения задают безопасные рабочие рамки и позволяют модели находить более эффективные решения в конкретных ситуациях.
Более мощный исполнительный интерфейс требует и более строгой модели безопасности. Когда агент перестаёт быть ограничен небольшим набором предопределённых действий, он фактически начинает напрямую работать с реальным программным обеспечением. Это сразу меняет профиль рисков.
При проектировании нужно учитывать четыре аспекта:
Раскрытие данных. Взаимодействуя с реальными интерфейсами, агент часто будет сталкиваться с конфиденциальной информацией. Поэтому необходим строгий подход к маскированию и управлению доступом. Данные следует раскрывать только тогда, когда это необходимо для выполнения задачи, а с журналами и трассировками нужно обращаться осторожно, чтобы средства наблюдаемости не стали самой уязвимой частью системы.
Область выполнения. Мощный агент не должен действовать бесконтрольно. На практике нужно ограничивать доступные ему маршруты навигации и домены, а также системы, с которыми ему разрешено взаимодействовать. Эти ограничения должны применяться на уровне среды выполнения, а не оставаться условностями в промпте.
Доверие к среде. Современные интерфейсы могут содержать вводящие в заблуждение или намеренно враждебные инструкции, материалы и процессы. Промпт-инъекция через содержимое страницы — это реальный вектор атаки. Чтобы агент не следовал непредусмотренным указаниям, системе необходимы чёткая иерархия инструкций, проверки и условия завершения работы.
Спектр автономности. Не все действия должны выполняться полностью автономно. Во многих промышленных системах автономность важно рассматривать как спектр. Система может обладать высокой агентностью при исследовании среды и выполнении задач, но всё же требовать одобрения для определённых категорий действий.
Основной принцип прост: чем больше возможностей получает модель, тем надёжнее должна быть окружающая её система. Автономность без политик не готова к промышленной эксплуатации.
Мы перестали спрашивать: какие действия браузера следует предоставить?
Вместо этого мы спросили: как предоставить модели полное пространство действий и при этом окружить его политиками среды выполнения, обеспечивающими безопасность?
Такое переосмысление меняет приоритеты. Таксономии действий и полнота обёрток становятся менее важны. Более важными становятся политики среды выполнения, наблюдаемость и оценка каждого шага. Возможности модели и архитектура системы не заменяют друг друга. По мере совершенствования моделей работа системы становится не менее, а более важной.
Браузерные агенты, успешно работающие в демонстрациях, часто добиваются успеха благодаря узкой задаче и благоприятной среде. Для промышленных систем нужно другое: ограниченное выполнение, инструментированное поведение и оценка, способная отличить правильный результат от случайного успеха.
Меньше проектирования обёрток. Больше системной инженерии.
И хотя мы сосредоточились на браузерных агентах, этот подход предлагает более широкий взгляд на управление компьютером как на системную дисциплину.