A zöld pipa nem azt jelenti, amit gondolsz
Kezdjük ott, ahol a legtöbb bevezetés befejezi. Az időzített futás legnagyobb kockázata nem az, hogy elbukik — hanem hogy sikeresnek látszik. (Ha az agent fogalma még új, előbb érdemes elolvasni, mit tesz egy agent a gyakorlatban.)
A gyártói dokumentáció szokatlanul őszinte erről: a futáslistában a zöld állapot csak annyit garantál, hogy a munkamenet elindult és infrastruktúra-hiba nélkül ért véget. Hogy mi történt közben, az csak a naplóból derül ki — a letiltott hálózati kérések, a hiányzó eszközök és a feladatszintű hibák mind ott jelennek meg, nem az állapotjelzőn.
Ez az egész cikk gondolati alapja. Egy háttéragentnél a legfontosabb tervezési kérdés nem az, hogy mit csináljon, hanem hogy honnan tudod meg, hogy nem csinálta meg.
Háromféle „háttérben"
A szóhasználat összemos három, technikailag nagyon különböző dolgot. Érdemes szétszedni, mert a választás dönti el, mit tudsz vele csinálni:
| Felhőben futó | A saját gépen | Nyitott munkamenetben | |
|---|---|---|---|
| Kell hozzá bekapcsolt gép | Nem | Igen | Igen |
| Kell hozzá nyitott munkamenet | Nem | Nem | Igen |
| Túléli az újraindítást | Igen | Igen | Csak külön folytatással |
| Látja a helyi fájljaidat | Nem (friss másolat) | Igen | Igen |
| Kérhet engedélyt futás közben | Nem — autonóm | Feladatonként állítható | Örökli a munkamenettől |
| Legkisebb időköz | 1 óra | 1 perc | 1 perc |
A táblázat két sora dönt a legtöbb esetben.
Az egyik a helyi fájlok. A felhőben futó agent friss másolatot kap, nem a te gépeden lévő állapotot. Ha a feladat a te mappádban lévő fájlokról szól, ez kizáró ok.
A másik az engedélykérés. A felhős futásnál nincs jóváhagyási párbeszéd — ami kényelmes, amíg nem gondolod végig, hogy ez mit jelent. Ugyanez a dokumentáció ki is mondja: az ilyen futások teljesen autonóm munkamenetek, jogosultsági mód választása és jóváhagyási kérdések nélkül. Vagyis amit adsz neki, azt használhatja, kérdés nélkül. A jogosultságok szűkítéséről a legkevesebb jogot kapó agent című írás szól részletesen.
Mi indítsa el?
Három kiváltó ok van, és a legtöbb csalódás abból ered, hogy valaki az elsőt használja a harmadik helyett:
1. Időzítés. Óránként, éjszakánként, hetente, vagy egyszeri jövőbeli időpontban. Egyszerű, kiszámítható — és pazarló, ha a legtöbb futásnak nincs mit csinálnia.
2. Külső hívás. Az agentnek van egy végpontja, amit egy másik rendszer meghív. Ez a legrugalmasabb: a te rendszered dönti el, mikor van dolga.
3. Esemény. A tárolóban létrejön egy beküldés, befut egy levél, változik egy sor az adatbázisban. Ez a legtöbb üzleti feladatnál a helyes válasz — az adat érkezésekor fut, nem óránként keresi, hogy van-e.
Egy gyakorlati részlet, ami eseményvezérlésnél mindig előkerül: az ismétlődő indítás. Jó rendszerekben óránkénti eseménykorlát van futásonként és fiókonként, és a korlát fölötti események eldobódnak. Ez nemcsak költségvédelem, hanem duplikáció elleni védelem is — ha az esemény kétszer jön be, ne fusson le kétszer.
Ha nem kódból építkezel, a no-code platformok pont ezt a három indítási módot csomagolják felületre — erről a no-code automatizálási platformok című összehasonlítás szól.
A megállás problémája, mérve
Ez a fejezet azért fontos, mert nem vélekedés. Egy 1 642 annotált futásnyomot feldolgozó tanulmány hibatipológiájában három kategória szól közvetlenül a megállásról:
| Hibamód | Gyakoriság |
|---|---|
| Ugyanazt a lépést ismétli | 15,7% |
| Nem ismeri fel, hogy készen van | 12,4% |
| Túl korán abbahagyja | 6,2% |
Együtt több mint 34% — vagyis a megfigyelt hibáknak több mint harmada arról szól, hogy az agent nem tudja, mikor álljon meg. Vagy köröz, vagy idő előtt feladja.
Interaktív használatnál ez bosszantó. Háttérben futva ez a számla. A körökben forgó agent nem panaszkodik, nem kérdez — csak fogyaszt, amíg valami le nem állítja.
Ezért a háttéragent első beállítása nem a prompt, hanem a korlát: maximális lépésszám, maximális futásidő, eszközszintű időkorlát. Ha a keret kimerül, a jó rendszerek nem kivételt dobnak, hanem kontrollált kimenetet adnak — vagyis meg lehet különböztetni a „nem fejezte be" esetet a „hibára futott" esettől. Hogy miért nő a hibaesély a lépésszámmal, arról az agent-megbízhatóság matematikája című írás szól számolással.
Mi történik, ha egy hónapig nem nézel rá?
Erre van egy szokatlanul őszinte, publikált kísérlet. Egy modellfejlesztő 2025-ben valódi pénzzel, valódi ügyfelekkel üzemeltetett egy irodai büfét egy agenttel, körülbelül egy hónapig: hűtő, polcok, önkiszolgáló kassza, és az agent kezében a beszerzés, az árazás és az ügyfélkommunikáció.
Az eredmény: veszteség. A legnagyobb esést az okozta, hogy nagy tételben vásárolt egy terméket, amit aztán a beszerzési ár alatt adott el.
A dokumentált hibamódok viszont ennél is tanulságosabbak:
- Hallucinált bankszámla. Az ügyfeleket egy nem létező számlára irányította fizetni.
- Rábeszélhetőség. Üzenetekben kedvezménykódokat csikartak ki belőle, majd visszamenőleg csökkentették az árajánlatait ezekre hivatkozva.
- Identitászavar. Két napon át kitalált egy beszélgetést egy nem létező személlyel, egy nem létező címre hivatkozott, majd valódi emberként kezdett viselkedni: azt állította, személyesen viszi ki a termékeket, és leírta, milyen ruhában.
Ebből a harmadik a legfontosabb tanulság a háttérfutásra. Nem az a kockázat, hogy az agent elromlik és leáll — hanem hogy elromlik és magabiztosan folytatja. A felügyelet nélküli futásban semmi nem jelezte, hogy baj van.
Hogyan jelezzen, ha baj van?
Itt jön a cikk gyakorlati magva. Négy mintázat, mind dokumentált forrásból:
1. A kimerült újrapróbálkozás a terminális jel. A jól megépített kliensek belül újrapróbálják a sikertelen kéréseket, és csak akkor adnak hibaeseményt, amikor feladták. Ez fontos: ha minden részleges hibáról riasztasz, zajt kapsz. Ha a feladást figyeled, jelet.
2. Meg kell tudni különböztetni a magához tért futást a beragadttól. A recept egyszerű: csoportosíts munkamenet-azonosító szerint, és nézd meg, van-e a hiba UTÁN újabb kérés. Ha van, az agent folytatta. Ha nincs, ott állt meg.
3. Az engedélykérés csendes megállást okoz. Ez az egyik legalattomosabb hiba: ha az agent jóváhagyást kér, miközben te nem ülsz a gép előtt, a munkamenet megáll és vár — nem hibázik, nem jelez, csak nem halad. Két megoldás van rá: vagy átirányítod a jóváhagyást egy csatornára, amit elérsz (üzenetküldő, csevegő), vagy előre megadod a jogokat — de ez utóbbi csak olyan környezetben elfogadható, amiben megbízol. A jóváhagyási pontok tervezéséről az ember a folyamatban című írás szól.
4. Három dolog, amire riasztást érdemes tenni — ezeket a gyártói monitorozási útmutató nevesíti: költségcsúcs, szokatlan tokenfogyasztás, és szokatlanul sok futás ugyanattól a forrástól. Mindhárom ugyanazt fogja meg: az agent csinál valamit, amit nem terveztél.
Költségkorlátok: hol állítsd meg?
A háttérfutás ott különbözik az interaktívtól, hogy nincs, aki észrevegye. Ezért a korlátot előre kell beépíteni, három szinten:
1. FIÓK- VAGY SZERVEZETI SZINTŰ KÖLTSÉGPLAFON
Havi keret, ami fölött a szolgáltatás elutasít.
Ez az utolsó védvonal, nem az első.
2. FUTÁSSZÁM-PLAFON
Naponta hány futás indulhat. Eseményvezérelt
agenteknél ez a fontosabb korlát.
3. FUTÁSON BELÜLI KERET
Maximális lépésszám, futásidő, eszköz-időkorlát.
Ez az egyetlen, ami a HURKOT megállítja.
Egy technikai részlet, ami sok automatizálást tönkretett már: amikor a szolgáltatás a költségplafon miatt utasít el, a válasz gyakran ugyanolyan „próbáld újra" típusú hibakód, mint a túlterheltségnél — de nincs mellette megmondva, mikor érdemes újrapróbálni. Az automatikus újrapróbálkozás ilyenkor garantáltan elbukik, viszont közben zajt csinál a naplóban. Érdemes a kliensben külön kezelni a kétféle esetet.
És egy pozitív részlet a másik irányba: a legtöbb szolgáltatónál a gyorsítótárból olvasott token nem számít bele a percenkénti bemeneti korlátba. Ismétlődő háttérfeladatnál — ahol ugyanaz a hosszú rendszerprompt megy be minden futásban — ez a különbség többszörös feldolgozási kapacitást jelent ugyanazon a limiten belül.
Naplózás: a legtöbb rendszer nem rögzíti, amit hiszel
Ez az a rész, ami egy hónappal később számít, amikor meg kellene mondani, mit csinált az agent kedden.
A bevett telemetria alapból rögzíti a futások számát, a tokenfogyasztást, a költséget, az API-hibákat, az eszközdöntéseket és az eszközeredményeket. Ez sok — de vedd észre, mi hiányzik belőle.
Ami alapértelmezésben KI van kapcsolva:
| Nem rögzül alapból | Mit veszítesz vele |
|---|---|
| A prompt szövege | nem tudod, mit kért az agenttől a kiváltó esemény |
| Az asszisztens válaszának szövege | nem tudod, mit válaszolt |
| Az eszközök részletei (parancsok, szervernevek) | nem tudod, mit hívott meg |
| Az eszközök be- és kimenete | nem tudod, milyen adatot látott |
| A nyers API-kérések | nincs végső hivatkozási alap |
Ez nem hiba, hanem tudatos adatvédelmi alapbeállítás — és pontosan ezért kell tudatosan dönteni róla, mielőtt elindítasz egy háttéragentet. Amit nem kapcsoltál be, azt utólag nem lehet rekonstruálni.
Két csapda ehhez:
- Amit az agent elindít, az kimaradhat a nyomkövetésből. A telemetriai beállítások jellemzően nem öröklődnek az agent által indított alfolyamatokba — a parancsokba, a külső eszközszerverekbe. Vagyis a napló azt mutatja, hogy az agent futtatott valamit, de azt nem, hogy az mit csinált.
- A költségmetrika közelítés. Ezt a dokumentáció maga mondja ki: a hivatalos elszámoláshoz a szolgáltató számlázási adatait kell nézni. A telemetria riasztásra jó, könyvelésre nem.
A how-to
1. ELŐBB DÖNTSD EL, MI INDÍTJA
Esemény > külső hívás > időzítés. Az óránkénti
futás a legdrágább módja annak, hogy megnézd,
van-e dolgod.
2. ADJ NEKI KERETET, MIELŐTT PROMPTOT ADSZ
Max lépésszám, max futásidő, eszköz-időkorlát.
A hurok a leggyakoribb egyetlen hibamód.
3. DÖNTSD EL, HOL FUSSON
Kell helyi fájl? Akkor nem a felhőben.
Kell autonómia? Akkor nem nyitott munkamenetben.
4. OLDD MEG A JÓVÁHAGYÁST, MIELŐTT ELINDUL
Vagy átirányítod egy csatornára, amit elérsz,
vagy előre megadod a szűk jogokat. A "majd
megkérdezi" háttérben csendes megállás.
5. ÍRASD LE, MIT CSINÁLT - NE CSAK AZT, HOGY FUTOTT
A záró üzenet tartalmazza: mit talált, mit
változtatott, mit NEM tudott elvégezni.
6. KAPCSOLD BE, AMIT NAPLÓZNI AKARSZ
Az eszközhívások és a tartalom alapból kimarad.
Utólag nem lehet visszamenni érte.
7. RIASSZ HÁROM DOLOGRA
Költségcsúcs, szokatlan tokenfogyasztás,
szokatlanul sok futás. Mind ugyanazt jelzi.
8. NÉZD MEG A NAPLÓT HETENTE EGYSZER
Nem az állapotjelzőt - a naplót. A zöld pipa
csak annyit mond, hogy elindult és kilépett.
Az ötödik pont a legolcsóbb és a legtöbbet hozó. Ha a háttéragent minden futás végén küld egy három mondatos összefoglalót arról, mit nem tudott elvégezni, akkor a legtöbb csendes hibát el is kaptad. A „minden rendben" típusú üzenet ennek az ellentéte: pontosan olyan, mint a zöld pipa.
Tipikus félreértések
- „Lefutott, tehát kész van." A futás állapota az infrastruktúráról szól, nem a feladatról. Ezt a gyártói dokumentáció maga írja le.
- „Ha baj van, majd szól." Alapbeállításon nem szól. A csendes megállás — például egy megválaszolatlan jóváhagyási kérdés — nem hiba, csak nem történik semmi.
- „Az óránkénti futás biztonságos alapértelmezés." Attól függ. Ha a legtöbb futásnak nincs mit csinálnia, akkor drága; ha az adat óránál gyorsabban érkezik, akkor késő. Az eseményvezérlés mindkettőt megoldja.
- „A naplóból utólag kiderül." Csak abból, amit bekapcsoltál. A promptok, a válaszok és az eszközhívások részletei jellemzően alapból nincsenek rögzítve.
- „Az újrapróbálkozás mindig segít." Költségplafon miatti elutasításnál nem: az újrapróbálkozás garantáltan elbukik, csak zajt csinál.
- „Kis feladatnál nem kell felügyelet." A hivatkozott kísérletben egy büfé volt a feladat, valódi pénzzel — és egy hónap alatt hallucinált bankszámláig és kitalált személyazonosságig jutott.
Amit érdemes elvinni
Az időzített agent nem attól lesz megbízható, hogy jó a promptja, hanem attól, hogy kimondtad, mit jelent a siker, és mi történik, ha nem az van.
Három dolog, ami minden háttéragentnél kötelező: keret (lépés, idő, költség), csatorna (ahol jóváhagyást kérhet és jelenthet), és napló, amit tényleg elolvasol. E három nélkül az automatizálás nem megspórolt munka, csak elhalasztott munka.
És a legolcsóbb ellenőrzés, amit ma megtehetsz: nézd meg a legutóbbi automatizált futásod naplóját — nem az állapotát, hanem a tartalmát. Ha nem tudod öt perc alatt megmondani belőle, mit csinált, akkor a következő hibát sem fogod észrevenni. A napi és heti riportok automatizálásáról külön írás szól: a visszatérő riportok témájú poszt gyakorlati példákkal.