Az ügynök, amelyik szól, ha elakad: az AI-ügynök hibakezelése a Moveworks és a Muse Spark 1.3 tanulságaival

Szeptember első felében két olyan bejelentés jelent meg az AI-ügynökök piacán, amely első ránézésre apróságnak tűnik, mégis többet elárul a technológia érettségéről, mint bármelyik benchmarkrekord. A Meta Muse Spark 1.3 modellje kérdez, ha nem érti a feladatot, elakadáskor pedig bevonja a felhasználót. A Moveworks szeptember 14-én úgy frissítette a saját modelljét, hogy a sikertelen eszközhívások többé ne látszódjanak sikeresnek. Az AI-ügynök hibakezelése eddig a legtöbb cégnél abból állt, hogy valaki hetekkel később, egy bosszús ügyfél telefonja után jött rá, hogy a rendszer szerint elvégzett feladat valójában soha nem készült el.

Egy 5 és 50 fő közötti magyar cégnél ez a különbség nagyon kézzelfogható: az egyik esetben az ügynök egy Slack-üzenetben jelzi, hogy nem tudta rögzíteni a megrendelést, a másikban a megrendelés egyszerűen eltűnik, a vevő pedig a konkurenciánál köt ki. A 2026. szeptember 22-i állapot szerint összeszedtük, miért veszélyesebb a csendben elbukó művelet a látványos összeomlásnál, hogyan tanítsd meg az ügynököt kérdezni és beismerni a kudarcot, hogyan építs hibaágakat az n8n-ben újrapróbálkozással, tartalék útvonallal és emberi eszkalációval, végül azt is, mikor elég egy Slack-üzenet és mikor kell valakit felhívni. A cégpéldák szemléltető jellegűek, a forintos számítások becslések, ezek menetét mindenhol megmutatjuk.

Röviden

• A Moveworks 2026. szeptember 14-i modellfrissítése óta a sikertelen vagy üres eszközhívások explicit hiba-, illetve „nincs találat” állapotot és felhasználói útmutatást adnak vissza, ahelyett hogy sikeresnek látszanának.
• A Meta Muse Spark 1.3 modellje a MarkTechPost szeptember 3-i beszámolója szerint kétértelmű kérésnél tisztázó kérdést tesz fel, elakadáskor bevonja a felhasználót, a következményes lépések előtt pedig megerősítést kér.
• A legdrágább ügynökhiba a csendes hiba, vagyis az a művelet, amely a naplóban sikeresnek látszik, a valóságban viszont nem történt meg, ezért napokig vagy hetekig senki sem veszi észre.
• Az n8n-ben a hibakezelés a node-szintű újrapróbálkozásra (Retry On Fail), a hibakimenetre (Continue (using error output)), a tartalék útvonalakra, az Error Trigger node-dal induló hibakezelő munkafolyamatra és az AI-ügynök eszközeinél beállítható emberi jóváhagyásra épül.
• Riasztásnál a Google SRE-könyvének elve a jó iránytű: telefonhívás csak akkor indokolt, ha a hiba már az ügyfeleket vagy a bevételt érinti és azonnali emberi döntés kell hozzá, minden más mehet Slackre, jegybe vagy napi összesítőbe.

Mi történt a Moveworksnél és a Muse Spark 1.3-mal?

A Moveworks 2026. szeptember 14-én olyan modellfrissítést adott ki, amely után a sikertelen vagy üres eszközhívások kifejezett hiba-, illetve „nincs találat” állapotot adnak vissza a látszólagos siker helyett. A Meta szeptember elején megjelent Muse Spark 1.3 modellje pedig kérdez, ha nem érti a feladatot, elakadás esetén jelez, a következményes lépések előtt megerősítést kér.

A Moveworks nagyvállalati AI-asszisztenst és ügynökplatformot fejleszt, amelyet jellemzően munkatársi ügyintézésre, például IT-helpdeskre, HR-kérdésekre vagy jogosultságkérésekre használnak. Az aiagentstore.ai heti összefoglalója szerint a szeptember 14-i frissítés lényege egyetlen mondatban elfér, saját fordításunkban: a sikertelen vagy üres eszközhívások „explicit hiba- vagy nincs-találat állapotot és felhasználói útmutatást adnak vissza, ahelyett hogy sikeresnek látszanának”. Az összefoglaló azt is kiemeli, miért lényeges mindez: a csendben elbukó eszközhívások az ügynökrendszerek megbízhatatlanságának gyakori forrásai, a világos hibaállapotok viszont megkönnyítik a hibakeresést, csökkentik a felhasználók zavarát, továbbá biztonságosabbá teszik az újrapróbálkozást és a tartalék útvonalakat.

Az eszközhívás (angolul tool call) az a pillanat, amikor a nyelvi modell nem szöveget ír, hanem egy külső rendszert szólít meg: lekérdez egy CRM-rekordot, időpontot foglal a naptárban vagy jegyet nyit a helpdeskben. Az ügynök ereje ezekben a hívásokban rejlik, a gyenge pontja viszont ugyanitt van, hiszen a modell csak annyit tud a külvilágról, amennyit az eszköz visszaüzen neki. Ha az eszköz hallgat vagy félrevezetően fogalmaz, a legokosabb modell is rossz következtetésre jut.

A Meta Muse Spark 1.3 modelljét a MarkTechPost 2026. szeptember 3-i cikke hosszú feladatokra tervezett, ügynöki kódolási modellként mutatta be. A leírás szerint a modell kétértelmű kérésnél tisztázó kérdést tesz fel, bevonja a felhasználót, amikor elakad, a következményes lépések előtt pedig megerősítést kér. A cikk külön kiemeli a modell pontosabb önismeretét, amit saját fordításunkban így lehet visszaadni: a Muse Spark 1.3 „jelzi az akadályokat ahelyett hogy kitalálna egy eredményt”. Mindez takarékosabb működéssel párosul, hiszen az elődjéhez képest nagyjából 20%-kal kevesebb eszközhívással és körülbelül 25%-kal kevesebb tokennel dolgozik, az ára pedig maradt 1,25 dollár millió bemeneti és 4,25 dollár millió kimeneti tokenenként. A token a szövegfeldolgozás alapegysége, nagyjából egy szótagnyi vagy rövid szónyi szövegdarab, az API-díjakat ez alapján számolják.

A két hír nem elszigetelt jelenség. Az OpenAI szeptember 3-án bemutatott GPT-6 Astra modelljéről a cég azt közölte, hogy háromszor kisebb eséllyel állítja hamisan a saját képességeit, belső tesztjein pedig 0% arányban lépte túl a kapott jogosultsági kört, míg az elődje, a GPT-5.6 Sol, ugyanitt 48%-ot mutatott. A gyártók láthatóan rájöttek, hogy az üzleti ügyfelek nem feltétlenül a legokosabb, hanem a legmegbízhatóbb ügynököt keresik, a megbízhatóság pedig nagyrészt azon múlik, hogy a rendszer tudja-e, mit nem tud.

Hogy hibamentes ügynökre ma sem lehet számítani, azt az Artificial Analysis és a Zapier 2026. július 6-án közzétett AutomationBench-AA mérése is mutatja: a 657 üzleti feladaton a legjobb modell is csak a feladatok 48,6%-át oldotta meg, ráadásul minden tesztelt modell megsértett üzleti szabályokat. A hiba tehát elkerülhetetlen, az viszont rajtad múlik, hogy látszik-e.

Miért veszélyes a „sikeres” hibás művelet?

A „sikeres” hibás művelet azért veszélyes, mert senki sem keresi: a napló zöld pipát mutat, az ügynök magabiztosan visszaigazol, a hiba pedig csak napokkal később, egy reklamáló ügyfélnél vagy a havi zárásnál bukkan fel. Addigra a kár megsokszorozódik, a kiváltó ok felderítése pedig órákig tart.

A csendes hiba (angolul silent failure) olyan hibás működés, amely semmilyen riasztást, hibaüzenetet vagy piros jelzést nem vált ki, ezért a rendszer minden mérőszáma szerint rendben van, miközben a várt eredmény nem jött létre. A látványos hibával, amikor az egész munkafolyamat leáll és valaki azonnal kap egy értesítést, sokkal könnyebb együtt élni, mert legalább tudod, hogy baj van, sőt többnyire azt is, hol kell keresni.

Öt út, amelyen a hiba sikernek álcázza magát

• A rendszer sikert jelez, a tartalom hibát. Sok webes szolgáltatás akkor is 200-as HTTP-státuszkódot, vagyis „rendben” jelzést küld vissza, ha a válasz törzsében hibaüzenet áll, például hogy egy kötelező mező hiányzott. Ha a munkafolyamat csak a státuszkódot nézi, a hibát sikernek könyveli el.
• Az üres válasz sikernek látszik. A keresés nem talált semmit, de nem azért, mert nincs mit találni, hanem mert lejárt a hozzáférési token vagy megváltozott egy mezőnév. Az ügynök ebből azt a következtetést vonja le, hogy nincs új tétel, ami formailag helyes válasz egy rosszul feltett kérdésre.
• A modell kitalálja az eredményt. Az eszköz hibát adott vissza, a nyelvi modell viszont a beszélgetés gördülékenysége kedvéért mégis azt írja, hogy „rögzítettem az időpontot”. Ezt a jelenséget hívják hallucinációnak, a Muse Spark 1.3 leírása szerint pedig a modell ilyenkor inkább jelzi az akadályt.
• A munkafolyamat átlép a hibán. Az automatizációs eszközökben gyakran van olyan beállítás, amellyel a folyamat a hiba ellenére továbbhalad. Ez kényelmes megoldás, ha azonban nincs mögötte hibaág, a következő lépések régi vagy üres adatokkal dolgoznak tovább.
• A részleges siker egésznek látszik. Az 50 tételes árlistafrissítésből 47 átment, három elakadt, az összefoglaló pedig annyit mond, hogy a frissítés lefutott.

Vegyünk egy képzeletbeli budapesti könyvelőirodát, ahol egy ügynök minden reggel lekérdezi az ügyfelek bejövő számláit a NAV Online Számla rendszeréből, majd előkészíti a könyvelést. Tegyük fel, hogy az egyik ügyfél egy csütörtöki napon új technikai felhasználót hoz létre a NAV-rendszerben, a régit pedig törli, erről viszont senki sem szól az irodának. A lekérdezés hitelesítési hibát ad, a munkafolyamat azonban úgy van megírva, hogy hiba esetén üres listával menjen tovább, így az ügynök azt jelenti: „ennél az ügyfélnél ma nincs új számla”. Másnap ugyanez történik, a probléma pedig csak a hónap végi zárásnál derül ki, amikor a bejövő számlák jó része hiányzik az áfabevallás előkészítéséből. Egy explicit hibaállapot („a NAV-lekérdezés hitelesítési hiba miatt nem futott le, a technikai felhasználó adatait ellenőrizni kell”) már az első reggelen egy ötperces javítással megoldotta volna a helyzetet.

