Agent-to-agent: amikor AI-ügynökök egymással beszélnek

Idén több olyan rendszert építettünk, amelyben nem egy LLM válaszol egy kérdésre, hanem több, különböző feladatú ügynök adja egymásnak a munkát. A tapasztalat vegyes: bizonyos feladatoknál ez az egyetlen járható út, máshol viszont egy egyszerű, determinisztikus workflow olcsóbb, gyorsabb és megbízhatóbb. Ebben a cikkben azt foglaljuk össze, mit tanultunk.

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

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

Nálunk ez gyakorlatilag azt jelenti, hogy a belső rendszereink (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 csak ezen keresztül érnek el bármit. Ennek két előnye van: az eszközök egy helyen tesztelhetők és jogosultságkezelhetők, és az ügynök promptja nem tartalmaz semmit az integráció részleteiről.

Az eszközök tervezésénél a legfontosabb tanulság: kevés, jól elhatárolt eszköz jobb, mint sok apró. Egy “keresd meg az ügyfelet e-mail alapján” eszköz megbízhatóbb, mint egy általános SQL-futtató.

Orkesztrációs minták

Két mintát használunk rendszeresen.

A planner/worker felállásban egy ügynök lebontja a feladatot lépésekre, és minden lépést egy szűkebb kontextusú, olcsóbb modellel futó workernek ad ki. A worker nem látja a teljes beszélgetést, 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, viszont a planner minősége határozza meg az egészet.

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 tipikus: egy általános recepciós ügynök felismeri, hogy időpontfoglalásról van szó, és átadja a foglalási ügynöknek, amelyiknek szűkebb, de pontosabb utasításai és eszközei vannak. A handoff a hívó számára láthatatlan, a rendszer számára viszont egy világos állapotváltás.

Mindkét mintánál a kommunikáció strukturált: az ügynökök nem szabad szövegben “beszélgetnek”, hanem sémával ellenőrzött üzeneteket adnak át. A szabad szöveges ügynök-ügynök párbeszéd látványos demókban, de a gyakorlatban hosszú, drága és nehezen debugolható.

Guardrailek és human-in-the-loop

Több ügynök több hibalehetőséget jelent, és a hibák terjednek. Ezért a védelmi vonalak nem a promptban vannak, hanem a kódban:

• 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 tudjon végtelenül futni.

Bizonyos döntéseket egyáltalán nem engedünk automatikusan: ilyen a visszatérítés, a szerződéses feltétel módosítása vagy egy eszkalált panasz lezárása. Ezeknél 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 nem a rendszer gyengesége, hanem tervezett része: az ügynök munkájának egy jól definiált kimenete a “kérdezz meg egy embert”.

Observability: tracing ügynökök között

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

Ez adja a költség- és késleltetés-elemzést is. Több ügynök esetén a válaszidő összeadódik: ha egy planner lépés 2 másodperc, és három worker fut egymás után, a hívó 8-10 másodpercet vár. Hangalapú rendszerben ez elfogadhatatlan, ezért ott a workerek párhuzamosan futnak, ahol lehet, és a hívó közben kitöltő visszajelzést kap. A költség pedig könnyen többszörösére nő, mert minden ügynök a saját kontextusát újra és újra elküldi; a prompt cache és a szűk kontextusú workerek itt sokat számítanak.

Mikor van értelme, és mikor nem

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 igényelnek, és a hibás lépés visszavonható vagy emberi jóváhagyáshoz köthető. Tipikus példa egy összetett ügyfélszolgálati eset, ahol azonosítás, ügyintézés és utánkövetés eltérő rendszereket érint.

Nem indokolt, ha a lépések sorrendje ismert és állandó. Egy “hívás vége után írj összefoglalót, küldd el e-mailben, frissítsd a CRM-et” folyamat egy sima workflow, amelynek egyetlen lépésében van LLM (az összefoglaló). Ebben az esetben az ügynökös megközelítés csak bizonytalanságot, költséget és késleltetést ad hozzá.

A szabályunk egyszerű: először írjuk le a folyamatot determinisztikus workflow-ként. Ahol ez nem megy, mert a döntés valóban kontextusfüggő, ott jön egy ügynök. Ahol egy ügynök kontextusa túl nagyra nő, ott bontjuk többre. Fordítva, ügynökökből indulva, szinte mindig túlbonyolított rendszert kapunk.