Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Компьютерного агента научили выбирать между графическим интерфейсом и командной строкой в ходе одной задачи. В работе Haoting Shi и коллег модель после такого обучения решала задания примерно втрое чаще и тратила на 60% меньше токенов, хотя работа не рецензирована, а все числа получили сами авторы. Для команд это рецепт, как собирать более короткие и дешёвые траектории без отказа от визуального управления.
Приложение превращают в среду с общим состоянием
GUI и CLI полезны для разных действий. Через GUI агент видит расположение объектов и состояние интерфейса, а через CLI может одной командой изменить файл, обработать группу элементов или задать точное значение.
Главная инженерная проблема — сохранить между ними общее состояние. Если команда изменила проект, приложение должно показать актуальный результат; если агент выбрал объект через GUI, следующие команды должны работать с тем же проектом. Иначе вместо гибридного агента получаются два независимых исполнителя.
Компонент App-Forge устанавливает настольное приложение в воспроизводимую виртуальную машину, проверяет запуск и собирает сведения о среде. Затем он создаёт командный слой одним из трёх способов: находит штатные команды, оборачивает программный интерфейс приложения или генерирует отдельный CLI.
Так авторы подготовили 16 приложений, включая Blender, GIMP, VLC, Draw.io и программы LibreOffice. Лёгкие адаптеры обновляют GUI после внешних изменений, поэтому оба интерфейса работают с одним файлом или проектом. Агент установки и общий процесс сборки сокращают ручную работу, но специфические команды и способы синхронизации всё равно зависят от приложения.
Задачи собирают из операций, а траектории направляют
Task-Weave сначала исследует приложение и выделяет повторно используемые операции. Последовательность кликов превращается, например, не в инструкцию «нажать сюда», а в действие «экспортировать сцену». Такие операции очищают от дублей и связывают с реальными исходными файлами: сценами, таблицами, презентациями или диаграммами.
Затем система комбинирует операции в задания разной сложности. Проверяющий агент запускает каждое задание в настоящем приложении, отсеивает уже выполненные, двусмысленные и невыполнимые варианты. В пакет входят исходное состояние, пользовательская формулировка, способ проверки результата и подсказка для построения траектории.
Path-Steer задаёт предпочтительный интерфейс для каждого этапа. Пакетные и точные изменения направляются в CLI, действия, зависящие от компоновки или видимого состояния, — в GUI. Это не жёсткий сценарий: во время прогона агент по-прежнему выбирает действие сам, а подсказка лишь удерживает его от длинных серий кликов и хрупких командных сценариев.
Успешные прогоны проходят автоматическую проверку и становятся данными для дополнительного обучения. В CUA-Verse этот процесс проверяли на 160 отложенных заданиях для восьми приложений; задания требовали обоих интерфейсов и не пересекались с обучающими. Дополнительные проверки прошли на OSWorld и OSWorld-MCP, то есть не ограничились собственной средой.
Планы меняет не новый агент, а способ собирать данные
После обучения модель на 9B параметров стала успешнее работать и за пределами CUA-Verse. На OSWorld переход от исполнения только через GUI к гибридному режиму прибавил 16,8 процентного пункта к доле выполненных задач. На OSWorld-MCP оценка выросла на 7,84 пункта относительно базовой модели, хотя формат вызова инструментов не встречался при обучении.
Отдельное сравнение показывает, что одного доступа к CLI недостаточно. При одинаковом наборе инструментов Path-Steer поднял долю принятых траекторий с 44% до 51%: выигрыш дал выбор подходящего интерфейса, а не само наличие командной строки. Более короткая история действий также сокращает число обрабатываемых токенов и стоимость прогонов.
Работа меняет планы команды, если продуктовый агент управляет сложным настольным приложением, регулярно выполняет пакетные операции или упирается в длинные визуальные сценарии. Вместо сбора только записей кликов имеет смысл проектировать общий слой состояния, программные команды и проверяемые задания одновременно.
Для веб-сервиса с полным API этот подход может оказаться избыточным: агенту не обязательно видеть интерфейс, если всё состояние доступно программно. Он полезнее там, где часть задачи определяется визуально, а часть эффективнее выполняется командами — например, при редактировании презентаций, трёхмерных сцен или диаграмм.
Пока это не готовая универсальная платформа, а проверенный на конкретном наборе настольных программ процесс. Практический вывод состоит не в выборе модели из статьи, а в архитектуре данных: воспроизводимая среда, общий проект для GUI и CLI, составные задания, автоматическая проверка и направляемые траектории.
Источники
Иллюстрация: рисунок из статьи «CUA-Universe: A Scalable and Dynamic Environment for Hybrid GUI+CLI Agents», Haoting Shi, Wenhao Wang, Weicheng Fang и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