Egy másik képzeletbeli eset: egy 14 fős győri autószerviz ügynöke a weboldalon foglal időpontot. A naptárszolgáltatás ütközést jelez, mert az adott órára közben telefonon már beírtak valakit, az ügynök viszont túlbuzgó segítőkészségből mégis visszaigazolja a foglalást, így két autó áll a műhely előtt ugyanarra az órára. Egy ilyen hiba nem kerül sokba forintban, a bizalomban viszont annál többe.

A látványos és a csendes hiba közötti különbség leginkább időben mérhető. A leálló munkafolyamatnál a hiba és az észlelés között percek telnek el, a csendes hibánál napok vagy hetek, közben pedig a hibás adatok továbbterjednek: bekerülnek a CRM-be, a számlázóba, a heti riportba, onnan pedig a vezetői döntésekbe. A javítás ilyenkor már nem egyszerű újrafuttatás, hanem hosszadalmas nyomozás.

A csendes hiba árulkodó jelei a saját folyamataidban

Nem kell megvárnod az első reklamációt ahhoz, hogy kiderüljön, hibáznak-e csendben az automatizációid. A csendes hibák jellegzetes nyomot hagynak a naplókban és a számokban, ezeket pedig fejlesztői tudás nélkül is át lehet nézni egy délután alatt.

A táblázat oldalra húzható ↔

A leghatékonyabb védelem ezek közül a független egyeztetés (angolul reconciliation): naponta egyszer egy külön, egyszerű lekérdezés összeveti, hogy amit az ügynök elvégzettnek jelentett, az valóban ott van-e a célrendszerben. Ha az ügynök szerint tegnap 38 időpontot foglalt, a naptárban viszont csak 36 új bejegyzés szerepel, akkor két hibát már azelőtt megtaláltál, hogy bármelyik ügyfél telefonált volna. A módszer azért működik, mert nem az ügynök önbevallására épít, hanem egy tőle független forrásra. Tapasztalatunk szerint a hetek óta tartó 0%-os hibaarány is inkább gyanús, mint megnyugtató, hiszen egy egészséges rendszerben mindig akad néhány hiba, amelyet a hibakezelés elkap és naplóz.

Mit jelent a tisztázó kérdés és az explicit hibaállapot?

A tisztázó kérdés az, amikor az ügynök a munka megkezdése vagy egy visszafordíthatatlan lépés előtt rákérdez arra, amit a kérésből nem lehet egyértelműen eldönteni. Az explicit hibaállapot olyan, géppel és emberrel is olvasható visszajelzés, amely kimondja, hogy a művelet nem sikerült, miért nem, mi történt meg mégis és mi a következő lépés.

A két fogalom ugyanannak az éremnek a két oldala. A tisztázó kérdés a munka elején előzi meg a hibát, az explicit hibaállapot pedig munka közben vagy a végén teszi láthatóvá. Mindkettő mögött ugyanaz a képesség áll, amelyet a szakma kalibrációnak hív: a modell reálisan felméri, mennyire biztos a dolgában, majd ennek megfelelően cselekszik, vagyis magabiztosan halad, ha van rá oka, ha pedig nincs, megáll.

Mikor kérdezzen az ügynök és mikor döntsön egyedül?

A túl sokat kérdező ügynök ugyanolyan használhatatlan, mint a túl magabiztos. Senki sem vágyik olyan digitális munkatársra, amely minden második lépésnél visszakérdez, hogy biztosan a céges fejléces sablont használja-e. A jó szabály egyszerű: az ügynök akkor kérdezzen, ha a lehetséges félreértés drágább, mint maga a kérdés, vagyis a várakozás és a felhasználó megzavarása. A gyakorlatban három helyzet indokolja a kérdést:

• A kérés többféleképpen érthető, az értelmezések pedig eltérő, nehezen visszafordítható eredményhez vezetnek, ilyen lehet egy dátum, egy mennyiség vagy egy címzett.
• Hiányzik egy kötelező adat, amelyet az ügynök nem tud megbízhatóan kikövetkeztetni, például a számlázási cím vagy az adószám.
• A kérés ütközik egy üzleti szabállyal, például a kért kedvezmény meghaladja azt a keretet, amelyet az ügynök önállóan megadhat.

Vegyünk egy képzeletbeli balatoni panziót, ahol egy ügynök válaszol a foglalási érdeklődésekre. Csütörtök este érkezik egy üzenet: „Jövő hétvégére kérnénk két szobát.” Csütörtökön a jövő hétvége egyeseknek a két nap múlva kezdődő, másoknak a kilenc nap múlva kezdődő hétvégét jelenti, a két értelmezés pedig két teljesen különböző foglalást eredményez. Itt egyetlen kérdés („Erre a hétvégére vagy a következőre gondolsz?”) néhány másodpercébe kerül a vendégnek, míg egy rossz dátumra rögzített foglalás lemondással, kárpótlással vagy egy csalódott értékeléssel járhat. Ha viszont a vendég azt kérdezi, van-e parkoló, az ügynöknek nincs mit tisztáznia, egyszerűen válaszol.

Az OpenAI a GPT-6 Astra bejelentésében egy okos mintát is bemutatott: a Codex fejlesztői környezetben a modell úgy tud tisztázó kérdést feltenni, hogy közben a kérdéstől független munkarészeken tovább dolgozik. Egy KKV-s folyamatban ez azt jelenti, hogy ha egy árajánlathoz hiányzik a szállítási cím, az ügynök rákérdez, közben pedig már kiszámolja a tételeket, így a válasz után csak a szállítási díjat kell hozzáadnia.

Hogyan néz ki egy jó hibaüzenet?

