Human in the loop AI-ügynököknél: hová kerüljenek a jóváhagyási kapuk

Minden csapat, amely ügynököt ad ki a kezéből, egy héten belül ugyanazzal a kérdéssel találkozik: mikor kell kérdeznie? Ha túl ritkán kérdez, egyetlen rossz eszközhívás letöröl egy táblát, rossz e-mailt küld, vagy rossz ügyfélnek utal vissza pénzt. Ha túl gyakran, az emberek olvasás nélkül kattintanak az „Engedélyezés” gombra, ami rosszabb a kapu hiányánál, mert a rendszer felügyeltnek látszik, miközben nem az.

A „human in the loop” legtöbbször pipa a listán: egy megerősítő ablak a veszélyes eszközök előtt. Ez a tervezés kezdete, nem a vége. Ez a cikk azokat a döntéseket járja végig, amelyek számítanak: hová kerülnek a kapuk, hogyan építs olyan jóváhagyást, amelyet az emberek tényleg elolvasnak, milyen interrupt és resume primitíveket kínálnak ma a fő ügynökframeworkök, mit kell tartalmaznia egy audit nyomvonalnak, és hogyan változtatják meg a képet az always-on ügynökök, mint az OpenAI dots. Ha előbb magát a ciklus működését szeretnéd megérteni, kezdd az ügynökciklus magyarázatával.

Miért csődöt mond a műveletenkénti jóváhagyás nagy léptékben

A kellemetlen bizonyíték azoktól jön, akik az iparág legnagyobb jóváhagyási ablakát üzemeltetik. Az auto módról szóló mérnöki cikkében az Anthropic azt írja, hogy a Claude Code felhasználói az engedélykérések 93 százalékát jóváhagyják, és a következményt jóváhagyási fáradtságnak nevezi: az emberek nem figyelnek oda többé arra, mit hagynak jóvá.

Egy beszámoló szerinti kísérlet élesebbé teszi a lényeget. A DevOps.com szerint az Anthropic 1053 tesztelőnél egy valóban veszélyes parancsot ágyazott az engedélykérések közé: az emberi ellenőrök az esetek 13,6 százalékában vették észre, az automatikus osztályozó 89 százalékban, és több mint 50 korábbi kérés után az emberi találati arány nagyjából 5 százalékra esett. Ez gyártói kísérlet, szándékosan álcázott paranccsal, ezért irányként olvasom, nem állandóként. Az irány ettől még egyértelmű: aki ötven ártalmatlan kérést látott, rossz detektor az ötvenegyedikhez.

Ugyanez a mérnöki cikk őszinte a másik oldalról is. A kétlépcsős osztályozó a valódi, túlbuzgó műveletek 52 elemű kis mintáján még mindig 17 százalékos hamis negatív arányt mutatott, amit az Anthropic az őszinte számnak nevez. Sem az ember, sem a modell nem megbízható egyedüli kapu. A tervezési cél ezért nem az, hogy „egy ember mindent jóváhagy”, hanem az, hogy a szűkös emberi figyelmet oda tedd, ahol megváltoztatja az eredményt, és olyan kontrollokkal támaszd meg, amelyek nem fáradnak el.

Hová tedd a kapukat: kockázat, visszafordíthatóság, hatókör

Az eszköz neve szerint kapuzni („kérdezz a Bash előtt”) túl durva, és túl könnyen felhígul. Én a művelet négy tulajdonsága szerint kapuzok, fontossági sorrendben:

• Visszafordíthatóság. Visszacsinálható-e a hatás olcsón és teljesen? Egy piszkozat, egy branch vagy egy staging táblasor igen. Egy elküldött e-mail, egy kifizetés, egy törölt bucket vagy egy megváltoztatott jogosultság nem.
• Hatókör. Hány rekordot, ügyfelet vagy rendszert érint egyetlen hívás? Az „egy jegy frissítése” és a „minden, a szűrőnek megfelelő jegy frissítése” ugyanaz az eszköz, ezerszer eltérő kockázattal.
• Adatok és láthatóság. Felfed-e személyes, pénzügyi vagy bizalmas adatot, vagy látható-e a szervezeteden kívül?
• Jogosultság. Olyan hitelesítő adatot használ-e, amelyet az ember nem erre a feladatra adott, vagy megváltoztatja-e, ki mit tehet?

Ezekből négy szint lesz. A jobb oldali oszlopok ugyanolyan fontosak, mint a bal oldaliak: egy szint csak akkor valódi, ha megnevezi a kontrollt és a hátrahagyott bizonyítékot.

Két szabály tartja őszintén a mátrixot. Először: az argumentumok legrosszabb esete szerint eszkalálj, ne az eszköz szerint. Egy visszatérítő eszköz a limit feletti összeggel 3. szint, alatta 2. szint. Másodszor: az ügynök sosem osztályozza be a saját műveletét. A szintet determinisztikus szabályok vagy egy, az ügynök elérésén kívüli külön komponens adja. Pontosan ezt a szerkezetet írja le az OpenAI a dotsnál, ahol egy különálló, az ügynök által módosítható környezeten kívüli ellenőrző rendszer dönt arról, hogy egy lépés lefut-e. A Claude Agent SDK engedélysorrendje is így épül fel: hookok, majd tiltó szabályok, majd kérdező szabályok, majd az engedélymód, majd engedélyező szabályok, végül a te callbacked.

Jóváhagyási UX, amely nem tanít igent kattintani

Amikor egy kapu működésbe lép, a felület dönti el, hogy működik-e. Ezeket a tervezési szabályokat alkalmazom, és mind egyetlen gondolatból következnek: az ellenőrnek néhány másodperc alatt meg kell tudnia ítélni a hatást.

• A hatást mutasd, ne a szándékot. Az „Az ügynök a send_email-t akarja futtatni” használhatatlan. Az „E-mail ceo@client.com címre, 340 szó, csatolja a contract.pdf-et, 12 másolatos címzett” ellenőrizhető. Kódnál és adatnál diffet mutass, pénznél összeget, pénznemet és címzettet.
• A veszélyes részt tedd hangossá. Emeld ki a szokatlant: új címzettet, a mediánnál nagyobb összeget, helyettesítő karaktert az útvonalban, külső domaint.
• Vond össze, ami összetartozik. Tíz hasonló 2. szintű lépés egy döntés látható listával, nem tíz ablak. A fáradtság a megszakítások számával nő.
• Ne csak igent vagy nemet kínálj, hanem szerkesztést is. A Claude Agent SDK-ban a callback módosított bemenetet adhat vissza, a LangChain human-in-the-loop middleware-ében pedig az approve és reject mellett van edit döntés. Aki ki tud javítani egy paramétert, nem veti el az egész tervet.
• Az elutasítás vigyen indoklást. A deny üzenet visszamegy a modellnek, amely így igazodhat. A Claude Agent SDK-ban Claude látja az elutasítás üzenetét, az OpenAI Agents SDK-ban hívásonként beállíthatsz elutasítási üzenetet.
• Vigyázz a „mindig engedélyez” opcióval. Az eltárolt döntés a jövőbeli súrlódást és a jövőbeli ellenőrzést is megszünteti. Ha felkínálod, szűken érvényesítsd (ez a parancs, ez az útvonal), járjon le, és az aktív szabályokat listázd ott, ahol az emberek átnézhetik.
• Hiba esetén zárj. Ha senki nem válaszol, a válasz nem. Időtúllépés sosem hagyhat jóvá.

Aztán mérj. A saját ökölszabályom, amely tapasztalaton alapuló heurisztika, nem közzétett küszöb: ha egy kaput az esetek több mint 95 százalékában jóváhagynak, és a döntés mediánja pár másodperc, az színház. Vagy a művelet az 1. szintre való, vagy a kérés nem adja meg, ami az elbíráláshoz kell. Műveletfajtánként kövesd a jóváhagyási arányt, a döntési időt és a később visszavont jóváhagyások arányát. Ugyanaz a figyelemprobléma, amely az ügynökök írta pull requesteket review-szűk keresztmetszetté teszi, és a megoldás is ugyanaz: kevesebb, jobban előkészített döntés.

Interrupt és resume a fő frameworkökben

Technikailag a kapu egy szünet: az ügynök javasol egy műveletet, a futtatókörnyezet megáll, az állapot elmentődik, és egy későbbi hívás döntéssel folytatja. Mindhárom nagy stack kapott már erre első osztályú primitívet. Az API különbözik, a hibamódok hasonlók.

A hivatalos dokumentációból érdemes tudni néhány részletet, mielőtt ráépítesz. A LangGraph interrupts útmutatója figyelmeztet, hogy a folytatott node az elejéről fut újra, így az interrupt előtt elküldött e-mail kétszer menne ki. Az OpenAI Agents SDK útmutatója megmutatja, hogy a needs_approval lehet async függvény, amely hívásonként a paraméterek alapján dönt, és hosszú életű jóváhagyásoknál azt írja: a szerver hitelesítse az ellenőrt, a tárolt futás ellen ellenőrizze a jogosultságot, a döntésazonosítókat a szerver oldali állapottal validálja, és a döntéseket atomikusan alkalmazza a replay megelőzésére. A Claude Agent SDK dokumentációja rögzíti, hogy a callback korlátlanul függőben maradhat, és a defer döntést ajánlja, ha az ember tovább tarthat, mint ameddig a folyamatod életben maradhat.

