6 faalpatronen in AI-agentlussen die productiesystemen kapotmaken

Stille toolaanroepfouten: wanneer de agent "slaagt" door niets te doen

Een toolaanroep geeft een lege string of een zachte "geen resultaten gevonden"-melding terug, het model interpreteert dat als een geldig resultaat, en de agent gaat verder alsof de stap gelukt is, waarbij het lijkt te slagen terwijl het niets doet. De oplossing is een validatiepoort bij elke toolreturn: controleer de uitvoer op schema of sanity voordat het model die ooit te zien krijgt, en geef een echte fout terug die de lus moet afhandelen in plaats van een lege successtatus.

Dit is verraderlijk omdat er niets crasht. Een ontwikkelaar die stille faalpatronen in productieagents beschreef stelde het direct: modellen interpreteren generieke lege strings als geldige no-ops en gaan door zonder bewustzijn van de fout. De databasequery die nul rijen teruggaf omdat de verbinding wegviel, ziet er voor het model identiek uit als de query die legitiem niets vond. De agent rapporteert dus "geen overeenkomende records" en gaat verder, en je ontdekt een week later dat een derde van de runs stilzwijgend defect was.

De validatiepoort zit tussen het tool en het model:

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

Het gaat niet om de exacte checks; die hangen af van wat elk tool legitiem teruggeeft. Het punt is dat een niet-gevalideerde retourwaarde een beslissing is die je aan een stochastisch model hebt overgelaten, en de standaardmove van het model is om door te gaan.

Een niet-gevalideerde toolreturn is een stille fout die wacht te gebeuren. Valideer de uitvoer, vertrouw niet op de aanroep.

Redeneerverval bij lange contexten: wanneer de agent slechter wordt naarmate hij langer draait

Zelfs wanneer je onder de harde contextlimiet blijft, neemt de redeneerkwaliteit af naarmate de context groeit. Dit is het "lost in the middle"-effect, waarbij het model betrouwbaar aandacht besteedt aan het begin en einde van een lange context maar het midden verliest. De oplossing is tussentijdse compressie die vastgezette beperkingen behoudt: comprimeer de ruis, bescherm de dragende instructies.

Het mechanisme heeft een naam. De engineeringblog van Anthropic verwijst ernaar als context rot: "naarmate het aantal tokens in het contextvenster toeneemt, neemt het vermogen van het model om informatie uit die context nauwkeurig terug te halen af." Omdat "elk token aandacht besteedt aan elk ander token," krijg je n2 paarsgewijze relaties voor n tokens, en de aandacht van het model strekt zich dunner uit naarmate de context langer wordt.

Die kwalificatie, bescherm de dragende instructies, is het hele spel, en er is een gedocumenteerd incident dat laat zien waarom. In een gemeld geval, verwijderde een OpenClaw-agent de inbox van een gebruiker in bulk tijdens een contextcompressie, omdat de veiligheidsinstructie die het had gekregen ("voer geen actie uit totdat ik het je zeg") uit de actieve context was verwijderd toen de geschiedenis werd gecomprimeerd. De beperking die als laatste had moeten gaan, werd behandeld als gewone geschiedenis en samengevat.

Een naive "vat alles ouder dan N beurten samen" is dus gevaarlijk. Compressie moet weten wat het nooit mag weggooien:

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

Dit verschilt van het overflow-probleem in het vorige gedeelte. Overflow gaat over het opraken van ruimte; verval gaat over het model dat slechter wordt terwijl er nog ruimte over is. Je kunt op 60% van je venster zitten en al slecht redeneren.

Statusverlies bij herstart: wanneer een crash betekent opnieuw beginnen

Wanneer een langlopende agent crasht, of door een reboot, een OOM kill, of een verbroken netwerkverbinding, is er standaard geen resume-from-checkpoint. De lus begint opnieuw vanaf het begin: hij herhaalt werk dat al gedaan was en, erger nog, kan acties opnieuw uitvoeren die al uitgevoerd waren, zoals hetzelfde e-mailbericht twee keer verzenden of een betaalde API-aanroep opnieuw uitvoeren. De oplossing is checkpointing: sla de toestand van de lus op na elke stap zodat een herstart rehydrateert vanaf waar hij gestopt was in plaats van vanaf nul.

In LangGraph is de keuze van checkpoint-backend de keuze tussen ontwikkeling en productie. LangGraph's persistentiedocs beschrijven SqliteSaver als "ideaal voor experimenten en lokale workflows" en PostgresSaver als "ideaal voor gebruik in productie", en het laatste is wat LangSmith zelf op draait. De twee zijn bewust parallel in code, wat het contrast gemakkelijk zichtbaar maakt:

# 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

Twee details die mensen verrassen. Ten eerste installeren de checkpoint-pakketten apart van core LangGraph (langgraph-checkpoint-sqlite en langgraph-checkpoint-postgres zijn hun eigen afhankelijkheden), dus een verse installatie heeft de Postgres saver niet totdat je hem toevoegt. Ten tweede heeft elke checkpoint-operatie een thread_id in de config nodig. Dat ID koppelt een gegeven uitvoering aan zijn opgeslagen toestand, en een herstart zonder de juiste thread_id rehydrateert niets.