Az explicit hibaállapot egyszerre két közönségnek szól. Az egyik a modell, amelynek el kell döntenie, mi legyen a következő lépés, a másik az ember, akinek a végén meg kell értenie, mi történt. Egy jó hibaüzenet ezért öt dologra felel: mi nem sikerült, miért nem, mi történt meg mégis, mit javasol a rendszer és kihez lehet fordulni.

Az egyik véglet a klasszikus „Hiba történt, kérjük, próbálja újra később” üzenet, amely se a modellnek, se az ügyfélnek nem ad fogódzót. A másik egy olyan válasz, amilyet egy képzeletbeli webshop ügynöke adhatna: „A megrendelést nem tudtam teljes egészében rögzíteni, mert a 4417-es cikkszámú termék készlete időközben elfogyott. A másik két tételt félretettem, ezek holnap délig foglaltak. Ajánlhatom helyette a hasonló 4418-as terméket, vagy kollégánk holnap délelőtt felhív a megadott számon.” A Moveworks-frissítés leírásában szereplő felhasználói útmutatás pontosan ezt a második felet jelenti: a felhasználó ne csak azt tudja meg, hogy baj van, hanem azt is, mit tehet.

Mit írj a rendszerpromptba?

A rendszerprompt az ügynök állandó munkaköri leírása, amelyet minden beszélgetés előtt megkap. A hibakezelési viselkedés jó része itt dől el, ezért ide érdemes néhány egyértelmű szabályt felvenni:

• „Soha ne állítsd, hogy egy művelet sikerült, ha az eszköz nem adott vissza kifejezett sikeres állapotot.”
• „Ha egy eszköz hibát jelez, mondd el a felhasználónak egyszerű nyelven, mi nem sikerült, majd ajánlj következő lépést.”
• „Ha a kérés kétféleképpen érthető és a lépés nem vonható vissza, kérdezz, mielőtt cselekszel.”
• „Ha ugyanaz a hiba kétszer egymás után előfordul, ne próbálkozz tovább, hanem add át az ügyet egy kollégának.”
• „Az üres találati lista nem hiba, de mindig mondd el, pontosan mit kerestél és hol.”

Ezek a mondatok önmagukban nem garantálnak semmit, hiszen a nyelvi modell a promptot sem követi száz százalékos pontossággal. A hibakezelésnek ezért a munkafolyamat szintjén is meg kell jelennie, ahol már nem a modell jóindulatán múlik, hogy a hiba kiderül-e.

Milyen állapotokat adjon vissza egy eszköz az ügynöknek?

Egy jól megtervezett eszköz legalább hat, egymástól egyértelműen elkülönülő állapotot ad vissza: sikert, üres találatot, részleges sikert, átmeneti hibát, végleges hibát és jogosultsági hibát. Ehhez jön még a tisztázást és a jóváhagyást kérő állapot, hogy az ügynök mindegyik esetben tudja, mi a helyes következő lépés.

Eszköz alatt itt minden olyan kapcsolódási pontot értünk, amelyet az ügynök meghívhat: egy webshop-API-t, egy n8n-munkafolyamatot, egy MCP-szervert vagy egy saját fejlesztésű végpontot. Az MCP (Model Context Protocol) az AI-eszközök csatlakoztatásának nyílt szabványa, amelynek eszközválaszaiban eleve van egy külön jelző (isError) arra, hogy az eszköz futása hibával zárult. A legtöbb házilag összerakott integráció viszont csak annyit tud mondani, hogy „ok” vagy „hiba”.

A táblázat oldalra húzható ↔

A státuszkódok a webes szolgáltatások szabványos válaszjelzései: a 2xx kezdetű kódok a sikert, a 4xx kezdetűek a kérés hibáját, az 5xx kezdetűek a szolgáltatás oldali hibát jelzik. A 429-es kód azt jelenti, hogy rövid idő alatt túl sok kérés érkezett, ez tipikusan átmeneti állapot, amelyen egy kis várakozás segít.

Idempotencia: amikor az újrapróbálkozás maga a hiba

Az idempotens művelet olyan művelet, amelyet többször végrehajtva ugyanaz az eredmény, mint egyetlen végrehajtás után. Egy ügyfél adatainak lekérdezése vagy egy megrendelés állapotának „teljesítve” értékre állítása ilyen. A nem idempotens művelet minden futásnál újabb hatást vált ki, ilyen az e-mail kiküldése, egy számla kiállítása vagy egy utalás indítása.

Az újrapróbálkozás igazi csapdája itt rejlik. Ha a számlázó rendszer időtúllépéssel válaszol, abból nem tudod, hogy a számla elkészült-e: lehet, hogy a kérés el sem jutott a rendszerig, de az is lehet, hogy a számla megszületett, csak a válasz veszett el útközben. Egy vakon beállított újrapróbálkozás ilyenkor két számlát állít ki. Egy magyar cégnél ez különösen kellemetlen, mert a kiállított és a NAV Online Számla rendszerébe beküldött számla nem törölhető, csak érvénytelenítő számlával javítható, ami plusz adminisztrációt és kínos magyarázkodást jelent a vevő felé.

A megoldás kétféle lehet. Az egyik az idempotenciakulcs, vagyis egy egyedi azonosító, amelyet a kérés magával visz, a fogadó rendszer pedig ennek alapján felismeri és eldobja az ismételt kérést, feltéve hogy támogatja ezt a megoldást. A másik az ellenőrző lekérdezés: újrapróbálkozás előtt a munkafolyamat megnézi, létrejött-e már számla az adott rendelésszámmal, újra pedig csak akkor próbálkozik, ha nem talált ilyet.

