Агентні воркфлоу GitHub вийшли в GA
GitHub Agentic Workflows від GitHub Next (open source) вийшли в GA для Free, Team і Enterprise. Задачу (тріаж issues, розбір падінь CI, оновлення доків, тести) описуєте в Markdown, а інструмент компілює її у звичайний YAML для Actions з вашими раннерами й політиками. Рушій — Copilot або власний агент.
За замовчуванням агент має read-only права й працює в sandbox-контейнері за Agent Workflow Firewall. Зміни проходять safe outputs і окремий job threat detection. Нове після превʼю: ARC-раннери з Docker-in-Docker, ізоляція в micro-VM, роутинг моделей.
Як це влаштовано і з чого почати
Workflow описуєте у Markdown природною мовою, а GitHub Agentic Workflows компілює його у стандартний YAML для GitHub Actions. Це звичайні Actions, тому працюють ваші наявні групи раннерів і політики обмежень, окрема інфраструктура під агентів не потрібна. Рушій обирається для кожного workflow окремо: GitHub Copilot або власний coding agent. Після GA для кожного workflow можна окремо вибрати й провайдера моделей. Є також model router, який підбирає модель під тип і складність задачі.
Старт такий: за quickstart ставите CLI-розширення і запускаєте перший workflow. Писати з нуля не обов'язково. У репозиторії agentics від GitHub Next є готові workflow для тріажу, керування залежностями, code review і звітності. Нові шаблони додаються командою gh aw add-wizard.
Що кажуть про результати і як це читати
У блозі GitHub наведено цитату Ben Alton, senior manager в Accenture. За його словами, один із лідів заощадив орієнтовно 29 годин на тиждень лише на власній розробці. У його команді виміряна швидкість у середньому зросла більш ніж удвічі, ШІ є автором 91% комітів, а помилки в продакшні скоротилися приблизно з 11 000 на день до менш ніж 1 000. Він також описує сценарії. Один workflow веде фічу від вимог до реалізації з доказами валідації. Інші підтримують фреймворки актуальними і поступово піднімають якість коду та покриття тестами. Інженери при цьому ведуть паралельно чотири-п'ять напрямів.
Це досвід однієї команди одного клієнта, а не бенчмарк GitHub. Для власного пілоту візьміть вузьку задачу, наприклад тріаж issues чи розбір падіння CI, і міряйте результат на своєму репозиторії.
Шари захисту і де вони вам потрібні
- доступ до контенту GitHub з дотриманням правил integrity filter;
- за замовчуванням лише read-only права;
- виконання в sandbox-контейнері за Agent Workflow Firewall;
- результати проходять процес safe outputs;
- окремий job threat detection сканує всі запропоновані зміни до того, як їх застосують.
Для жорсткішої ізоляції агентів можна запускати в micro-VM: Cloud Hypervisor або NVX. Якщо workflow працює з кількома репозиторіями, від витоку даних між ними захищають enclaves. Про це варто подумати до запуску крос-репо сценарію, а не після. Тепер підтримуються й self-hosted ARC-раннери з Docker-in-Docker, тож агентів можна тримати на власній інфраструктурі.
Що перевірити, перш ніж вмикати на постійно
- Ліцензія. Типовий рушій — GitHub Copilot CLI, і для нього потрібна ліцензія Copilot. Без неї лишається власний агент.
- Бюджет. Запустіть
gh aw forecast. Команда вийшла з експериментального статусу і тепер показує місячні діапазони витрат AI-кредитів разом із кредитами на threat detection. Перевірка змін теж коштує кредитів. - Права. Read-only — це дефолт. Кожне розширення прав робіть свідомо і фіксуйте в рев'ю workflow.
- Скомпільований YAML. На виході звичайний Actions-файл. Перед мерджем читайте його, як будь-який інший workflow.
Повний список змін є в release notes. Ціни AI-кредитів у матеріалі не наведено.