6 AI-ügynök hurok-hibamód, amely tönkreteszi a produkciós rendszereket

Néma eszközhívás-hibák: amikor az ügynök "sikeresen" nem tesz semmit

Egy eszközhívás üres karakterláncot vagy egy halvány "nincs találat" üzenetet ad vissza, a modell érvényes eredményként értelmezi, és az ügynök úgy folytatja, mintha a lépés működött volna, látszólag sikeresnek tűnve anélkül, hogy bármit tett volna. A megoldás egy ellenőrzési kapu minden eszközvisszatérésnél: séma-ellenőrzés vagy épszérű ellenőrzés a kimeneten, mielőtt a modell egyáltalán látná, és egy valódi hiba felszínre hozása, amellyel a huroknak foglalkoznia kell, egy üres siker helyett.

Ez azért alattomos, mert semmi sem omlik össze. Egy fejlesztő, aki leírta a néma hibamódokat éles ügynököknél , egyenesen fogalmazott: a modellek az általános üres karakterláncokat érvényes nullműveletként értelmezik, és a hiba tudatossága nélkül folytatják a végrehajtást. Az adatbázis-lekérdezés, amely a kapcsolat megszakadása miatt adott vissza nulla sort, pontosan ugyanúgy néz ki a modell számára, mint a lekérdezés, amely jogosan nem talált semmit. Tehát az ügynök "nincs megfelelő rekord" üzenetet jelent és továbblép, és egy héttel később derül ki, hogy a futások egyharmada csendben volt törött.

Az ellenőrzési kapu az eszköz és a modell közé kerül:

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

A lényeg nem az pontos ellenőrzések; az Öné attól függ, mit ad vissza jogosan minden eszköz. A lényeg az, hogy egy ellenőrizetlen visszatérési érték egy sztochasztikus modellnek átadott döntés, és a modell alapértelmezett mozdulata a folytatás.

Egy ellenőrizetlen eszközvisszatérés néma hiba, amely csak idő kérdése. Ellenőrizze a kimenetet, ne bízzon csak a hívásban.

Gondolkodási romlás hosszú kontextusokban: amikor az ügynök minél tovább fut, annál rosszabbul teljesít

Még ha a kemény kontextuskorlát alatt is marad, a gondolkodási minőség romlik a kontextus növekedésével. Ez a "középen elveszett" hatás: a modell megbízhatóan figyel egy hosszú kontextus elejére és végére, de elveszíti a középső részt. A megoldás a közbülső tömörítés, amely megőrzi a rögzített megkötéseket: tömörítse a zajt, védje a teherhordozó utasításokat.

A mechanizmusnak neve van. Az Anthropic mérnöki blogja így hivatkozik rá: kontextusromlás: "mivel a kontextusablakban lévő tokenek száma növekszik, a modell képessége pontosan visszaidézni az adott kontextusból csökken." Mivel "minden token figyel minden más tokenre," n token esetén n² páros kapcsolatot kap, és a modell figyelme egyre vékonyabbra nyúlik, ahogy a kontextus hossza nő.

Ez a minősítő, védje a teherhordozó utasításokat, ez az egész játék lényege, és van egy dokumentált eset, amely megmutatja, miért. Egy bejelentett esetbenegy OpenClaw ügynök tömegesen törölte egy felhasználó postafiókját kontextustömörítés közben, mert a kapott biztonsági utasítást ("ne tegyél semmit, amíg nem szólok") kiesett az aktív kontextusból, amikor az előzményt tömörítették. A megkötés, amelynek az utolsónak kellett volna maradnia, közönséges előzményként kezelték és összefoglalták.

Tehát egy naiv "foglaljon össze mindent, ami N fordulónál régebbi" veszélyes. A tömörítőnek tudnia kell, mit nem szabad soha eldobnia:

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

Ez különbözik az előző szakaszban leírt túlcsordulási problémától. A túlcsordulás arról szól, hogy elfogy a hely; a romlás arról, hogy a modell rosszabbodik, miközben még van hely. Lehet az ablak 60%-ánál és már rosszul gondolkodhat.

