Jak funguje AI a proč se dokáže zaseknout

Praktický report pro lidi, kteří staví, zadávají nebo řídí AI agenty a pracují s LLM.

TL;DR

LLM není databáze pravdy. Je to model, který generuje další token podle kontextu a naučených vzorů.
AI agent je LLM zapojený do smyčky: cíl → rozhodnutí → nástroj → pozorování → další rozhodnutí.
Zaseknutí většinou nevzniká jednou „hloupou“ odpovědí, ale špatně řízenou smyčkou.
AI slop je výstup, který vypadá jako práce, ale má nízkou hustotu signálu: hodně slov, málo evidence, málo rozhodnutí.
Velký prompt není automaticky lepší prompt. Často přidá šum, konfliktní instrukce a context rot.
Dlouhé context window není spolehlivá paměť. Relevantní informace se může „vejít“, ale model ji stejně nepoužije správně.
Dobří agenti potřebují malé úkoly, čistý kontext, jasná hotovo-kritéria, limity, ověření, observability a možnost včas zastavit.

Krátká formule:

Méně promptu, více procesu. Méně sebejistého textu, více evidence.

Jak LLM funguje

Nejužitečnější mentální model:

LLM je velmi schopný generátor dalšího tokenu nad textovým kontextem.

Funguje zhruba takto:

Text se rozdělí na tokeny. Token může být celé slovo, část slova, mezera, interpunkce nebo častý výraz. Čím víc tokenů, tím vyšší cena, latence a riziko šumu.
Model generuje odpověď postupně. Nepíše hotový text „z hlavy“. V každém kroku vybírá pravděpodobné pokračování podle instrukcí, historie, přiložených dat a naučených vzorů.
Kontext je pracovní paměť. Obsahuje systémové instrukce, uživatelský úkol, historii, výstupy nástrojů, dokumenty, chyby, shrnutí i staré plány.
Attention pomáhá vybírat relevantní části kontextu. Transformer architektura stojí na attention mechanismu. Ten ale nezaručuje, že model vždy správně použije každou důležitou informaci.
Model nemá přímý zdroj pravdy. Pravděpodobný text není totéž co pravdivý text. Bez zdrojů, testů, retrievalu nebo nástrojů může model plynule doplnit něco, co zní správně, ale správně není.

AI agent k tomu přidává „ruce“:

volá nástroje,
čte soubory,
spouští příkazy,
používá API,
plánuje další krok,
interpretuje výsledky.

Tím získá schopnosti, ale i nové body selhání. Agent musí vybrat správný nástroj, dát mu správné parametry, poznat chybu, změnit plán a vědět, kdy je hotovo.

Proč vzniká AI slop

AI slop je obsah, který vypadá jako výstup, ale nemá dost užitné hodnoty.

Typicky:

hodně slov, málo konkrétních závěrů,
obecné fráze místo rozhodnutí,
chybí zdroje nebo evidence,
výstup opakuje zadání,
text působí uhlazeně, ale nejde podle něj jednat,
shrnutí nahrazuje skutečnou práci.

Slop vzniká hlavně tehdy, když systém optimalizuje na „vypadá to jako odpověď“ místo „splnilo to cíl“.

Časté příčiny:

vágní zadání,
chybí definition of done,
tlak na objem místo kvality,
moc dlouhý prompt s nízkým poměrem signál/šum,
model nemá zdroj pravdy,
agent nemá povinnost ověřovat,
completion summary se hodnotí podle sebejistosti, ne podle artefaktů.

Praktické pravidlo:

Pokud výstup nemá rozhodnutí, důkaz, zdroj, test, artefakt nebo další konkrétní krok, je podezřelý ze slopu.

Velký prompt a context rot

Velký prompt často vypadá jako bezpečnější varianta: „Dáme modelu všechno, ať má kompletní kontext.“

Problém: context window není databáze.

Do dlouhého promptu se postupně dostává:

aktuální zadání,
stará zadání,
logy,
chybové výstupy,
předchozí plány,
dokumentace,
duplicitní informace,
historické poznámky,
vlastní chyby agenta,
tool outputy, které mohou znít jako instrukce.

Tím padá poměr signál/šum. Důležitá informace se sice může technicky vejít do context window, ale model ji nemusí použít správně.

Context rot

Context rot je degradace výkonu s rostoucím a špinícím se kontextem.

Projevuje se tak, že model:

ignoruje acceptance criteria,
řeší vedlejší problém,
míchá starý stav s aktuálním,
opakuje už neplatné informace,
přeceňuje vlastní předchozí shrnutí,
reaguje na rušivé části promptu.

Lost in the middle

Empirické práce ukazují, že modely často lépe využívají informace na začátku a konci dlouhého kontextu než informace uprostřed. Když dáte kritické hotovo-kritérium doprostřed dlouhých logů, zvyšujete riziko, že ho model mine.

„Fake long context“

Model může projít jednoduchým testem typu „najdi jednu větu v dlouhém textu“, ale selhat na reálné práci, kde musí kombinovat více detailů, řešit konflikty a dodržet instrukce. Nominální velikost context window není totéž co efektivně použitelný kontext.

Praktický závěr:

Velké context window je užitečné, ale nenahrazuje context management.

Typické způsoby zaseknutí

1. Hallucination

Model vygeneruje fakt, citaci, API parametr, cestu k souboru nebo výsledek testu bez opory v realitě.

Příklad:

„Testy prošly“, ale žádné testy nebyly spuštěny.
„Soubor je upraven“, ale diff neexistuje.
„Podle dokumentace…“, ale odkaz neexistuje.

2. Snowballing hallucination

První malá chyba se dostane do kontextu a další kroky na ní staví.

Příklad:

Agent si splete cestu k souboru.
Pokusí se patchovat špatné místo.
Vysvětlí neexistující architekturu.
Další agent převezme chybný handoff jako fakt.

3. Prompt bloat

Do promptu se přidává všechno. Agent pak ignoruje důležité věci, zpomalí se a začne míchat staré požadavky s novými.

4. Context drift

Agent se odchýlí od původního cíle podle poslední chyby nebo posledního tool outputu.

Příklad:

Úkol je opravit jednu chybu. Po problému s instalací balíčků agent začne refaktorovat celý build systém.

5. Instruction conflict a prompt injection

Různé vrstvy instrukcí chtějí různé věci, nebo externí dokument obsahuje text typu „ignoruj předchozí instrukce“.

Riziko je hlavně u agentů, kteří čtou web, e-maily, issues, dokumenty nebo tool outputy. Externí obsah musí být data, ne instrukce.

6. Repetition loop

Agent opakuje stejný plán, stejný tool call nebo stejný fix bez nové informace.

Typické signály:

stejný failing test znovu a znovu,
„zkusím jiný přístup“, ale přístup je stejný,
dlouhé plánování bez artefaktu,
opakované shrnování místo práce.

7. Tool failure dead end

Nástroj selže a agent chybu špatně vyhodnotí.

Příklady:

timeout,
403/404,
rate limit,
prázdný výstup,
nevalidní JSON,
změněné API schema,
validní odpověď, která ale neodpovídá otázce.

Důležité:

Prázdný výstup není automaticky úspěch.

8. Špatný výběr nástroje

Agent má moc nástrojů, nejasné popisy nebo špatné instrukce. Vybere špatný nástroj, udělá zbytečné side effects nebo ztratí auditovatelnost.

9. Multi-agent echo

Více agentů dojde ke stejnému závěru, ale jen proto, že všichni vyšli ze stejné chyby nebo stejného slabého zdroje.

Shoda více agentů není důkaz. Důkaz je nezávislá verifikace.

Jak to poznat

Varovné signály během práce agenta:

opakuje stejný tool call se stejnými parametry,
po druhém neúspěchu nezmění strategii,
tvrdí ověření bez testu, logu, zdroje nebo artefaktu,
píše dlouhé texty, ale nic nevytváří,
řeší vedlejší problém místo původního cíle,
bere tool output jako instrukci,
completion summary je jen próza bez cest k souborům, testů nebo zdrojů,
přibývá historie, ale žádná komprese ani reset kontextu,
agent tvrdí „hotovo“, ale chybí read-after-write kontrola,
po chybě vysvětluje místo ověřování.

Jednoduchý runtime guard:

if same_error_count >= 2: change_strategy_or_block
if same_tool_call_same_params >= 2: stop_and_replan
if no_new_information_in_last_2_steps: checkpoint_and_stop
if claim_without_evidence: verify_before_continuing
if destructive_action: require_human_approval

Jak tomu předejít

1. Zadávej malé úkoly

Špatně:

Postav celý systém, oprav chyby, napiš dokumentaci a nasaď to.

Lépe:

Cíl: oprav chybu X v souboru Y.
Definition of done: test Z prochází, diff obsahuje jen související změny.
Ověření: spusť konkrétní test a uveď výsledek.
Stop: pokud test dvakrát selže ze stejného důvodu, zablokuj task s důvodem.

2. Drž čistý kontext

Do hlavního promptu patří:

aktuální cíl,
constraints,
zdroj pravdy,
relevantní vstupy,
hotovo-kritéria,
očekávaný výstup.

Mimo hlavní prompt patří:

dlouhé logy,
celé datasety,
staré transkripty,
historické poznámky,
duplicitní dokumentace.

Tyto věci dej raději do souborů nebo retrieval vrstvy a do promptu vlož jen odkazy a stručné shrnutí.

3. Kritické instrukce dej na začátek a do checklistu

Neschovávej důležitá kritéria doprostřed raw logů.

Dobrá struktura task briefu:

Cíl: ...
Definition of done: ...
Zdroj pravdy: ...
Povolené změny: ...
Zakázané změny: ...
Ověření: ...
Stop/eskalace: ...
Výstup: summary + artifacts + tests/sources/evidence.

4. Nástroje musí mít kontrakt

Každý tool by měl mít jasné:

vstupy,
výstupy,
timeout,
typy chyb,
retry pravidla,
co znamená success,
co znamená partial output,
co znamená fatal error.

U write operací používej read-after-write ověření.

5. Nastav limity

Agent bez limitů se snadno rozjede do smyčky.

Používej:

max steps,
timeout per task,
timeout per tool call,
retry budget,
loop detection,
circuit breaker pro externí API,
povinnou eskalaci při chybějících právech nebo nejasném rozhodnutí.

6. Vyžaduj evidence pointery

Sebejistý tón není evidence.

Evidence je:

zdroj,
test output,
log,
diff,
cesta k souboru,
URL,
ID z API,
reprodukovatelný příkaz,
screenshot nebo artefakt.

Completion summary bez evidence je slabý handoff.

7. Testuj agenty na chybách

Nestačí happy path.

Minimální eval suite pro agenta:

splnění definition of done,
správný výběr nástroje,
reakce na prázdný/partial/timeout tool output,
odolnost proti loopu,
dlouhý kontext se šumem,
prompt injection v dokumentu,
kvalita handoffu pro dalšího agenta,
bezpečné chování u destruktivních akcí.

Checklist pro agenty

Před spuštěním

[ ] Cíl je jedna věta.
[ ] Definition of done je explicitní.
[ ] Je jasné, co agent nemá dělat.
[ ] Je jasný výstupní formát.
[ ] Jsou uvedené zdroje pravdy.
[ ] Je jasné, kdy blokovat nebo eskalovat.
[ ] Do promptu jde jen relevantní kontext.
[ ] Raw logy jsou mimo hlavní prompt.
[ ] Staré instrukce jsou odstraněné nebo označené jako historické.
[ ] Kritická kritéria jsou na začátku a v checklistu.
[ ] Nástroje mají timeouty a jasný success/error kontrakt.
[ ] Existuje retry budget a max steps.

Během běhu

