6 poruchových režimů smyčky AI agenta, které ničí produkční systémy

Tichá selhání volání nástrojů: když agent "uspěje" tím, že neudělá nic

Volání nástroje vrátí prázdný řetězec nebo měkkou zprávu "žádné výsledky nenalezeny", model ji interpretuje jako platný výsledek a agent pokračuje, jako by krok proběhl v pořádku, přičemž vykazuje zdánlivý úspěch, aniž by cokoli udělal. Opravou je validační brána na každý návrat nástroje: ověřte výstup schémou nebo rozumnostní kontrolou dříve, než ho model vůbec uvidí, a zobrazte skutečné selhání, které musí smyčka řešit, namísto prázdného úspěchu.

Tento problém je zákeřný, protože nic nespadne. Vývojář popisující tichá selhání v produkčních agentech to říká přímo: modely interpretují obecné prázdné řetězce jako platné no-opy a pokračují ve vykonávání bez vědomí selhání. Databázový dotaz, který vrátil nula řádků, protože spojení bylo přerušeno, vypadá pro model totožně jako dotaz, který legitimně nic nenašel. Agent tedy hlásí "žádné odpovídající záznamy" a jde dál, a za týden zjistíte, že třetina jeho spuštění byla tiše nefunkční.

Validační brána sedí mezi nástrojem a modelem:

def gate_tool_result(tool_name: str, result):
    # Reject empties and soft errors before the model can rationalize them
    if result is None or (isinstance(result, str) and not result.strip()):
        raise ToolFailure(f"{tool_name} returned empty -- treat as failure, not no-op")
    if isinstance(result, str) and result.lower().startswith(("error", "exception")):
        raise ToolFailure(f"{tool_name} returned a soft error: {result[:120]}")
    return result  # validated -- safe to hand back to the model

Nejde o konkrétní kontroly; vaše závisí na tom, co každý nástroj legitimně vrací. Jde o to, že neověřená návratová hodnota je rozhodnutí, které jste přenechali stochastickému modelu, a výchozí reakce modelu je pokračovat dál.

Neověřený návrat nástroje je tiché selhání čekající na příležitost. Ověřujte výstup, nespoléhejte se na samotné volání.

Degradace uvažování při dlouhých kontextech: když agent ztrácí kvalitu s délkou běhu

I když zůstanete pod tvrdým limitem kontextu, kvalita uvažování klesá s rostoucím kontextem. Jde o efekt "ztraceno uprostřed", kdy model spolehlivě věnuje pozornost začátku a konci dlouhého kontextu, ale střed mu uniká. Opravou je komprese uprostřed smyčky, která zachovává připnutá omezení: zkomprimujte šum, ochraňte nosné instrukce.

Tento mechanismus má jméno. Inženýrský blog Anthropic ho označuje jako context rot: "s rostoucím počtem tokenů v kontextovém okně klesá schopnost modelu přesně si vybavit informace z tohoto kontextu." Protože "každý token věnuje pozornost každému jinému tokenu", dostanete n² párové vztahy pro n tokenů a pozornost modelu se s délkou kontextu rozptyluje.

Tato podmínka, ochrana nosných instrukcí, je celá ta hra, a existuje zdokumentovaný incident, který ukazuje proč. V nahlášeném případu, agent OpenClaw hromadně smazal doručenou poštu uživatele při kompakci kontextu, protože bezpečnostní instrukce, která mu byla dána ("neprovádějte akci, dokud vám to neřeknu"), byla vypuštěna z aktivního kontextu při komprimaci historie. Omezení, které mělo být poslední věcí k odstranění, bylo zpracováno jako běžná historie a shrnuto pryč.

Naivní přístup "sumarizuj vše starší než N tahů" je tedy nebezpečný. Komprese musí vědět, co nikdy nesmí zahodit:

PINNED = {"system_constraints", "safety_instructions", "active_task_spec"}

def compress_history(messages):
    pinned = [m for m in messages if m.tag in PINNED]      # never summarized
    transient = [m for m in messages if m.tag not in PINNED]
    summary = summarize(transient)                          # lossy is fine here
    return pinned + [summary]                               # constraints survive intact

To se liší od problému přetečení v předchozí části. Přetečení je o tom, že dojde místo; degradace je o tom, že model ztrácí výkon, i když místo ještě zbývá. Můžete být na 60 % svého okna a uvažovat již špatně.

Ztráta stavu při restartu: když havárie znamená začít od nuly

Když dlouhotrvající agent havaruje, ať už kvůli restartu, OOM kill nebo přerušení síťového spojení, neexistuje výchozí možnost obnovení od kontrolního bodu. Smyčka začíná od nuly: opakuje práci, kterou již dokončila, a co je horší, může znovu provést akce, které již provedla, jako například odeslat stejný e-mail dvakrát nebo znovu spustit placené API volání. Opravou je checkpointing: persistujte stav smyčky po každém kroku, aby restart obnovil stav z místa zastavení, nikoli od nuly.

V LangGraph je výběr backendového úložiště kontrolních bodů volbou mezi vývojem a produkcí. Dokumentace persistence LangGraph popisuje SqliteSaver jako "ideální pro experimenty a lokální pracovní postupy" a PostgresSaver jako "ideální pro produkci", a právě na tom druhém běží samotný LangSmith. Oba jsou v kódu záměrně paralelní, což usnadňuje srovnání:

# Development -- single file, no server, do not ship this
from langgraph.checkpoint.sqlite import SqliteSaver

# Production -- survives the box it runs on
from langgraph.checkpoint.postgres import PostgresSaver