Állapotvesztés újraindításkor: amikor egy összeomlás nulláról kell kezdeni

Ha egy hosszan futó ügynök összeomlik, legyen az újraindítás, OOM-leállítás vagy megszakadt hálózati kapcsolat, alapértelmezés szerint nincs ellenőrzőpontból való folytatás. A hurok nulláról indul: megismétli a már elvégzett munkát, és ami rosszabb, újra végrehajthatja a már megtett műveleteket, például kétszer küldi el ugyanazt az e-mailt vagy újra lefuttat egy fizetős API-hívást. A megoldás az ellenőrzőpontozás: mentse el a hurok állapotát minden lépés után, hogy egy újraindítás ott folytassa, ahol abbahagyta, nem nulláról.

A LangGraph-ban az ellenőrzőpont-háttér megválasztása a fejlesztési és a produkciós út közötti választás. A LangGraph perzisztencia-dokumentációja úgy írja le a SqliteSaver mint "kísérletezéshez és helyi munkafolyamatokhoz ideális", és a PostgresSaver mint "éles üzemhez ideális," és az utóbbit futtatja maga a LangSmith is. A kettő kódban szándékosan párhuzamos, ami könnyen láthatóvá teszi a különbséget:

# 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

Két részlet, amely megcsíp embereket. Először is, az ellenőrzőpont-csomagok a LangGraph magtól külön telepítendők (langgraph-checkpoint-sqlite és langgraph-checkpoint-postgres saját függőségek), tehát egy friss szerveren nem lesz meg a Postgres-mentő, amíg hozzá nem adja. Másodszor, minden ellenőrzőpont-művelethez kell egy thread_id a config-ban. Ez az azonosító köti az adott futást a mentett állapothoz, és egy helytelen thread_id nélküli újraindítás semmit nem tölt vissza.

Újrapróbálkozási viharok: amikor saját ügynökei DDoS-olnak egy leállt szolgáltatást

Ha egy alsóbb szintű szolgáltatás leáll, a naiv futásonkénti újrapróbálkozások az ügynökflottáját önsugárzó szolgáltatásmegtagadássá változtatják. A megoldásnak két fele van: exponenciális visszalépés jitterrel minden ügynökön az újrapróbálkozások időbeli elosztásához, és egy globális megszakító, amely meghúzódik egy megosztott hibaszám után, és megakadályozza az egész csordát abban, hogy egy nyilvánvalóan leállt szolgáltatást ostromoljon.

A matematika könyörtelen. Ahogy egy újrapróbálkozási minták leírása fogalmaz: tíz párhuzamos ügynök, egyenként tíz újrapróbálkozással, száz kéréssel zúdul egy már padlón lévő szolgáltatásra, mert minden ügynök visszalépése futásonkénti, nem globális. Önmagában a per-ügynök visszalépés nem oldja meg. Tíz ügynök, amelyek egyenként szépen visszalépnek, mégis egyszerre lép vissza, ha mind egyszerre indultak, így szinkronizált hullámokban próbálnak újra. A jitter megszakítja a szinkronizációt az egyes ügynökök várakozási idejét véletlenszerűsítve; a megszakító megszakítja a csordát azáltal, hogy egy közös hibainformációt oszt meg köztük.

A visszalépés fele Pythonban megoldott probléma; a tenacity könyvtár tisztán kezeli az exponenciálist jitterrel:

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)

A megszakítónak globálisnakkell lennie: megosztottnak minden ügynök között, nem példányosítva minden futásnál. Ha a hibák átlépnek egy küszöböt, kinyílik, minden ügynök gyorsan kudarcot vall a hívás helyett, és egy lehűlési idő után beenged egyetlen szondát, hogy tesztelje, visszatért-e a szolgáltatás. Egy megszakító, amely minden ügynök saját folyamatában él, semmit nem véd, mert semmi nincs megosztva; a leállt szolgáltatás mégis megkapja a teljes száz kérést.

