Zpět na domů

AI agenti: architektura a implementace v Pythonu

Článek vysvětluje architekturu AI agentů pro vývojáře: komponenty (LLM, nástroje, paměť, plánovač), vzor ReAct, multiagentní systémy a praktickou implementaci v Pythonu s LangChain.

AI agenti: od teorie k funkčnímu kódu
Advertisement 728x90

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.

Google AdInline article slot

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.

Google AdInline article slot

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á

Google AdInline article slot

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

Advertisement 728x90

Číst dál