GitHub объявила о запуске динамических workflow в Copilot CLI, приложении GitHub Copilot и Copilot SDK. Вместо того чтобы каждый раз поручать агенту самостоятельно выбирать последовательность действий, разработчик может описать процесс в коде: какие шаги выполнить, где подключить агентов и как передать их результаты дальше. Функция находится в публичной предварительной версии и может измениться.
Процесс задаёт код, анализ выполняют агенты
По описанию GitHub, динамический workflow — программа, которая объединяет автоматические операции и работу одного или нескольких агентов. Этапы можно запускать последовательно, параллельно или сочетать оба режима. Код определяет порядок шагов и обработку результатов, а агентам остаются задачи, требующие анализа или суждения.
В качестве примера GitHub приводит разбор инцидента в сервисе: workflow собирает логи и телеметрию, поручает разным агентам анализ отдельных систем, а затем сводит структурированные результаты в хронологию и отчёт о возможной причине сбоя. Это пример предполагаемого применения, а не опубликованный результат испытания.
Workflow размещается внутри расширения GitHub Copilot и использует API расширений. GitHub пишет, что разработчик может создать такой процесс сам или попросить Copilot помочь с его написанием. При этом воспроизводимость относится прежде всего к заданной последовательности действий: аналитические выводы агентов всё равно требуют проверки.
Чем это отличается от `/fleet`
GitHub отдельно разграничивает динамические workflow и `/fleet`. В описании компании `/fleet` делегирует работу субагентам и координирует их выполнение, тогда как workflow исполняет заранее определённый в коде процесс. Иными словами, это разные способы организации задач, а не просто два названия для параллельного запуска агентов.
Документация GitHub подтверждает, что workflow могут сочетать детерминированные операции, агентов, инструменты, API и взаимодействие с пользователем. Она также отмечает публичный предварительный статус функции. Это даёт разработчикам больше контроля над этапами и передачей данных, но само по себе не гарантирует правильность анализа, который выполняет модель.
GitHub сообщает, что динамические workflow доступны на всех планах Copilot. Для Copilot CLI в анонсе также указан запуск через команду `/workflow`, а обратную связь предлагают отправлять командой `/feedback`. Перед настройкой стоит сверить актуальную документацию: предварительные функции могут менять поведение и требования.
Где это может пригодиться командам
Формат может подойти для повторяемых многошаговых задач: например, когда перед обзором изменений нужно собрать результаты проверок, поручить агентам независимый анализ, сопоставить ответы и подготовить отчёт заданной структуры. Для простой правки или быстрого вопроса такой процесс может быть избыточным — GitHub рекомендует в подобных случаях обычный запрос в стандартном режиме чата.
Документация Copilot также советует формулировать задачи ясно, разбивать крупную работу на меньшие этапы и давать агенту необходимые примеры и контекст. Динамический workflow позволяет зафиксировать часть этой структуры в исполняемом процессе, но не заменяет конкретные критерии приёмки и ревью результата.
Для команд, которые рассматривают инструмент для проверки релизов или анализа инцидентов, практический смысл — в возможности отделить машинно проверяемые действия от интерпретации агента. Например, сбор статусов CI и запуск тестов можно задать как обязательные шаги, а классификацию ошибок поручить модели. Вывод агента при этом не следует считать заменой существующим контрольным процедурам.
Как проверить функцию на безопасном пилоте
Независимая публикация QA Tech Tools описывает похожий сценарий для контроля качества, но предлагает его как подход к пилоту, а не приводит результаты сравнительного тестирования. Доступные материалы не содержат измерений точности, скорости или стоимости динамических workflow относительно `/fleet` либо обычного чата. Поэтому оценивать преимущества в этих параметрах пока рано.
Для первого испытания подойдёт задача с ограниченным воздействием и проверяемым результатом:
Выберите тестовый репозиторий или чтение данных без доступа к производственным системам.
2. Зафиксируйте автоматические шаги: например, сбор статуса CI и запуск уже используемых тестов.
3. Попросите агента классифицировать ошибки, а результат требуйте в заранее заданной структуре.
4. Сопоставьте вывод с фактическими логами и решениями разработчиков; отдельно отмечайте пропуски и ложные выводы.
5. Не разрешайте workflow автоматически выполнять необратимые действия, пока команда не проверит его поведение на нескольких запусках.
Такая проверка покажет, насколько процесс повторяем в конкретном проекте и где необходим ручной контроль. Пока функция остаётся предварительной, её разумно тестировать как дополнительную оркестрацию, а не как единственный механизм проверки релиза.