Hibaágak tervezése n8n-ben: retry, fallback, emberi eszkaláció

Az n8n a Sustainable Use License alatt, úgynevezett fair-code modellben terjesztett munkafolyamat-automatizáló platform, amely több mint 1 500 integrációt kínál felhős és saját szerveres (self-hosted) változatban is. A hibakezelése öt eszközre épül, ezeket vesszük sorra az alábbiakban.

A node az n8n munkafolyamatának egy lépése, például egy Gmail-művelet, egy HTTP-kérés vagy egy AI Agent. A beállítások neveit az n8n hivatalos dokumentációja szerint adjuk meg, hogy a felületen is könnyen megtaláld őket.

Újrapróbálkozás a Retry On Fail beállítással

Az n8n dokumentációja szerint a Retry On Fail bekapcsolásakor a node hiba esetén újrafut, amíg nem sikerül, a próbálkozások számát és a köztük eltelt várakozási időt pedig a node beállításainál adhatod meg. Ez az átmeneti hibák ellenszere: ha egy külső szolgáltatás éppen túlterhelt, vagy a hálózat egy pillanatra megakad, a második vagy harmadik próbálkozás jó eséllyel átmegy. További előnye, hogy a node-szintű újrapróbálkozás nem hívja meg újra a nyelvi modellt, így tokenköltséget sem termel.

Három szabályt érdemes betartani. Először is csak ott kapcsold be, ahol a hiba jellemzően átmeneti, vagyis külső API-hívásoknál és adatbázis-kapcsolatoknál, mert a saját logikai hibáidon az újrapróbálkozás nem segít. Másodszor ügyelj a várakozási időre, mert egy percenkénti kéréskorlátot túllépő hívásnál hiába próbálkozol újra fél másodperc múlva. Harmadszor soha ne kapcsold be vakon nem idempotens műveletnél, például számlakiállításnál vagy e-mail-küldésnél, ha előtte nem ellenőrzöd, hogy az előző próbálkozás valóban nem ment át.

Hibaág az On Error beállítással

A node beállításai között az On Error mezőben dől el, mi történjen, ha a node az újrapróbálkozások után is hibára fut. A dokumentáció három lehetőséget ír le:

• Stop Workflow: a teljes munkafolyamat leáll a hibánál, a további node-ok nem futnak le. Ez a biztonságos alapviselkedés, ilyenkor a beállított hibakezelő munkafolyamat is elindul.
• Continue: a munkafolyamat a hiba ellenére továbblép a következő node-ra az utolsó érvényes adatokkal. Ezzel a beállítással a legkönnyebb csendes hibát gyártani, mert a folyamat zölden fut végig, miközben egy lépés valójában nem teljesült.
• Continue (using error output): a node kap egy külön hibakimenetet, amelyen a hiba adatai a következő node-ra kerülnek, így a hibás tételeket külön ágon kezelheted.

A gyakorlati ajánlásunk egyszerű. Ahol a munkafolyamatnak hiba esetén is tovább kell mennie, mert például 200 tételből egyetlen hibás tétel miatt nem akarod leállítani a többit, ott a Continue (using error output) lehetőséget válaszd, a hibakimenetre pedig köss egy ágat, amely naplóz, értesít vagy emberi feldolgozásra tesz félre. A sima Continue opciót csak akkor használd, ha tényleg mindegy, sikerült-e a lépés, ilyen helyzet viszont ritkábban fordul elő, mint gondolnád.

Hasonló óvatosságot kíván az Always Output Data beállítás, amely a dokumentáció szerint akkor is egy üres elemet ad vissza, ha a node nem kapott adatot. Hasznos, ha a munkafolyamatnak mindenképp tovább kell futnia, pontosan így születik viszont az a helyzet, amikor egy üres CRM-keresés után a következő node létrehoz egy név nélküli ügyfelet. A „nincs találat” esetét inkább egy If node-dal kezeld külön ágon, ahogyan a Moveworks is külön állapotként kezeli.

Tartalék útvonal: a B terv, ha az A nem működik

A fallback olyan előre megtervezett tartalék útvonal, amely akkor lép életbe, ha az elsődleges megoldás nem működik. Egy ügynök-munkafolyamatban ez többféle lehet: egy másik szolgáltató API-ja, egy másik nyelvi modell, egy korábban elmentett adat vagy egyszerűen egy tisztességes visszalépés, például: „A szállítási időt most nem tudom lekérdezni, kollégánk két órán belül e-mailben megírja.”

Az n8n dokumentációja külön példát hoz az emberi tartalékra (human fallback). A Chat Trigger node-dal induló beszélgetésben az AI Agent egy „Not sure?” nevű eszközt hív meg, ha nem tudja biztosan a választ. Ez az eszköz egy külön munkafolyamat, amely If node-dal ellenőrzi, megadta-e a felhasználó az e-mail-címét: ha igen, Slack-üzenetet küld az ügyfélszolgálati csatornára, ha nem, udvariasan elkéri. A mintában az a szép, hogy a bizonytalanság nem zsákutca, hanem egy eszköz, amelyet a modell ugyanúgy használhat, mint bármely másikat.

Modellszintű tartaléknál tartsd szem előtt, hogy két modell nem egyformán viselkedik ugyanarra a promptra, ezért a tartalék modellt is teszteld a saját feladataidon. Az árkülönbség is számít: a Muse Spark 1.3 millió kimeneti tokenje 4,25 dollár, a GPT-6 Astráé 50 dollár, vagyis ha a drága modell a tartalék, egy hosszabb leállás a havi számlán is látszani fog.

