Když jsem si poprvé rozklikl podrobný záznam běhu jednoho agenta, čekal jsem kód. Místo toho tam byl skoro dialog. Myšlenka, akce, výsledek. Zase myšlenka, zase akce, zase výsledek. Sedmnáctkrát za sebou.

Ten záznam mi o agentech řekl víc než všechna dema dohromady. Uvnitř totiž nesedí žádná chytrá bytost. Sedí tam jazykový model, který dokola odpovídá na jednu otázku: co teď?

Definice, která se vejde do jedné věty

AI agent je jazykový model, který dostal cíl, sadu nástrojů a povolení používat je opakovaně, dokud cíl nesplní. Tři podstatná jména v té větě dělají všechnu práci. Model rozhoduje. Nástroje dovolují sáhnout mimo text a smyčka je to, co odlišuje agenta od jednorázové odpovědi. Kdo z těch tří něco vynechá, dostane něco jiného než agenta.

Rozdíl proti běžnému chatbotu jsem podrobně rozebíral v samostatném článku o tom, kde končí odpověď a začíná čin. Přehled nástrojů, scénářů a toho, jak si agenti vedou v ostrém provozu, najdete v průvodci AI agenti a automatizace. Tady mě zajímá jen to, co je vidět v tom záznamu: co se stane při každém jednom průchodu smyčkou.

Smyčka přemýšlej a jednej, krok za krokem

Princip popsali v roce 2022 Shunyu Yao a jeho kolegové v práci nazvané ReAct, tedy Reasoning and Acting, česky zhruba uvažování a jednání. Model střídá dva druhy výstupu: úvahu o tom, co je potřeba zjistit, a akci, kterou to zjistí. Výsledek akce se mu vrátí zpátky a on podle něj uvažuje dál.

Vezměme si konkrétní zadání: „Zjisti, jestli objednávka 4471 už odešla, a když ano, napiš zákazníkovi číslo zásilky.“

Průchod první. Model dostane zadání a k němu seznam nástrojů, které smí použít. Odpoví, že potřebuje zjistit stav objednávky, a vyžádá si nástroj pro čtení objednávek s parametrem 4471.

Průchod druhý. Program kolem modelu (odborně se mu říká runtime, tedy prostředí, ve kterém agent běží) ten nástroj skutečně zavolá a výsledek vloží modelu zpátky do konverzace. Řekněme, že se vrátí stav „odesláno“ a číslo zásilky. Model se podívá a rozhodne, že teď potřebuje e-mailový nástroj. Průchod třetí. Model si vyžádá odeslání e-mailu s konkrétním textem. Runtime ho odešle a vrátí potvrzení.

Průchod čtvrtý. Model se podívá na potvrzení, usoudí, že zadání je hotové, a místo další akce napíše obyčejnou textovou odpověď. Tím smyčka končí. Podstatné je, že model sám nic nedělá. Nikam nesahá, nic neodesílá. Jen napíše, co by se mělo udělat, ve strukturované podobě, kterou runtime pozná. Veškerou skutečnou práci odvede program okolo. To je taky důvod, proč se agenti dají omezovat: stačí runtime nedat nástroj, který nechcete, aby agent použil.

Model: část, která si vybírá z nabídky

Model dostane při každém průchodu tři věci naráz. Vaše zadání. Popis všech nástrojů, které má k dispozici. A celý dosavadní průběh, tedy co už zkusil a co mu z toho vyšlo.

Na základě toho vygeneruje další krok. Žádný plán uložený stranou, žádné vědomí toho, kolikátý je to pokus. Rozhoduje se pokaždé znovu z toho, co má právě před sebou. Odtud plyne pár praktických důsledků. Slabší a levnější model dělá víc kroků a častěji se vydá špatným směrem, takže levnější model může nakonec vyjít dráž. Model s krátkým kontextem zvládne kratší úkoly. A vzhledem k tomu, že rozhodnutí generuje stejný stroj, který občas napíše nesmysl, může si i akci vymyslet. Proč se to děje, popisuju v článku o halucinacích AI.

