Hogyan építsünk egy AI ügynököt

Rövid válasz: Egy gyakorlatban működő MI-ügynök felépítéséhez úgy kell kezelni, mint egy szabályozott ciklust: bemenetet kell fogadni, el kell dönteni a következő műveletet, meg kell hívni egy szűk hatókörű eszközt, meg kell figyelni az eredményt, és addig kell ismételni, amíg egy egyértelmű „kész” ellenőrzés nem sikerül. Akkor érdemli ki a jutalmát, ha a feladat több lépésből áll és eszközvezérelt; ha egyetlen prompt megoldja, akkor ki kell hagyni az ágenst. Szigorú eszközsémákat, lépéskorlátokat, naplózást és egy validátort/kritikust kell alkalmazni, hogy amikor az eszközök meghibásodnak vagy a bemenetek nem egyértelműek, az ágens eszkalálódik a ciklus helyett.

Főbb tanulságok:

Vezérlőhurok: Bemenet→cselekvés→ismétlés megfigyelése explicit leállítási feltételekkel és maximális lépésekkel.

Eszköztervezés: Az eszközök legyenek szűkek, típusosak, jogosultságokkal ellátottak és validáltak, hogy elkerüljük a „bármit is csináljunk” káoszt.

Memóriahigiénia: Használjon kompakt rövid távú állapotot és hosszú távú visszakeresést; kerülje a teljes átiratok kiírását.

Visszaélés-gátló: Engedélyezési listák, sebességkorlátok, idempotencia és „száraz futtatás” hozzáadása kockázatos műveletekhez.

Tesztelhetőség: Forgatókönyv-készletet kell fenntartani (hibák, kétértelműségek, injekciók), és minden változás esetén újra kell futtatni.

---

1) Mit jelent a mesterséges intelligencia által vezérelt ügynök egy átlagos ember számára? 🧠

Egy MI-ügynök egy ciklus. LangChain „Ügynökök” dokumentáció

Ennyi. Egy hurok, aminek a közepén egy agy van.

Bevitel → gondolkodás → cselekvés → megfigyelés → ismétlés. ReAct papír (indoklás + cselekvés)

Ahol:

• A bemenet egy felhasználói kérés vagy egy esemény (új e-mail, támogatási jegy, érzékelő ping).

• A Think egy nyelvi modell, amely a következő lépésről gondolkodik.

• Az Act egy eszközt hív (belső dokumentációk keresése, kód futtatása, ticket létrehozása, válasz vázlatának elkészítése). OpenAI függvényhívási útmutató

• Az Observe leolvassa az eszköz kimenetét.

• Az ismétlődés az a rész, ami miatt „ügynöki” a „beszédes” helyett. LangChain „Ügynökök” dokumentáció

Néhány ügynök alapvetően intelligens makró. Mások inkább egy junior operátorként működnek, akik képesek feladatokat zsonglőrködni és hibák után helyreállítani a folyamatot. Mindkettő számít.

Ráadásul nincs szükséged teljes autonómiára. Sőt… valószínűleg nem is akarod 🙃

---

2) Mikor érdemes ügynököt építened (és mikor nem) 🚦

Hozz létre egy ügynököt, amikor:

• A munka több lépésből , és attól függően változik, hogy mi történik a folyamat közepén.

• A munkakörhöz eszközök használata szükséges (adatbázisok, CRM-ek, kódfuttatás, fájlgenerálás, böngészők, belső API-k). LangChain „Eszközök” dokumentáció

• Megismételhető eredményeket szeretnél korlátokkal, nem csak egyszeri válaszokat.

• A „kész” szót úgy definiálhatod, hogy egy számítógép – akár csak lazán is – ellenőrizni tudja.

Ne építsen ügynököt, ha:

• Egy egyszerű kérdés + válasz megoldja (ne tervezd túl, mert később utálni fogod magad).

• Tökéletes determinizmusra van szükség (az ágensek lehetnek konzisztensek, de nem robotikusak).

• Nincsenek eszközeid vagy adataid a kapcsolódáshoz – akkor többnyire csak rezgések maradnak.

Legyünk őszinték: az „AI-ügynökprojektek” fele lehetne egy munkafolyamat néhány elágazási szabállyal. De hé, néha a hangulat is számít 🤷♂️

---

3) Mitől lesz egy AI-ügynök jó ✅

Itt van a „Mitől lesz jó egy verziója?” rész, amit kértél, de kicsit nyers leszek:

Egy MI-ügynök jó verziója nem az, amelyik a legkeményebben gondolkodik, hanem az, amelyik:

• Tudja, mit szabad tennie (hatókör határai)

• Megbízhatóan használja az eszközöket (strukturált hívások, újrapróbálkozások, időtúllépések) OpenAI függvényhívási útmutató AWS „Időtúllépések, újrapróbálkozások és visszalépések jitterrel”

• Tisztán tartja az állapotot (nem korhadó memória) LangChain „Memória áttekintés”

• Elmagyarázza a tevékenységeit (ellenőrzési naplók, nem titkos indoklások) NIST AI RMF 1.0 (megbízhatóság és átláthatóság)