Hibakezelő munkafolyamat az Error Trigger node-dal

Az error workflow (hibakezelő munkafolyamat) az n8n-ben olyan külön munkafolyamat, amely akkor fut le, ha egy másik munkafolyamat végrehajtása hibával zárul. Az Error Trigger node-dal kell kezdődnie, hozzárendelni pedig a figyelt munkafolyamat beállításaiban (Workflow Settings), az Error workflow mezőben lehet. A dokumentáció szerint ugyanazt a hibakezelő munkafolyamatot több munkafolyamathoz is beállíthatod, ami egy KKV-nál ideális, mert így egyetlen központi hibaközpont gyűjti az összes automatizáció problémáit.

Az Error Trigger többek között megkapja a hibás futás azonosítóját és linkjét, a hibaüzenetet, az utolsóként lefutott node nevét, valamint a munkafolyamat azonosítóját és nevét. Ebből már összerakható egy olyan értesítés, amelyből a címzett két másodperc alatt látja, melyik folyamat, melyik lépésnél és milyen hibával állt meg, egy kattintással pedig a hibás futáshoz jut. A dokumentáció néhány fontos korlátot is rögzít: ha a hiba magában a trigger node-ban keletkezik, a futás azonosítója és linkje hiányzik, a hibakezelő munkafolyamat pedig kézi futtatással nem tesztelhető, mert az Error Trigger csak automatikusan induló futások hibájára indul el. Az Error Triggert tartalmazó munkafolyamatot ugyanakkor nem kell külön publikálnod. Arra viszont figyelj, hogy a hibaüzenetekkel könnyen az ügyfél neve vagy teljes levele is bekerül a naplóba és az értesítésekbe, ami a GDPR szerint is adatkezelés, ezért a hibanaplók megőrzési idejét és a hozzáférést is szabályozni kell.

A tesztelési korlát miatt a hibakezelést élesítés előtt úgy érdemes kipróbálni, hogy egy ütemezetten induló tesztmunkafolyamatba beteszel egy Stop And Error node-ot. A dokumentáció szerint ezzel a node-dal a saját feltételeid alapján kényszerítheted hibára a futást, ami a hibakezelő munkafolyamatot is elindítja. Ugyanez a node élesben is hasznos: ha az ügynök kimenete nem felel meg egy ellenőrzésnek, mert például hiányzik belőle a rendelésszám, vagy negatív a kiszámolt összeg, a Stop And Error node-dal a csendes továbbhaladás helyett kifejezett hibát generálhatsz.

Emberi jóváhagyás az ügynök eszközeinél

A human-in-the-loop (emberi jóváhagyás a folyamatban) az n8n dokumentációja szerint azt jelenti, hogy az AI Agent egy adott eszközt csak emberi jóváhagyás után futtathat. Amikor a modell úgy dönt, hogy meghívná a jóváhagyáshoz kötött eszközt, a munkafolyamat megáll, a jóváhagyó pedig megkapja a kérést a beállított csatornán. Jóváhagyás (Approve) esetén az eszköz az AI által megadott bemenettel lefut, elutasításnál (Deny) a művelet elmarad, az AI pedig értesül az elutasításról.

A dokumentáció szerint a kérés érkezhet az n8n beépített chatfelületén, a Slacken, a Discordon, a Telegramon, a Microsoft Teamsen, a Gmailen, a WhatsApp Business Cloudon, a Google Chaten és a Microsoft Outlookon keresztül. A jóváhagyás beállítható az összes eszközre vagy csak egyesekre, a jóváhagyó üzenetében pedig a $tool.name és a $tool.parameters változókkal megjelenítheted, pontosan melyik eszközt milyen paraméterekkel hívná meg az ügynök. A dokumentáció azt is javasolja, hogy a rendszerprompt írja le, mely eszközök igényelnek jóváhagyást és mi történjen elutasítás esetén, különben a modell nem tudja, hogyan folytassa.

Ha az emberi beavatkozás nem igen-nem döntés, hanem adatpótlás, akkor a Wait node a jó eszköz. A dokumentáció szerint négyféleképpen folytathatja a futást: adott idő elteltével (After Time Interval), egy megadott időpontban (At Specified Time), egy webhookhívásra (On Webhook Call) vagy egy űrlap beküldésére (On Form Submitted). A Limit Wait Time opcióval felső határt szabhatsz a várakozásnak, hogy egy elfelejtett jóváhagyás ne tartsa örökké függőben a folyamatot.

Lépésről lépésre: hibatűrő ügynök-munkafolyamat n8n-ben

Az alábbi sorrend egy tipikus KKV-s ügynök-munkafolyamatra épül, például egy webshopos rendelésállapot-kezelésre vagy az ajánlatkérések feldolgozására. A lépések logikája a Make vagy a Zapier felületén is megvalósítható, a node-nevek viszont az n8n-re vonatkoznak.

