28 октября GitHub объявил общий доступ к Agentic Workflows. Инструмент позволяет описать задачу в Markdown и запустить кодинг-агента внутри GitHub Actions. На Mentoring.digital разбираем, что это меняет для команд, которые регулярно сортируют задачи, исследуют сбои CI и обновляют документацию.
Markdown становится исполняемым процессом Actions
Файл с описанием задачи и конфигурацией компилируется в стандартный YAML для Actions. Поэтому процесс использует существующие группы раннеров и ограничения политик. Для выполнения можно выбрать GitHub Copilot или другой поддерживаемый кодинг-агент. Сам проект открыт, а общий доступ объявлен для GitHub Free, Team и Enterprise на github.com. Для движка Copilot CLI по умолчанию нужна лицензия Copilot.
Среди сценариев GitHub называет разбор входящих задач, анализ падений CI, обновление документации и подготовку тестов. В стартовом примере агент собирает активность репозитория и создаёт issue с отчётом. Это конкретный результат, который можно проверить по исходным событиям, прежде чем поручать автоматизации более сложную работу.
Права агента и запись результатов разделены
По умолчанию агент получает права чтения и работает в изолированном контейнере с контролем сетевого доступа. Для входящего содержимого действуют правила доверия. Предложенные изменения проходят отдельную проверку угроз, а запись выполняется через механизм safe outputs.
В выпуске также заявлены поддержка Actions Runner Controller с Docker-in-Docker, обновлённый выбор движков и шаблонов. Команда gh aw forecast перестала быть экспериментальной: прогноз учитывает расходы на проверку угроз и показывает месячные диапазоны. Такой прогноз помогает оценить затраты, но не заменяет наблюдение за фактическим потреблением.
С чего начать проверку в своём проекте
Выберите одну задачу с понятным результатом, например отчёт об изменениях за день. До включения расписания проверьте, какие данные читает агент, кому доступны журналы и какие записи ему разрешены. Сопоставьте первый отчёт с реальными issue и pull request, отдельно отметив пропуски и ошибочные выводы.
Документация требует хранить в репозитории и исходный Markdown, и скомпилированный файл .lock.yml. После изменения конфигурации его нужно пересобрать. Планировать полномочия автоматизации и проверки CI можно с наставником по DevOps и рабочим процессам разработки. Начинать разумно с ограниченного сценария, для которого команда заранее определила критерии приёмки.