• Megfelelően megáll (teljesítési ellenőrzések, maximális lépésszám, eszkaláció) LangChain „Ügynökök” dokumentáció

• Biztonságosan kudarcot vall (segítséget kér, nem hallucinál tekintélyt) NIST AI RMF 1.0

• Tesztelhető (előkészített forgatókönyveken futtatható és az eredményeket pontozhatja)

Ha az ügynöködet nem lehet tesztelni, akkor alapvetően egy nagyon magabiztos nyerőgépről van szó. Bulikon szórakoztató, produkcióban ijesztő 😬

---

4) Egy ágens alapvető építőelemei („anatómia” 🧩)

A legtöbb szilárd ügynök rendelkezik ezekkel a darabokkal:

A) A vezérlőhurok 🔁

Ez a hangszerelési szakember:

• gólt szerezni

• kérdezd meg a modellt a következő lépésről

• futtatóeszköz

• megfigyelés hozzáfűzése

• ismételd, amíg kész nem lesz a LangChain „Ügynökök” dokumentációja

B) Eszközök (más néven képességek) 🧰

Az eszközök teszik hatékonnyá az ügynököt: LangChain „Eszközök” dokumentáció

• adatbázis-lekérdezések

• e-mailek küldése

• fájlok lehívása

• futó kód

• belső API-k hívása

• táblázatokba vagy CRM-ekbe írás

C) Memória 🗃️

Kétféle számít:

• rövid távú memória: a jelenlegi futási kontextus, a legutóbbi lépések, a jelenlegi terv

• hosszú távú memória: felhasználói preferenciák, projekt kontextusa, visszakeresett tudás (gyakran beágyazások + vektortároló segítségével) RAG-papír

D) Tervezési és döntéshozatali politika 🧭

Még ha nem is nevezed „tervezésnek”, szükséged van egy módszerre:

• ellenőrzőlisták

• ReAct stílusú „gondolkodj, majd használd” ReAct dolgozat

• feladatgráfok

• felügyelő-munkavállaló minták

• felügyelő-munkavállaló minták Microsoft AutoGen (többügynökös keretrendszer)

E) Korlátok és értékelés 🧯

• jogosultságok

• biztonságos eszközsémák OpenAI strukturált kimenetek

• kimeneti validáció

• lépéskorlátok

• fakitermelés

• NIST AI RMF 1.0 tesztek

Igen, ez inkább mérnöki munka, mintsem sugalmazás. Ami… nagyjából a lényeg is.

---

5) Összehasonlító táblázat: népszerű módszerek ügynöképítésre 🧾

Alább egy valósághű „Összehasonlító táblázat” látható – néhány furcsasággal, mert az igazi csapatok különcök 😄

Eszköz / Keretrendszer	Közönség	Ár	Miért működik	Jegyzetek (apró káosz)
LangChain	építőknek, akik szeretik a Lego stílusú alkatrészeket	ingyenes-szerű + infra	nagy ökoszisztéma eszközök, memória és láncok számára	gyorsan spagettivé válhatsz, ha nem nevezed meg a dolgokat világosan
LámaIndex	RAG-nehéz csapatok	ingyenes-szerű + infra	erős visszakeresési minták, indexelés, csatlakozók	nagyszerű, ha az ügynököd alapvetően „keresés + cselekvés”... ami gyakori
OpenAI asszisztens stílusú megközelítés	gyorsabb beállítást igénylő csapatok	használatalapú	beépített eszközhívási minták és futási állapot	kevésbé rugalmas egyes sarkokban, de sok alkalmazáshoz tiszta	OpenAI Runs API OpenAI Assistants függvényhívások
Szemantikus kernel	fejlesztők, akik strukturált hangszerelést szeretnének	szabados	ügyes absztrakció a készségekhez/függvényekhez	„vállalati rendnek” érződik - néha ez dicséretnek is számít 😉
AutoGen	többágenses kísérletezők	szabados	ügynökök közötti együttműködési minták	túlzásba eshet; szigorú felmondási szabályokat állíthat fel
CrewAI	„ügynökcsapatok” rajongói	szabados	a szerepek + feladatok + átadások könnyen kifejezhetők	akkor működik a legjobban, ha a feladatok élesek, nem pedig nyálasak
Szénaboglya	keresés + folyamatok emberek	szabados	szilárd csővezetékek, visszakeresés, alkatrészek	kevesebb „ügynökszínház”, több „gyakorlati gyár”
Saját tekercs (egyéni hurok)	kontrollmániások (gyengédek)	az időd	minimális varázslat, maximális tisztaság	általában a legjobb hosszú távú megoldás… amíg mindent újra nem találsz 😅

Nincs egyetlen győztes megoldás. A legjobb választás attól függ, hogy az ügynök fő feladata-e a visszakeresés, az eszközök futtatása, a több ügynök közötti koordinációvagy a munkafolyamat-automatizálás.

---

6) Hogyan építsünk MI-ügynököt lépésről lépésre (a tényleges recept) 🍳🤖

