Většina týmů zabývajících se AI sahá při snaze zlepšit výkon agentů po stejných nástrojích: větších kontextových oknech, větším množství dokumentů a chytřejších promptech. Tento článek tvrdí, že je to zcela mylný instinkt. Chybějící přísadou není více informací. Je jí řízení. Dobře navržená řídicí vrstva odlišuje agenta, který funguje v ukázce, od agenta, který obstojí v produkci.
Větší paměť, více dokumentů ani delší kontextové okno neudělají agenta AI chytřejším, pouze ho zpomalí a prodraží. Skutečné zlepšení přichází, když se agent naučí vybírat, co a kdy potřebuje, místo aby zpracovával vše najednou.
Spolehlivost vychází ze smyčky, nikoli z modelu. Rozdíl mezi agentem, který zaujme v ukázce, a agentem, který obstojí v produkci, nespočívá v kvalitě AI, ale v tom, zda systém kontroluje vlastní práci. Agenti, kteří v každém kroku plánují, jednají, pozorují a ověřují, zachytí vlastní chyby, místo aby sebejistě podávali nesprávné výsledky.
Většina dnešních agentů AI jsou v zásadě chatboty s několika kroky navíc. Nemají žádný mechanismus, který by jim umožnil poznat, zda postupují správně, kdy mají skončit nebo kdy mají zkusit jiný přístup. Teprve přidání správné řídicí vrstvy – jasných kritérií úspěchu, strukturovaného stavu a validačních kontrol – promění objekt ve tvaru agenta v něco, čemu lze skutečně důvěřovat.
Co jste měli včera k obědu?
Nejspíš jste si nepřehrávali každou vzpomínku, kterou jste kdy měli, dokud jste nenarazili na „včera + oběd“. Přešli jste rovnou k části své zkušenosti, kde se tyto pojmy nacházejí. To je užitečný mentální model pro tvorbu agentů:
Obrovské kontextové okno není paměť.
Hromada načtených dokumentů není porozumění.
Dlouhý myšlenkový řetězec není spolehlivost.
To jsou jen přísady. To, díky čemu agent působí jako agent, je totéž, díky čemu váš mozek nemusí hrubou silou procházet celý váš život: řízení.
Nedávná studie Agentic Reasoning for Large Language Models výborně shrnula a pojmenovala změnu, kterou mnozí z nás při vývoji vnímají: přechod od uvažování uvnitř modelu k uvažování prostřednictvím interakce. Tento článek není shrnutím dané studie. Snaží se tuto změnu převést do praktického návrhu systémů:
Pokud agenty vytváříte jako chatboty s nástroji, budete se dál setkávat se selháními chatbotů, jen budou chyby dražší.
Náš obvyklý recept na „chytřejší model“ dlouho spočíval hlavně v lepších promptech, myšlenkovém řetězci, zlepšeních pomocí sebekonzistence či vzorkování a možná také ve vyhledávání.
ReAct představoval zásadní zlom, protože díky němu začala posloupnost „myšlenka → akce → pozorování“ působit přirozeně. Všimněte si však skrytého omezení: mnoho z toho stále končí jako „inference na jednom příkladu, jen s více tokeny“. Studie nabízí přesnější rámec: agentní uvažování zdůrazňuje škálování interakce během testování a mění inferenci v iterativní proces, v jehož smyčce zůstávají model, paměť i prostředí.
Pokud jste vytvářeli nebo používali agenty, kteří působí působivě v ukázkách, ale ve skutečných pracovních postupech jsou křehcí, je tento článek určen vám.
Popíšu vám vzorec, který vídám často a jehož varianty jsem rozhodně sám vytvářel:
Vezměte dobrý chatovací model
Přidejte několik nástrojů (vyhledávání, dotazy do databáze, případně spouštění kódu)
Přidejte RAG
Přidejte systémový prompt „jste autonomní agent“
Vše zabalte do smyčky while, která běží, dokud se nezastaví nebo nevyprší časový limit
Gratulujeme, máte objekt ve tvaru agenta. Ten však obvykle selhává předvídatelnými způsoby:
Bujení kontextu: připojuje se každé pozorování a z promptů se stávají archeologické vrstvy.
Bezradné zkoušení nástrojů: výchozím způsobem selhání se stává „sebejistě použít nesprávný nástroj“.
Žádné podmínky ukončení: pokračuje, protože může, nikoli protože by měl.
Žádná disciplína ukotvení: pokud ho nedonutíte, nevšimne si, že se mýlí.
Paměť = historie chatu: což je v podstatě zapisování protokolů vydávané za učení.
Proto „agenti“ často působí v ukázkách kouzelně, ale v produkci chaoticky. Potvrzují to i naše zkušenosti s nasazováním agentních systémů do produkce: jakmile už nehodnotíte model, ale systém, mezi způsoby selhání patří navigace, správné používání nástrojů, prořezávání kontextu a návrh hodnocení, nejen otázka, zda model odpověděl správně.
Otázka tedy zní: jak vypadá záměrně navržený agent?
Aby to nebylo tak abstraktní, zde je jednoduchý pracovní postup, který si většina lidí dokáže představit: “Book me a flight from London to New York next Tuesday. Arrive before 6pm. Keep it under £900. Aisle seat.”
Běžná implementace „ve tvaru agenta“ vypadá takto:
Okamžitě načte množství dokumentů s pravidly leteckých společností a cestování, i když zatím žádné nepotřebuje.
Zavolá vyhledávací nástroj, vloží dlouhý seznam výsledků do promptu a „jeden vybere“.
Provede rezervaci předčasně, aniž by ověřil omezení týkající se času příletu, zavazadel, sedadla či pravidel.
Pokud neuspěje, zkusí to znovu trochu jinak, ale bez jasného povědomí o tom, co se změnilo nebo co se naučil.
Problém nespočívá v tom, že by model neuměl uvažovat, ale v tom, že systém pracovní postup neřídí.
Agentnější verze přistupuje k úloze jako k interaktivnímu procesu s explicitním stavem a kontrolami:
PLÁNOVAT: zopakovat omezení a vyjmenovat chybějící informace (např. „které letiště preferujete?“ nebo „může let zahrnovat jedno mezipřistání?“).
JEDNAT: zavolat vyhledávání letů pomocí strukturovaného dotazu (časové rozpětí, omezení příletu, rozpočet).
POZOROVAT: uložit výsledky do kompaktního stavového objektu (pět nejlepších možností s cenou, příletem a přestupy), nikoli jako obrovský vložený blok.
AKTUALIZOVAT: pokud omezení nejsou splněna, upravit dotaz (např. „přílet před 18. hodinou je příliš přísný požadavek – rozšířit časové rozpětí, nebo zvýšit rozpočet?“).
OVĚŘIT: spustit validátory („přílet < 18:00“, „cena ≤ 900 £“, „v souladu s pravidly“, „výběr sedadla je k dispozici“).
SKONČIT: až když rezervační API vrátí potvrzení a všechny validátory uspějí.
Změna je nenápadná, ale rozhodující. Načítání je podmíněné, nikoli reflexivní; kontext se spravuje, takže stav je strukturovaný, nikoli pouze hromaděný; a ověřování je součástí smyčky, místo aby zůstalo na uživateli. Nahraďte „rezervaci letu“ výrazem „vytvoření nákupní objednávky“, „vrácení peněz“, „změna produkční konfigurace“ nebo „nasazení pull requestu“ a princip zůstane stejný: jakmile může agent jednat, záleží na smyčce více než na promptu.
Výše zmíněná studie člení agentní uvažování do tří vrstev: základní (plánování, používání nástrojů a vyhledávání), samostatně se vyvíjející (zpětná vazba a paměť) a kolektivní (koordinace více agentů).
Hlubší myšlenka však zní: uvažování se stává organizačním principem plánování, rozhodování a ověřování, nikoli jen generováním věrohodného myšlenkového řetězce. Zní to abstraktně, dokud si neukážete, co se ve vaší architektuře změní. Je třeba pamatovat na tři hlavní body:
Dobrý agent by neměl k načítání přistupovat jako k něčemu, co se dělá vždy. Načítání je rozhodnutí, nikoli reflex.
Praktické vodítko:
Pokud váš systém načítá data v každém tahu, nevytvořili jste načítání, ale daň z kontextu.
V praxi se s tím setkáváme neustále. Při ladění produkčního incidentu nevložíte do kontextu všechny protokoly. Podle aktuální hypotézy rozhodnete, které metriky či protokoly načíst jako další. To je „agentní načítání“. Konkrétnější postup vypadá takto:
Rozhodnout, zda potřebujete něco načíst
Pokud ano: sestavit dotaz, načíst, projít a získat podstatné informace
Pokud si důkazy odporují: načíst další
Teprve potom vše spojit
Právě zde se také „agentní RAG“ začíná lišit od tradičního RAG: načítání se stává záměrným krokem uvažování, nikoli výchozí fází procesu.
Jakmile přestanete hodnotit „model“ a začnete hodnotit „systém“, začne záležet na sledování stavu a trasování.
Jednou z věcí, které už odvětví řeší otevřeněji, je pozorovatelnost pracovních postupů agentů. Například sada Agents SDK od OpenAI obsahuje integrované trasování a řídicí panel Traces, který zaznamenává běhy agentů (generování, volání nástrojů, předávání úloh, ochranná pravidla a vlastní události), abyste mohli krok za krokem ladit a auditovat, co se stalo.
To není něco, co je jen „dobré mít“. Je to rozdíl mezi systémem, který můžete ladit, a systémem, u něhož můžete jen odhadovat, zda funguje správně.
Nejpraktičtější částí studie je podle mě její přímočarý přístup ke zpětné vazbě. Rozlišuje tři režimy: reflexivní zpětnou vazbu (vygenerovat → posoudit → upravit), parametrickou adaptaci (učení pomocí dolaďování či RL) a zpětnou vazbu řízenou validátorem (opakovat pokus, dokud neprojde validací).
Většina týmů by měla začít se zpětnou vazbou řízenou validátorem, protože je sice nezajímavá, ale účinná. Pokud dokážete napsat jakýkoli validátor, který provádí jednotkové testy, kontroluje schéma, stanovuje obchodní pravidla či omezení („bez eskalace nevracet částky nad X“) nebo ověřuje faktickou správnost („vyžadují se citace“), můžete z nedeterministického výstupu modelu vytvořit něco, čemu lze skutečně důvěřovat.
Jedna z dříve netušených změn je prostá: ve světě agentů spolehlivost často vychází spíše ze smyčky než z modelu.
Toto je nejjednodušší disciplinovaný postup ve smyčce, který podle mých zkušeností spolehlivě zlepšuje chování bez trénování:
Postupujte po krocích: Plánovat → Jednat → Pozorovat → Aktualizovat,
po každé akci shrňte pozorování do 1–3 bodů,
skončete po splnění kritérií úspěchu nebo vyčerpání rozpočtu; vraťte nejlepší známý výsledek a zbývající nejistoty.
Nejde o to, aby byl model upovídaný. Jde o to, aby byl systém srozumitelný a v každém kroku se musel konfrontovat s realitou. Příkladem blízkým technikům je ukotvení v uzavřené smyčce na způsob CI:
Plánovat: navrhnout seznam změn
Jednat: spustit testy a lintování
Pozorovat: analyzovat selhání
Aktualizovat: opravit a zkusit znovu
Několik otázek, které často odhalí návrhy agentů vzniklé bez jasného záměru:
„Rozhoduje můj agent, co má načíst, nebo vždy načítám všechno?“
Pokud se načítání provádí bezpodmínečně, zaplatíte za to delší odezvou, vyššími náklady, rozmělněním kontextu a větším rizikem, že nekvalitní vstup povede ke špatnému výstupu.
„Dokáže můj agent rozpoznat, že se mýlí?“
Pokud je jediným signálem zpětné vazby pro vašeho agenta rozladěný uživatel, provádíte RL prostřednictvím lidského utrpení. Smyčka opakovaných pokusů řízená validátorem je nejčistší způsob, jak ho konfrontovat s realitou.
„Lze do paměti zapisovat a zlepšuje se postupem času?“
Pokud vaše „paměť“ pouze připojuje historii chatu, v podstatě jen zapisujete protokoly. Pojetí paměti v této studii je důležité: paměť se stává dynamicky rostoucím kontextem, který agenti postupem času zdokonalují, nikoli pouhým přepisem.
Protokoly vám řeknou, co se stalo, zatímco paměť vám řekne, co udělat příště. Historie chatu je přepis. Paměť je vyvíjející se zásada určující, co stojí za to uchovat do budoucna.
Praktickým začátkem je malá tabulka „získaných poznatků“, jejímž klíčem jsou typ úlohy, nástroj a způsob selhání a hodnotou informace o tom, co fungovalo a čemu se vyhnout. Cílem není vytvořit dokonalý znalostní graf. Cílem je dosáhnout kumulativního zlepšování: paměť spolu se zpětnou vazbou mění agenty z „pomocníků bez stavové paměti“ na systémy, které se postupem času zlepšují.
Je lákavé nasadit na problém více agentů, ale tím se často násobí režie spojená s koordinací. Dobrý vzorec „minimálního životaschopného týmu“:
Koordinátor: rozděluje a přiděluje úlohy
Vykonavatel: volá nástroje a provádí změny
Kritik/hodnotitel: kontroluje správnost a rizika
Správce paměti: zapisuje a třídí získané poznatky
Pokud nedokážete vysvětlit, za co každý agent odpovídá, více agentů zatím nejspíš nepotřebujete.
Pokud tuto změnu paradigmatu skutečně přijmeme, nejspíš přestaneme cpát všechno do promptů, považovat selhání za konečné výstupy a hodnotit agenty jako chatboty. A začneme k agentům přistupovat takoví, jací jsou: jako k softwarovým systémům, v nichž jazyk tvoří řídicí rovinu a spolehlivost vychází ze smyčky.
Než přidáte další model, přidejte další hodnoticí smyčku. Než načtete všechno, nastavte načítání jako podmíněné. Než nasadíte deset validátorů, nasaďte jeden. K paměti přistupujte jako k rozhodnutím o zásadách, nikoli jako k databázi. A při přechodu na více agentů začněte dvěma, nikoli dvaceti. Nejsou to pravidla, ale vzorce, které obstály v produkci.