Přejít k hlavnímu obsahu

Agentická AI v produkci: Jak vyřešit token-burn a proměnit prototyp v ziskový produkt

AI article illustration for jarvis-ai.cz
Dostat AI agenta z prototypu do ostré produkce je dnes překvapivě snadné. Stačí pár řádků kódu, dobře napsaný prompt a agent začne sám plnit úkoly. Jenže pak přijde účet za API a realita udeří — to, co v demu vypadalo jako magie, se v produkci mění v drahou noční můru. Problém, kterému vývojáři říkají token-burn, je hlavní brzdou toho, aby se agentická AI stala skutečně výnosnou technologií. Jak ho řešit?

Co je token-burn a proč na něm záleží

Každý dotaz na velký jazykový model (LLM) něco stojí. Cena se odvíjí od počtu tokenů — tedy jednotek textu, které model zpracuje na vstupu a vygeneruje na výstupu. Když AI agent v rámci jednoho úkolu volá model opakovaně, prochází různé cesty, zkouší nástroje a přemýšlí nad každým krokem, spotřeba tokenů raketově roste.

Token-burn je neformální označení pro situaci, kdy agent spotřebovává nepřiměřeně mnoho tokenů na splnění relativně jednoduchého úkolu. V prototypu vám to může být jedno — platíte pár dolarů za testování. Jenže v ostré produkci, kde agent obsluhuje tisíce nebo desetitisíce požadavků denně, se z "pár dolarů" stávají tisíce dolarů měsíčně.

Podle článku Rahula Vira a Reyi Vir na Towards Data Science se metriky ve firmách posouvají od "token maxingu" — tedy snahy dosáhnout nejlepších výsledků za každou cenu — k měření poměru hodnota ku spotřebovaným tokenům. Jinými slovy: nestačí, aby agent úkol splnil. Musí ho splnit efektivně.

Proč přehnaně omezovaní agenti selhávají

První instinkt vývojáře, který chce ušetřit tokeny, je agenta pevně svázat pravidly. "Dělej jen tohle, jdi touto cestou, neodbočuj." Jenže výzkum profesora Jeffa Clunea o open-ended agent learning ukazuje, že to je cesta do pekel. Agent, který je za každou odbočku penalizován, uvízne v takzvaném lokálním optimu — dokola zkouší stejnou slepou cestu a nikdy nedosáhne cíle.

Představte si zdravotnického agenta, který zpracovává rutinní příjem pacientů. Pokud ho naprogramujete tak, aby striktně následoval předepsaný formulář, selže ve chvíli, kdy pacient uprostřed rezervace zmíní bolest na hrudi. Rigidní agent nedokáže rozpoznat urgentní kontext a eskalovat situaci na lidského operátora. Přesně proto nástroje jako Google Antigravity nebo Anthropic Claude Code dávají agentům svobodu vytvářet si vlastní nástroje a prozkoumávat alternativní cesty — fungují právě proto, že nejsou svázané mikromanagementem.

Cena svobody: Když agent přemýšlí až příliš

Svoboda má ale svou cenu. Když agent při každém požadavku znovu prochází celým rozhodovacím prostorem — zkouší nástroje, testuje cesty, "přemýšlí nahlas" — spotřeba tokenů se násobí počtem iterací. Pro jednorázové, komplexní úkoly je to akceptovatelné. Pro rutinní, opakované workflow je to ekonomický nesmysl.

Vir a Vir to ilustrují na příkladu klinické administrativy: routování pacientských příjmů a eskalačních scénářů se dá za určitou dobu naučit. Většina workflow se ustálí na deterministických cestách a pouze vzácné okrajové případy vyžadují autonomní rozhodování agenta. Klíčová otázka zní: jak zkombinovat svobodu pro výjimečné situace s efektivitou pro ty běžné?

Early Commitment: Rozhodni se dřív, než jednáš

První architektonické řešení, které článek popisuje, se nazývá Early Commitment. Je to princip známý z výzkumu strukturovaného řešení problémů: donuť model, aby nejprve klasifikoval typ problému, a teprve potom generoval exekuční logiku.

V praxi to znamená obohatit systémový prompt o požadavek na klasifikační tag. Například v telehealth třídění: agent musí nejprve definitivně určit, že jde o "rutinní obnovení receptu", a teprve potom smí začít jednat. Tím se omezí množina nástrojů, které má k dispozici — v tomto případě pouze farmaceutickou databázi — a odpadne drahé diagnostické uvažování, které by model jinak spustil.

Výsledek? Méně tokenů, rychlejší odezva, méně halucinací. Nevýhoda? Early Commitment funguje dobře pro jasně klasifikovatelné úkoly, ale selhává tam, kde je hranice mezi kategoriemi nejasná.

LOOP Skill Engine: Jednou prozkoumej, pak jen mechanicky opakuj

Ještě razantnější přístup přináší výzkumný tým vedený Xiaohuou Wangem. Jejich LOOP Skill Engine, publikovaný na arXiv v květnu 2026 (arXiv:2605.14237), funguje na principu one-shot recording + deterministický replay:

  1. Agent poprvé spustí úkol s plným LLM uvažováním — prozkoumává, hledá optimální cestu.
  2. Systém transparentně zachytí celou trajektorii volání nástrojů.
  3. Algoritmus "greedy length-descending template extraction" převede záznam na parametrizovaný, bezvětvený recept — takzvanou Loop Skill.
  4. Při všech dalších spuštěních se LLM zcela vynechá — engine pouze dosadí aktuální hodnoty do šablony a deterministicky přehraje sekvenci kroků.

Čísla jsou působivá: 99% úspěšnost a snížení spotřeby tokenů o 93,3 % až 99,98 % v závislosti na frekvenci úlohy. U denních rutinních reportů, jako je generování klinických compliance zpráv nebo standardních propouštěcích sumářů, to znamená, že agent po prvním "promyšlení" pracuje de facto jako klasický software — bez LLM, bez halucinací, s garantovaným výstupem.

LOOP Skill Engine je součástí open-source frameworku buddyMe a tým k němu dokazuje dvě formální věty: Replay Determinism (sekvence kroků validované Loop Skill se při budoucích spuštěních nemění) a Write Safety (paralelní přístup ke konfiguraci je bezpečně serializován).

Hybridní přístup: SKILL.md jako zlatá střední cesta

Ne vždy je čistě deterministický replay ideální. Vir a Vir navrhují hybridní model, kde agent svou objevenou cestu uloží do souboru SKILL.md — podobně jako to dělá Claude Code nebo Google Antigravity. Při dalším spuštění agent cestu následuje, ale ponechává si určitou míru "reasoning headroom" pro přizpůsobení se změnám.

To je praktické zejména v situacích, kdy se mění podkladová infrastruktura — například struktura databáze. Čistě deterministický replay by zde selhal, protože SQL dotazy by přestaly odpovídat schématu. Hybridní agent naopak dokáže detekovat změnu a přizpůsobit extrakci dat, byť za cenu několika tokenů navíc.

Co to znamená pro firmy a vývojáře

Pro produktové manažery a ML inženýry z toho plyne jasné doporučení: fáze prozkoumávání a fáze provozu jsou dvě různé disciplíny. Během vývoje a při řešení okrajových případů je rozumné nechat agenta volně uvažovat. Jakmile se ale workflow ustálí, je třeba přejít na deterministickou exekuci — ať už přes Early Commitment, LOOP Skill Engine, nebo hybridní SKILL.md přístup.

Náklady na LLM inference jsou dnes stále významnou položkou. GPT-4o stojí $2,50 za milion vstupních tokenů a $10 za milion výstupních. Claude 3.5 Sonnet je na tom podobně. Když agent při jednom úkolu spotřebuje 20 000 tokenů a takových úkolů proběhne 10 000 denně, bavíme se o stovkách dolarů denně jen za inference. Snížení o 95 % znamená úsporu, která může rozhodnout o tom, zda je produkt ziskový, nebo ne.

Evropský a český kontext

Pro evropské a české firmy je téma token-efektivity obzvlášť aktuální. Evropská unie tlačí na AI Act, který vyžaduje transparentnost a spolehlivost AI systémů — a deterministický replay je v tomto ohledu ideální, protože eliminuje nepředvídatelné chování LLM. Navíc v oblastech jako zdravotnictví nebo finance, kde platí přísná regulace (GDPR, MDR), je garance reprodukovatelného výstupu klíčová.

České firmy, které vyvíjejí AI agenty — ať už v oblasti health-tech, logistiky nebo zákaznické podpory — by měly architekturu typu LOOP Skill Engine nebo Early Commitment zvážit už ve fázi návrhu. Není to jen o úspoře peněz za API, ale také o splnění regulatorních požadavků a o důvěře zákazníků, že agent nezačne halucinovat v tu nejméně vhodnou chvíli.

Open-source povaha frameworku buddyMe navíc znamená, že řešení není vázané na konkrétního cloudového poskytovatele — což je výhoda pro firmy, které z bezpečnostních nebo regulatorních důvodů provozují AI na vlastní infrastruktuře (on-premise nebo v evropských datacentrech).

Jak poznám, že můj agent trpí token-burn problémem?

Sledujte metriky na úrovni jednotlivých úkolů — kolik tokenů agent spotřebuje na jeden požadavek a jak se to liší mezi prvním a stým spuštěním stejného typu úkolu. Pokud spotřeba neklesá nebo je opakovaně vysoká u rutinních úloh, máte token-burn problém. Pomůže logging na úrovni jednotlivých LLM volání a porovnání trajektorií mezi spuštěními.

Dá se LOOP Skill Engine použít i s jinými modely než s OpenAI?

Ano. LOOP Skill Engine je součástí open-source frameworku buddyMe a pracuje na úrovni volání nástrojů, nikoliv na úrovni konkrétního modelu. V principu ho lze použít s libovolným LLM, který podporuje function calling — včetně Claude, Gemini, Llama nebo evropských modelů jako Mistral.

Není deterministický replay jen jiný název pro caching?

Není to totéž. Klasický caching vrací stejný výstup pro stejný vstup — pokud se změní data, cache selže. LOOP Skill Engine naopak parametrizuje proměnné části úlohy (například ID pacienta, datum, výsledky měření) a při každém spuštění je dosadí do předem ověřené šablony. Výstup se tedy může lišit podle dat, ale cesta k němu je vždy stejná a bez LLM.

X

Nezmeškejte novinky!

Přihlaste se k odběru novinek a aktualit.