Co je AI agent a jak vlastně funguje?

Slovo „agent“ je dnes v AI světě všude — agentní kódování, agentní workflow, multiagentní systémy. Pod marketingovou vrstvou se ale skrývá překvapivě jednoduchý princip: jazykový model běžící ve smyčce, který smí volat nástroje. V tomto článku si tu smyčku rozebereme krok za krokem, postavíme si minimálního agenta v čistém Pythonu i v LangChainu a podíváme se, co odděluje víkendové demo od agenta, kterému svěříte produkční data.

Chatbot odpovídá, agent jedná

Klasické použití LLM je jednorázové: pošlete prompt, dostanete odpověď, konec. Model je čistá funkce text → text — nemá přístup k vašim datům, nemůže nic spustit a neví, co se stalo po jeho odpovědi. Když chcete, aby odpověď zohlednila obsah databáze, musíte ho tam vložit sami. Když vygeneruje kód, musíte ho sami spustit. A když se spletl, dozvíte se to až vy — model ne.

AI agent tento model rozšiřuje o dvě klíčové věci: o nástroje (tools), kterými může působit na okolní svět — hledat na webu, číst soubory, volat API, spouštět kód — a o smyčku, ve které se rozhoduje, co udělat dál, dokud úkol nedokončí. Agent tedy udržuje stav mezi kroky a přizpůsobuje další postup tomu, co zjistil v krocích předchozích. Právě zpětná vazba z prostředí je to, co dělá agenta agentem: může svůj plán ověřit, narazit, opravit se a zkusit to jinak.

Užitečné je rozlišení, které zavedl Anthropic v často citovaném textu Building effective agents:

• Workflow — LLM a nástroje jsou propojené předem definovanou cestou v kódu. Počet kroků i jejich pořadí určuje programátor. Příklad: „vezmi e-mail, klasifikuj ho, podle kategorie vygeneruj odpověď šablonou A nebo B“.
• Agent — LLM si sám řídí, které nástroje a v jakém pořadí použije. Počet kroků předem neznáme. Příklad: „najdi příčinu tohohle padajícího testu a oprav ji“.

Agenti dávají smysl tam, kde je problém otevřený a počet kroků nepředvídatelný. Pokud lze úlohu popsat pevným postupem, bývá workflow levnější, rychlejší a spolehlivější. Tohle rozhodnutí je vůbec první, které byste při návrhu měli udělat — a upřímně: většina úloh, které dnes firmy řeší „agentem“, by workflow zvládlo líp.

Agentní smyčka: Thought → Action → Observation

Jádrem každého agenta je cyklus, který poprvé systematicky popsal článek ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022). Model v něm střídá tři fáze:

1. Thought (úvaha) — model si v textu rozmyslí, co potřebuje zjistit nebo udělat.
2. Action (akce) — model zavolá konkrétní nástroj s konkrétními parametry.
3. Observation (pozorování) — výsledek nástroje se vrátí do kontextu a model na jeho základě pokračuje.

Smyčka se opakuje, dokud model neusoudí, že má finální odpověď. Síla ReActu je v tom, že se úvahy a akce vzájemně ukotvují: každé volání nástroje je zdůvodněné a každá další úvaha stojí na skutečném výsledku, ne na halucinaci. Autoři v původním článku ukázali, že tato kombinace poráží jak čisté řetězení úvah (chain-of-thought, které si fakta vymýšlí), tak slepé jednání bez rozmyslu.

V roce 2022 znamenal ReAct textový prompt s řádky Thought: / Action: / Observation: a regulárním výrazem na parsování. Dnes tutéž smyčku zajišťuje nativní tool calling a interní uvažování modelů (reasoning tokens) — formát se změnil, princip zůstal.

Anatomie agenta: čtyři stavební kameny

Když se podíváte na libovolný agentní systém — od víkendového skriptu po Cursor nebo Claude Code — najdete v něm vždy stejné čtyři komponenty:

1. Model (mozek)

LLM je jediné místo, kde se „rozhoduje“. Kvalita agenta proto stojí a padá se schopností modelu plánovat, držet se instrukcí a správně volat nástroje. Pro agentní použití se modely dnes cíleně trénují (post-training na trajektoriích s nástroji) a benchmarky jako SWE-bench nebo τ-bench měří přesně tohle. Slabší model nezachrání žádný framework.

2. Nástroje (ruce)

Nástroj je libovolná funkce s popisem a schématem parametrů. Kvalita popisů je přitom zásadní — model se podle nich rozhoduje, kdy a jak nástroj použít. Dobrý nástroj má jasný název, popis psaný pro model (ne pro člověka), vrací stručné a strukturované výstupy a je pokud možno idempotentní, aby opakované volání nenapáchalo škodu.

3. Kontext a paměť

Krátkodobou pamětí agenta je samotná konverzace — seznam zpráv, který roste s každým krokem. Dlouhodobá paměť (fakta o uživateli, výsledky předchozích běhů) musí bydlet mimo model: v databázi, vektorovém úložišti nebo souborech, a do kontextu se natahuje podle potřeby. Víc o tom níže.

4. Orchestrace (kostra)

Kód, který smyčku pohání: skládá zprávy, vykonává nástroje, hlídá limity, ukládá stav, loguje. V demu je to while-cyklus, v produkci stavový stroj s perzistencí a recovery. Tady bydlí frameworky typu LangChain či LangGraph.

Volání nástrojů: strukturovaná JSON odpověď

Moderní modely (GPT, Claude, Gemini i řada open-source modelů) jsou dotrénované tak, aby uměly místo textové odpovědi vrátit strukturované volání funkce. Vy modelu popíšete dostupné nástroje (název, popis, JSON schéma parametrů) a model, když usoudí, že nástroj potřebuje, vrátí JSON s názvem funkce a argumenty. Takhle vypadá surová odpověď modelu, který se rozhodl zavolat nástroj:

{
  "role": "assistant",
  "content": null,
  "tool_calls": [{
    "id": "call_abc123",
    "type": "function",
    "function": {
      "name": "get_weather",
      "arguments": "{\"city\": \"Brno\"}"
    }
  }]
}

Váš kód funkci vykoná a výsledek pošle zpět jako zprávu s rolí tool. Důležité je uvědomit si, že model sám nic nespouští. Jen generuje požadavek; vykonání je vždy ve vaší režii. Právě tady je místo pro bezpečnostní kontroly — validaci argumentů (model si umí vymyslet neexistující hodnoty), omezení oprávnění nebo potvrzení od uživatele u destruktivních operací.

Minimální agent v Pythonu

Celý princip se vejde do zhruba třiceti řádků. Následující ukázka používá OpenAI SDK, ale stejné schéma funguje s libovolným modelem podporujícím tool calling:

import json
from openai import OpenAI

client = OpenAI()

def get_weather(city):
    # zde by bylo volani skutecneho API
    return f"V miste {city} je 24 stupnu a jasno."

TOOLS = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Vrati aktualni pocasi v zadanem meste.",
        "parameters": {
            "type": "object",
            "properties": {"city": {"type": "string"}},
            "required": ["city"],
        },
    },
}]

messages = [{"role": "user",
             "content": "Mam si zitra v Brne vzit bundu?"}]

while True:                                        # agentni smycka
    response = client.chat.completions.create(
        model="gpt-4.1", messages=messages, tools=TOOLS)
    msg = response.choices[0].message
    messages.append(msg)

    if not msg.tool_calls:                         # finalni odpoved
        print(msg.content)
        break

    for call in msg.tool_calls:                    # Action
        args = json.loads(call.function.arguments)
        result = get_weather(**args)               # Observation
        messages.append({"role": "tool",
                         "tool_call_id": call.id,
                         "content": result})

Všimněte si, že „inteligence“ agenta není v našem kódu — ten jen přeposílá zprávy. O tom, kdy zavolat nástroj a kdy odpovědět, rozhoduje model. Přesně tohle dělají pod kapotou i velké agentní systémy typu Cursor, Claude Code nebo Deep Research; liší se hlavně množstvím a kvalitou nástrojů, prací s kontextem a produkční robustností.

Totéž s LangChainem

