Jak jsou postaveni AI agenti: architektura, ReAct a praktická implementace v Pythonu
AI agenti nejsou pouze „chytré chatboty“, ale autonomní systémy schopné plánovat, vybírat nástroje, provádět externí volání a korigovat své činnosti v reálném čase. Na rozdíl od RAG, který jen předkládá kontext před generací, agent řídí celý cyklus řešení úlohy – od analýzy cíle až po finální výsledek s automatickou kontrolou. Jedná se o zcela nový level automatizace pro vývojáře, zejména v scénářích vyžadujících mnohastupňovou interakci s API, kódem, databázemi či externími službami.
Proč je RAG nedostatečný pro složité úlohy
RAG řeší jednu konkrétní problém – aktualizaci znalostí pomocí externích zdrojů. Ale je statický: model dostane sadu fragmentů a vygeneruje odpověď jen jednou. Neexistuje mechanismus opakovaných dotazů při irelevantních výsledcích, žádná kontrola důvěryhodnosti meziproduktů ani přeplánování. V reálných pracovních procesech to je kriticky důležité:
- Při analýze technické dokumentace může být třeba postupné procházení odkazů, extrakce kódu z různých souborů a jeho validace;
- Při generování reportu z dat Excelu je třeba nejprve přečíst tabulku, potom určit metriky, vypočítat je a teprve pak formátovat výstup;
- Při automatizaci CI/CD je nutné interpretovat logy chyb, spustit diagnostiku, aplikovat opravu a potvrdit výsledek.
Všechny tyto scénáře přesahují možnosti jednorázové generace. Zde je třeba dynamická architektura – tedy agent.
Klíčové komponenty moderního AI agenta
Agent není monolit, ale koordinovaný systém vzájemně propojených modulů. Každá součást plní striktně definovanou funkci a může být nahrazena či rozšířena bez přepisování celé logiky.
LLM jako jádro rozhodování
Model neprodukuje konečnou odpověď přímo, ale funguje jako „mozek“: formuluje plán, vybírat nástroje, interpretuje výsledky volání a rozhoduje o dalším kroku. Jeho role je strategické řízení, nikoli textová produkce.
Nástroje jako rozhraní k okolí
Jedná se o jakékoli externí možnosti: HTTP požadavky na REST API, spuštění Python kódu v sandboxu, čtení/zápis souborů, SQL dotazy, volání CLI utilit. Nástroj musí mít jasný popis (docstring), typizované argumenty a zvládnutí chyb – právě tak ho LLM může bezpečně používat.
Paměť: krátkodobá a dlouhodobá
Krátkodobá paměť zahrnuje aktuální kontext dialogu a mezivýsledky (například ID vytvořeného resursu). Dlouhodobá paměť obsahuje vektorové základny znalostí, kešované odpovědi, historická data uživatelských sezení. Umožňuje agentovi „pamatovat“ kontext mezi voláními a učit se z vlastní zkušenosti.
Plánovač a kontrolér chyb
Plánovač rozděluje cíl na kroky, sleduje pokrok a předchází zacyklování. Kontrolér chyb ověřuje výsledky nástrojů na validitu, porovnává fakta se zdroji a iniciuje opakované pokusy v případě neúspěchu. Bez těchto komponent je agent nestabilní a nepředvídatelný.
ReAct: transparentní vzorec chování pro LLM
ReAct (Reason + Act + Observe) není framework, ale vzorec chování, který stanoví jasný cyklus práce agenta. Díky němu jsou interní úvahy modelu viditelné a kontrolovatelné:
- Reason – model analyzuje aktuální stav, formuluje hypotézu o dalším kroku a vysvětluje, proč je nutný;
- Act – model vyvolá nástroj s konkrétními parametry;
- Observe – model obdrží výsledek volání a posoudí, zda je vhodný pro danou úlohu.
Tento cyklus se opakuje až do dosažení cíle. Příklad z praxe: při hledání informací o kompatibilitě knihovny s Pythonem 3.12 model nejprve „rozmyslí“, že je třeba zkontrolovat PyPI a GitHub; potom „zakročí“ a vyvolá get_pypi_info('requests'); následně „pozoruje“ výsledek a rozhodne, zda má smysl analyzovat zdrojový kód repozitáře.
Výhoda ReActu je reprodukovatelnost a možnost ladění. Každý krok je logován: plán → volání → výsledek → nové rozhodnutí. To je kriticky důležité pro produkční systémy, kde je třeba audit a trasa.
Multiagentní systémy: škálování prostřednictvím specializace
Jeden univerzální agent rychle dosahuje limitu složitosti. Multiagentní systémy (MAS) to řeší rozdělením rolí. Místo monolitu – tým specializovaných agentů koordinovaných orchestrátorem.
Typické role v MAS:
- Plánovač – dekomponuje cíl, určuje pořadí podúkolů a přiděluje je vykonavatelům;
- Výzkumník – pracuje s externími zdroji: API, dokumentací, databázemi;
- Vykonavatel – spouští kód, upravuje soubory, aplikuje konfigurace;
- Validátor – ověřuje výsledky na správnost, soulad s požadavky a bezpečnost.
Orchestrátor shromažďuje výsledky, řeší rozpory a formuluje finální odpověď. Tento přístup přináší tři klíčové výhody:
- Paralelnost: několik agentů může současně zpracovávat nezávislé podúkoly;
- Zvýšení spolehlivosti: validátor zachytí chyby, které by mohl vynechat vykonavatel;
- Zjednodušení ladění: selhání v jedné roli nezablokuje celý systém.
Avšak MAS vyžaduje promyšlený protokol interakce a ochranu před cyklickými závislostmi – například když výzkumník žádá data od validátora a ten čeká na potvrzení od výzkumníka.
Praktika: minimální asistenční agent na LangChain
Implementujeme jednoduchého, ale plně funkčního agenta schopného získat počasí, najít akce a odeslat e-mail. Cíl je ukázat, jak se jednotlivé komponenty spojují do jednotného systému, nikoli vytvořit produkční řešení.
Inicializace modelu a prostředí
Používáme Qwen 3.5 (9B) přes Ollama – model je dostatečně výkonný pro agentní úlohy a vejde se do Google Colabu. Připojení je standardní:
from langchain_openai import ChatOpenAI
llm = ChatOpenAI(
model="qwen3.5:9b",
base_url="http://localhost:11434/v1",
api_key="ollama",
temperature=0.3,
)
Definice nástrojů
Každý nástroj je Pythonová funkce s dekorátorem @tool, jasným docstringem a typizovanými argumenty. Například get_weather:
@tool
def get_weather(city: str) -> str:
"""Vrací aktuální počasí ve zadaném městě.
Přijímá název města v ruštině nebo angličtině."""
# ... implementace přes Open-Meteo API
return f"{name}: {weather['temperature_2m']}°C, {desc}, vítr {weather['wind_speed_10m']} km/h"
Důležité: funkce musí zvládat síťové chyby, neexistující města i nekorektní kódy počasí – jinak by agent dostal nestrukturovaný text místo očekávané odpovědi.
Prompt a kontext uživatele
Prompt určuje roli, omezení a styl odpovědi. Pro technického agenta je kriticky důležité explicitně specifikovat:
- Které nástroje jsou k dispozici a za jakých okolností je třeba je použít;
- Co dělat v případě chyby (opakovat, upřesnit uživatele, odmítnout);
- Jak formátovat finální výsledek (například pouze JSON, bez vysvětlení).
USER_CONTEXT obsahuje personalizované údaje – jméno, preference, historii interakcí. To umožňuje agentovi přizpůsobit tón a hloubku detailů.
Co je důležité
- AI agent není LLM s rozšířeným promptem, ale architektonicky složitý systém s jasným rozdělením odpovědnosti mezi komponenty.
- ReAct není „fígl“, ale nezbytný vzorec pro zajištění transparentnosti, ladění a bezpečnosti v produkci.
- Nástroje musí být typizované, zdokumentované a odolné vůči chybám – jinak agent ztrácí kontrolu nad svým provedením.
- Multiagentní systémy mají smysl ne kvůli módnímu trendu, ale pro škálování složitosti: jeden agent nemůže spolehlivě řídit desítky nástrojů a zdrojů.
- Agenti v produkci vyžadují mechanismy trasování, logování každého kroku cyklu a striktní validaci vstupních/výstupních dat.
— Editorial Team
Zatím žádné komentáře.