Jak postavit AI agenta, kterému můžete věřit: 6 kroků od promptu k produkčnímu workflow

AI agenta dnes dokáže vytvořit téměř každý. Stačí prompt, model a pár minut práce.

Otázka ale zní: Jak postavit agenta, jehož výstupům můžete skutečně věřit?

Právě na to jsme se zaměřili během hackathonu v ProRocketeers. Původně jsme chtěli pracovat na našich interních projektech. Nakonec jsme ale navázali na předchozí Knowledge Sharing o Agent Workflows a rozhodli se využít celý den k tomu, abychom si stavbu AI agentů rozebrali od úplných základů.

Nechtěli jsme začít hotovým komplexním řešením. Udělali jsme přesný opak.

Pro praktickou část jsme použili open-source TypeScript framework Mastra, který je určený pro vývoj AI aplikací a agentů. Umožnil nám postupně skládat jednotlivé části agentního workflow a sledovat, co každý další krok reálně mění.

Postavili jsme nejjednoduššího možného agenta a postupně mu přidávali jednu schopnost po druhé. Každý krok měl ukázat jeden nový koncept a hlavně problém, který bez něj nedokážeme spolehlivě vyřešit.

Výsledkem bylo šest kroků od sebevědomě halucinujícího modelu až k agentovi, jehož odpovědi dokážeme technicky ověřovat.

1. Agent bez nástrojů: prompt + model

Začali jsme tím nejjednodušším.

Agent dostal pouze prompt a přístup k jazykovému modelu. Zeptali jsme se ho na pravidla vymyšlené hry.

Odpověděl okamžitě.

A špatně.

Vymyslel si pravidlo, doplnil přesvědčivě znějící vysvětlení a samozřejmě nepřidal žádný ověřitelný zdroj.

Tohle je důležitý výchozí bod pro pochopení AI agentů:

Samotný agent není žádná magická inteligentní bytost. Na začátku máme model a instrukce. Schopnosti, které od skutečného agenta očekáváme, vznikají až tím, co kolem modelu postavíme.

A první věc, kterou potřebuje, jsou nástroje.

2. Agent dostává první nástroj

Přidali jsme agentovi funkci, která dokázala vyhledávat v pravidlech hry podle klíčových slov.

Model sám rozhodoval, kdy nástroj použije, jaký dotaz mu předá a co udělá s výsledkem.

V trace jsme tak mohli přesně sledovat:

• rozhodnutí modelu použít nástroj,
• dotaz, který si vytvořil,
• volání funkce,
• její návratovou hodnotu,
• následnou odpověď uživateli.

A právě tady jsme narazili na jeden z nejzajímavějších problémů celého dne.

Zeptali jsme se:

„Můžu postavit figurku na řeku?“

Vyhledávání nic relevantního nenašlo.

Jenže pravidla tuto situaci ve skutečnosti řešila. Používala ale jiná slova, například „potok“ a „hlídka“.

Klasické hledání podle slov proto selhalo.

A to ukazuje jeden z méně viditelných problémů RAG systémů.

Největší problém nemusí být vždy halucinace.

Systém může selhat jednoduše tím, že správnou informaci nenajde.

Uživatel pak získá dojem, že dokumentace jeho situaci neřeší, přestože odpověď někde uvnitř skutečně existuje.

Navíc je potřeba počítat s další věcí: vyhledávací nástroj nemusí dostat původní otázku uživatele. Dostane dotaz, který pro něj vytvořil model.

Kvalita retrievalu je proto pro výslednou spolehlivost agenta zásadní.

3. Hledání podle významu: RAG

Ve třetím kroku jsme změnili způsob vyhledávání.

Rozhraní nástroje zůstalo stejné. Agent ho používal úplně stejně jako předtím.

Změnila se pouze jeho implementace.

Místo hledání shodných slov jsme použili embeddingy a sémantické vyhledávání, tedy hledání podle významu.

Znovu jsme položili stejnou otázku.

Tentokrát agent našel správnou část pravidel.

Pro model se přitom zdánlivě nic nezměnilo. Stále měl k dispozici stejný nástroj se stejným rozhraním.

Změnila se ale jeho kvalita.

A tím se změnila kvalita celého agenta.

Kvalita AI agenta nestojí jen na modelu nebo délce jeho instrukcí. Stojí především na kvalitě nástrojů, které mu dáme k dispozici.

4. Strukturovaný výstup: z chatbota se stává komponenta

Do této chvíle agent odpovídal textem.

To je vhodné pro chat. Méně už pro situaci, kdy chceme AI zapojit do skutečné aplikace nebo automatizovaného workflow.

Proto jsme ve čtvrtém kroku definovali přesné schéma odpovědi.

Místo libovolného odstavce začal agent vracet strukturovaný objekt.

Najednou bylo možné výstup:

• validovat,
• uložit,
• předat další části aplikace,
• automaticky testovat,
• použít jako vstup dalšího kroku workflow.

Strukturovaný výstup zároveň výrazně omezuje prostor modelu pro improvizaci.

Dobře navržené schéma často model zdisciplinuje lépe než další odstavec instrukcí v promptu.

A právě tady se z experimentálního chatbota začíná stávat skutečná softwarová komponenta.

5. Guardrail: nejlevnější obrana proti halucinaci může být obyčejný if

Dalším krokem bylo ověřování.

Agent měl odpovídat na základě dokumentace a uvádět citace. Nechtěli jsme mu ale pouze napsat:

„Nevymýšlej si citace.“

Chtěli jsme být schopni dokázat, že si je nevymyslel.

Přidali jsme proto jednoduchý guardrail napsaný klasickým kódem.

Ten ověřil, zda každá uvedená citace skutečně existuje ve zdrojovém dokumentu a zda odpovídá jeho obsahu. Pokud kontrolou neprošla, odpověď se zahodila.

Bez dalšího LLM.

Bez dalšího agenta.

Bez složitého promptu.

Jen deterministická kontrola.

V našem experimentu trvala přibližně 0,007 sekundy, zatímco samotné volání modelu přibližně 4,53 sekundy.

To dobře ilustruje důležitý princip:

Ne každý problém v AI systému potřebuje řešit další AI.

Někdy je nejspolehlivější, nejrychlejší a nejlevnější guardrail obyčejná podmínka v kódu.

6. Paměť: agent získává kontext

Posledním krokem byla paměť.

Uživatel například jednou řekl, jakou variantu hry používá. Agent si tuto informaci uložil a při dalších otázkách s ní automaticky pracoval.

Nemusel se tedy pokaždé ptát znovu.

Paměť je zdánlivě malá funkcionalita, ale právě ona mění izolované dotazy na kontinuální interakci.

Agent už nereaguje pouze na poslední prompt.

Pracuje s kontextem předchozí komunikace.

Od halucinace k ověřitelnosti

Když porovnáme první a poslední verzi našeho agenta, rozdíl není jen v počtu funkcí.

První agent odpověděl sebevědomě, i když odpověď neznal.

Poslední agent měl:

• přístup ke znalostem,
• sémantické vyhledávání,
• nástroje,
• strukturovaný výstup,
• deterministické guardraily,
• paměť.

Nejdůležitější změna ale byla jiná.

U prvního agenta jsme doufali, že si nebude vymýšlet. U posledního jsme jeho výstup ověřovali.

A přesně v tom vidíme rozdíl mezi AI demem a AI systémem, který může být součástí skutečného produktu.

Spolehlivost nevzniká tím, že model důrazněji požádáme, aby byl spolehlivý.

Musíme ji navrhnout do celého systému.

Bonus: agent nemusí pracovat jen s dokumenty

Prvních šest kroků pracovalo s informacemi, které jsme měli ve vlastní dokumentaci.

Na závěr jsme proto vyzkoušeli ještě jiný scénář: agenta napojeného na externí API.

Postavili jsme jednoduchého weather agenta využívajícího veřejné API Open-Meteo.

Jeho workflow mělo tři kroky:

město → souřadnice → předpověď → srozumitelná odpověď

Princip je ale stejný.

Model nemusí všechno vědět.

Potřebuje mít správné nástroje, umět je použít a dostat jasně definovaný prostor, ve kterém se může rozhodovat.

Agentic Engineering není o tom dát AI celý vývoj

Právě podobné experimenty jsou jedním z důvodů, proč v ProRocketeers mluvíme o Agentic Engineering.

AI agenty nevnímáme jako náhradu softwarového inženýrství.

Naopak.

Čím větší část práce svěříme AI, tím důležitější je kvalitní architektura, observabilita, testování, guardraily a jasně definovaná odpovědnost.

AI agenta dnes postavíte za pár minut.

Postavit agenta, kterému můžete věřit, je engineering. Agentic Engineering.