Nástroje: model si je vybírá podle popisu

Nástroj je pro model jenom položka v seznamu. Má jméno, krátký popis, co dělá, a seznam parametrů, které od modelu očekává. Nic víc o něm model neví.

To má překvapivě velký dopad na to, jestli agent funguje, nástroj pojmenovaný get_data s popisem „vrátí data“ si model splete s kdečím. Nástroj najdi_objednavku_podle_cisla s popisem „vrátí stav a číslo zásilky pro zadané číslo objednávky, pro jiné dotazy nepoužívat“ si splete mnohem hůř.

Když ladíte agenta, který sahá po špatných nástrojích, nemá obvykle smysl vylepšovat hlavní zadání. Přepište popisy nástrojů. Bývá to nejrychlejší oprava, jakou u agentů znám. Nástrojem přitom může být skoro cokoliv: vyhledávání na webu, dotaz do databáze, odeslání zprávy, spuštění kusu kódu, ale klidně i celý jiný agent. Rozdělení práce mezi několik menších agentů se v poslední době používá čím dál častěji, protože jeden agent s třiceti nástroji si vybírá znatelně hůř než tři agenti s deseti.

Paměť: dvě různé věci pod jedním slovem

Tady vzniká nejvíc nedorozumění, protože slovo paměť se používá pro dvě věci, které spolu skoro nesouvisí. První je kontext, tedy pracovní stůl modelu. Do něj se při každém průchodu vejde zadání, popisy nástrojů a celá dosavadní historie. Kontext má pevný strop a když se naplní, nejstarší část z něj vypadne. Agent v takové chvíli zapomene, co dělal na začátku úkolu, a klidně zopakuje krok, který už jednou udělal. Jak kontextové okno funguje a proč se plní rychleji, než by člověk čekal, jsem rozebíral zvlášť v článku Kontextové okno.

Druhá je trvalá paměť, tedy poznámkový blok mimo model. Zápisky do databáze, uložené preference zákazníka, textový soubor s pravidly firmy. Agent si do ní zapisuje a při dalším běhu z ní čte. Bez ní začíná každý běh úplně od nuly.

Rozdíl je vidět na nástrojích.

Automatizační platforma n8n má pro chatovou historii uzel nazvaný Simple Memory, který si drží posledních několik výměn podle takzvaného klíče relace. V dokumentaci k němu ale výslovně varuje, že se nehodí pro provoz s více pracovními procesy, protože nezaručí, že další zpráva dorazí na stejný proces jako ta předchozí. Pro trvalejší uložení nabízí uzly napojené na databáze, třeba na Postgres nebo Redis. To rozdělení je typické: krátká paměť je snadná a křehká, dlouhá paměť potřebuje databázi.

Jedna věc do těchhle dvou kategorií nepatří, i když se za paměť často vydává. Agent se z opravených chyb neučí. Když mu dnes řeknete, že objednávky nad sto tisíc chodí přes paní Novákovou, zítra to bude vědět jedině tehdy, když si to někam zapsal nebo když mu to někdo natrvalo napsal do instrukcí. Samotný model zůstává po celou dobu úplně stejný.

Čtvrtý díl, na který se zapomíná: instrukce

Model, nástroje a paměť se vyjmenují v každém návodu. Čtvrtá součástka se vyjmenuje málokdy, přitom ji píšete vy a rozhoduje o výsledku nejvíc. Jsou to trvalé instrukce, které agent dostane před každým jedním průchodem. Kdo je, co má za úkol, čeho se nemá dotýkat, kdy má práci předat člověku. V různých nástrojích se tomu říká systémový prompt, role nebo prostě instrukce, funguje to ale všude stejně: text se přilepí na začátek a model ho vidí pokaždé znovu.

Dobré instrukce popisují hlavně hranice. Ne „buď nápomocný“, ale „když číslo objednávky nenajdeš ve dvou pokusech, napiš to a skonči“. Ne „piš zdvořile“, ale „u reklamací nad pět tisíc korun nikdy neslibuj vrácení peněz, jen předej případ podpoře“. Model potřebuje vědět, co dělat v situacích, které nevyšly, protože právě ty tvoří většinu problémů.

Souvisí s tím i rozdíl mezi dvěma povahami agentů. Jeden si na začátku sepíše plán a pak ho odpracovává. Druhý žádný plán nemá a reaguje krok po kroku. Plánující agent zvládne delší úkoly, ale hůř se přizpůsobí, když se okolnosti změní. Reagující agent se přizpůsobí snadno, zato se snáz ztratí. Který z nich máte před sebou, poznáte právě ze záznamu kroků: buď je na začátku seznam, nebo není.

Kdy se smyčka zastaví

Agent končí ze čtyř různých důvodů a rozeznat je od sebe se hodí, protože každý znamená něco jiného.

Model usoudí, že je hotovo, a místo akce napíše odpověď. To je ten správný konec. Dojde limit kroků. Každý slušně postavený agent má strop, obvykle deset až padesát průchodů. Když ho vyčerpá, práci utne uprostřed. Vypadá to jako hotový výsledek, ale hotový není.

Narazí na chybu, kterou nejde obejít. Nástroj vrátí, že přístup byl zamítnut, a agent nemá jak si ho obstarat.

Nebo si vyžádá akci, která vyžaduje lidské potvrzení, a čeká. To u citlivých kroků chcete. Praktický důsledek: když agent skončí, dívejte se, čím skončil. Utnutý běh po vyčerpání limitu vypadá na první pohled stejně jako úspěch.

Proč se agent zacyklí

Nejčastější porucha, na kterou u agentů narazíte, není chybná odpověď. Je to kolečko. Agent zavolá nástroj, dostane nic, zavolá ho znovu se skoro stejným parametrem, dostane zase nic, a takhle patnáctkrát, dokud nedojde limit. Důvod je v tom, jak se rozhoduje. Model při každém průchodu vidí historii, ve které předchozí pokus vypadá rozumně, tak zkusí drobnou obměnu. Neumí říct „tudy cesta nevede, potřebuju jiný nástroj“, pokud ho k tomu nikdo nenavedl.

Pomáhají tři věci. Nástroj má vracet srozumitelnou chybu („objednávka s tímhle číslem neexistuje“) místo prázdné odpovědi. V zadání má být napsané, co dělat, když informace nejde najít. A limit kroků má být nastavený tak nízko, aby vás kolečko nestálo celý měsíční kredit.

Na co si dát pozor

Než agentovi něco svěříte, projděte si jeho seznam nástrojů a škrtněte všechno, co pro daný úkol nepotřebuje. Model si vybírá z toho, co vidí, a nástroj, který v seznamu není, nepoužije.

Podívejte se, jestli má nástroj krok, který nejde vzít zpět. Odeslání, platba, smazání. U takových kroků se vyplatí nechat si potvrzení, i za cenu, že agent nedoběhne sám.

Počítejte s tím, že delší běh stojí víc, než vypadá. Do každého dalšího průchodu jde celá dosavadní historie znovu, takže dvacátý krok je dražší než první, u agentů se cena nesčítá lineárně. A když ladíte, čtěte záznam kroků odshora, ne odspodu. Chyba, kterou vidíte na konci, obvykle vznikla o osm průchodů dřív.

Sedmnáct otázek za sebou

Ten můj záznam se sedmnácti průchody nakonec skončil správně. Když jsem si ho pročetl podruhé, došlo mi, že agent v něm třikrát zkusil totéž jinými slovy a jednou si vymyslel číslo, které si o dva kroky později sám opravil. Vypadá to jako přemýšlení. Zblízka je to spíš vytrvalost. Model si při každém průchodu klade stejnou otázku, co teď, a je mu úplně jedno, že ji dnes položil už posedmnácté.

Což je vlastně dobrá zpráva. Vytrvalost se dá řídit. Stačí vědět, kolik kroků povolíte, jaké nástroje dáte na stůl a co se stane, když si agent řekne o osmnáctý pokus.