Jakmile agentů a nástrojů přibude, nechce se vám smyčku, parsování argumentů a správu historie psát pořád dokola. Přesně tuhle práci obaluje LangChain — nejrozšířenější open-source framework pro stavbu LLM aplikací. Jeho ekosystém má tři hlavní části: samotný LangChain (agenti, nástroje, integrace na desítky modelů), LangGraph (nízkoúrovňový engine pro složitější orchestraci, na kterém agenti běží) a LangSmith (observabilita a vyhodnocování).

Náš agent s počasím vypadá v LangChainu takto:

from langchain.agents import create_agent
from langchain.tools import tool

@tool
def get_weather(city: str) -> str:
    """Vrati aktualni pocasi v zadanem meste."""
    return f"V miste {city} je 24 stupnu a jasno."

agent = create_agent(
    model="openai:gpt-4.1",
    tools=[get_weather],
    system_prompt="Jsi uzitecny asistent. Odpovidej cesky.",
)

vysledek = agent.invoke(
    {"messages": [{"role": "user",
                   "content": "Mam si zitra v Brne vzit bundu?"}]})
print(vysledek["messages"][-1].content)

Celá agentní smyčka z předchozí kapitoly se schovala do create_agent. Dekorátor tool navíc vygeneroval JSON schéma nástroje automaticky z typových anotací a docstringu — žádné ruční psaní definic. A protože model předáváte jen řetězcem ("openai:gpt-4.1"), přepnete na Claude nebo lokálně hostovaný model změnou jednoho řádku.

Skutečná přidaná hodnota se ale ukáže až u věcí, které byste si jinak psali sami: parametr checkpointer přidá perzistenci konverzace (agent přežije restart procesu), middleware umožní vstoupit do smyčky — např. sumarizovat dlouhou historii, schvalovat citlivé nástroje člověkem nebo omezit počet iterací — a napojení na LangSmith vám zaznamená každou trajektorii pro debugování.

Framework ale není podmínka. Pro jednoduché agenty je holá smyčka často čitelnější a lépe se ladí; po LangChainu sáhněte, až budete potřebovat perzistenci, orchestraci více agentů nebo hotové integrace. A hlavně: i s frameworkem vám znalost holé smyčky zůstane — přesně to se děje uvnitř.

Paměť a správa kontextu

Tohle je nejpodceňovanější část agentního inženýrství. Kontextové okno je konečné a každý výsledek nástroje z něj ukusuje — výpis souboru má klidně tisíce tokenů, výsledek vyhledávání desítky tisíc. Dlouhý agentní běh tak dřív nebo později narazí: buď na tvrdý limit okna, nebo na měkčí problém, že modely s rostoucím a „zaneseným“ kontextem uvažují hůř (tzv. context rot; souvisí s U-křivkou pozornosti, které se věnujeme v samostatném článku). V praxi se používají tři techniky:

• Ořezávání a sumarizace — staré kroky konverzace se průběžně nahrazují shrnutím. Přijdete o detail, zachováte nit.
• Odkládání mimo kontext — objemné výstupy nástrojů se uloží na disk či do úložiště a do kontextu jde jen odkaz a krátký výtah; agent si detail vyžádá, až když ho potřebuje.
• Strukturovaný stav — místo spoléhání na volný text v historii si agent vede explicitní stav (todo list, poznámky, mezivýsledky), který se do promptu vkládá vždy celý a aktuální.

Tomuto oboru se začalo říkat context engineering a u dlouhých agentních úloh rozhoduje o úspěchu víc než výběr frameworku.

Multiagentní systémy: kdy je jeden agent málo

Když jeden agent přestane stačit — typicky proto, že úloha má víc nezávislých částí, než kolik se vejde do jednoho kontextu — přichází na řadu rozdělení práce mezi více agentů. Nejosvědčenější vzor je orchestrátor–pracovníci: hlavní agent úlohu rozloží na podúkoly a každý z nich zadá specializovanému podagentovi s vlastním čistým kontextem a užší sadou nástrojů. Podagent vrátí jen zhuštěný výsledek, takže orchestrátor pracuje s podstatou, ne se stovkami tisíc tokenů surových dat. Přesně takhle funguje např. multiagentní rešeršní systém Anthropicu.