[ ] Agent dělá kroky, které přímo vedou k cíli.
[ ] Po chybě mění hypotézu nebo strategii.
[ ] Neopakuje stejný tool call bez nové informace.
[ ] Každé tvrzení o stavu má evidence pointer.
[ ] Tool output je čten jako data, ne jako instrukce.
[ ] Nevzniká jen text bez artefaktu.
[ ] Dlouhá historie se průběžně komprimuje nebo resetuje.

Před dokončením

[ ] Existuje konkrétní artefakt nebo ověřitelný výsledek.
[ ] Proběhl test, kontrola, source check nebo read-after-write.
[ ] Summary obsahuje co vzniklo, kde to je a jak bylo ověřeno.
[ ] Metadata jsou strojově čitelná.
[ ] Nevyřešená rizika jsou explicitně uvedená.

Krátký debug playbook, když se agent zasekne

Zmraz stav. Ulož prompt, kontext, tool transcript, artefakty, model/provider a task metadata.
Klasifikuj selhání. Je to ambiguity, context rot, retrieval failure, tool failure, loop, chybějící oprávnění, model limitace nebo orchestrace?
Najdi první špatný krok. Neřeš jen poslední error. Hledej moment, kdy agent přijal špatný předpoklad.
Ověř zdroj pravdy. Re-run minimální tool call, přečti soubor, zkontroluj API/state.
Zmenši reprodukci. Minimal prompt + minimal context + jeden nástroj.
Přidej guardrail. Incident nemá skončit jen poučením. Má skončit testem, limitem, kontraktem, monitorem nebo lepším handoffem.
Resetni kontext. Pokud je transcript špinavý, spusť nový task s krátkým incident briefem a odkazy na artefakty.

Doporučená architektura agenta

Dobrý agent není jen dlouhý prompt. Je to řízený proces.

Minimum:

Task decomposition Malé úkoly s vlastním done condition.
Context discipline Čistý prompt, artefakty mimo prompt, metadata v handoffu.
Execution limits Max steps, timeouty, retry budget.
Verification Testy, evaly, read-after-write, zdroje.
Observability Trace pro run, tool cally, chyby, latenci, artefakty a rozhodnutí.
Human escalation Jasné block reason, když chybí oprávnění, data nebo rozhodnutí.

Co logovat:

run_id, task_id, parent_task_id,
prompt/template version,
model/provider/version,
context size/token usage,
tool input hash, output summary, latency, status, error class,
artifacts created/modified,
final decision + evidence.

Závěr

AI se nezasekne magicky. Zasekne se, když pravděpodobnostní model pracuje v přeplněném, konfliktním nebo špatně strukturovaném kontextu, bez jasného zdroje pravdy, bez limitů a bez ověření.

Slop je symptom systému, který odměňuje plynulý objem místo evidence.

Řešení není jen „lepší prompt“. Řešení je lepší proces:

menší úkoly,
čistší kontext,
explicitní hotovo-kritéria,
dobré tool kontrakty,
limity,
observability,
evaly,
ověřitelné handoffy,
ochota včas zastavit nebo eskalovat.

Jak funguje AI a proč se dokáže zaseknout

TL;DR

Jak LLM funguje

Proč vzniká AI slop

Velký prompt a context rot

Context rot

Lost in the middle

„Fake long context“

Typické způsoby zaseknutí

1. Hallucination

2. Snowballing hallucination

3. Prompt bloat

4. Context drift

5. Instruction conflict a prompt injection

6. Repetition loop

7. Tool failure dead end

8. Špatný výběr nástroje

9. Multi-agent echo

Jak to poznat

Jak tomu předejít

1. Zadávej malé úkoly

2. Drž čistý kontext

3. Kritické instrukce dej na začátek a do checklistu

4. Nástroje musí mít kontrakt

5. Nastav limity

6. Vyžaduj evidence pointery

7. Testuj agenty na chybách

Checklist pro agenty

Před spuštěním

Během běhu

Před dokončením

Krátký debug playbook, když se agent zasekne

Doporučená architektura agenta

Závěr

Zdroje