Microsoft FSQ: обзор каркаса, который требует доказательства каждого действия ИИ-агента

Microsoft FSQ — открытый каркас для агентной автоматизации интерфейсов, где результатом считается не фраза «готово», а воспроизводимый набор свидетельств. Проект охватывает веб, мобильные и настольные приложения. Его полезно рассматривать не как ещё одного универсального робота, а как инженерный слой между моделью, инструментами и проверяющим человеком.

Что меняет evidence-first подход

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

Такой подход особенно важен для интерфейсов. DOM-элемент может существовать, но быть закрыт диалогом; мобильная кнопка — выглядеть активной, но не принять касание; настольное приложение — сохранить данные не в тот профиль. Снимок состояния и проверка после действия надёжнее доверия к текстовому ответу модели.

Где FSQ уместен

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

FSQ не отменяет обычные тесты. Если действие можно проверить быстрым API или модульным тестом, UI-маршрут будет медленнее и хрупче. Каркас нужен там, где интерфейс является частью задачи или другого надёжного доступа нет. Перед выбором полезно пройти методику первого пилота агента.

Архитектурная цена

Воспроизводимость требует закреплённых версий браузера, приложения, данных и разрешений. Нужно хранить снимки, логи и идентификаторы прогонов, а затем удалять чувствительные данные по политике. Скриншот способен случайно захватить имя клиента, уведомление или токен. Поэтому evidence-first без классификации артефактов легко превращается в новый архив утечек.

Отдельная работа — устойчивые критерии проверки. Цвет зелёной кнопки не всегда означает завершённый платёж, а наличие сообщения «успешно» может быть ошибкой интерфейса. Проверка должна опираться на итоговое состояние системы или независимый сигнал. Для рискованных операций нужен человек и лимит шагов агента.

Как провести честный тест

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

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

Сильные стороны

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

Ещё один плюс — отделение исполнения от оценки. Та же модель не должна сама окончательно решать, что её действие корректно. Лучше использовать детерминированную проверку, отдельного оценщика и выборочную ручную ревизию. Это соответствует принципу независимого журнала из разбора инцидентов агентных систем.

Ограничения

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

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

Вердикт

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

FAQ

FSQ заменяет Playwright или мобильные тестовые фреймворки?

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

Подходит ли каркас для production-операций?

Только после собственного аудита, ограничения прав и тестов на отказ. Открытый репозиторий не является гарантией готовности конкретной интеграции.

Нужно ли хранить все скриншоты?

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

Чем проверять успех?

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