Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Исследователи из Shanghai Jiao Tong University и Ant Group собрали ConflictGUI для проверки невыполнимых команд и предложили ConflictGuard, который помогает GUI-агенту прекратить задачу вместо неверного действия. В работе, опубликованной как не прошедший рецензирование препринт, средняя успешность обработки конфликтов выросла более чем на 35 процентных пунктов. Результат важен командам, которые дают мультимодальным моделям доступ к кликам, вводу текста и другим действиям в интерфейсах.
Что сделали
Авторы рассматривают два вида невыполнимых команд. Внутренний конфликт возникает, когда действие противоречит цели: например, предлагается нажать кнопку удаления, чтобы сохранить файл. Контекстный конфликт означает, что команда не соответствует текущему экрану: запрошенного элемента нет, его свойства отличаются или выполнению мешает состояние интерфейса.
Для оценки собрали ConflictGUI из примеров AMEX, AndroidControl и AITZ. В наборе 4660 заданий: исходные выполнимые инструкции и связанные с ними конфликтные варианты. Последние генерировали с помощью Kimi-K2.5 и Gemini-2.5 Pro, сохраняя экран и добавляя одно противоречие. Затем примеры вручную проверяли на то, действительно ли агент должен остановиться и правильно ли сформулирована причина.
ConflictGuard работает во время вывода и не меняет веса модели. Сначала в запрос добавляется протокол проверки выполнимости: агент должен сопоставить цель, требуемое действие и видимые данные интерфейса. Если команда противоречива или не подтверждается экраном, ожидаемым результатом становится завершение задачи со статусом ошибки.
Одного указания оказалось недостаточно: модель может заметить конфликт в рассуждении, но всё равно выдать клик. Поэтому авторы дополнительно вмешиваются во внутренние представления модели. На связанных выполнимых и конфликтных примерах они заранее выделяют направления активаций, соответствующие каждому типу конфликта, а также направление от исполнения к остановке. Во время работы пороговый механизм проверяет сходство текущего состояния с конфликтным направлением. Если порог пройден, к активациям добавляется сигнал остановки; иначе модель выполняет обычный проход.
Что показали
Успех на конфликтной задаче означает, что агент прекратил выполнение, а не выбрал ближайшее доступное действие. На Qwen3-VL-8B-Instruct доля успешных остановок при внутренних конфликтах выросла с 9,61% до 68,98%, а при конфликтах с интерфейсом — с 13,16% до 71,17%. Успешность обычных выполнимых заданий при этом снизилась на 3,44 процентного пункта.
Направление результата сохранилось на остальных моделях, к которым авторы применили полный метод. Проверка выполнимости уменьшала число действий, совершённых вопреки обнаруженному конфликту, а условное вмешательство ограничивало постоянный уклон к отказу. По замерам авторов, явной общей прибавки к задержке относительно обычного вывода не возникло.
Ограничения
Основной ConflictGUI проверяет выбор следующего действия по текущему экрану, а не завершение полноценного процесса из многих шагов. Конфликтные инструкции созданы синтетическим преобразованием существующих наборов, поэтому работа не показывает, как часто такие ситуации возникают в продуктах и насколько их формулировки совпадают с ошибками реальных пользователей.
Проверка длинных процессов предварительная: она проведена на 100 вручную составленных задачах с одной моделью. В конфликтной части успешность остановки выросла с 2% до 36%, но такого масштаба недостаточно для вывода о стабильности метода в продолжительных сценариях, где состояние меняется после каждого действия.
Полный ConflictGuard требует доступа к скрытым состояниям модели, поэтому его нельзя напрямую перенести на закрытый API. Авторы отдельно проверяли обычные запросы к закрытым моделям, но в основном сравнении полного метода не хватает закрытых агентов и производственных механизмов подтверждения человеком, отката операций и разграничения прав. Работа также не оценивает последствия ложной остановки по стоимости процесса или риску для пользователя.
Что это значит
Для команд, строящих GUI-агента на модели с открытыми весами, работа меняет план защитного контура, но не выбор базовой модели. Проверку выполнимости стоит проектировать как отдельный этап перед действием, а остановку — как явный результат с причиной, а не как текстовое замечание внутри рассуждения. Парные тесты «обычная команда — конфликтная команда» позволяют отдельно следить за двумя ошибками: неверным действием при конфликте и необоснованным отказом при корректной задаче.
Сам ConflictGuard пока следует рассматривать как кандидат для эксперимента, а не готовую гарантию безопасности. Его внедрение требует калибровочных данных для конкретной модели, доступа к декодеру и регрессионной проверки после замены весов или шаблона запроса. Для агента поверх закрытого API применима только часть с явной проверкой инструкции и экрана; управление активациями недоступно.
Метод не заменяет ограничения прав, подтверждение необратимых действий и журналирование. Он закрывает более узкую проблему: агент уже способен нажать кнопку, но должен сначала установить, что нажатие соответствует цели и текущему состоянию интерфейса. Если продукт выполняет платежи, удаляет данные или меняет настройки, такую проверку разумно добавить в архитектуру независимо от того, будет ли использован именно ConflictGuard.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
