Menu
Přihlásit
Domů / Obsah / Automatizace / Jak monitorovat AI agenty v pr...
Automatizace 18.08.2026 Article

Jak monitorovat AI agenty v produkci: observability, která zachrání tvůj rozpočet

AI agent v produkci dělá tisíce rozhodnutí denně a klasický monitoring nevidí žádné z nich. Nauč se trasovat běhy agentů, sledovat cenu za run a nastavit alarmy dřív, než ti shoří rozpočet.

Jak monitorovat AI agenty v produkci: observability, která zachrání tvůj rozpočet - ilustrační obrázek

Máš AI agenta v produkci. Funguje. Metriky vypadají dobře, uptime 99,9 %, žádné errory v logu. A pak přijde faktura od API provideru o 2 800 dolarů vyšší, než čekáš — a zjistíš, že se agent někomu zasekl ve smyčce a čtyři hodiny burnoval tokeny, než si toho někdo všiml.

Klasický monitoring ti u AI agenta nestačí. Apka buď běží, nebo nebeží — agent může technicky běžet a přitom dělat nesmysly. Uptime ti neřekne, že agent halucinuje, že volá špatný nástroj, že se mu rozšiřuje kontext nebo že cena za běh zdvojnásobila po posledním deployi. Na tohle potřebuješ observability postavenou přímo pro agenty.

V tomhle návodu ti ukážu, co monitorovat, jak strukturovat logy a které nástroje v roce 2026 reálně použít.

Proč klasický monitoring selhává

Tradiční dohled sleduje signály jako HTTP statusy, latenci a chybovost. U deterministickejch služeb to stačí. Agent je ale nedeterministický, vícekrokový systém: chyba v odpovědi na kroku 10 má kořen často v tool callu na kroku 3 nebo v kontextu, který jsi mu nacpal na kroku 1.

Typický scénář, který tě připraví o peníze, je tokenová spirála. Agent se v iteraci vrátí s výsledkem, vyhodnotí ho jako nevyhovující, a spustí se znovu — s větším kontextem. Každá iterace má víc tokenů než předchozí a cena roste exponenciálně. Reálný příklad z praxe: 15 iterací, od 0,01 dolaru po 80 dolarů za běh, celkem 2 847 dolarů, než si toho někdo všiml — čtyři hodiny. Agent přitom pořád "běžel". Žádný error, žádný alert.

Další věci, které klasický monitoring nevidí:

  • Kvalita výstupu. Agent může vracet formálně validní, ale nesmyslnou odpověď.
  • Cena za běh. Tokeny se počítají per call, ale hodnota (a faktura) se počítá per run — včetně sub-agentů, retry a externích API.
  • Drift kvality. Výměna modelu nebo promptu za stejným kódem může tiše zhoršit výsledky o desítky procent.

Čtyři pilíře observability pro agenty

1. Trasování běhů (session-scoped tracing)

Každý běh agenta musí mít trace_id, ke kterému se vážou všechny kroky — LLM call, tool call, retrieval, sub-agent handoff, retry. Každý krok je span s inputem, outputem, latencí, počtem tokenů, cenou a verzí promptu/modelu. Až ti přijde stížnost, že agent vrací blbosti, otevřeš trace a vidí celý řetězec rozhodnutí. Bez toho debuguješ naslepo.

2. Cena za běh (cost attribution)

Cena se musí umět sčítat per run, per agent, per uživatel a per use case. Klíčový trik je cost-per-span enrichment: každý LLM call span obohatíš o tokeny a cenu, takže se ceny přirozeně roll-upují od jednotlivejch callů přes session po celýho agenta. Bez toho ti cena zůstane jedna velká černá skříňka na konci měsíce.

3. Kvalita za běhu

Nejsnazší začátek: loguj si u vzorku běhů skóre nebo aspoň binární signál (usměrnil agent konverzaci k cíli? použil správný nástroj?). Pokročilejší vrstva jsou online evaly — malý, levný model ti hodnotí výstupy produkčního agenta na rubrice. A nezapomeň na uživatelský feedback (thumbs up/down), to je nejdřívější signál driftu.

4. Anomálie a alarmy

Nastav si tvrdé prahové alarmy dřív, než spustíš agenta vůbec:

  • Spend rate: alarm, když míra utrácení přesáhne 3× klouzavý průměr.
  • Cena za run: alert, když průměrná cena za běh přesáhne pevnou hranici (třeba 1 dolar).
  • Délka běhu: agent, který běží déle než X minut, je podezřelá smyčka.
  • Tokeny per run: prudký nárůst meanu znamená rozbalující se kontext nebo smyčku.

Jak začít: strukturovaný log za odpoledne

Než koupíš jakoukoli platformu, dej agentovi strukturovaný logging. Každá akce jedna řádka JSON:

{
  "timestamp": "2026-08-18T10:23:45Z",
  "agent_id": "support-agent-v3",
  "trace_id": "abc-123",
  "span_id": "def-456",
  "event": "tool_call",
  "tool": "search_knowledge_base",
  "input_tokens": 245,
  "output_tokens": 1023,
  "latency_ms": 340,
  "cost_usd": 0.002,
  "user_id": "user-789"
}

Tenhle jeden krok ti dá 80 % hodnoty. Už jen groupování pres trace_id v jakémkoli logovacím nástroji ti ukáže, kde běhy houstnou a co stojí nejvíc. Až pak narosteš, vyměníš ruční analýzu za platformu.

Nástroje v roce 2026: co si vybrat

Nemusíš stavět všechno sám. Krajinu vypadá zhruba takhle:

  • Langfuse — open source, self-hosted, trace viewver, verzování promptů, sledování cen napříč deploymenty. Nejlepší start, když chceš data držet u sebe a neplatit per GB.
  • Braintrust — evaluace a observability v jednom, generózní free tier (1 GB dat měsíčně), ceny per run a per uživatel v reálném čase.
  • Datadog LLM Observability — pokud už Datadog máš, přidává LLM cally, tokeny a cenu do existujících dashboardů.
  • Splunk Agent Observability — novinka, která letos/z loňska posunula agentí monitoring do GA: trasuje workflow od requestu po response, koreluje s infrastrukturou a umí evaluace přepnout do runtime guardrailů, který riskantní akce blokují.
  • Helicone — proxy-based: směruješ API cally přes ně, dostaneš usage a ceny bez zásahu do kódu. Nejrychlejší onboarding.
  • Mastra Studio — pokud stavíš v TypeScriptu, traces a per-trace cost má out of the box.

Praktické pravidlo: proxy-based (Helicone) když chceš vidět ceny rychle, SDK-based (Langfuse, Braintrust) když chceš vidět kvalitu. Ideálně obojí — proxy na factury, SDK na kvalitu.

Kontrolní list před produkčním nasazením

Než pustíš agenta k zákazníkům, projdi si tohle:

  1. Každý běh má trace_id, každý krok span_id s tokeny a cenou.
  2. Cena se reportuje per run a per uživatel, ne jen celkově.
  3. Alarm na spend rate (3× klouzavý průměr) i absolutní strop denního budgetu.
  4. Timeout a maximální počet iterací per run — hard limit, ne doporučení.
  5. Vzorkování tras pro ruční review (třeba 5 % běhů) a feedback button u výstupů.
  6. Verze promptu a modelu zaznamenaná u každého běhu — bez toho nezjistíš, který deploy rozbil kvalitu.

Srovnej to s tím, co už znáš

Pokud čteš aicko.cz delší dobu, víš, že evaly před nasazením a sandboxy řeší jiné fáze života agenta. Evaluace testujou agenta před produkčním nasazením na datasetu. Sandbox a guardraily brání škodě v okamžiku akce. Observability je třetí noha: říká ti, co agent reálně dělá, když běží. Bez ní létáš na slepo — a faktury za tokeny jsou nemilosrdný navigační systém.

Začni tím JSON logem. Je to odpoledne práce a zásadní rozdíl mezi "agent asi funguje" a "agent funguje, stojí nás to 42 haléřů za běh a kvalita drží tři týdny v řadě".

Začínáte s AI?

Navštivte zacinamsai.cz — průvodce světem AI pro úplné začátečníky.

Přejít na Začínáme s AI →

// Další články, které by tě mohly zajímat

Potřebujete pomoct s AI automatizací?

Domluvte si nezávaznou konzultaci →