Ez az a rész, amit a legtöbb ember kihagy, aztán csodálkoznak, hogy az ügynök miért viselkedik úgy, mint egy mosómedve a kamrában.

1. lépés: Definiáld a munkát egy mondatban 🎯

Példák:

• „Készítsen ügyfélválaszt a szabályzat és a jegy kontextusának felhasználásával, majd kérjen jóváhagyást.”

• „Vizsgáljon meg egy hibajelentést, reprodukálja azt, és javasoljon javítást.”

• „Alakítsd át a tökéletlen megbeszélési jegyzeteket feladatokká, tulajdonosokká és határidőkké.”

Ha te nem tudod egyszerűen meghatározni, akkor az ügynököd sem. Úgy értem, tud, de improvizálni fog, és az improvizáció az a pont, ahol a költségvetések elsorvadnak.

2. lépés: Döntsd el az autonómia szintjét (alacsony, közepes, csípős) 🌶️

• Alacsony autonómia: lépéseket javasol, emberi kattintás a „jóváhagyásra”

• Közepes: eszközöket futtat, kimenetet készít, bizonytalanság esetén eszkalál

• Magas: végponttól végpontig végrehajt, csak kivételek esetén pingeli az embereket

Kezdj alacsonyabban, mint szeretnéd. Később mindig feljebb tekerhetsz.

3. lépés: Válassza ki a modellstratégiáját 🧠

Általában a következőket választod:

• egyetlen erős modell mindenre (egyszerű)

• egy erős modell + kisebb modell az olcsóbb lépésekhez (osztályozás, marás)

• speciális modellek (látás, kód, beszéd), ha szükséges

Döntsd el azt is:

• maximális tokenek

• hőmérséklet

• engedélyezed-e a hosszú érvelési láncolatokat belsőleg (engedélyezhetsz, de ne tegyél ki nyers gondolatláncokat a végfelhasználók számára)

4. lépés: Szigorú sémákkal rendelkező eszközök definiálása 🔩

Az eszközöknek a következőknek kell lenniük:

• keskeny

• gépelt

• engedélyezett

• validált OpenAI strukturált kimenetek

A do_anything(input: string) nevű eszköz helyett készítsd el a következőt:

• search_kb(lekérdezés: karakterlánc) -> eredmények[]

• create_ticket(cím: karakterlánc, törzs: karakterlánc, prioritás: enum) -> ticket_id

• send_email(címzett: string, tárgy: string, törzs: string) -> status OpenAI függvényhívási útmutató

Ha láncfűrészt adsz az ügynöknek, ne lepődj meg, amikor a kerítés eltávolításával a sövényt is megnyírja.

5. lépés: Építsd fel a vezérlőhurkot 🔁

Minimális ciklus:

1. Kezdjük a céllal + kezdeti kontextussal

2. Kérdezd meg a modelltől: „Következő lépés?”

3. Ha szerszámhívás történik, akkor a szerszám végrehajtása

4. Megfigyelés hozzáfűzése

5. Ellenőrizze a leállási feltételt

6. Ismételd meg (maximális lépésszámmal) a LangChain „Ügynökök” dokumentációját

Hozzáadás:

• időtúllépések

• újrapróbálkozások (vigyázat - az újrapróbálkozások ciklusba kerülhetnek) AWS „Időtúllépések, újrapróbálkozások és visszalépések jitterrel”

• eszközhiba formázása (átlátható, strukturált)

6. lépés: Óvatosan adj hozzá memóriát 🗃️

Rövid távon: minden lépésben frissítsen egy kompakt „állapot-összefoglalót”. LangChain „Memória áttekintése”.
Hosszú távon: tartós tények tárolása (felhasználói beállítások, szervezeti szabályok, stabil dokumentációk).

Ökölszabály:

• ha gyakran változik - rövid távon tartsd

• ha stabil - hosszú távon tárolandó

• ha érzékeny - tárolja minimálisan (vagy egyáltalán ne)

7. lépés: Validáció és „kritikus” átadás hozzáadása 🧪

Egy olcsó, praktikus minta:

• az ügynök eredményt generál

• A validátor ellenőrzi a struktúrát és a korlátozásokat

• opcionális kritikus modellfelülvizsgálatok hiányzó lépések vagy irányelvsértések esetén NIST AI RMF 1.0

Nem tökéletes, de megdöbbentően sok ostobaságot ragad ki.

8. lépés: Naplózz mindent, amit később megbánsz 📜

Napló:

• eszközhívások + bemenetek + kimenetek

• meghozott döntések

• hibák

• végső kimenetek

• tokenek és késleltetés OpenTelemetry megfigyelhetőségi alapozó

Jövő - hálás leszel. Jelen - el fogod felejteni. Ez már csak az élet 😵💫

---

7) Szerszámhívás, ami nem töri össze a lelked 🧰😵

Az eszközhívás az, ahol a „Hogyan építsünk mesterséges intelligenciával működő ügynököt” című könyvből valódi szoftverfejlesztés válik.

Tegye az eszközöket megbízhatóvá (a megbízható jó)

