GitHub Agentic Workflows: первые шаги к автоматизации с ИИ

Что такое Agentic Workflows от GitHub

Представьте: понедельник, 9 утра, и в бэклоге висят 43 новых задачи. Одни — настоящие баги. Другие — дубликаты запросов на фичи. Пара — просто жалобы на опечатку. Тому, кто дежурит на этой неделе, придётся потратить первые два часа на чтение, маркировку и ответы, прежде чем он сможет заняться тем, что действительно планировал.

Именно такую рутину и призваны снять Agentic Workflows. 11 июня 2026 года GitHub перевёл инструмент в публичное превью, открыв для каждого репозитория возможность запускать ИИ-агентов прямо внутри GitHub Actions. Не просто автодополнение кода и не чат-помощник, а полноценный агент, который срабатывает по расписанию или событию, читает задачу, пул-реквест или недельную историю коммитов и делает с найденным что-то полезное.

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

Если отбросить маркетинг, идея проста. Вы пишете Markdown-файл в папке .github/workflows/. В его начало добавляется небольшой блок YAML с описанием условий запуска, разрешений и выбранного ИИ-движка. Ниже, уже простым языком, вы описываете, что должен делать агент.

Утилита командной строки gh-aw читает этот Markdown и компилирует его в .lock.yml — совершенно обычный файл GitHub Actions. Вот важный момент: никакого отдельного агентского рантайма, прикрученного к репозиторию, нет. Используются те же раннеры, те же правила защиты веток и корпоративные политики, потому что под капотом это всего лишь Actions.

Проект создан командами GitHub Next и Microsoft Research и поддерживает четыре ИИ-движка «из коробки»: GitHub Copilot, Anthropic Claude, OpenAI Codex и Google Gemini. При желании можно подключить свой обработчик. По умолчанию используется Copilot, и если ваша организация уже оплачивает тариф Copilot, запуски workflow-ов будут списываться прямо на неё — без лишних токенов.

Agentic Workflows — часть более широкой концепции, которую GitHub называет Continuous AI. Это систематическое применение ИИ на всех этапах разработки, а не разовые запросы к модели. Workflow-ы позволяют делать это по расписанию или по событиям в репозитории, не дожидаясь, пока разработчик вручную задаст вопрос Copilot.

Важно понимать, чем Agentic Workflows не являются. Это не облачный агент Copilot, который вы запускаете вручную для конкретной задачи, когда хотите, чтобы он что-то реализовал прямо сейчас. Agentic Workflows ближе к постоянной политике: «каждый понедельник подводи итоги недельной активности» или «при каждом новом PR проверяй его на безопасность». Первое — разовое поручение. Второе — привычка, встроенная в сам репозиторий.

Почему на это стоит обратить внимание

GitHub редко публикует цифры по внедрению на столь ранних этапах, поэтому наличие именованных отзывов от клиентов в анонсе говорит о том, насколько далеко зашло внутреннее тестирование.

Carvana рассказала GitHub, что гибкость и встроенные средства контроля дали их инженерам уверенность запускать агентские workflow-ы на по-настоящему сложных системах, включая изменения, затрагивающие несколько репозиториев одновременно (из официального журнала изменений). Marks & Spencer описали похожую историю под другим углом: их разработчики теряли реальные часы спринта на рутинные вещи — сортировку задач, обслуживание зависимостей, исправление уязвимостей и стандартные проверки. Создав общий каталог переиспользуемых агентских workflow-ов, команды смогли применять эту автоматизацию к любому репозиторию, не изобретая всё заново.

Hud.io отметили момент, который легко пропустить при беглом знакомстве: самое сложное — не заставить агента открыть пул-реквест, а доверять результату настолько, чтобы его принять. На этом и строится модель безопасности, о которой пойдёт речь дальше.

Вот сводка возможностей на сегодня, взятая со страницы цифр GitHub:

Модель безопасности — главная изюминка

Большинство презентаций в духе «ИИ теперь делает DevOps» обходят стороной очевидный вопрос: что случится, если агент ошибётся или, хуже того, окажется скомпрометирован через вредоносный комментарий в issue или файл в репозитории. Инъекции промтов через содержимое репозитория — известный риск для любого агента, читающего непроверенный текст, и GitHub предусмотрел пять уровней защиты именно для его нейтрализации.

