Nyolc-tíz másodperc csend: amit az egymással beszélő AI-ügynökökről tanultunk

Ha egy tervező ügynök lépése 2 másodpercig tart, és utána három worker fut egymás után, a telefonáló 8-10 másodpercig csendet hall. Idén több olyan rendszert építettünk, amelyben a kérdésre több, különböző feladatú ügynök válaszol közösen, egymásnak adva a munkát. A tapasztalat vegyes. Bizonyos feladatoknál ez az egyetlen járható út, máshol egy egyszerű, determinisztikus workflow olcsóbb, gyorsabb és megbízhatóbb. Az alábbiakban azt írjuk le, mit tanultunk.

Tool-use és MCP: a közös nyelv

Az ügynökök együttműködésének alapja, hogy a modell eszközöket tud hívni: strukturált paraméterekkel meghív egy függvényt, és az eredménnyel folytatja a gondolkodást. A Model Context Protocol (MCP) ezt szabványosítja. Az eszközök külön szerveren élnek, önleíró sémával, és bármelyik ügynök, bármelyik modellszolgáltatóval ugyanúgy éri el őket.

Nálunk a belső rendszerek (CRM-lekérdezés, naptárfoglalás, hívásindítás, számlázási státusz) MCP-szerverként vannak kitéve, és az ügynökök kizárólag ezen keresztül nyúlnak bármihez. Ennek két haszna van: az eszközök egy helyen tesztelhetők és jogosultságkezelhetők, az ügynök promptjába pedig semmi sem kerül az integráció részleteiből.

Az eszköztervezés legfontosabb tanulsága, hogy kevés, jól elhatárolt eszköz jobban működik, mint sok apró. Egy „keresd meg az ügyfelet e-mail alapján” eszköz megbízhatóbb egy általános SQL-futtatónál.

Tervező, munkás, átadás

Két mintát használunk rendszeresen.

A planner/worker felállásban egy ügynök lépésekre bontja a feladatot, és minden lépést kiad egy workernek, amely szűkebb kontextussal, olcsóbb modellen fut. A worker a teljes beszélgetést nem látja, csak a saját feladatát és az ahhoz szükséges eszközöket. Ez csökkenti a költséget és a hibalehetőséget, cserébe a planner minőségén áll vagy bukik az egész.

A handoff mintában egy ügynök egy ponton átadja a beszélgetést egy másiknak, a teljes vagy szűrt kontextussal együtt. Hangalapú ügyfélszolgálatban ez a jellemző eset: egy általános recepciós ügynök felismeri, hogy időpontfoglalásról van szó, és továbbadja a foglalási ügynöknek, amelynek szűkebb, de pontosabb utasításai és eszközei vannak. A hívó ebből semmit sem érzékel, a rendszer számára viszont világos állapotváltás történik.

Mindkét mintában strukturált a kommunikáció. Az ügynökök sémával ellenőrzött üzeneteket adnak át egymásnak, szabad szöveges „beszélgetés” nincs. Az ügynökök közötti szabad párbeszéd a demókon látványos, a gyakorlatban hosszú, drága és nehezen debugolható.

A korlátok a kódban vannak

Több ügynök több hibalehetőség, és a hibák továbbterjednek. A védelmi vonalakat ezért a kódba építjük, a promptra nem bízzuk:

• minden eszközhívás jogosultságellenőrzésen megy át, az ügynök identitása és a tenant alapján;
• az írási műveletek (foglalás, e-mail-küldés, státuszváltás) explicit engedélyezési listán vannak, a többi eszköz csak olvas;
• a bemenet és a kimenet sémaellenőrzött; ha az ügynök rossz formátumot ad, egyszer újrapróbálunk, utána hibát jelzünk;
• lépésszám- és költséglimit ügynökönként és teljes futásonként, hogy egy körbe-körbe forgó ügynök ne fusson a végtelenségig.

Bizonyos döntéseket egyáltalán nem engedünk automatikusan meghozni: a visszatérítést, a szerződéses feltételek módosítását és egy eszkalált panasz lezárását. Ilyenkor az ügynök előkészíti a javaslatot, és egy ember hagyja jóvá, egy sorból, egy kattintással. A human-in-the-loop a rendszer tervezett része. Az ügynök munkájának egyik jól definiált kimenete az, hogy „kérdezz meg egy embert”.

Egy futás, egy trace

Egy többügynökös futás hibakeresése tracing nélkül reménytelen. Minden futás egyetlen trace, ezen belül minden ügynöklépés, modellhívás és eszközhívás egy span, bemenettel, kimenettel, tokenszámmal és időtartammal. A trace-azonosító a handoffokon is átmegy, így a teljes út egy helyen látható.

Ebből jön a költség- és késleltetéselemzés is. Több ügynöknél a válaszidők összeadódnak: 2 másodperces planner-lépés és három egymás utáni worker 8-10 másodperc várakozást jelent. Hangalapú rendszerben ez elfogadhatatlan, ott a workerek párhuzamosan futnak, ahol lehet, a hívó pedig közben kitöltő visszajelzést kap. A költség is könnyen a többszörösére nő, mert minden ügynök újra és újra elküldi a saját kontextusát. Itt sokat számít a prompt cache és a szűk kontextusú workerek.

Először workflow

Több ügynök akkor indokolt, ha a feladat lépései előre nem ismertek, a részfeladatok eltérő tudást és eszközkészletet kívánnak, és egy hibás lépés visszavonható vagy emberi jóváhagyáshoz köthető. Tipikus példa egy összetett ügyfélszolgálati eset, amelyben az azonosítás, az ügyintézés és az utánkövetés más-más rendszert érint.

Ha a lépések sorrendje ismert és állandó, nincs rá szükség. A „hívás után írj összefoglalót, küldd el e-mailben, frissítsd a CRM-et” folyamat sima workflow, amelynek egyetlen lépésében dolgozik LLM, az összefoglalónál. Itt az ügynökös megoldás csak bizonytalanságot, költséget és késleltetést hozna.

A szabályunk egyszerű. Először determinisztikus workflow-ként írjuk le a folyamatot. Ahol ez nem megy, mert a döntés valóban a kontextustól függ, ott belép egy ügynök. Ha egy ügynök kontextusa túl nagyra nő, több ügynökre bontjuk. A fordított irány, az ügynökökből induló tervezés, szinte mindig túlbonyolított rendszerhez vezet.