LangGraph és human-in-the-loop vállalati környezetben

Amikor a fejlesztők elkezdenek az AI-al kísérletezni, általában egyszerű láncokat (Chains) építenek, például a népszerű LangChain alapkönyvtárral. Ez úgy néz ki: Kérdés be → Adatbázis keresés → Prompt kiegészítés → Válasz ki.

Ez egy laborban vagy egy egyszerű ügyfélszolgálati chatbotnál tökéletesen működik, de egy komplex vállalati munkafolyamatban (ahol írni, törölni, jóváhagyni kell adatokat) azonnal elvérzik. Egy lánc nem tud visszalépni (loop), nem tud órákat várakozni egy emberi döntésre (megszakad a szerver kapcsolat), és ha a 8. lépésben jön egy API hiba, a teljes folyamat elszáll, kezdve mindent elölről.

Egy vállalati folyamatnak (pl. "Készíts egy ajánlatot, kérj vezetői jóváhagyást, majd küldd ki és rögzítsd a CRM-ben") Ciklusokra (Ciklikus Gráfokra) és Állapotokra (State) van szüksége. Itt lép be a képbe a LangGraph.

A LangGraph a LangChain csapatának fejlesztése, ami pont azt a problémát oldja meg, hogy egy AI-Agent munkafolyamatát Csomópontokra (Nodes) és Élekre (Edges/Transitions) bontja.

Adatgyűjtés (Node 1) → Kockázatelemzés (Node 2) → Emberi Jóváhagyás (Pause/Interrupt) → Rendszerbe írás (Node 3)

A LangGraph legfontosabb képessége a State (Állapot) és a Checkpointer (Mentési pont). Minden lépés után a rendszer lementi a teljes kontextust (mit tudunk eddig, mik az eddigi eredmények) egy adatbázisba (pl. PostgreSQL). Ha a folyamatot meg kell szakítani (pl. mert egy embertől várunk választ), a szerver nyugodtan leállhat. Amikor az ember (akár 2 nap múlva) rákattint az "Engedélyezem" gombra, a LangGraph betölti az állapotot, és pontosan onnan folytatja a gráf végrehajtását, ahol abbahagyta.

A "Human-in-the-Loop" (Ember a hurokban) nem azt jelenti, hogy egy szegény adminisztrátornak minden egyes AI döntést el kell olvasnia. A kontroll szintjét a kockázat (Risk) alapján kell a gráfban elhelyezni.

Fejlesztői szempontból a megszakítás a legnehezebb feladat. A LangGraph segítségével azonban a fejlesztő szó szerint betehet egy interrupt() parancsot abba a csomópontba (node), ahol mondjuk a pénzügyi tranzakció történne.

Mi történik a háttérben?

• 1. Fagyasztás: A gráf leáll. A Checkpointer kimenti az adatbázisba a jelenlegi állapot minden változóját (Thread ID, Memory).
• 2. Értesítés: Egy háttérfolyamat küld egy webhookot, Slack üzenetet vagy e-mailt a kijelölt vezetőnek, benne egy linkkel a Jóváhagyási Dashboardra.
• 3. Bizonyítékok (Evidence) bemutatása: Amikor a vezető megnyitja a linket, nem csak egy "Ok/Nem Ok" gombot lát. Látnia kell, hogy az Agent milyen adatok (források) alapján döntött, mi lenne a végrehajtandó API hívás (pl. Update Status to Refunded), és mi a javaslat indoklása.
• 4. Folytatás vagy Visszagörgetés (Rollback): A vezető dönthet úgy, hogy elfogadja (ekkor a gráf folytatódik a következő lépéssel), módosítja az adatokat (új State-et injektál a gráfba), vagy megszakítja a folyamatot.

Mivel a LangGraph csomópontokra bontja a folyamatot, minden lépés külön újrapróbálható (Retry). Ha az 5. csomópontban a CRM szerver API-ja másodpercekre leáll, a gráf nem bukik el (mint egy régi script), hanem csak azt az egy csomópontot futtatja újra, az elmentett állapot alapján.

Nagyon fontos fogalom az Idempotencia. Ha egy folyamat valamiért újraindul (mert mondjuk a vezető kétszer nyomott a jóváhagyás gombra), a rendszernek garantálnia kell, hogy a végrehajtás (pl. egy számla kiállítása) ne történjen meg kétszer. A LangGraph Thread ID-jai (szálazonosítói) és a Backend egyedi azonosítói (UUID) védik a vállalatot a duplikált akcióktól.

"Egy Agent önállósága nem attól lesz nagyobb, hogy vakon megbízunk benne, hanem attól, hogy beépítjük a fékeket. Amikor egy ügyfelünknek LangGraph alapú rendszert tervezünk, a projekt első lépése sosem az AI promtok írása, hanem a Kockázati Mátrix felrajzolása. Megkeressük a 'Pont of No Return' lépéseket (ahol az adat elhagyja a céget, vagy pénzbe kerül), és oda keménykódolt emberi megszakítási pontokat teszünk. A vicc az, hogy ahogy az operátorok látják, hogy az Agent naponta 100-ból 99-szer jól dönt, ők maguk fogják kérni pár hónap múlva, hogy vegyük ki a jóváhagyási pontot, mert fárasztó kattintgatni. Ezt hívjuk 'Earned Autonomy'-nak (Kiérdemelt Autonómia)." — Szabó Attila, Integrációs Szakértő

Szükséges egyedi szoftvert (Frontend UI) fejleszteni a jóváhagyásokhoz?
Igen, egy teljesen éles, biztonságos vállalati környezetben javasolt. Bár a LangGraph háttérrendszere (Backend) kezeli az állapotot, a vezetőknek szükségük van egy tiszta, webes felületre, ahol az SSO (Single Sign-On) login után látják az engedélyre váró Agent feladatokat (Review Queue). Mi az AI Hungáriánál dedikált, reszponzív UI-t fejlesztünk ehhez.

A LangGraph csak Pythonban érhető el?
Nem. A LangGraph rendkívül erős és hivatalosan támogatott TypeScript (Node.js) ökoszisztémával is rendelkezik, ami tökéletessé teszi modern, felhős (pl. Next.js, Vercel, AWS Lambda) webes környezetekbe történő integrációra.

Mi történik, ha egy Agent hibás eszközt (Tool) akar meghívni?
A LangGraph gráfjában a "Tool Node" (Eszköz végrehajtó csomópont) kapja el a hívást. Ha a modell hibás paramétert küldött (pl. string-et szám helyett), a kódolt Tool Node visszaadja a hibaüzenetet a gráfba (mint egy kivételt). A gráf visszalép az AI csomópontba a hibaüzenettel: "A hívás elbukott, mert a paraméter rossz, próbáld újra javítva." Az AI ilyenkor képes az önkorrekcióra (Self-Correction).