• Írd össze az ügynök összes eszközét és sorold be őket. Minden eszköznél döntsd el, hogy olvas vagy ír, visszafordítható-e a hatása és mennyibe kerül, ha rosszul fut le. Egy képzeletbeli debreceni webshopnál a rendeléskeresés olvasó, visszafordítható művelet, a visszatérítés indítása viszont író és visszafordíthatatlan.
• Határozd meg eszközönként a visszaadott állapotokat. Használd a fenti táblázat nyolc állapotát, a „nincs találat” pedig ne üres listaként, hanem kifejezett állapotként érkezzen vissza.
• Kapcsold be a Retry On Fail beállítást a külső, átmeneti hibára hajlamos node-okon, a nem idempotens node-ok elé pedig tegyél ellenőrző lekérdezést.
• Állítsd az On Error mezőt Continue (using error output) értékre ott, ahol a hibás tételeket külön kell kezelni, a hibakimenetre pedig köss egy naplózó és egy értesítő ágat.
• Hozz létre egy központi hibakezelő munkafolyamatot Error Trigger node-dal. Rendeld hozzá az összes éles munkafolyamathoz a Workflow Settings Error workflow mezőjében, az értesítésbe pedig tedd bele a munkafolyamat nevét, a hibás node nevét, a hibaüzenetet és a futás linkjét.
• Kösd jóváhagyáshoz a következményes eszközöket. A visszatérítés, a kedvezményadás vagy az ügyfélnek küldött ajánlat csak emberi jóváhagyás után fusson le, a rendszerpromptban pedig írd le, mi a teendő elutasításkor.
• Építs be egy eszközt a bizonytalan esetekre, amelyet a modell akkor hív meg, ha nem biztos a válaszában, ez pedig az ügyet egy kollégához irányítja.
• Írd meg a rendszerpromptot a hibakezelési szabályokkal. A korábban felsorolt öt szabály jó kiindulópont, amelyet a saját üzleti szabályaiddal (kedvezménykeret, visszatérítési limit, tiltott témák) egészíthetsz ki.
• Teszteld a hibaágakat szándékos hibákkal. Egy ütemezett tesztfuttatásban a Stop And Error node-dal, érvénytelen hozzáférési adattal és nem létező rendelésszámmal ellenőrizd, hogy minden hiba a megfelelő ágra fut és a megfelelő emberhez jut el.
• Állíts be napi egyeztetést és heti áttekintést. Egy külön munkafolyamat naponta vesse össze az ügynök jelentéseit a célrendszer adataival, hetente pedig nézd át az eszkalációk és a hibák listáját, mert ebből derül ki, mit érdemes a következő körben javítani vagy tovább automatizálni.

Riasztások: mikor szóljon Slackre és mikor telefonra?

Telefonon vagy SMS-ben csak akkor riassz, ha a hiba már most érinti az ügyfeleket vagy a bevételt, azonnali emberi döntés kell hozzá és a riasztott ember tud is tenni valamit. Minden más mehet Slack- vagy Teams-csatornára, jegybe vagy napi összesítő e-mailbe, különben a riasztások hamar háttérzajjá válnak.

A Google üzemeltetési mérnökei (SRE, site reliability engineering) évek óta ezt az elvet követik. A Google SRE-könyvének monitorozásról szóló fejezete háromféle értesítést különít el: a jegyet (ticket), az e-mailes riasztást és az azonnali riasztást (page), amely rögtön mozgósítja az ügyeletest. A fejezet egyik legtöbbet idézett gondolata saját fordításunkban így szól: „Minden azonnali riasztásnak cselekvést kell kiváltania. Minden azonnali riasztásra adott válasznak emberi gondolkodást kell igényelnie. Ha egy riasztásra gépies válasz is elég, akkor az nem lehet azonnali riasztás.” A fejezet arra is figyelmeztet, hogy a túl gyakori riasztásokat a munkatársak előbb-utóbb csak átfutják vagy figyelmen kívül hagyják, így a valódi vészjelzés is elsikkadhat a zajban. Egy KKV-ra lefordítva ez azt jelenti, hogy ha egy hibára az a helyes reakció, hogy valaki megnyomja az újrafuttatás gombot, akkor azt az automatizációnak kell elvégeznie, nem egy felébresztett ügyvezetőnek.

A táblázat oldalra húzható ↔

A táblázat a saját ajánlásunk, a pontos határokat a cég működéséhez kell igazítani. Minden szintnek legyen megnevezett felelőse és helyettese, mert a közös hibacsatornába érkező üzenetet mindenki látja, így senki sem érzi a sajátjának. Egy 5 és 50 fő közötti cégnek ritkán van éjjel-nappali ügyeleti csapata, ezért jól működik a lépcsőzetes eszkaláció: a riasztás először a felelős csatornájába megy, ha 30 percen belül senki sem nyugtázza, SMS megy a felelősnek, ha arra sincs reakció, a helyettese kap hívást. Az n8n-ben ez úgy rakható össze, hogy a hibakezelő munkafolyamat a Slack node-dal üzen, egy Wait node a Limit Wait Time beállítással vár a nyugtázó gombnyomásra (On Webhook Call), a határidő lejárta után pedig egy If node dönt arról, kell-e HTTP-kéréssel meghívni egy SMS- vagy hívásküldő szolgáltatás, illetve egy ügyeleti rendszer API-ját.

Mit mérj az ügynökeiden?

Az SRE-könyv négy aranyjelzést (four golden signals) javasol minden felhasználói rendszerhez: a késleltetést, a forgalmat, a hibákat és a telítettséget. Ügynököknél ezek a futásidőt és a jóváhagyásra várás idejét, az óránkénti futások számát, a hibaarányt és az eszkalációs arányt (az embernek átadott ügyek részarányát), valamint az API-kvóta és a költségkeret kihasználtságát jelentik.

Az eszkalációs arány a legbeszédesebb ügynökspecifikus mutató. Az aiagentstore.ai összefoglalója szerint a Live Nation fesztiválügynökei a rajongói kérdések körülbelül 85%-át három válaszon belül megoldják, ami egyben azt is jelenti, hogy a maradék nagyjából 15%-nak valahová tovább kell jutnia. Ha a te ügynököd eszkalációs aránya hetek óta 15% körül mozog, majd egyik napról a másikra 3%-ra esik, az nem feltétlenül ok az ünneplésre, mert lehet, hogy az ügynök egyszerűen abbahagyta a jelzést.