A megbízható eszközök a következők:

• determinisztikus

• szűk hatókörű

• könnyen tesztelhető

• biztonságosan újra futtatható a Stripe „Idempotent kérések”

Korlátokat adj hozzá az eszközréteghez, ne csak a promptokhoz

A promptok udvarias javaslatok. Az eszközvalidáció egy zárt ajtó. OpenAI strukturált kimenetek

Csináld:

• engedélyezőlisták (mely eszközök futtathatók)

• beviteli validáció

• sebességkorlátok OpenAI sebességkorlátozási útmutató

• jogosultságellenőrzések felhasználónként/szervezetenként

• „Száraz futás üzemmód” kockázatos műveletekhez

Részleges meghibásodásra való tervezés

Az eszközök meghibásodnak. A hálózatok akadoznak. A hitelesítés lejár. Egy ügynöknek a következőket kell tennie:

• hibák értelmezése

• újrapróbálkozás visszatartással, ha szükséges Google Cloud újrapróbálkozási stratégia (visszatartás + időzítés)

• válasszon alternatív eszközöket

• fokozódik, ha elakad

Egy csendesen hatékony trükk: adjon vissza strukturált hibákat, például:

• típus: hitelesítési_hiba

• típus: nem_található

• típus: rate_limited
  Így a modell intelligensen tud reagálni a pánik helyett.

---

8) Emlék, ami segít ahelyett, hogy kísértene 👻🗂️

Az emlékezet erős, de egyben kacatfiókká is válhat.

Rövid távú memória: tartsd kompaktnak

Használat:

• utolsó N lépés

• egy futó összefoglaló (minden ciklusban frissül)

• jelenlegi terv

• jelenlegi korlátok (költségvetés, idő, szabályzatok)

Ha mindent kontextusba helyezünk, akkor ezt kapjuk:

• magasabb költség

• lassabb késleltetés

• nagyobb zavar (igen, még akkor is)

Hosszú távú memória: előhívás a „tömés” helyett

A legtöbb „hosszú távú memória” inkább ilyen:

• beágyazások

• vektorbolt

• visszakeresés kiterjesztett generáció (RAG) RAG papír

Az ügynök nem memorizál. Futásidőben kéri le a legrelevánsabb kódrészleteket. LlamaIndex „Bevezetés az RAG-ba”

Gyakorlati memória szabályok

• Tárold a „beállításokat” explicit tényként: „A felhasználó szereti a felsorolásjeles összefoglalókat és utálja az emojikat” (lol, de itt nem 😄)

• Tárold a „döntéseket” időbélyegekkel vagy verziókkal (különben ellentmondások halmozódnak fel)

• Soha ne tárolj titkokat, hacsak nem feltétlenül muszáj

És itt van a tökéletlen metaforám: az emlékezet olyan, mint egy hűtőszekrény. Ha soha nem takarítod ki, végül a szendvicsed olyan ízű lesz, mint a hagyma és a megbánás.

---

9) Tervezési minták (az egyszerűtől a divatosig) 🧭✨

A tervezés csak irányított lebontás. Ne csinálj belőle misztikusat.

A minta: Ellenőrzőlista-tervező ✅

• A modell lépések listáját adja ki

• Lépésről lépésre végrehajtja

• Frissíti az ellenőrzőlista állapotát

Nagyszerű a betanuláshoz. Egyszerű, tesztelhető.

B minta: ReAct ciklus (indoklás + cselekvés) 🧠→🧰

• a modell dönti el a következő szerszámhívást

• megfigyeli a kimenetet

• ismétli a ReAct dolgozatot

Ez a klasszikus ügynöki érzés.

C minta: Felügyelő-munkavállaló 👥

• a felügyelő lebontja a célt feladatokra

• a munkavállalók speciális feladatokat végeznek

• a felügyelő egyesíti az eredményeket Microsoft AutoGen (többügynökös keretrendszer)

Ez akkor értékes, ha a feladatok párhuzamosíthatók, vagy ha különböző „szerepköröket” szeretne, például:

• kutató

• kódoló

• szerkesztő

• QA-ellenőrző

D minta: Tervezés, majd végrehajtás újratervezéssel 🔄

• terv létrehozása

• végrehajt

• ha az eszközök eredményei megváltoztatják a valóságot, tervezze újra

Ez megakadályozza, hogy az ágens makacsul egy rossz tervet kövessen. Az emberek is ezt teszik, kivéve, ha fáradtak, ebben az esetben ők is rossz terveket követnek.

---

10) Biztonság, megbízhatóság és hogy ne rúgjanak ki 🔐😅

Ha az ügynököd képes intézkedéseket hozni, akkor biztonsági tervezésre van szükséged. Nem a „jó, ha van”. Szükség van rá. NIST AI RMF 1.0

Kemény korlátok

• max. lépésszám futásonként

• szerszámhívások percenként maximuma

• maximális költés munkamenetenként (token költségvetés)

• korlátozott eszközök a jóváhagyás mögött

Adatkezelés

• érzékeny bemenetek törlése naplózás előtt