Zároveň platí střízlivé varování: multiagentní systém je násobně dražší (každý agent spotřebovává tokeny), hůř se ladí a chyby se v něm skládají. Začněte jedním agentem a dělte ho, až když narazíte na skutečný limit — ne proto, že je to módní.

Jak agenti selhávají

Než se pustíte do produkce, počítejte s typickými poruchami:

• Halucinované argumenty — model zavolá nástroj s ID, které neexistuje, nebo s cestou, kterou si vymyslel. Obrana: validace na vstupu nástroje a chybové hlášky psané tak, aby modelu pomohly se opravit.
• Zacyklení — agent opakuje stejnou akci se stejným výsledkem (typicky po nejasné chybě). Obrana: limit iterací, detekce opakovaných volání a instrukce „když se to nepovede třikrát, zastav se a popiš problém“.
• Předčasná kapitulace či falešný úspěch — agent prohlásí úkol za hotový, i když není (nejzákeřnější porucha, protože vypadá jako úspěch). Obrana: nezávislé ověření výsledku — testem, kontrolním dotazem, druhým modelem v roli kritika.
• Otrava kontextu — chybný mezivýsledek se usadí v historii a všechna další rozhodnutí staví na něm. Obrana: struktura stavu, checkpointy a možnost vrátit se před chybu.

Co k tomu potřebuje produkce

Mezi třicetiřádkovým demem a spolehlivým produkčním agentem je propast. V praxi řešíte hlavně tyto věci:

• Limit iterací a rozpočet — smyčka bez stropu může běžet (a utrácet) donekonečna. Vždy nastavte maximální počet kroků a tokenů na úlohu.
• Správa kontextu — viz výše; bez sumarizace a odkládání dlouhé běhy degradují.
• Observabilita — bez záznamu celé trajektorie (úvahy, volání, výsledky, latence, cena) nedokážete selhání agenta vůbec debugovat. Nástroje: LangSmith, Langfuse, OpenTelemetry.
• Guardrails — oprávnění nástrojů (read-only vs. write), sandboxing spouštěného kódu, potvrzování nevratných akcí člověkem (human-in-the-loop), ochrana před prompt injection z dat, která agent čte.
• Vyhodnocování (evals) — agenti jsou nedeterminističtí; bez sady testovacích scénářů nepoznáte, jestli změna promptu něco zlepšila, nebo rozbila. Evals pro agenty měří nejen finální výsledek, ale i kvalitu trajektorie (počet kroků, zbytečná volání, cena).

S většinou těchto věcí pomůže LangChain zmíněný výše, případně jeho nízkoúrovňový základ LangGraph či Microsoft Agent Framework. Pro standardizované připojování nástrojů existuje protokol MCP (Model Context Protocol) — jednou napsaný MCP server s nástroji připojíte k libovolnému agentovi, který protokol podporuje. MCP a bránám, které ho drží pod kontrolou, jsme věnovali samostatný článek. Vyplatí se ale nejdřív rozumět holé smyčce — frameworky ji jen obalují.

Kdy agenta (ne)nasadit

Poslední rada je možná nejcennější: agent je nejdražší a nejméně předvídatelný nástroj v krabici. Pokud úlohu zvládne jeden dobře napsaný prompt, použijte prompt. Pokud má úloha pevný postup, použijte workflow. Agenta nasaďte tam, kde skutečně potřebujete dynamické rozhodování — průzkum neznámé codebase, ladění chyby, rešerše napříč zdroji. A i tam mu dejte jasné nástroje, jasné limity a možnost říct „nevím“.

Autor článku

Zdeněk Vais

Zakladatel · Senior Principal Software Engineer, Oracle

Zdeněk programuje už od střední školy. Od té doby si prošel cestou od programátora přes team leadera až k architektovi. Za tuto dobu vyvíjel velké finanční systémy, věděcké aplikace nebo například IoT řešení pro letadla. V součastnosti pracuje jako senior principal software engineer ve společnosti Oracle, kde staví cloud pro mediální služby.

Poznej náš tým

← Zpět na blog