GitHub Copilot Dynamic Workflows: multi-agent proces v praxi

GitHub od 1. října 2026 zpřístupnil Dynamic Workflows v Copilot CLI a v aplikaci Copilot — a je to zatím nejvíc „multi-agent" věc, kterou GitHub u Copilota udělal. GitHub Copilot Dynamic Workflows totiž umožňují nadefinovat opakovatelný proces v kódu: sekvenci kroků, ve kterých střídáš běžné příkazy a nástroje s AI agenty, které běží paralelně, předávají si strukturované výsledky a zastaví se na checkpointu, kdy se máš podívat na mezivýsledek.

Pokud znáš Dynamic Workflows z Claude Code, kde jeden agent orchestruje stovky subagentů, bude ti koncept povědomý — GitHub ale přichází s vlastní variantou postavenou přímo do Copilota, bez nutnosti cokoliv instalovat. V tomto článku ti ukážu, jaký je rozdíl oproti Autopilotu a /fleet, jak první workflow vytvořit, spustit ho z terminálu nebo na schedule, a jak u toho nespálit AI kredity.

01Co jsou Dynamic Workflows v Copilotu

Dynamic Workflow je program, který definuje, jak se úkol vykoná. V kódu je nastaveno všechno: jednotlivé kroky, kdy se připojí agenti, co dostanou na vstupu a jak se použijí jejich výsledky. Kroky můžou běžět sekvenčně, paralelně nebo v kombinaci — a agenti se starají o části, které vyžadují analýzu nebo úsudek, zatímco skriptovou část (příkazy, nástroje, volání API) zvládne workflow samo.

Prakticky to znamená, že si jednou nadefinuješ například bezpečnostní revizi Javy: workflow vypíše změněné soubory, rozdělí je mezi několik agentů, nechá je hledat zranitelnosti, výsledky sloučí do jedné zprávy a na konci se zastaví, aby sis ji přešel ty. Příště stačí říct „spusť java-security-review" a běží úplně stejný proces — opakovatelnost je hlavní důvod, proč tuhle funkci vůbec používat.

Důležitá je i výměna dat mezi kroky. Agenty můžeš nechat vracet výsledky ve stanoveném formátu, aby je další fáze zvládly strojově zpracovat, a můžeš si nechat nálezy vzájemně prověřovat subagenty — dva nezávislí agenti se podívají na totéž a reportuje se jen to, na čem se shodnou. Čím víc je proces definovaný v kódu, tím méně záleží na tom, jaké modely zrovna v Copilotu vybíráš; strukturu drží workflow, ne štěstí.

Dostupnost funkce je od 1. 10. 2026 ve public preview pro všechny Copilot tarify. V aplikaci Copilot je dostupná hned bez nastavování; v Copilot CLI musíš zapnout experimentální funkce — buď spusť CLI s přepínačem --experimental, nebo v interaktivní relaci zadej /experimental on a následně /update.

02Autopilot, /fleet nebo Dynamic Workflows

Copilot má teď tři režimy práce s agenty a liší se tím, kdo plánuje a řídí průběh — ne jen počtem agentů. GitHub to rozlišuje takto:

Klíčový rozdíl: u /fleet se Copilot při každém spuštění znovu rozhoduje, jak úkol rozdělí. U Dynamic Workflow je proces definovaný předem — kroky, podmínky i předání mezi agenty. Cesta skrz kroky se může lišit podle vstupů nebo toho, co agenti najdou, ale sada kroků a pravidel zůstává stejná. Proto se hodí na věci, které děláš opakovaně a chceš u nich konzistentní výstup — to je přesně to, co jednorázový /fleet nesplní.

03Jak vytvořit první Dynamic Workflow

Workflow nemusíš psát ručně — vytvoří ti ho Copilot sám na popis v přirozeném jazyce. Postup pro Copilot CLI:

1. Zapni experimentální funkce: /experimental on (nebo spusť CLI s --experimental) a aktualizuj se přes /update.
2. Popiš Copilotovi cíl, pořadí kroků, kde má použít agenty a jaké limity má dodržet. Třeba:

Create a dynamic workflow named review-changed that lists changed files,
asks an agent to review them, and summarizes the findings.

3. Schval prompt na vytvoření (a případné následné dotazy), dokud Copilot workflow nezaregistruje. Když jméno v promptu nezadáš, vymyslí ho Copilot sám — pojmenované workflow se ale lépe spouštějí a sdílejí.
4. Ověř si ho dotazem What dynamic workflows are available? — nový workflow by měl být v seznamu. Detaily zjistíš dotazem na konkrétní jméno, třeba „Tell me more about the java-security-checks dynamic workflow."

Tip i úpravy dělej přirozeným jazykem. Update the check-python-style dynamic workflow to use no more than 10 subagents in total. úplně stačí; Copilot kód rozšíření přepíše za tebe.

Vytvoření a registrace workflow nespouští žádný běh — to je zvlášť krok. Workflow žije jako rozšíření Copilota: ty vytvořené v relaci najdeš pod ~/.copilot/session-state/<id>/extensions/<name>/extension.mjs. Když chceš vidět, jak je to postavené uvnitř, nebo chceš psát kód sám, stačí požádat: Show me the guidance for writing dynamic workflows.