• különálló környezetek (fejlesztői vs. éles)

• legkevésbé jogosult eszközengedélyek

Viselkedési korlátok

• kényszerítse az ügynököt belső bizonyítékrészletek idézésére (nem külső linkekre, csak belső hivatkozásokra)

• bizonytalansági jelzőket igényel, ha alacsony a bizalom

• „Tegyen fel tisztázó kérdést” előírás, ha a bemeneti adatok nem egyértelműek

Egy megbízható ügynök nem a legmagabiztosabb. Az, aki tudja, mikor találgat... és ezt ki is mondja.

---

11) Tesztelés és értékelés (az a rész, amit mindenki elkerül) 🧪📏

Amit nem tudsz mérni, azt nem tudod fejleszteni. Igen, ez a sor giccses, de bosszantóan igaz.

Forgatókönyvkészlet létrehozása

Hozz létre 30-100 tesztesetet:

• boldog ösvények

• szélső esetek

• „szerszámhiba” esetek

• kétértelmű kérések

• ellenséges promptok (azonnali injekciózási kísérletek) OWASP Top 10 LLM alkalmazásokhoz OWASP LLM01 Prompt Injection

Eredmények pontszáma

Használjon olyan mérőszámokat, mint:

• feladat sikerességi aránya

• befejezési idő

• szerszámhiba-javítási arány

• hallucinációs arány (bizonyítékok nélküli állítások)

• emberi jóváhagyási arány (felügyelt módban)

Regressziós tesztek promptokhoz és eszközökhöz

Bármikor, amikor változtatsz:

• eszközséma

• rendszerutasítások

• visszakeresési logika

• memóriaformátum
  Futtassa újra a csomagot.

Az ügynökök érzékeny állatok. Mint a szobanövények, csak drágábbak.

---

12) Telepítési minták, amelyek nem olvasztják fel a költségvetésedet 💸🔥

Kezdje egyetlen szolgáltatással

• ügynökvezérlő API

• szerszámszolgáltatások mögött

• naplózás + monitorozás OpenTelemetry megfigyelhetőségi alapozó

Költségszabályozás hozzáadása korán

• a lekérési eredmények gyorsítótárazása

• beszélgetési állapot tömörítése összefoglalókkal

• kisebb modellek használata maráshoz és kitermeléshez

• a „mély gondolkodási mód” korlátozása a legnehezebb lépésekre

Gyakori architektúraválasztás

• állapot nélküli vezérlő + külső állapottároló (DB/redis)

• Az eszközhívások lehetőség szerint idempotensek Stripe „Idempotent kérések”

• hosszú feladatok sorba állítása (így nem kell örökre nyitva tartani egy webes kérést)

Valamint: építs egy „kill switch”-et. Nem lesz rá szükséged, amíg igazán, nagyon nem lesz rá szükséged 😬

---

13) Záró megjegyzések - a MI-ügynökök felépítésének rövid változata 🎁🤖

Ha semmi másra nem emlékszel, akkor erre emlékezz:

• Az MI-ügynökök felépítése többnyire egy modell köré épített biztonságos hurokról szól. LangChain „Ügynökök” dokumentáció.

• Kezdj egy egyértelmű céllal, alacsony autonómiával és szigorú eszközökkel. OpenAI strukturált kimenetek

• Memóriabővítés előhívással, nem végtelen kontextus-tömörítéssel. RAG-papír

• A tervezés lehet egyszerű – az ellenőrzőlisták és az újratervezés sokat segíthetnek.

• A naplózás és a tesztek az ügynökök káoszát valami olyasmivé varázsolják, amit szállíthatsz. OpenTelemetry megfigyelhetőségi alapismertető

• A korlátoknak a kódban is helyük van, nem csak a promptokban. OWASP Top 10 LLM alkalmazásokhoz

Egy ügynök nem varázslat. Egy rendszer, ami elég gyakran hoz jó döntéseket ahhoz, hogy értékes legyen... és beismeri a vereséget, mielőtt kárt okozna. Csendesen megnyugtató, bizonyos értelemben 😌

És igen, ha jól építed fel, olyan érzés, mintha egy apró digitális gyakornokot alkalmaznál, aki sosem alszik, időnként pánikba esik, és imádja a papírmunkát. Szóval, lényegében egy gyakornok.

Valós példa: Támogatási triázs mesterséges intelligencia ügynökének felépítése 🎫🤖

Forgatókönyv

Képzeljünk el egy kis SaaS-csapatot, amely hetente 120-180 támogatási kérelmet kap. A legtöbb kérelem nem bonyolult, de mégis időigényes: jelszó-visszaállítások, számlázási kérdések, hibajelentések, funkcióigénylések és a „ez a viselkedés várható?” üzenetek.

Egy egyszerű chatbot képes válaszokat írni, de nem tudja megbízhatóan ellenőrizni a fiók állapotát, keresni a tudásbázisban, besorolni a sürgősséget, vagy eldönteni, hogy mikor kell közbelépnie egy embernek. Itt jön be az eszmény egy ügynöknek.

