AI agentek élesben: mit tanultunk, amikor multi-agent rendszereket építettünk ügyfeleknek

Mindenki AI agenteket épít 2026-ban. Szinte senki nem futtatja őket élesben. Mi igen — és a demó és a telepítés közötti szakadék szélesebb, mint a legtöbb ember gondolja.

A számok mindent elmondanak: a Lenovo megbízásából készült IDC-kutatás szerint az átlagos szervezet 33 elindított AI-pilotjából csak 4 jutott el élesbe — nagyjából 88% sosem. Nem azért, mert a technológia nem működik. Hanem azért, mert egy agent, ami demóban működik, és egy agent, ami megbízhatóan működik vasárnap hajnali 3-kor, amikor senki nem figyel — két alapvetően különböző mérnöki probléma.

Az elmúlt évben öt ügyfélnek telepítettünk multi-agent rendszereket. Dokumentumfeldolgozó pipeline-ok, ügyfélszolgálati triázs, minőségellenőrzési workflow-k. Mindegyik tanított nekünk valamit, amit egyetlen framework tutorial sem mond el.

Miért hal meg a legtöbb agent pilot

Három gyilkos van, és egyik sem az LLM.

1. Orchestrációs komplexitás

Egyetlen AI agent kezelhető. Három agent, ami egy feladaton koordinál, már elosztott rendszerprobléma. Döntened kell: ki kezd? Mi történik, ha az A agentnek információ kell a B agenttől, de a B agent még dolgozik? Mi van, ha a C agent kimenete érvényteleníti, amit az A agent már megcsinált? Hogyan kezeled a részleges meghibásodásokat?

A legtöbb demó megkerüli ezeket a kérdéseket azzal, hogy az agenteket szekvenciálisan futtatja happy-path adaton. Élesben konkurens végrehajtással, versenyhelyzetekkel, timeout kezeléssel és újrapróbálkozási logikával foglalkozol. Ez már nem AI — ez elosztott rendszermérnökség, az összes fájdalommal együtt.

2. Állapotkezelési rémálmok

Az agenteknek memóriára van szükségük. Nemcsak egyetlen beszélgetésen belül, hanem feladatokon, munkameneteken, meghibásodásokon és helyreállításokon átívelően is. Amikor egy multi-agent workflow a 7-ből a 4. lépésnél meghibásodik, folytathatod a 4. lépéstől? Vagy elölről kell kezdened? Ha a B agent készített egy köztes eredményt és aztán összeomlott, az az eredmény még érvényes? A C agent használhatja?

Ezt a drága úton tanultuk meg. Az első multi-agent telepítésünknek nem volt perzisztens állapota. Amikor a rendszer összeomlott (és az első hónapban hetente összeomlott), minden folyamatban lévő workflow elveszett. Az ügyfeleknek újra be kellett nyújtaniuk a dokumentumokat. Az egész rendszert újraépítettük checkpoint-alapú állapot-perzisztenciával. Minden agent tartós tárolóba írja a kimenetét, mielőtt átadná. Ha bármi összeomlik, az utolsó checkpoint-tól folytatsz, és nem kell az elejétől kezdened.

3. Hibakaszkádok

Ez az, ami éjszaka ébren tart minket. Egy pipeline-ban a hibák elszigeteltek — a 3. lépés rossz kimenete nem érinti az 1. lépés eredményét. Egy multi-agent rendszerben az A agent hallucinációja a B agent bemenete lesz. A B agent magabiztosan feldolgozza. A C agent a B agent kimenetére épít. Mire egy ember felülvizsgálja a végeredményt, három rétegnyi magabiztosan hangzó nonszensz halmozódott össze valamivé, ami hihetőnek tűnik, de teljesen rossz.

Ez megtörtént egy szerződésvizsgáló rendszernél. A kinyerő agent rosszul olvasta a felmondási záradékot. Az elemző agent a rossz záradékra építette kockázatértékelését. Az összefoglaló agent az hibás elemzést kulcsfontosságú megállapításként mutatta be. Az ügyfél majdnem kihagyott egy kritikus szerződéses kötelezettséget, mert a lánc minden agentje magabiztos volt.