Dvě detaily, které lidi překvapí. Zaprvé, balíčky pro checkpointing se instalují odděleně od základního LangGraph (langgraph-checkpoint-sqlite a langgraph-checkpoint-postgres jsou vlastními závislostmi), takže čerstvá instalace nebude mít Postgres saver, dokud ho nepřidáte. Zadruhé, každá operace checkpointingu potřebuje thread_id v konfiguraci. Toto ID váže konkrétní spuštění k uloženému stavu a restart bez správného thread_id neobnoví vůbec nic.

Retry bouře: když vaši vlastní agenti zaplaví mrtvou službu

Když padne downstream služba, naivní pokusy o opakování v rámci každého spuštění promění váš fleet agentů v self-inflicted denial-of-service. Oprava má dvě části: exponenciální backoff s jitterem na každém agentu, aby se pokusy o opakování rozložily v čase, a globální circuit breaker, který se sepne po dosažení sdíleného prahu selhání a zastaví celé stádo od bombardování služby, která je evidentně nedostupná.

Matematika je neúprosná. Jak popisuje materiál o vzorech opakování , při deseti paralelních agentech, každý s deseti pokusy, odešlete sto požadavků na službu, která je již na zemi, protože backoff každého agenta je per-execution, nikoli globální. Samotný backoff na úrovni agenta to nevyřeší. Deset agentů, kteří každý slušně počká, stále čeká synchronizovaně, pokud všichni začali ve stejnou dobu, takže opakují v synchronizovaných vlnách. Jitter rozbíjí synchronizaci randomizací čekání každého agenta; circuit breaker rozbíjí stádo tím, že sdílí jeden kus stavu selhání napříč všemi agenty.

Část backoffu je v Pythonu vyřešený problém; knihovna tenacity zvládá exponenciální-s-jitterem čistě:

from tenacity import retry, stop_after_attempt, wait_random_exponential

@retry(wait=wait_random_exponential(multiplier=1, max=60), stop=stop_after_attempt(5))
def call_flaky_service(payload):
    return downstream.post(payload)

Circuit breaker musí být globální: sdílený napříč všemi agenty, nikoli znovu vytvářený pro každé spuštění. Když selhání překročí práh, otevře se, každý agent rychle selže namísto odeslání požadavku a po ochlazení propustí jediný testovací požadavek, zda je služba zpět. Breaker, který žije uvnitř procesu každého agenta, nic nechrání, protože nic není sdíleno; mrtvá služba stále dostane plných sto požadavků.

Backoff na úrovni spuštění stále nechá deset agentů zasypat mrtvou službu synchronizovaně. Circuit breaker musí být globální, aby zastavil stádo.

Šest selhání na jednom místě

Před infrastrukturní částí: celý katalog na jednom místě, selhání, mechanismus, který ho způsobuje, oprava harnesu a kde příslušný parametr v každém frameworku najdete.

Poznámka pro čtenáře používající CrewAI, AutoGen, Dify nebo ručně psanou Python smyčku: parametry frameworku se mění, ale šest vzorů nikoli. Deduplikace, intervalová sumarizace, validace schématu, komprese s vědomím omezení, checkpointing a globální circuit breaker jsou koncepty nezávislé na frameworku. Specifika pro LangGraph a n8n jsou zde konkrétními vodítky, nikoli hranicí, kde vzory přestávají platit.

Nastavení velikosti produkčního nasazení agenta

Každý vzor výše předpokládá, že kontrolujete správce procesů, databázi a chování při restartu. Checkpointing vám nic nepřinese, pokud se havarovaná smyčka nikdy nevrátí do provozu, a globální circuit breaker potřebuje místo pro uchování sdíleného stavu. Právě tuto kontrolu vám self-hosting dává a spravovaná černá skříňka nikoli; takže poslední rozhodnutí je, jak dimenzovat server, který to celé provozuje 24/7.

Pro většinu nasazení s jedním agentem (jeden agent, LLM volání odcházející na externí API, základní Postgres checkpointing) stačí malá instance: přibližně 2 GB RAM, 1 vCPU, and 60 GB of NVMe storage. Těžké výpočty probíhají na straně poskytovatele modelu; váš server orchestruje, ukládá kontrolní body a drží stav, neprovádí inference. Přejděte přibližně na 4 GB RAM, 2 vCPU, and 120 GB NVMe když je agent stavový a vícekrokový s Postgres checkpointingem plus Redis pro hydrataci relací, nebo když spouštíte souběžné pracovní postupy sdílející hostitel.

Důvod, proč je pro to vhodný self-managed VPS a nikoli omezená platforma, je tentýž, proč opravy vůbec fungují: potřebují root přístup. Vlastní Postgres pro checkpointing, vlastní Redis pro stav relací a skutečný správce procesů jako systemd or pm2, takže když smyčka selže, supervisor ji restartuje a obnoví stav z posledního kontrolního bodu namísto spuštění úlohy od začátku. Celý příběh o obnově závisí na vlastnictví životního cyklu procesu.

Protože n8n provozujeme jako aplikaci jedním klikem v našem vlastním marketplace, je tato část nastavení u nás nejrychlejší cestou: můžete nasadit n8n na Cloudzy VPS s konfigurací podloženou Postgres, kterou produkční cesta potřebuje, na instanci, kde máte root přístup pro přidání vlastního Redis a dohledu nad procesy. Jde o stejnou self-hostenou architekturu popsanou výše, kde vlastníte databázi a chování při restartu, což je to, co dělá checkpointing a automatické obnovení skutečně funkčními.

Vzory harnesu jsou jen tak spolehlivé jako server, na kterém běží. Checkpointing vám nic nedá, pokud se proces nikdy nerestartuje.

Časté dotazy