A cél nem a támogatás teljes lecserélése. A cél egy alacsony autonómiájú ügynök létrehozása, amely beolvassa az új jegyeket, összegyűjti a kontextust, elkészíti a választ, és a megfelelő várólistára irányítja a jegyeket. Egy ember továbbra is jóváhagy mindent, ami az ügyféllel történik.

Amire szüksége van az asszisztensnek

A biztonságos munkavégzéshez az ágensnek szüksége van egy kis, ellenőrzött bemeneti és eszközkészletre:

• A bejövő jegy szövege

• Ügyfélcsomag típusa, a fiók kora és a legutóbbi számlázási állapot

• Legutóbbi termékváltozási napló vagy ismert incidensek

• Belső súgóközpont cikkek

• Korlátozott mezőkkel rendelkező jegyfrissítő eszköz

• Egy vázlatválasz eszköz, nem pedig e-mail küldő eszköz

• Egyértelmű eszkalációs politika

Az eszközök listájának szándékosan szűknek kell lennie:

• search_help_centre(lekérdezés)

• get_customer_status(ügyfél_azonosító)

• check_known_incidens(termékterület)

• update_ticket_category(ticket_id, kategória, prioritás)

• draft_reply(ticket_id, reply_text)

• escalate_to_human(ticket_id, indok)

Figyeljük meg, mi hiányzik: nincs „ügyfél visszatérítése”, „fiók lezárása” vagy „végső válasz küldése” eszköz. Ezek a műveletek túl kockázatosak egy első verzióhoz.

Példa utasítás

Ön egy SaaS termék támogatási triázs ügynöke.

A feladatod a bejövő jegyek osztályozása, a szükséges kontextus összegyűjtése, egy javasolt válasz megfogalmazása, és annak eldöntése, hogy a jegyet eszkalálni kell-e.

Szabályok:

Ne küldj válaszokat közvetlenül az ügyfeleknek.

A termékkel kapcsolatos kérdések megválaszolása előtt használd a súgóközpontot.

Számlázási, csomag- vagy hozzáférési kérdések megválaszolása előtt ellenőrizze az ügyfél állapotát.

Ha az ügyfél jogi fenyegetéseket, adatvesztést, biztonsági problémákat, fizetési hibákat, fiók megszüntetését vagy sértő nyelvezetet említ, jelentse az ügyet egy emberi erőforráshoz.

Ha a választ nem támasztják alá a lekért súgóközpont-tartalom vagy a fiókadatok, mondja el, mi hiányzik, és továbbítsa a kérdést.

Legfeljebb 6 szerszámhívás után álljon meg.

Egy jegy csak akkor „kész”, ha van benne kategória, prioritás, bizonyítékösszefoglaló, választervezet, valamint vagy „emberi jóváhagyás szükséges”, vagy „eszkalált”.

Hogyan teszteljük

Kezdj 30 tesztjeggyel, mielőtt élő felhasználókhoz csatlakoztatod:

• 10 normál jegy, például jelszó-visszaállítás, csomagkorlátok és alapvető „hogyan csináljam?” kérdések

• 5 számlázási jegy

• 5 hibajelentés

• 5 kétértelmű jegy hiányos információkkal

• 5 kockázatos jegy, például biztonsági aggályok, visszatérítési igények és dühös panaszok

Minden jegyért jár a pontszám:

• Jó kategóriát választott?

• A megfelelő eszközt használta a válaszadás előtt?

• Elkerülte a megalapozatlan állításokat?

• Eszkalálta a kockázatos jegyeket?

• A vázlat komoly szerkesztést igényelt?

Egy egyszerű értékelő táblázat elég az elején. Ne építsd túl az értékelő rendszert, mielőtt megtudnád, hogy az ügynök értéket képvisel-e.

Eredmény

Szemléltető eredmény: A munkafolyamat használata előtt és után 30 mintajegy időzítésével egy ügyfélszolgálati érdeklődő a következőket mérheti:

• Az átlagos első osztályozási idő jegyenként 6 percről 90 másodpercre csökkent

• 30 jegyet 45 perc alatt, a korábbi 3 óra helyett elbíráltak

• 30 jegyből 27 a megfelelő kategóriába került

• 5 kockázatos jegyből 5-öt helyesen eszkaláltak

• 0 ügyfélválasz emberi jóváhagyás nélkül elküldve

Ezek a számok példaként szolgálnak, nem pedig bizonyítottan megbízható referenciaértékek. A mérés könnyen megismételhető: mérjük meg manuálisan ugyanazon tesztjegy-sorozat időzítését, majd futtassuk át őket az ügynökön, és hasonlítsuk össze a kategória pontosságát, az eszkalációs pontosságot és a szerkesztési időt.

Mi romolhat el

Az ügynök továbbra is kudarcot vallhat nagyon is normális módon.

Lehet, hogy egy frusztrált, de egyszerű ügyfelet „sürgősként” minősít, mert a nyelvezete dühösnek hangzik. Lehet, hogy egy elavult súgócikkből merít magabiztos választ. Lehet, hogy folytatja a keresést, amikor a helyes lépés az ügy eszkalálása lenne. Lehet, hogy túl sok fiókadatot tesz közzé egy válaszvázlatban.