04Spuštění v chatu, z terminálu a na pozadí

Nejjednodušší cesta je pořád přirozený jazyk: Run the java-security-review dynamic workflow on the java files in the current directory, with an AI credit limit of 500. Copilot se zeptá na potvrzení a pustí se do toho. Doporučený limit na kredity tam dávat buď — uvidíš proč níže.

Pro skripty a CI existuje plnohodnotný terminálový příkaz:

copilot workflow run java-security-checks \
   --args '{"directories":["java/src","java/tests"]}' \
   --allow-tool=read

Vstupy předáváš jako JSON přes --args (nebo ze souboru --args @workflow-input.json), výsledek zapisuješ přes --result-file security-results.json. Příkaz blokuje, dokud běh neskončí, takže se hodí do pipeline.

Pozor terminálový režim nezobrazuje dotazy na oprávnění — vše, co není schválené předem (třeba přes --allow-tool nebo --allow-url), se zamítne. V CI navíc nastav token (COPILOT_GITHUB_TOKEN) a pro načtení projektových rozšíření z nedůvěryčného adresáře proměnnou GITHUB_COPILOT_PROMPT_MODE_EXTENSIONS=true — jen u kódu, kterému věříš. Pro strojový záznam o běhu přidej --silent --output-format json a dostaneš jméno, ID běhu, stav i výsledek v JSONu.

Workflow jde i naplánovat: /every 1d run the changed-files-report dynamic workflow on the 'main' branch, limiting it to 200 AI credits a každý den ti poběží stejná sestava nad aktuálním mainem. Podobný princip pravidelné agentní údržby repa jsme řešili i u Claude Code napojeného na GitHub Actions — Dynamic Workflows ho zjednodušují, protože orchestraci nemusíš stavět na Actions YAML.

05Sdílení workflow v týmu

Protože je workflow soubor, sdílí se jako kód. Adresář rozšíření zkopíruj buď do ~/.copilot/extensions/ (osobní, dostupné ve všech tvých relacích), nebo do .github/extensions/ v repozitáři — pak ho po mergi a načtení rozšíření používá celý tým. Kopíruje se jen definice, ne historie běhů ani uložený progres. Pro širší distribuci můžeš workflow zabalit jako plugin a publikovat ho na marketplace.

Tohle je z pohledu týmu asi nejcennější vlastnost: proces typu „revize PR, bezpečnostní sweep nebo release checkupy" se dá jednou vyladit a pak sdílet jako standard — podobně jako si týmy sdílejí pravidla v AI coding governance, jen konkrétněji a spustitelně.

06Limity, AI kredity a kontrola nad během

Multi-agent běhy umí rychle spálit rozpočet, takže má smysl nastavit limity předem. Osobní defaulty nastavíš přes /settings:

• workflows.defaultLimits.maxConcurrentSubagents — kolik subagentů běží současně
• workflows.defaultLimits.maxTotalSubagents — kolik jich smí běž celkem použít
• workflows.defaultLimits.timeoutSeconds — strop běhu (čas na pauze se nepočítá)
• workflows.defaultLimits.maxAiCredits — přibližný strop spotřeby kreditů

Priorita je prompt > kód workflow > osobní nastavení — limit zadaný přímo v promptu vždy vyhraje. Vždycky. U kreditů počítej s tím, že jde o orientační strop, ne tvrdou zeď; jak AI kredity v Copilotu fungují a jak se připravit na přechod z přídělového modelu, jsme rozebírali v článku o AI kreditech GitHub Copilotu.

Běh monitoruješ přes /workflows v CLI (detaily běhu, aktivní čas, fáze, počty agentů i spotřebované kredity; P pozastaví, X zruší) nebo přes tlačítko Workflows v aplikaci Copilot. Pauznutý běh nebo běh zastavený limitem můžeš obnovit (R v CLI, tlačítko Resume v aplikaci) a použijí se uložené mezivýsledky — zrušený běh obnovit nejde. Každý běh a obnovení zanechá OpenTelemetry span invoke_workflow, takže to připojíš i k firemní observabilitě.

07Kde se Dynamic Workflows hodí v praxi

GitHub v dokumentaci přímo doporučuje scénáře, kde se proces v kódu vyplatí:

• Paralelní revize PR po souborech — každý agent dostane část změn, výstupy se sloučí; pro hlubší revizi s lidským schvalovacím procesem se hodí i Copilot code review se schvalováním pull requestů.
• Release checky s povinným review — workflow projde kontrolní seznam a na checkpointu se zastaví, dokud člověk neschválí pokračování.
• Sweepy nad kódovou základnou — hledání chybějících testů nebo deprecated API napříč repozitářem, opakovaně a se stejnými pravidly.
• Vyšetřování incidentů — sběr logů a telemetrie, agenti paralelně na různých systémech, výstupy sloučené do hlášení o příčině.
• Cross-model verifikace — necháš dvě věci ověřit nezávislé agenty a reportuje se jen shoda; falešně pozitivních hlášení tím výrazně ubyde.

Společný jmenovatel: opakovaný proces, kde chceš konzistentní postup a kontrolované náklady, ne jednorázovou kreativní práci. Na tu pořád stačí obyčejný agent nebo Autopilot.

08Časté otázky