Mennyibe kerül az AI-ügynök hibakezelése és mennyibe a hiánya?

Az AI-ügynök hibakezelése közvetlenül olcsó: egy tisztázó kérdés modelltől függően néhány forintos vagy néhány tíz forintos tokenköltség, a node-szintű újrapróbálkozás pedig tokent egyáltalán nem használ. A csendes hiba ára ezzel szemben munkaórában, elveszett rendelésben és bizalomban mérhető, ami egy kisebb cégnél is könnyen havi százezer forint fölé mehet.

A számítás saját becslés, kerekített 320 Ft-os dollárárfolyammal (2026. szeptember 21-én 1 dollár kb. 317 Ft volt). Egy tisztázó kérdés egy újabb modellhívást jelent, amelyben a modell újraolvassa a teljes kontextust, ezt kb. 22 000 bemeneti és 200 kimeneti tokenre becsüljük. A Muse Spark 1.3 áraival ez 0,022 × 1,25 + 0,0002 × 4,25 = 0,028 dollár, azaz kb. 9 Ft, a GPT-6 Astra 10 és 50 dolláros áraival 0,022 × 10 + 0,0002 × 50 = 0,23 dollár, azaz kb. 74 Ft. A többi feltételezés egy képzeletbeli debreceni webshopra vonatkozik, amely napi 60 rendelést kap, a munkaóra teljes költségét pedig 6 000 Ft-tal számoljuk.

A táblázat oldalra húzható ↔

A számokból két tanulság adódik. Az egyik, hogy a legdrágább tétel az emberi idő, ezért a jóváhagyást csak a valóban következményes lépésekre érdemes kérni, a tisztázó kérdésekhez pedig nem kell a legdrágább modell. A másik, hogy a csendes hiba már 1%-os gyakorisággal is havonta nagyjából 126 000 Ft-os veszteséget okoz utómunkában és elmaradt forgalomban, miközben a megelőzése a legdrágább modellel is ennek töredékébe kerül. Az ügynökszintű újrapróbálkozás, amikor a modell maga dönt úgy, hogy újra meghívja az eszközt, viszont nem olcsó: a GPT-6 Astránál egy kb. 20 000 bemeneti és 200 kimeneti tokenes kör nagyjából 67 Ft, három kör tehát körülbelül 200 Ft, ezért az átmeneti hibákat érdemes a munkafolyamat szintjén kezelni.

Az önállóság fokozatai: mit csinálhat az ügynök egyedül?

Az ügynök önállósága nem igen-nem kérdés, hanem egy skála. Minél drágább és kevésbé visszafordítható egy hiba, annál alacsonyabb szinten kell lennie az adott eszköznek, a szintet pedig mérések alapján, fokozatosan érdemes emelni.

• Első szint, csak olvas: az ügynök lekérdez, összefoglal és válaszol, de semmit sem módosít, ilyen a rendelésállapot-lekérdezés vagy a belső tudásbázisból adott válasz.
• Második szint, vázlatot készít: megírja a választ, az ajánlatot vagy a számla adatait, elküldeni azonban csak ember tudja.
• Harmadik szint, jóváhagyással cselekszik: az ügynök elvégezné a műveletet, de előtte emberi jóváhagyást kér, ez az n8n human-in-the-loop funkciójának terepe.
• Negyedik szint, önállóan cselekszik utólagos ellenőrzéssel: a műveletek egy részét mintavétellel átnézi valaki, a napi egyeztetés pedig kiszűri az eltéréseket.
• Ötödik szint, teljesen önálló: csak olcsón visszafordítható, kis tétű műveleteknél javasolt, például egy belső címke vagy prioritás beállításánál.

A szintlépés feltétele legyen mérhető, például az, hogy egy eszköz 200 egymást követő futásában a jóváhagyó semmit sem módosított és semmit sem utasított el. Arra is figyelj, hogy a naponta nyolcvan kérést kapó jóváhagyó előbb-utóbb gépiesen kattintgat. Hogy a korlátozás nagy léptékben is része a működésnek, azt az Anthropic szeptember 19-i közlése mutatja: a cég körülbelül 30 000 belső ügynöke augusztusban több mint 1 milliárd döntést hozott, ezek nagyjából 0,002%-át blokkolták, ez pedig legalább 20 000 megállított lépést jelent. Egy KKV-nál a nagyságrend más, a tanulság viszont ugyanaz: az ügynök nem attól megbízható, hogy soha nem kell megállítani, hanem attól, hogy a megállítás működik és látszik.

Miben segít a Convergo?

A Convergo workflow-automatizációs csapata n8n-ben és egyedi AI-integrációkkal építi meg azokat az ügynök-munkafolyamatokat, amelyek nemcsak dolgoznak, hanem szólnak is, ha elakadnak: eszközállapotokkal, hibaágakkal, emberi jóváhagyással és a cégmérethez illő riasztási renddel. Ha már futnak automatizációid, egy IT audit keretében átnézzük, hol hibázhatnak csendben, illetve mely pontokon hiányzik a hibakezelés. Az élesített rendszerek felügyeletét és hibajavítását support csomagban is vállaljuk, havi 30 000 Ft-ért, amely 3 fejlesztői órát tartalmaz. Az első lépés egy ingyenes egyeztetés, ahol közösen kiválasztjuk azt a folyamatot, amelyiknél a csendes hiba a legtöbbe kerülhet.