A megoldás nem az, hogy „írj egy jobb promptot” és reménykedj. Adj hozzá szigorú korlátokat:

• Jelentsen eszkalációt, ha számlázási, biztonsági, jogi vagy lemondási információkkal kapcsolatos szöveg jelenik meg

• Belső súgócikkekből származó hivatkozások megkövetelése a bizonyítékok összefoglalásában

• A „válasz küldése” gombra csak emberi jóváhagyás után kerüljön sor

• Minden szerszámhívás és a végső vázlat naplózása

• Futtassa újra a 30 jegyes tesztcsomagot minden egyes prompt, eszköz vagy szabályzatmódosítás után

Gyakorlati elvitel

Egy értékes ügynöknek nincs szüksége drámai autonómiára. Ebben a példában az érték egy kontrollált ciklusból származik: elolvassa a ticketet, lekéri a megfelelő kontextust, osztályozza, megfogalmazza a választ, és megáll felülvizsgálatra. Ebben sokkal könnyebb megbízni, tesztelni és fejleszteni, mint egy olyan ügynökben, amely egyetlen hatalmas prompttal próbálja „kezelni a támogatást”.

---

GYIK

Mi az a mesterséges intelligencia ügynök egyszerűen fogalmazva?

Egy MI-ügynök alapvetően egy ismétlődő ciklus: bemenetet vesz fel, eldönti a következő lépést, használ egy eszközt, leolvassa az eredményt, és ismétli, amíg el nem éri a célt. Az „ügynöki” rész a cselekvésből és a megfigyelésből származik, nem csak a csevegésből. Sok ügynök csak intelligens automatizálás eszközhozzáféréssel, míg mások inkább egy junior operátorként viselkednek, aki képes helyreállni a hibák után.

Mikor érdemes AI-ügynököt létrehoznom ahelyett, hogy csak egy promptot használnék?

Építs ágenst, ha a munka több lépésből áll, a köztes eredmények alapján változik, és megbízható eszközhasználatot igényel (API-k, adatbázisok, ticketing, kódfuttatás). Az ágensek akkor is hasznosak, ha megismételhető eredményeket szeretnél korlátokkal és a „kész” állapotának ellenőrzésére szolgáló módszerrel. Ha egy egyszerű, azonnali válasz működik, egy ágens általában felesleges többletterhelést és extra hibamódokat jelent.

Hogyan építhetek egy olyan AI-ügynököt, amely nem akad el ciklusokban?

Használjon kemény leállítási feltételeket: maximális lépésszám, maximális eszközhívás és egyértelmű befejezési ellenőrzések. Adjon hozzá strukturált eszközsémákat, időtúllépéseket és újrapróbálkozásokat, amelyek nem fognak örökké újrapróbálkozni. Naplózza a döntéseket és az eszközök kimeneteit, hogy lássa, hol siklik ki. Gyakori biztonsági szelep az eszkaláció: ha az ügynök bizonytalan, vagy ismétli a hibákat, akkor segítséget kell kérnie ahelyett, hogy improvizálna.

Mi a minimális architektúra a Hogyan építsünk AI-ügynököt? című részhez?

Minimum egy olyan vezérlőhurokra van szükség, amely célt és kontextust ad a modellnek, rákérdez a következő műveletre, végrehajt egy eszközt, ha kéri, hozzáfűzi a megfigyelést, és ismétli a folyamatot. Szükség van szigorú bemeneti/kimeneti alakzatokkal és „kész” ellenőrzéssel rendelkező eszközökre is. Még egy „saját görgetésű” ciklus is jól működhet, ha tisztán tartod az állapotot és betartatod a lépéskorlátokat.

Hogyan tervezzem meg az eszközhívást, hogy megbízható legyen éles környezetben?

Tartsa az eszközöket szűken, típusosan, jogosultságokkal ellátva és validálva – kerülje az általános „bármit_csinálj” eszközöket. Előnyben részesítse a szigorú sémákat (például strukturált kimeneteket/függvényhívásokat), hogy az ügynök ne tudja manuálisan megadni a bemeneteket. Adjon hozzá engedélyezőlistákat, sebességkorlátokat és felhasználói/szervezeti jogosultságellenőrzéseket az eszközszinten. Tervezzen olyan eszközöket, amelyek biztonságosan újra futtathatók, amikor lehetséges, idempotencia minták használatával.

Mi a legjobb módja a memória bővítésének anélkül, hogy az ügynök rontaná a teljesítményét?

A memóriát két részként kezeljük: rövid távú futási állapot (legutóbbi lépések, aktuális terv, korlátozások) és hosszú távú visszakeresés (beállítások, stabil szabályok, releváns dokumentációk). A rövid távú memóriát tömören tartsuk futó összefoglalókkal, ne teljes átiratokkal. Hosszú távú memória esetén a visszakeresés (beágyazások + vektortárolás/RAG minták) általában jobb, mint mindent „belezsúfolni” a kontextusba és összezavarni a modellt.

Melyik tervezési mintát használjam: ellenőrzőlistát, ReAct-ot vagy felügyelő-munkavállalói mintát?

Egy ellenőrzőlista-tervező nagyszerű, ha a feladatok kiszámíthatóak, és könnyen tesztelhetőt szeretnél. A ReAct stílusú ciklusok akkor ragyognak, ha az eszköz eredményei megváltoztatják a következő lépéseket. A felügyelő-munkavállaló minták (mint például az AutoGen stílusú szerepszétválasztás) akkor segítenek, ha a feladatok párhuzamosíthatók, vagy ha a különböző szerepkörökből (kutató, kódoló, minőségbiztosítás) profitálnak. A tervezés, majd végrehajtás újratervezéssel egy praktikus köztes megoldás a makacs rossz tervek elkerülésére.

Hogyan tehetek egy ügynököt biztonságossá, ha valódi cselekvésre képes?

Használjon minimális jogosultságokat, és korlátozza a kockázatos eszközöket jóváhagyás vagy „száraz futtatás” módok mögé. Adjon hozzá költségkereteket és korlátokat: maximális lépésszám, maximális költség és percenkénti eszközhívási korlátok. Szerkessze az érzékeny adatokat a naplózás előtt, és válassza el a fejlesztői környezetet az éles környezettől. Követeljen meg bizonytalansági jelzőket vagy tisztázó kérdéseket, ha a bemenetek nem egyértelműek, ahelyett, hogy hagyná, hogy a magabiztosság helyettesítse a bizonyítékokat.

Hogyan tesztelhetek és értékelhetek egy MI-ügynököt, hogy idővel fejlődjön?

Készítsen egy forgatókönyv-készletet boldog útvonalakkal, szélső esetekkel, eszközhibákkal, kétértelmű kérésekkel és prompt-injektálási kísérletekkel (OWASP stílusban). Pontozza az eredményeket, például a feladat sikerességét, a befejezési időt, az eszközhibák utáni helyreállítást és a bizonyíték nélküli állításokat. Valahányszor megváltoztatja az eszközsémákat, promptokat, lekérést vagy memóriaformázást, futtassa újra a készletet. Ha nem tudja tesztelni, nem tudja megbízhatóan szállítani.

Hogyan telepíthetek egy ügynököt a késleltetés és a költségek növekedése nélkül?

Gyakori minta az állapot nélküli vezérlő külső állapottárolóval (DB/Redis), mögötte eszközszolgáltatásokkal és erős naplózással/monitorozással (gyakran OpenTelemetry). A költségeket a lekérési gyorsítótárazással, a kompakt állapot-összefoglalókkal, a kisebb útvonal-/kinyerési modellekkel és a „mélyreható gondolkodás” a legnehezebb lépésekre korlátozásával lehet szabályozni. Hosszú feladatokhoz várólisták használata, hogy ne tartsa nyitva a webes kéréseket. Mindig használjon kill switch-et.

Referenciák

1. Nemzeti Szabványügyi és Technológiai Intézet (NIST) - NIST AI RMF 1.0 (megbízhatóság és átláthatóság) - nvlpubs.nist.gov

2. OpenAI - Strukturált kimenetek - platform.openai.com

3. OpenAI - Függvényhívási útmutató - platform.openai.com

4. OpenAI - Áramkorlátok útmutatója - platform.openai.com

5. OpenAI – Fut az API – platform.openai.com

6. OpenAI - Asszisztensek függvényhívása - platform.openai.com

7. LangChain - Ügynökök dokumentációja (JavaScript) - docs.langchain.com

8. LangChain - Eszközök dokumentációja (Python) - docs.langchain.com

9. LangChain - Memória áttekintése - docs.langchain.com

10. arXiv - ReAct dolgozat (indoklás + cselekvés) - arxiv.org

11. arXiv - RAG cikk - arxiv.org

12. Amazon Web Services (AWS) Builders' Library - Időtúllépések, újrapróbálkozások és visszalépések jitterrel - aws.amazon.com

13. OpenTelemetry - Megfigyelhetőségi alapismertető - opentelemetry.io

14. Stripe - Idempotent kérések - docs.stripe.com

15. Google Cloud - Újrapróbálkozási stratégia (visszalépés + időingadozás) - docs.cloud.google.com

16. OWASP - A 10 legjobb nagyméretű nyelvi modellalkalmazás - owasp.org

17. OWASP - LLM01 Azonnali injekció - genai.owasp.org

18. LlamaIndex - Bevezetés az RAG-ba - developers.llamaindex.ai

19. Microsoft - Szemantikus kernel - learn.microsoft.com

20. Microsoft AutoGen - Többügynökös keretrendszer (dokumentáció) - microsoft.github.io

21. CrewAI - Ügynökökkel kapcsolatos koncepciók - docs.crewai.com

22. Haystack (mélyen fekvő) - Retrieverek dokumentációja - docs.haystack.deepset.ai

Találd meg a legújabb mesterséges intelligenciát a hivatalos AI Assistant áruházban

Rólunk