A futásonkénti visszalépés még mindig engedi, hogy tíz ügynök egyszerre verje a leállt szolgáltatást. A megszakítónak globálisnak kell lennie a csorda megállításához.

A hat hiba egy pillantásra

Az infrastrukturális rész előtt itt a teljes katalógus egy helyen: a hiba, az azt okozó mechanizmus, a keretrendszer-javítás és az, hogy az adott paraméter hol található az egyes keretrendszerekben.

Megjegyzés CrewAI, AutoGen, Dify vagy saját Python-hurkot használó olvasóknak: a keretrendszer paraméterei változnak, de a hat minta nem. A deduplikáció, az időközönkénti tömörítés, a sémaellenőrzés, a megkötés-tudatos tömörítés, az ellenőrzőpontozás és a globális megszakító keretrendszer-agnosztikus fogalmak. Az itt szereplő LangGraph és n8n részletek konkrét kapaszkodók, nem a minták alkalmazhatóságának határa.

Egy produkciós ügynök-telepítés méretezése

A fenti minden minta azt feltételezi, hogy Ön kezeli a folyamatfelügyelőt, az adatbázist és az újraindítási viselkedést. Az ellenőrzőpontozás semmit nem ér, ha egy összeomlott hurok sosem indul újra, és a globális megszakítónak szüksége van egy helyre a megosztott állapot tárolásához. Ez a kontroll pontosan az, amit az önálló üzemeltetés ad, és egy felügyelt doboz nem ad, tehát az utolsó döntés az a szerver méretezése, amely ezt 24/7-ben futtatja.

A legtöbb egy ügynökes telepítésnél (egy ügynök, LLM-hívások külső API-ra mennek, alap Postgres-ellenőrzőpontozás) elegendő egy kis példány: 2 GB RAM, 1 vCPU, and 60 GB of NVMe storage. A nehéz számítás a modelszolgáltató oldalán van; az Ön szervere irányít, ellenőrzőpontoz és állapotot tart, nem futtat inferenciát. Lépjen fel nagyjából 4 GB RAM, 2 vCPU, and 120 GB NVMe ha az ügynök állapotalapú és többlépéses Postgres-ellenőrzőpontozással plusz Redis session-hidratáláshoz, vagy ha párhuzamos munkafolyamatokat futtat, amelyek megosztják a hostot.

Az ok, amiért ez önkezelt VPS-t igényel egy korlátozott platform helyett, ugyanaz, amiért a javítások egyáltalán működnek: root hozzáférés kell. Saját Postgres az ellenőrzőpontozáshoz, saját Redis a session-állapothoz, és egy valódi folyamatfelügyelő, mint például a systemd or pm2, hogy ha egy hurok meghal, a felügyelő újraindítsa, és az utolsó ellenőrzőpontjából töltse vissza, ahelyett, hogy elölről kezdené a feladatot. Ez a teljes helyreállítási történet azon alapul, hogy Ön tulajdonosa a folyamat életciklusának.

Mivel az n8n-t saját piacterünkön one-click alkalmazásként futtatjuk, a beállítás ez a részben a mi oldalunkon a legrövidebb út: telepítse az n8n-t egy Cloudzy VPS-re azzal a Postgres-alapú konfigurációval, amelyre a produkciós útnak szüksége van, egy olyan példányon, ahol rendelkezik root hozzáféréssel a saját Redis és folyamat-felügyelet hozzáadásához. Ez ugyanaz az önállóan futtatott lábnyom, amelyet fentebb leírtunk, ahol Ön tulajdonosa az adatbázisnak és az újraindítási viselkedésnek, ami az ellenőrzőpontozást és az automatikus helyreállítást ténylegesen működővé teszi.

A keretrendszer-minták csak annyira megbízhatók, mint az a szerver, amelyen futnak. Az ellenőrzőpontozás semmit nem ér, ha a folyamat sosem indul újra.

Gyakran ismételt kérdések