1. Токены только для чтения: GitHub-токен агента по умолчанию имеет доступ лишь на чтение. Даже если агент попытается запушить код, открыть PR или удалить файл, токен физически не позволит это сделать.
2. Никаких секретов внутри агента: Процесс, который непосредственно работает с ИИ-моделью, никогда не получает токены на запись, API-ключи или любые другие учётные данные. Они живут только в отдельной задаче, запускаемой после завершения работы агента и проверки его предложений. Если агента взломают во время работы, украсть будет нечего.
3. Песочница с сетевым файрволом: Агент выполняется в изолированном контейнере, и весь исходящий трафик проходит через так называемый Agent Workflow Firewall — Squid-прокси, пропускающий только адреса из явного разрешённого списка. Всё остальное обрывается на уровне ядра, так что у скомпрометированного агента нет способа незаметно связаться с внешним сервером.
4. Безопасные выводы: Эту часть стоит понять правильно, потому что именно она связывает всю модель воедино. Агент вообще не может писать в репозиторий напрямую. Вместо этого он формирует структурированное описание того, что хочет сделать — например, «создать задачу с таким заголовком и текстом». Отдельная задача с узкими правами на запись читает этот запрос и применяет только то, что вы явно разрешили в заголовке workflow-а: жёсткий лимит в одну задачу за запуск, обязательный префикс заголовка, конкретные ограничения на метки — всё на ваше усмотрение. Агент предлагает. Изолированная, детерминированная задача выполняет.
5. Обнаружение угроз: Прежде чем любое изменение попадёт в репозиторий, специальная задача детектирования угроз проводит собственное ИИ-сканирование предлагаемых правок на предмет попыток инъекций, утекших учётных данных или подозрительных участков кода. Если что-то выглядит не так, весь запуск проваливается, и ни одна запись не производится.

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

Что понадобится для начала

Нужно совсем немного, но каждый пункт важен:

Аккаунт в одном из поддерживаемых ИИ-сервисов: GitHub Copilot, Anthropic Claude, OpenAI Codex или Google Gemini. GitHub-репозиторий с правами на запись. В репозитории должны быть включены GitHub Actions. На локальной машине — GitHub CLI версии 2.0.0 или новее, причём уже авторизованный.

Проверьте версию CLI командой gh --version. Если нужна авторизация, выполните:

# Вход в GitHub CLI с двумя областями видимости, # которые нужны agentic workflows: доступ к репозиторию и управление workflow gh auth login --scopes repo,workflow

После этого установите расширение, которое компилирует Markdown в YAML:

# Установка расширения gh-aw в ваш GitHub CLI gh extension install github/gh-aw

Если у вас GitHub CLI 2.90.0 или новее, при первом вызове любой команды gh aw вам автоматически предложат установить расширение, так что ошибка «расширение не найдено» не застанет врасплох.

Настройка аутентификации

Это шаг, на котором спотыкаются почти все новички, поэтому разберём его подробно.

Если вы используете GitHub Copilot в репозитории, принадлежащем организации с тарифом Copilot, вам нужен встроенный подход с GITHUB_TOKEN. Он сразу спишет расходы на организацию и избавит от необходимости хранить персональный токен (PAT) в секретах репозитория. Администратор организации должен предварительно включить политику «Allow use of Copilot CLI billed to the organization» в настройках Copilot. После этого в заголовке workflow-а достаточно указать:

permissions: contents: read copilot-requests: write # списывает использование Copilot на организацию, а не на личный токен

Это недавнее изменение, о котором стоит упомянуть отдельно: начиная с того же релиза от 11 июня 2026 года, GitHub Agentic Workflows больше не требуют PAT для этого сценария. Более ранние руководства, написанные в феврале 2026 года, описывали создание fine-grained PAT с правами Copilot Requests и добавление его как секрета COPILOT_GITHUB_TOKEN. Для личных репозиториев или сторонних движков вроде Claude или Codex такой способ по-прежнему возможен, но при использовании Copilot в организационном репозитории все танцы с токенами можно пропустить.

Если вам всё же нужно хранить секрет (личные репозитории, Claude, Codex), добавьте его один раз через секреты Actions в интерфейсе GitHub или командой gh aw secrets set из CLI.

Пишем первый workflow

Давайте создадим что-то действительно полезное для реального репозитория: агент, который при появлении новой задачи сразу классифицирует её, навешивает метки и оставляет короткий осмысленный ответ.

Можно написать файл вручную, но лучше поручить шаблон вашему ИИ-помощнику. Выполните один раз на репозиторий:

# Добавляет в репозиторий навыки, инструкции и вспомогательного агента, # чтобы любой ваш ИИ-ассистент в дальнейшем понимал, # как правильно создавать и редактировать agentic workflows gh aw init

Затем, находясь в среде вашего ИИ-помощника (подойдёт Copilot CLI или режим агента в VS Code), дайте запрос вроде: «создай новый workflow для сортировки новых issues, классифицируй их по типу и приоритету, примени метки и оставь комментарий-подтверждение». Агент сам создаст файл и скомпилирует его.

Однако полезно прочитать и понять, что в итоге получилось. Вот рукописная версия, которую можно поместить в .github/workflows/issue-triage.md:

--- description: Классификация новых задач, навешивание меток и короткий ответ on: issues: types: [opened] # срабатывает только при создании новой задачи permissions: contents: read # агент может читать содержимое репозитория для контекста issues: read # агент может читать саму задачу network: defaults # исходящий трафик ограничен стандартным списком разрешённых адресов tools: github: toolsets: [issues] # доступны только инструменты GitHub для работы с задачами safe-outputs: add-label: max: 3 # не более трёх меток за один запуск add-comment: max: 1 # ровно один комментарий-подтверждение, не больше --- # Агент сортировки задач Когда открывается новая задача, прочитай её заголовок, текст и любые вложенные фрагменты кода. Классифицируй задачу как: bug, feature request, question или documentation gap. Оцени приоритет как critical, high, medium или low, исходя из того, насколько сильно задача затрагивает систему и блокирует ли других пользователей. Примени метки, отражающие тип и приоритет. Оставь один короткий комментарий с благодарностью автору, изложением классификации простым языком и сообщением, что мейнтейнер свяжется с ним, если приоритет high или выше. Уложи комментарий в четыре предложения. Не рассуждай о возможном исправлении. Только подтверди и направь.

Что этот файл делает построчно: Блок on означает, что workflow запускается только при создании новой задачи, а не при редактировании или комментировании — это дёшево и предсказуемо. permissions намеренно заужены — только чтение содержимого репозитория и самих задач — потому что задача агента наблюдать и классифицировать, а не менять что-либо напрямую. network: defaults ограничивает исходящие вызовы стандартным разрешённым списком GitHub, не открывая контейнер в интернет. Блок tools ещё больше сужает доступную агенту поверхность GitHub API, так что он не сможет, скажем, просматривать пул-реквесты, когда ему нужны только данные задач. Блок safe-outputs — это тот самый контур доверия, о котором говорилось выше: агент может предложить не более трёх меток и ровно один комментарий, и ничего другого, что бы он ни решил сделать в процессе работы.

Сохраните файл и скомпилируйте:

# Читает Markdown-файл и генерирует реальный YAML для GitHub Actions # (issue-triage.lock.yml), который и будет исполняться gh aw compile

Закоммитьте оба файла: .md и сгенерированный .lock.yml. Да, оба идут в систему контроля версий. Markdown — ваш источник истины, а lock-файл — то, что исполняет Actions, примерно как package-lock.json рядом с package.json.

Запушьте, откройте тестовую задачу и смотрите на вкладку Actions. Или запустите вручную, не дожидаясь настоящего события:

# Ручной запуск workflow-а по имени; удобно для тестирования # до того, как положиться на реальный триггер gh aw run issue-triage

Все поля заголовка (frontmatter)

В примере выше использовалась лишь часть доступных полей, но перед тем как писать собственные workflow-ы с нуля, полезно знать полную картину.

Полный справочник находится в документации gh-aw по frontmatter — его стоит добавить в закладки, когда начнёте создавать workflow-ы с более чем одним триггером.

Популярные шаблоны

GitHub документирует более восемнадцати повторяющихся шаблонов проектирования для таких workflow-ов, и большинство реальных сценариев группируются вокруг нескольких из них.