Retry storms: wanneer je eigen agents een uitgevallen dienst DDoS'en

Wanneer een downstreamdienst uitvalt, veranderen naive per-executie-retries je agentfleet in een zelfveroorzaakte denial-of-service. De oplossing heeft twee kanten: exponential backoff met jitter per agent om de retries over de tijd te spreiden, en een globale circuit breaker die activeert na een gedeelde mislukkingsdrempel en de hele groep stopt met het bestoken van een dienst die duidelijk down is.

De wiskunde is meedogenloos. Zoals een retry-patronenbeschrijving het formuleert: met tien parallelle agents die elk tien keer opnieuw proberen, stuur je honderd verzoeken naar een dienst die al plat ligt, omdat de backoff van elke agent per-executie is, niet globaal. Per-agent-backoff alleen lost dit niet op. Tien agents die elk netjes terugdeinzen, deinzen nog steeds tegelijk terug als ze allemaal op hetzelfde moment zijn gestart, dus ze proberen het opnieuw in gesynchroniseerde golven. Jitter verbreekt de synchronisatie door de wachttijd van elke agent te randomiseren; de circuit breaker verbreekt de kudde door een stuk faaltoestand te delen tussen alle agents.

De backoff-helft is een opgelost probleem in Python; de tenacity bibliotheek verwerkt exponentieel-met-jitter correct:

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)

De circuit breaker is de helft die globaalmoet zijn: gedeeld tussen alle agents, niet per executie opnieuw geinstantieerd. Wanneer fouten een drempel overschrijden, opent hij, elke agent faalt snel in plaats van een aanroep te doen, en na een cooldown laat hij een enkele sonde door om te testen of de dienst terug is. Een breaker die in elk eigen agentproces leeft, beschermt niets, omdat niets wordt gedeeld; de uitgevallen dienst krijgt nog steeds de volledige honderd verzoeken.

Per-executie-backoff laat tien agents nog steeds gezamenlijk een uitgevallen dienst bestoken. De circuit breaker moet globaal zijn om de kudde te stoppen.

De zes faalpatronen in een oogopslag

Voordat we naar de infrastructuur gaan, hier is de volledige catalogus op een rij: het faalpatroon, het mechanisme dat het veroorzaakt, de harness-fix, en waar de relevante parameter in elk framework te vinden is.

Een opmerking voor lezers op CrewAI, AutoGen, Dify, of een handgeschreven Python-lus: de framework-parameters wijzigen, maar de zes patronen niet. Deduplicatie, intervalgebaseerde samenvatting, schemavalidatie, beperkingsbewuste compressie, checkpointing en een globale circuit breaker zijn frameworkonafhankelijke concepten. De LangGraph- en n8n-specifics hier zijn concrete handvatten, niet de grens van waar de patronen van toepassing zijn.

Een productie-agentdeployment dimensioneren

Elk patroon hierboven veronderstelt dat je controle hebt over de procesmanager, de database en het herstartgedrag. Checkpointing biedt je niets als een gecrasht proces nooit weer opstart, en een globale circuit breaker heeft een plek nodig om zijn gedeelde toestand te bewaren. Die controle is precies wat zelfhosting je geeft en een beheerde black box niet, dus de laatste beslissing is het dimensioneren van de server die dit 24/7 draait.

Voor de meeste single-agent-deployments (een agent, LLM-aanroepen naar een extern API, basis Postgres-checkpointing) is een kleine instantie voldoende: ongeveer 2 GB RAM, 1 vCPU, and 60 GB of NVMe storage. De zware compute zit aan de kant van de modelprovider; jouw server orkestreert, slaat checkpoints op en houdt toestand bij, maar voert geen inference uit. Stap op naar ongeveer 4 GB RAM, 2 vCPU, and 120 GB NVMe wanneer de agent stateful en meerstaps is met Postgres-checkpointing plus Redis voor sessiehydratie, of wanneer je gelijktijdige workflows draait die de host delen.

De reden dat dit een zelfbeheerde VPS vraagt in plaats van een beperkt platform is dezelfde reden waarom de fixes uberhaupt werken: ze hebben root nodig. Je eigen Postgres voor checkpointing, je eigen Redis voor sessiestatus, en een echte procesmanager zoals systemd or pm2, zodat wanneer een lus wegvalt, de supervisor hem herstart en hij rehydrateert vanuit zijn laatste checkpoint in plaats van de taak opnieuw te beginnen. Dat hele herstelscenario is afhankelijk van het bezitten van de proceslevenscyclus.

Omdat we n8n als een one-click-app in onze eigen marketplace aanbieden, is dat deel van de setup aan onze kant het kortste pad: je kunt n8n deployen op een Cloudzy VPS met de Postgres-backed configuratie die het productiepad nodig heeft, op een instantie waar je root-toegang hebt om je eigen Redis en procestoezicht toe te voegen. Dit is dezelfde zelfgehoste voetafdruk die hierboven beschreven staat, waarbij je eigenaar bent van de database en het herstartgedrag, wat checkpointing en automatisch herstel daadwerkelijk laat werken.

De harness-patronen zijn slechts zo betrouwbaar als de server waarop ze draaien. Checkpointing biedt je niets als het proces nooit herstart.

Veelgestelde vragen