from langgraph.types import interrupt, Command

def refund_node(state):
    # runs again from the top after resume: keep everything above idempotent
    decision = interrupt({
        "action": "refund", "amount": state["amount"],
        "customer": state["customer_id"], "tier": 3,
    })
    return Command(goto="execute" if decision["approved"] else "cancel")

# later, possibly from another process, same thread_id
graph.stream_events(Command(resume={"approved": True}),
                    config={"configurable": {"thread_id": "case-4711"}}, version="v3")

Bármelyik frameworköt használod, négy tulajdonságot teszek hozzá. Kösd a jóváhagyást a pontos műveletre: a döntés mellé tárold az eszköznév és az argumentumok hash-ét, és végrehajtáskor ellenőrizd újra, hogy a jóváhagyás után megváltozott terv ne legyen fedezve. Hitelesítsd a jóváhagyót a session alapján, soha ne a request body-ból. Járasd le a jóváhagyásokat percek vagy órák után, ne napokéra. Tedd idempotenssé a végrehajtó lépést idempotency kulccsal, mert a resume, a retry és a dupla kattintás mind létezik. Az eszközbiztonság tágabb kérdéseiben az MCP szerver biztonsági ellenőrzőlistám a probléma másik felét fedi le.

Audit nyomvonal és eszkaláció

A nyom nélküli jóváhagyást nem lehet felülvizsgálni, megtámadni vagy tanulni belőle. Minden kapuzott műveletnél kis, unalmas tényhalmazt naplózok: a futás és a szál azonosítóját, a javasolt műveletet teljes argumentumokkal, a szintet és a szabályt, amely hozzárendelte, ki döntött (ember, szabály vagy ellenőrző modell), a döntést és az esetleges módosítást, az időbélyeget és a késleltetést, valamint a végrehajtás eredményét. Az argumentumokat úgy tárold, ahogy az ellenőrnek megmutattad. Ha a felület összefoglalót jelenít meg, azt is őrizd meg, mert a vita gyakran arról szól, mit látott az ember.

Szabályozott területen ez nem opcionális. Az EU AI Act 14. cikke, amely a nagy kockázatú rendszerekre vonatkozik, olyan felügyeletet kér, amellyel a kijelölt személyek megérthetik a rendszer korlátait, tudatában maradhatnak az automation biasnak, dönthetnek úgy, hogy nem használják vagy felülbírálják a kimenetet, és beavatkozhatnak a működésbe vagy leállíthatják a rendszert. Hogy az ügynököd nagy kockázatú-e, a felhasználási esettől függ, ezért ellenőrizd, mielőtt bármelyik irányba feltételezed. Az EU AI Act ellenőrzőlistám fejlesztőknek az átláthatósági oldalt tárgyalja.

Az eszkaláció az a rész, amelyet a csapatok elfelejtenek. Előre döntsd el, kit kérdeznek, mennyi ideje van, és mi történik utána. Egy működő létra: először a kérő felhasználó, aztán egy megnevezett szerep (a folyamat gazdája), aztán a 3. szintnél egy második jóváhagyó, és ha senki nem válaszol, az alapértelmezés az elutasítás. Adj hozzá az ügynöktől független kill switchet: egy jelzőt, amely leállítja az új futásokat és megszakítja a függő jóváhagyásokat. Az értesítéseket olyan csatornán küldd, amelyet az emberek amúgy is figyelnek. A Claude Agent SDK-nak például van PermissionRequest hookja, amelyet arra szántak, hogy Slack- vagy e-mail-értesítést küldjön, amikor az ügynök vár.

Mit változtatnak az always-on ügynökök

Minden eddigi feltételezte, hogy egy ember ül egy chat előtt. Az always-on ügynökök ezt a feltételezést megdöntik. Egy dot vagy egy ütemezett kódoló ügynök órákig dolgozik, akkor is fut, amikor te alszol, és géptempóban termel jóváhagyásokat. Ahogy a dots hatáselemzésben írtam, az ember a lánc elejéről a végére kerül, és a szűk keresztmetszet a figyelem lesz.

Az OpenAI közzétett dots-tervezése hasznos referencia, mert kockázat szerint szintezett kapu. A háttérkutatás csak olvasó eszközökkel fut, egy külön Auto-review rendszer a következményekkel járó lépéseket az utasításaid, a Custom Rules szabályaid és a biztonsági követelmények ellen ellenőrzi, a Custom Rules pedig engedélyezhet, jóváhagyáshoz köthet vagy tilthat műveleteket, de a kötelező alsó határt nem tudja eltávolítani: jelszó megváltoztatása vagy számlák közötti pénzmozgatás mindig visszamegy a személyhez. Ez a 0., 2. és 3. szint egy termékben.

Ebből három következmény adódik a saját tervezésedre. Először: a szabályok kiváltják a kérdések többségét. Egy olyan szabályrendszer, mint „X alatti visszatérítés fut, felette kérdez, bankadatot érintő minden tiltott”, ezernyi kis értékű megszakítást szüntet meg, a megmaradók pedig olvasásra érdemes eseményekké válnak. Másodszor: az ellenőrző modell eszköz, nem orákulum. Skálázódik és nem fárad, de az Anthropic saját számai nullánál nagyobb hibaarányt mutatnak, az OpenAI Auto-review-ja pedig a gyártó modellje, amely a gyártó ügynökét felügyeli. A determinisztikus 3. szintű szabályokat tartsd bármely modellen kívül, az automatikusan jóváhagyott műveletekből pedig vegyél mintát emberi auditra. Harmadszor: a kapuk a műveleteket kontrollálják, nem azt, amit az ügynök olvas. Egy csak olvasó dot is látja a teljes ügyfélrekordot, ezért a minimális jogosultságú kapcsolatok és a maszkolt adatok éppúgy a tervezés részei, mint a jóváhagyások. Ezt a mintát mélyebben a prompt injection és a lethal trifecta cikkben tárgyalom.

Ellenőrzőlista a következő ügynöködhöz

Ezt a listát venném végig, mielőtt írási joggal rendelkező ügynököt engednék valódi adatokra:

1. Listázd az összes eszközt és hozzájuk a legrosszabb esetű argumentumokat. Rendelj szintet a visszafordíthatóság, a hatókör, az adatok és a jogosultság alapján.
2. A szintdöntést told az ügynökön kívülre: először determinisztikus szabályok, aztán egy ellenőrző modell, soha nem az ügynök saját megítélése.
3. A 3. szintet alapból tiltsd, és csak megnevezett átadáson, hitelesített jóváhagyóval engedd.
4. A jóváhagyó képernyőt a hatás köré építsd: payload, diff, címzett, összeg, a szokatlan részek kiemelésével.
5. Vond össze a hasonló 2. szintű lépéseket, támogasd a szerkesztést a jóváhagyás és az elutasítás mellett, és az elutasítás indokát add vissza az ügynöknek.
6. Checkpointerrel vagy szerializált állapottal szüneteltess, a szünet előtti mindent tegyél idempotenssé, és minden jóváhagyást kösd a pontos művelet hash-éhez.
7. Időtúllépésnél utasíts el, járasd le a jóváhagyásokat, és tarts egy, az ügynöktől független kill switchet.
8. Naplózd, hogy ki, mit, melyik szint, melyik szabály, döntés, módosítások, idő és eredmény, és őrizd meg, amit az ellenőr ténylegesen látott.
9. Hetente vegyél mintát az automatikusan jóváhagyott műveletekből emberi felülvizsgálatra, és műveletfajtánként kövesd a jóváhagyási arányt és a döntési időt.
10. Minden incidens és minden új eszköz után szintezz újra: a mátrix élő dokumentum.

Ha segítséget szeretnél ennek konkrét architektúrává alakításához az ügynökeidhez, ezt csinálom az AI engineering munkám során.

A nagyobb kép

A human in the loop nem tűnik el, ahogy az ügynökök jobbak lesznek, de az alakja változik. Az alapértelmezés „egy ember minden lépést jóváhagy”-ról „egy ember szabályokat állít, átnézi a kivételeket és auditálja a többit”-re tolódik. Az, hogy a Claude Code-ban az auto mód lesz az alapértelmezett, a dotsnál pedig Auto-review réteg van, két gyártó, amely ugyanabban a szezonban jut ugyanarra a következtetésre.

Ami emberi marad, az a felelősség. Egy osztályozó jóváhagyhat egy műveletet, de nem lehet felelős érte. Úgy tervezz minden kaput, hogy ha valami rosszul sül el, meg tudd válaszolni, ki engedte, milyen információ alapján és melyik szabály szerint.

Források

1. LangChain docs: LangGraph interrupts
2. LangChain docs: Human-in-the-loop (HumanInTheLoopMiddleware)
3. OpenAI Agents SDK (Python): Human in the loop
4. Claude Agent SDK: Handle approvals and user input
5. Claude Agent SDK: Configure permissions
6. Claude Code docs: Hooks (PreToolUse defer, PermissionRequest)
7. Anthropic Engineering: Claude Code auto mode
8. DevOps.com: Anthropic makes Claude Code auto mode the default
9. EU AI Act, Article 14: Human oversight
10. OpenAI: How we build safety, security and privacy into dots