1. IssueOps — именно то, что показано в примере сортировки: агент реагирует на события задач и управляет их жизненным циклом.
2. DailyOps или WeeklyOps — запуск по расписанию, а не по событию; формирование дайджестов, отчётов или проверок здоровья. В собственной документации GitHub описан пример еженедельного отчёта: агент просматривает активность по задачам за семь дней и открывает одну сводную задачу с общими цифрами, повторяющимися темами и коротким списком моментов, требующих внимания — с помощью триггера schedule и безопасного вывода create-issue с лимитом одна задача за запуск.
3. ChatOps — реакция на комментарии или упоминания; мейнтейнер пишет что-то вроде «@bot summarize this thread» прямо в задаче или PR и получает структурированный ответ.
4. BatchOps — обработка сразу множества элементов по расписанию: например, сканирование всех открытых PR на обновление зависимостей на предмет конфликтов слияния или пометка устаревших задач по всему репозиторию за один проход.

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

Переиспользование готовых workflow-ов

Не обязательно каждый раз начинать с чистого листа. Команда GitHub Next ведёт публичный каталог agentics с готовыми workflow-ами для сортировки, проверок соответствия, отчётности и многого другого. Можно импортировать их напрямую в свой репозиторий:

# Импорт готового workflow из публичного каталога GitHub Next # с интерактивной настройкой под ваши параметры gh aw add-wizard githubnext/agentics/daily-repo-status

Для неинтерактивной настройки команда gh aw add делает то же самое и позволяет зафиксировать конкретную версию. При импорте таким образом CLI записывает в заголовок поле source:, по которому в дальнейшем gh aw update сможет подтягивать изменения из источника.

Два важных предостережения. Во-первых, импортируйте workflow-ы только из источников, которым доверяете и которые вы проверили: вы фактически даёте ИИ-агенту определённый, но реальный доступ к вашему репозиторию на основе чужих инструкций. Во-вторых, workflow-ы, помеченные в исходном репозитории как private: true, вообще нельзя импортировать куда-либо ещё, так что не рассчитывайте, что любой внутренний каталог workflow-ов вашей команды будет пригоден для повторного использования за её пределами.

Что пока действительно сыровато

Было бы нечестно писать руководство по публичному превью и делать вид, что всё отшлифовано. Несколько моментов стоит знать заранее — они основаны на реальном опыте разработчиков, запускавших agentic workflows в репозиториях, близких к продакшену, включая подробный отчёт разработчика Hector Flores, документирующий четыре созданных им workflow-а.

Отладка местами остаётся непрозрачной. Если агент классифицировал задачу не так, как вы ожидали, единственным окном в причины будут стандартные логи GitHub Actions, а не структурированное объяснение решения. Пока с этим можно жить, но опытные пользователи просят именно это в первую очередь.

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

Шаг компиляции в .lock.yml ощущается как временное решение. Он работает надёжно, но двухфайловая схема (Markdown-источник и сгенерированный lock-файл) выглядит так, будто в будущем компиляция станет встроенной в платформу: вы пушите .md, а GitHub компилирует его нативно, без отдельной команды в CLI.

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

Сравнение с другими Copilot-инструментами

Легко спутать Agentic Workflows с другими решениями GitHub под брендом Copilot, поэтому вот краткое сравнение.

Эти три вещи не заменяют друг друга. В здоровой среде обычно работают все три сразу: Custom Actions для детерминированных проверок вроде линтинга и тестов, облачный агент Copilot для конкретной задачи по разработке фичи и Agentic Workflows для повторяющихся оценочных решений, которые не вписываются в жёсткое правило, но и не требуют участия человека при каждом запуске.

Заключительные мысли

Самый полезный способ думать о GitHub Agentic Workflows — не как о «ИИ теперь пишет за меня YAML», а как о возможности наконец закодировать оценочные суждения в автоматизацию, а не только правила. Традиционный Action может обеспечить «каждый PR, затрагивающий src/auth/, требует проверки безопасности». Агентский workflow может действовать по принципу «отметь всё, что выглядит подозрительно с точки зрения безопасности, и направь соответствующим образом» — а это качественно иная и более сложная задача, которая раньше требовала участия человека каждый раз.

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

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