LangGraph vs CrewAI — mit használunk valójában

Nem vagyunk ideologikusak a keretrendszerek terén. Mindkettőt használjuk, különböző okokból.

A LangGraph az, amihez éles rendszereknél nyúlunk. Explicit kontrollt ad a végrehajtási gráf felett — melyik agent mikor fut, milyen állapot kerül átadásra köztük, hová kerülnek a checkpointok, hogyan kezelik a hibákat. Több kód, több előzetes komplexitás, de ez a komplexitás a különbség aközött, hogy egy rendszert tudsz hajnali 3-kor debugolni, vagy nem tudod. Több mint 400 cég futtat LangGraph-ot élesben — köztük a Klarna, az Uber, a JPMorgan. Ez nem véletlen. Amikor az állapotkezelés számít, a LangGraph az eszköz.

A CrewAI az, amivel prototípusokat kezdünk. Definiálod az agenteket szerep szerint, adsz nekik eszközöket, és hagyod, hogy a framework kezelje az orchestrációt. Gyors beállítani, intuitív, és kiváló annak bizonyítására, hogy egy multi-agent megközelítés képes megoldani a problémát. 2-3 nap alatt építettünk PoC-kat CrewAI-jal, amelyek LangGraph-fal egy hétbe teltek volna.

A mintánk: a PoC-t CrewAI-jal építjük a megközelítés validálására. Ha az ügyfél zöld utat ad, az éles rendszert LangGraph-fal építjük újra. A PoC bizonyítja a koncepciót. A LangGraph kezeli a valóságot.

Ez nem ideológia. Ez mérnöki munka. Használd a megfelelő eszközt ahhoz a fázishoz, amiben vagy.

A human-in-the-loop minta, ami megmentett minket

A legfontosabb architekturális döntésünk nem keretrendszerekről vagy modellekről szól. Arról szól, hogy tudd, mikor kell a rendszernek megállnia és embert kérdeznie.

Az Anthropic 2026-os agent-kutatása jól fogalmazta meg: azok az agentek sikeresek élesben, amelyek tudják, mikor kell segítséget kérniük. Ezt szívünkre vettük.

Építettünk egy dokumentumfeldolgozó rendszert három agenttel: egy kinyerő agent, ami adatokat húz ki a számlákból, egy validáló agent, ami ellenőrzi a kinyert adatokat a megrendelésekkel szemben, és egy könyvelő agent, ami rögzíti a validált adatokat az ügyfél ERP-jében.

Eredetileg a validáló agent vagy jóváhagyott, vagy elutasított. Bináris. A probléma: az esetek kb. 8%-ában tévedett — vagy rossz adatot hagyott jóvá, vagy jó adatot utasított el. Mindkettő drága hiba.

Hozzáadtunk egy harmadik opciót: bizonytalan. Amikor a validáló agent konfidenciája egy küszöb alá esik, nem dönt. Megjelöli azokat a specifikus mezőket, amelyeknél bizonytalan, és az adott dokumentumot emberi felülvizsgálóhoz irányítja, előre kitöltve azzal, amit helyesnek gondol, és kiemelve, ahol bizonytalan.

A hibaarány 8%-ról 1% alá csökkent. Nem azért, mert a modell okosabb lett — hanem mert a rendszer őszinte lett azzal kapcsolatban, amit nem tudott. Az emberi felülvizsgálatok egyenként kb. 45 másodpercet vesznek igénybe, és a dokumentumok csak ~12%-ánál fordulnak elő. A 88%, ahol a rendszer magabiztos, érintés nélkül halad át.

Ez a minta — magas konfidenciájú automatizáció emberi eszkalációval bizonytalanság esetén — most az alapértelmezett architektúránk minden multi-agent rendszerhez, amit építünk.

Mi romlik el először

Öt éles telepítés után ez a rangsorolt listánk arról, ami elromlik:

1. Állapot-perzisztencia agent-átadásoknál

Amikor az A agent befejezi és átadja a B agentnek, az átadás a törékeny pont. Ha a rendszer az átadás közben omlik össze, elveszítheted az eredményt. Ha az A agent kimeneti formátuma enyhén megváltozik, a B agent nem biztos, hogy értelmezi. Most típusos állapot-sémát használunk verziókezeléssel — minden agent egy megosztott állapotobjektumba olvas és ír, explicit mezőtípusokkal és validációval.

2. Költségmeglepetések

Egy rosszul korlátozott agent-hurok pénztűz. Volt egy korai rendszerünk, ahol a kutató agent feladata "releváns információ keresése" volt. Korlátok nélkül egyetlen futás során 847 API hívást indított, egyre távolabbi szálakat követve. Az éjszakai számla 3400 dollár volt azért, aminek 2 dolláros feladatnak kellett volna lennie.

Minden agentnek most kemény korlátai vannak: maximális iteráció, maximális token futásonként, maximális költség feladatonként. Ha bármely korlát teljesül, az agent leáll és eszkalál. Inkább legyen hiányos az eredmény, mint meglepetés számla.

3. Hibakaszkádok hallucinációból

Ahogy fentebb leírtam — az egyik agent hallucinációja a másik agent megbízható bemenete lesz. A megoldásunk: minden agent, ami egy másik agent kimenetét dolgozza fel, alap szaniter-ellenőrzést futtat. Úgy néz ki, mint az adattípus, amit várok? A számok ésszerű tartományban vannak? Jelen van ez a mező? Ez a kaszkádoló hibák kb. 70%-át elkapja, mielőtt összeadódnának.

Amikor nincs szükséged agentekre

Ez talán a legértékesebb dolog, amit megtanultunk: néha egyáltalán nincs szükséged agentekre.

Az elmúlt évben háromszor beszéltünk le ügyfeleket agent-architektúrákról. Mindhárom esetben valójában egy jól megtervezett pipeline-ra volt szükségük feltételes logikával. Ha a bemenet A típusú, csináld ezt. Ha B típusú, csináld azt. Ha bizonytalan, kérdezz egy embert.

Ez nem agent. Ez egy folyamatábra LLM-mel bizonyos döntési pontokon. Egyszerűbb megépíteni, egyszerűbb debugolni, egyszerűbb karbantartani és olcsóbb futtatni. Nincs orchestrációs komplexitás, nincs állapotkezelés, nincsenek hibakaszkádok.

A kérdés nem az, hogy "használhatunk-e agenteket?" Hanem: "az agentek megoldanak-e egy problémát, amit egy pipeline nem tud?" Az agentek akkor érik meg a komplexitásukat, amikor a feladat valódi tervezést, adaptációt és mérlegelést igényel több lépésben — amikor az agentnek el kell döntenie, mit csináljon ezután az alapján, amit az imént megtanult. Ha a workflow kiszámítható, a pipeline mindig legyőzi az agenteket.

Az őszinte igazság

Az agentek nem varázslat. Mérnöki munka. És a mérnöki munka nehezebb, mint amit bárki, aki agent-keretrendszert ad el neked, elismer. Az orchestráció nehéz. Az állapotkezelés nehéz. A hibakezelés nehéz. A költségkontroll nehéz.

De amikor a probléma valóban összetett — amikor tervezést, adaptációt és mérlegelést igényel több lépésben — az agentek olyan eredményeket hoznak, amiket egyetlen statikus pipeline sem tud. Láttunk dokumentumfeldolgozó rendszereket olyan éles eseteket kezelni, amelyekhez korábban ember kellett. Láttunk triázs rendszereket olyan árnyaltsággal irányítani ügyeket, amit egyetlen szabályfa sem tudott befogni.

Csak győződj meg róla, hogy a megfelelő okból építed őket. És győződj meg róla, hogy az agentjeid tudják, mikor kell segítséget kérniük.