Když jeden AI asistent přestane stačit

Co si z agentických týmů Katy Šrámkové můžeme vzít i mimo vývoj softwaru: orchestrátor, mikroagenti, nezávislá kontrola a příklad tvorby kurzu.

Na Meetupu #2 ukázala Katy Šrámková systém, který si postupně vytvořila při vývoji aplikací: orchestrátor, úzce zaměření mikroagenti a samostatná vrstva kontroly.

Ten systém řeší velmi obyčejný problém: jak rozdělit složitější práci tak, aby se chyby nepřenášely dál bez kontroly.

← Celé shrnutí Meetupu #2

Proč vůbec práci rozdělovat

Katy začala jednoduchým příkladem. Vezmete záznam přednášky a necháte AI udělat přepis. Už v něm budou chyby. Z přepisu necháte udělat shrnutí a ze shrnutí další výstup. Každý krok pracuje s tím, co mu předal ten předchozí – včetně jeho chyb.

Na slidu to ukázala na modelu: každý krok znehodnotí náhodných 15 % obsahu.

Zrádné je, že takový výstup často vypadá skvěle. Je pěkně naformátovaný, detailní, má zdroje. Právě proto mu podle Katy nestačí věřit jen proto, že vypadá dobře – je potřeba ho ověřovat.

K rozdělování práce ji dovedla ještě jedna zkušenost: jeden agent, který na úkolu pracuje dlouho, postupně ztrácí kontext a začíná si vymýšlet.

Jeden drží celek. Ostatní dostávají menší práci.

V Katyině systému existuje jeden orchestrátor. S ním Katy mluví – s ostatními agenty přímo ne. Orchestrátor si sám spouští subagenty, zadává jim práci a sbírá výsledky. Agenti mezi sebou komunikují přes orchestrátor, ne bokem či napřímo mezi sebou.

Jedno rozhodnutí se ukázalo jako zásadní: co orchestrátor subagentům předá. Když jim Katy nechávala předávat i jeho paměť, začali si zadání vykládat příliš volně. Teď dostávají jen instrukce – ve formě promptu a pravidel.

Mikroagent je Katyin vlastní pojem. Její mikroagenti mají opravdu malý záběr: jako kdyby při výrobě halenky například jeden uměl jen rozpoznat materiál, druhý barvu a třetí stříhat. Díky tomu se nemají kam odchýlit a ten, kdo určuje barvu, nezačne dělat něco jiného.

V prezentaci Katy zmínila i praktické nastavení: agent musí umět ukládat soubory, spouštět a instalovat nástroje a pracovat ve smyčkách, tedy bez toho, aby u každého kroku čekal na člověka. Orchestrátor u ní běží se středním reasoningem a subagentům volí úroveň podle toho, co potřebují. Maximální úroveň na všechno podle její zkušenosti smysl nedávala.

Agent, který něco vytvořil, nemusí být ten, kdo to schválí.

Jádro Katyina systému je na slidu „Vývoj softwaru s agentickým týmem“: jeden orchestrátor, specializovaná implementace, nezávislé ověření.

Úkoly má Katy u složitější aplikace v GitHub Issues: orchestrátoru stačí říct, ať si vezme konkrétní požadavek, a celý tým pracuje na něm. U jednodušších projektů používá textový soubor se seznamem požadavků, které orchestrátor zpracovává jeden po druhém. Funkční mikroagenti změnu udělají, a když se shodnou, že je hotová, orchestrátor spustí verifikátory.

A přiznala i to, co se do schémat obvykle nevejde: nejvíc času jí zabírá vlastní testování výsledku.

Některé kontroly potřebují projít napříč celým výsledkem.

Verifikační agenty Katy dělí do tří skupin. Každá odpovídá na jinou otázku:

Do funkční verifikace patří i negativní testy: neověřit jen, že výsledek dělá, co má, ale i že nedělá, co nemá. Katy to ilustrovala příkladem z praxe. Zadání říkalo, že k citlivým reportům má mít přístup určitá skupina manažerů. Testovalo se, že přístup má. Netestovalo se, že ho nemá nikdo jiný – a kvůli chybě ho nakonec dostal skoro každý.

Cross-verifikace je další Katyina vlastní kategorie. Funkční mikroagenti vlastní každý jednu oblast aplikace, například přihlášení, první nastavení, úkoly nebo připomínky. Cross-verifikační mikroagenti procházejí napříč všemi oblastmi, ale každý hlídá jen svou jednu věc:

• ovládání a přístupnost: dá se to snadno používat?
• jazyk a formáty: jsou texty a údaje srozumitelné?
• bezpečnost a chyby: chráníme data i při selhání?
• shoda dat: rozumí si aplikace a server?

Proč je to potřeba, ukázala na tlačítkách. Agenti vytvoří tlačítko, pak další a další, a každé je trochu jiné. Když pak chcete změnit barvu všech tlačítek, změní se jedno, protože nepoužívají sdílenou komponentu. Takovou chybu najde jen kontrola, která se dívá napříč.

Obecný princip

Katyina prezentace sama končí posunem od vývoje softwaru k „Obecnému principu – aneb jak to aplikovat na jiný druh úloh“. Má tři kroky:

A jedna poznámka ze slidu, která se snadno přehlédne: už samotná analýza může být zpracovaná pomocí tohoto principu.

Jak by mohl stejný princip vypadat při tvorbě kurzu

A tady mě to začalo zajímat pro vlastní práci. Princip jsem si proto zkusila přeložit do procesu, který řeším já: tvorby online kurzu.

Následující příklad už není Katyin systém. Je to moje aplikace stejného principu na jiný typ práce.

Nezačala jsem týmem agentů. Nejdřív jsem měla jeden skill na komponenty do našeho LMS, potom další na aktivity, pak na research. Orchestrátor přišel ve chvíli, kdy jsem si přestala pamatovat, který skill dělá co. Dnes mám dva režimy: u nového kurzu mě orchestrátor nejdřív vyzpovídá a spustí celý tým. Když chci jen přidat jednu aktivitu, zavolá jen konkrétního agenta.

Stejně jako u Katy je nejdůležitější rozdělení rolí: kdo tvoří, kdo nezávisle kontroluje a kde rozhoduje člověk.

Nemusíš začínat týmem deseti agentů.

Pro jeden opakovaný workflow bych začala třemi otázkami: