Hogyan Működik egy IA Ügynök?

Hogyan Működik egy Beszélgetési IAI Ügynök (OpenClaw Architektúra)

Hogyan működik egy beszélgetési IAI ügynök a gyakorlatban, fordulónként? Ez a bejegyzés megnyitja a fekete dobozt az OpenClaw: a vevő üzenetének érkezésétől a ügynök visszajelzéséig. Lesz technikai. Érdemes elolvasni, ha termékkoncepciót tervez, ha megvásárol egy megoldást és értékelni szeretné a hátteret, vagy ha élvezi, hogy mi történik a beszélgetés mögött.

TL;DR: minden forduló 6 szakaszon megy keresztül — fogyasztás, kontextus megoldása, készségek kiválasztása, következő cselekvés meghatározása, végrehajtás védőrácsokkal, memória megőrzése. Az egész ciklus a Cloudflare Edge-n fut másodpercekben, nincs fix szerver.

---

Miért fontos az architektúra

A beszélgetési IAI ügynök, amely egy demóban működik, de a termelésben megszakad, általában az egyik ezek közül a 4 probléma közül:

1. Magas késés — a vevő 8 másodpercet vár a válaszra, a beszélgetés meghal.
2. Kontroll nélküli hallucináció — az ügynök átveri a vevőt, például átveri a árat, az időpontot vagy a politikát.
3. Kontextus elvesztése — a vevő visszatér 2 nap múlva, és az ügynök "elfelejti" az összes információt.
4. Kontroll nélküli költség — minden hosszú beszélgetés feltölti a promptot, és a tulajdonosok nagy összegeket fizetnek tokenekért.

A 4 mind a termékkoncepció választása, nem a modell korlátozása. Az OpenClaw építésének célja az volt, hogy elkerülje a 4-et — és a megértés útja, hogy nézzük a forduló ciklusát.

---

A forduló ciklus (6 szakasz)

Képzeljük el, hogy a vevő most küldte el az üzenetet "Szeretném megjegyezni a szombat reggelt". Mi történik a "kapott" és az ügynök válasza között?

Szakasz 1 — Fogyasztás (Edge Worker, <ms)

A WhatsApp üzenet a Meta webhookjén keresztül érkezik egy Cloudflare Worker-ba a legközelebbi geográfiai helyen. Brazíliában ez a São Paulo vagy Rio, a hálózati késés <0ms.

A munkaerő három dolgot tesz:

1. Hitelesíti a webhook (HMAC a WABA ellenőrzésével).
2. Azonosítja a bérlőt a vevő számának alapján (multi-tenant to_number alapján).
3. Normalizálja a payload-t — az audio átalakul transzkripcióvá, a kép átalakul leírásúvá, a helyzet átalakul {lat,lng}-re, a szöveg marad a régi.

A szakasz végén egy {tenant_id, conversation_id, user_message} objektum készen áll a következő szakaszra.

Szakasz 2 — Kontextus megoldása (D1 + KV, ~80ms)

Az ügynöknek 3 kontextus-szükséglete van, mielőtt dönt:

• Utolsó N forduló a beszélgetés története (utolsó N releváns forduló).
• Hosszú távú emlékezet a kliens (preferenciák, vásárlási történet, megjegyzések).
• Az ügynök állapota (személyiség, engedélyezett készségek, szabályok).

Mindenki a D1-ből (Cloudflare által elosztott SQLite) származik. A D1 hagyományos Postgres/Mongo helyett szerver nélkül működik – a munkavégzőhöz kevesebb ms-t vesz igénybe, többfajta ügyfélre tenant_id-vel.

Fontos pont: nem töltsük be a teljes beszélgetést a promptba. Az OpenClaw Memory Manager 2 (leírást a Cloudflare fejlesztői dokumentációjában) csak a releváns fordulókat választja ki a jelenlegi fordulóhoz (utolsó N + N magas szemantikai relevancia nélkül). Ez a token költségeket előre jelezhetővé teszi, még akkor is, ha a beszélgetés 100-nál több fordulót tartalmaz.

Szakasz 3 – Készségek kiválasztása (policy engine, ~20ms)

Minden ügynöknek van egy készségek-gyűjteménye – olyan funkciók, amelyeket meghívhat. Példák: consultar_calendario, criar_evento, gerar_link_pagamento, consultar_pedido, chamar_humano.

Adott a quero marcar pra sábado de manhã üzenet, a policy engine szűri:

• Kompatibilis készségek az értelemmel (tervezés).
• Engedélyezett készségek a beszélgetés jelenlegi szakaszában (nem minden készség elérhető az idők során).
• Akkor engedélyezett készségek, amikor a tenant engedélyezi (a naptár csak akkor jelenik meg, ha a tenant integrálta).

Végül egy kis készségek-csoportot kapunk, amelyet a modellhez küldünk – nem a 50 lehetséges készséget, hanem a 4-et, amelyek itt értelmesek. Ez drasztikusan csökkenti a modell hibás készség meghívásának esélyét.

Szakasz 4 – A döntés (LLM hívás, 400-1200ms)

Most a modell lép. Az OpenClaw egyetlen hívást tesz a határoló LLM-hez (Anthropic Claude, OpenAI GPT, Google Gemini – konfigurálható a tenant által) a következővel:

• Sistem-prompt = ügynök személyisége + szabályok + elérhető készségek.
• Történet = a szakasz 2-ben kiválasztott fordulók.
• Felhasználói üzenet = a jelenlegi forduló üzenete.

A modell két dolgot adhat vissza:

• Végső válasz (szöveges válasz a kliensnek).
• Tool hívás (kérés a készség meghívására egyes paraméterekkel).

A quero marcar pra sábado de manhã példában a modell általában a következőt adja vissza:

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

Szakasz 5 – Végrehajtás a védőrácsokkal (változó, ~100-500ms)

A készség nem fut a modellben. Fut egy kódunk, amely:

Translated markdown (hu-HU) (folytatás):

1. Érvényes szabályok ellenőrzése (a date_range formátuma helyes? A tenant szabályai szerint van-e benne?).
2. Hozzáférés ellenőrzése (ez az ügynök jogosult-e a kalendárium megtekintésére?).
3. A Google Calendar API meghívása (ebben az esetben).
4. Strukturált eredmény visszaadása a modellnek.

Miért fontos ez? Mert a modell soha nem gyártja a eredményt. Ha a kalendárium visszaadja [10h, 11h]-t, akkor ez az, amit a következő hívásra küldünk. Ha a képesség meghiúsul, a modell tudja, hogy meghiúsult. Zéró kockázat, hogy az ügynök "kitalálja", hogy van időpontja 9 órakor, amikor nincs.

A kényes információkkal (ár, határidő, ügyfél neve) foglalkozó esetekben a folyamat erősen kényszeríti a tool call-t – nem hagyja, hogy a modell a saját "tudásából" válaszoljon. Ez eltünteti a leggyakoribb hallucináció-t az ügynökök között.

6. szakasz – Válasz és fennmaradás (~50ms)

A képesség eredményével a modell a második hívást teszi – most a végleges válasz kialakítására a vevőnek. Például:

"Szerdán 10 órakor és 11 órakor van. Melyiket preferálja?"

Ezen idő alatt a munka:

1. Visszaküldi a választ a WhatsApp API-n keresztül.
2. Fennmaradás a teljes forduló (felhasználó + asszisztens + eszköz-hívások + időtartam) a D1-ben.
3. Frissíti a hosszú távú memóriát , ha a forduló új tényt alkotott (pl. "a vevő szerdát preferálja").
4. Emitál megfigyelhető eseményt (latencia mértéke, token költsége, méretezési arány).

Mindez párhuzamosan fut. A fennmaradás nem blokkolja a válasz küldését – a vevő nem várja a D1-et.

---

A hallucináció elleni védelem

A termelésben hallucináló ügynök gyorsan elveszíti a bizalmat. Az OpenClaw 4 vonalas védelmet kínál:

1. Forráskódú igazság. A tények (ár, időpont, neve) mindig a képességtől származnak, soha nem a modelltől.
2. Kettős ellenőrzés kényes adatoknál. Az időpontokat a vevővel igazoljuk, mielőtt fennmaradnánk. A fizetést igazoljuk, mielőtt engedélyeznénk az hozzáférést.
3. Kifejezett negatív szabályok. Minden ügynök személyisége tartalmazza a "soha ne találd ki X, Y, Z" – a modell engedelmeskedik.
4. Visszalépés a humánhoz. Amikor nincs képesség, amely fedezné a kérdést, az ügynök azt mondja "hagyjuk meg, hogy a csapat ellenőrizze" és nyit egy jegyzetet – nem lövi.

Az elmúlt 6 hónapban végzett auditokban (valós beszélgetések, manuálisan ellenőrizve) a tények hallucinációja 0,3%-os fordulókra csökkent – és a legtöbb esetben a konfiguráció (a tenant elfelejtette a releváns képességet engedélyezni) volt a hiba, nem a modellhiba.

---

A beszélgetés költsége

A fordulók költsége

Jó arhitektúra nem is látszik, amíg meg nem nézed a számlát. Adott, hogy minden forduló 1-2 LLM-hívást és D1-ben végzett kereséseket tartalmaz, a teljes beszélgetés (10-15 forduló) átlagos költsége a következő:

(Note: I translated the text exactly as per your requirements, preserving all markdown formatting and not translating URLs, code, or HTML tags.)