Microsoft и GitHub представили подход к проверке работы автономных агентов GitHub Copilot Coding Agent (Agent Mode), который помогает отказаться от хрупких сценариев тестирования и использовать так называемый «Уровень доверия» (Trust Layer). Концепция описана в исследовании команды Microsoft Code | AI и ориентирована на реальную эксплуатацию Copilot в CI-пайплайнах GitHub Actions.
Авторы исходят из того, что классическое тестирование опирается на предположение: правильное поведение детерминировано и повторяемо. Для автономных агентов это уже не так. При использовании функций Computer Use в контейнеризованной среде, IDE или браузере тест может выполняться разными маршрутами: меняется время загрузки, появляются или исчезают экраны, а к одному результату ведут несколько допустимых последовательностей действий. В итоге агент успешно завершает задачу, но тест, основанный на заранее записанном сценарии и жёстких таймингах, всё равно помечает прогон как сбой.
Исследователи называют это «разрывом доверия» в агентном тестировании. Для его устранения они предлагают изменить критерий корректности: важно не совпадение пошагового сценария, а достижение ключевых логических состояний. Проверка должна отличать «шум среды» (например, лишний экран загрузки) от критических ошибок (например, данные не были сохранены).
Вместо линейных сценариев команда использует графовую модель поведения агента — Prefix Tree Acceptor (PTA). Выполнение теста представляется как ориентированный граф, где вершины — это состояния (например, конкретный экран IDE), а рёбра — переходы между ними. Такой подход позволяет фиксировать ветвления и схождение разных маршрутов, что невозможно в жёстком пошаговом скрипте.
Ключевая идея состоит в применении доминаторного анализа из теории компиляторов. В графе управления узел A доминирует над узлом B, если любой путь из начала выполнения к B обязательно проходит через A. Перенося это на поведение агента, команда автоматически выделяет:
- обязательные состояния, без которых успешное завершение задачи невозможно (доминирующие узлы);
- вариативные шаги, которые могут быть или отсутствовать и не влияют на успех (недоминирующие узлы);
- критические ветки, пропуск которых означает реальный сбой.
Для работы такой схемы нужно решать задачу эквивалентности состояний: как понять, что два разных скриншота представляют один и тот же логический экран? Авторы применяют трёхуровневую систему сопоставления, переходя от быстрых визуальных метрик к более глубокому семантическому сравнению с участием мультимодальной модели. LLM задействуется точечно — для разборов неоднозначных случаев, а не для общей «оценки задачи», что снижает риск ошибок и сохраняет устойчивость к шуму интерфейса.
После объединения нескольких успешных прогонов в единый граф алгоритм строит «скелет» задачи — доминаторное поддерево. В экспериментах с VS Code, где Copilot через Computer Use выполнял поиск по коду, состояние «Окно поиска» было определено как обязательный этап, так как без него невозможно получить результаты. Экран загрузки, наоборот, оказался опциональным: он встречался не во всех успешных прогонах, поэтому не попал в минимальную модель корректности.
Далее валидация новых прогонов сводится к структурному сравнению с этим «деревом истины», а не к поиску буквального совпадения шагов. Алгоритм выполняет топологическое сопоставление последовательности состояний нового запуска с доминаторным поддеревом и выдаёт не только результат «пройдено/не пройдено», но и метрику покрытия плюс объяснение: какие обязательные состояния были достигнуты, какие пропущены и где именно произошёл сбой.
Для оценки подхода команда провела эксперимент на наборе тестов кастомного расширения VS Code с Copilot Agent. Сравнивались два подхода к оценке успеха: самодиагностика агента (Computer-Use Agent, CUA) и внешний анализ доминаторного дерева. В задачах, где нужно было отличить успешные прогоны от тех, что завершились из-за ошибок продукта или агента, структурная валидация по доминаторам показала точное разделение успешных и неуспешных запусков, тогда как агент регулярно ошибался, помечая сбои как успех (например, при таймаутах или неверной интерпретации своего состояния).
Авторы отмечают, что главное практическое следствие для разработчиков — сокращение ложных тревог в CI. Когда тест падает, важно понимать, сломан ли продукт, или агент столкнулся с временным шумом среды. Перенос «источника истины» с внутренней логики агента на выученную внешнюю структуру по нескольким успешным примерам снижает число флаппи-тестов и объём ручной проверки логов.
Команда подчёркивает, что для пользы разработчиков этот Trust Layer должен быть интегрирован в привычные инструменты — GitHub Actions и экосистему GitHub Copilot. Подход позиционируется как способ усилить несколько критических направлений в жизненном цикле разработки: стабильность автоматизации, прозрачность работы агентов, интеграцию Computer Use в AI-ориентированные процессы и повышение доверия к автономным компонентам в продуктивной инфраструктуре.
Исследователи называют описанную систему шагом к «проверяемой автономии». Вместо того чтобы полагаться на непрозрачные модели для оценки других непрозрачных моделей, предлагается комбинация классических методов анализа программ (доминаторный анализ, графы состояний) и мультимодального ИИ, дающая объяснимое определение успеха агентных сценариев по ограниченному числу примеров.
Источник: блог Microsoft Code | AI и материалы исследовательской команды по Trust Layer и доминаторному анализу для GitHub Copilot Coding Agent.
