Hogyan Működik egy Beszélgető AI Ügynök Belülről

Hogyan Működik egy Beszélgetési AI Ügynök Belülről (OpenClaw Architektúra)

Hogyan működik egy beszélgetési AI ügynök a gyakorlatban, körről körre? Ez a bejegyzés kinyitja az OpenClaw fekete dobozát: attól a pillanattól, hogy az ügyfél üzenete megérkezik a WhatsAppra, addig a szövegig, amit az ügynök visszaír. Technikai lesz. Megéri, ha termékarchitektúráról döntesz, ha megoldást akarsz vásárolni és mélyrehatóan értékelni szeretnéd, vagy ha érdekel, mi történik a beszélgetés mögött.

TL;DR: minden kör 6 szakaszon megy keresztül — betöltés, kontextus feloldása, képességek kiválasztása, következő lépés eldöntése, végrehajtás korlátokkal, memória megőrzése. Az egész ciklus <2 másodperc alatt fut a Cloudflare edge-én, fix szerver nélkül.

---

Miért számít az architektúra

A beszélgetési ügynök, ami demóban működni látszik, de éles környezetben összeomlik, általában e 4 probléma egyikével rendelkezik:

1. Magas késleltetés — az ügyfél 8 másodpercet vár a válaszra, a beszélgetés meghal.
2. Ellenőrizetlen hallucináció — az ügynök kitalál árat, időpontot, szabályzatot.
3. Elveszett kontextus — az ügyfél 2 nap után visszatér és az ügynök "elfelejt" mindent.
4. Ellenőrizetlen költség — minden hosszú beszélgetés megtölti a promptot és vagyonokat fizetsz tokenekért.

Mind a 4 architektúra választás, nem a modell korlátja. Az OpenClaw úgy lett megépítve, hogy elkerülje mind a 4-et — és a megértés útja egy kör ciklusának megtekintése.

---

Egy kör ciklusa (6 szakasz)

Képzeld el, hogy az ügyfél épp elküldte az üzenetet: "szombat reggelre szeretnék időpontot". Mi történik a "received" és az ügynök válasza között?

1. szakasz — Betöltés (edge worker, <50ms)

A WhatsApp üzenet webhookon keresztül érkezik a Metától közvetlenül egy Cloudflare Worker-be a legközelebbi földrajzi jelenléti ponton (PoP). Brazíliában ez São Paulót vagy Riót jelenti, <20ms hálózati késleltetéssel.

A worker három dolgot csinál:

1. Validálja az aláírást a webhookból (HMAC a WABA titkos kulcsa ellen).
2. Azonosítja a bérlőt a fogadó telefonszáma alapján (multi-tenant to_number szerint).
3. Normalizálja a payloadot — hang átírássá válik, kép leírássá, helyszín {lat,lng}-vé, szöveg marad, ami.

Az 1. szakasz végén van egy {tenant_id, conversation_id, user_message} objektumod készen a következő lépésre.

2. szakasz — Kontextus feloldása (D1 + KV, ~80ms)

Az ügynöknek 3 kontextus darabra van szüksége a döntés előtt:

• A beszélgetés közelmúltbeli előzményei (az utolsó N releváns fordulók).
• Az ügyfél hosszú távú memóriája (preferenciák, vásárlási előzmények, megjegyzések).
• Az ügynök állapota (persona, engedélyezett skillek, szabályok).

Mindegyik a D1-ből (Cloudflare elosztott SQLite) származik. A D1 helyettesíti a hagyományos Postgres/Mongo megoldásokat — nincs karbantartandó adatbázis-szerver, néhány ms-os hozzáférés a workerből, multi-tenant tenant_id alapján.

Kulcspont: nem töltjük be a teljes beszélgetést a promptba. Az OpenClaw Memory Manager v2 (amelyet a belső dokumentációnkban írunk le) csak az aktuális forduló szempontjából releváns fordulatokat választja ki (utolsó N + N magas szemantikai relevanciával). Ez kiszámíthatóan tartja a token költséget még 100+ fordulós beszélgetések esetén is.

3. szakasz — Skill kiválasztás (policy engine, ~20ms)

Minden ügynöknek van egy sor elérhető skillje — funkciók, amelyeket meghívhat. Példák: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

A "quero marcar pra sábado de manhã" üzenet esetén a policy engine szűri:

• Az észlelt szándékkal kompatibilis skilleket (időpontfoglalás).
• A beszélgetés ezen fázisában engedélyezett skilleket (nem minden skill érhető el mindig).
• Azokat a skilleket, amelyeket ez a tenant engedélyezett (a calendar csak akkor jelenik meg, ha a tenant integrálta).

Végül egy kis skill-részhalmazt kap a modell — nem az összes 50 lehetséges, csak a 4, ami itt értelmes. Ez drasztikusan csökkenti annak esélyét, hogy a modell rossz skillt hívjon meg.

4. szakasz — Döntés (LLM hívás, 400-1200ms)

Most lép be a modell. Az OpenClaw egyetlen hívást végez egy élvonalbeli LLM-hez (Anthropic Claude, OpenAI GPT, Google Gemini — tenant szerint konfigurálható) a következőkkel:

• System prompt = az ügynök personája + szabályok + elérhető skillek.
• History = a 2. szakaszban kiválasztott fordulók.
• User message = az aktuális fordulat üzenete.

A modell két dolog egyikével válaszol:

• Végső válasz (közvetlen szöveg az ügyfélnek).
• Tool call (kérés egy adott skill végrehajtására paraméterekkel).

A "quero marcar pra sábado de manhã" példában a modell jellemzően ezt adja vissza:

{
  "tool": "consultar_calendario",
  "args": { "date_range": "2026-04-19 06:00 to 12:00" }
}

5. szakasz — Végrehajtás guard-railekkel (változó, ~100-500ms)

A skill nem a modellben fut. A saját kódunkban fut, amely:

1. Paraméterek validálása (a date_range formátuma helyes? megfelel a bérlő szabályainak?).
2. Jogosultság ellenőrzése (ez az ügynök jogosult lekérdezni ezt a naptárt?).
3. Hívás végrehajtása (ebben az esetben a Google Calendar API).
4. Strukturált eredmény visszaadása a modellnek.

Miért fontos ez? Mert a modell soha nem gyárt eredményt. Ha a naptár [10h, 11h]-t ad vissza, pontosan ez megy tovább a következő hívásba. Ha a skill sikertelen, a modell tudja, hogy sikertelen volt. Nulla kockázata annak, hogy az ügynök "kitalálja", hogy van időpont 9 órakor, amikor nincs.

Érzékeny információt érintő esetekben (ár, határidő, ügyfél neve) a pipeline tool call-t kényszerít — nem engedi, hogy a modell a saját "tudásából" válaszoljon. Ez kiküszöböli a leggyakoribb hallucinációs osztályt a kereskedelmi ügynökökben.

6. szakasz — Válasz és perzisztencia (~50ms)

A skill eredményével a kezében a modell elvégzi a második hívást — most a végső válasz kialakítására az ügyfél számára. Pl.:

"Szombaton 10 és 11 órakor van időpontom. Melyiket részesíti előnyben?"

Ezzel párhuzamosan a worker:

1. Elküldi az üzenetet a WhatsApp API-n keresztül.
2. Perzisztálja a teljes fordulót (user + assistant + tool calls + időtartam) a D1-ben.
3. Frissíti a hosszú távú memóriát, ha a forduló új tényt eredményezett (pl.: "az ügyfél a szombatot részesíti előnyben").
4. Megfigyelhetőségi eseményt bocsát ki (késleltetési metrika, token költség, eszkalációs arány).

Mindez párhuzamosan fut. A perzisztencia nem blokkolja az üzenet küldését — az ügyfél nem vár a D1-re.

---

Hol van a védelem a hallucináció ellen

Az ügynök, amely hallucinál éles környezetben, gyorsan elveszíti a bizalmat. Az OpenClaw 4 védelmi vonallal rendelkezik:

1. Kényszerített igazságforrás. A tényadatok (ár, időpont, név) mindig skillből származnak, soha nem a modellből egyedül.
2. Dupla ellenőrzés érzékeny adatoknál. Az időpontfoglalást az ügyféllel megerősítik a perzisztálás előtt. A fizetést megerősítik a hozzáférés engedélyezése előtt.
3. Explicit negatív szabályok. Minden ügynök personája tartalmazza: "soha ne találd ki X, Y, Z-t" — a modell engedelmeskedik.
4. Fallback emberi beavatkozásra. Amikor egyetlen skill sem fedi le a kérdést, az ügynök azt mondja: "hadd ellenőrizzem a csapattal" és ticketet nyit — nem tippel.

Az elmúlt 6 hónapban végzett auditokban (valós beszélgetések manuális felülvizsgálata) a ténybeli hallucináció aránya a fordulók 0,3%-a alatt maradt — és szinte minden eset konfigurációs hiba volt (a bérlő elfelejtette engedélyezni a releváns skillt), nem a modell hibája.

---

A beszélgetésenkénti költség

A jó architektúra láthatatlan, amíg meg nem nézed a számlát. Mivel minden fordulóban 1-2 LLM hívás + D1 lekérdezés történik, egy teljes beszélgetés (10-15 fordulós) tipikus költsége: