Multi-agent rendszerek

Miért érdekel ez téged?

A multi-agent rendszer haladó téma, és a legtöbb esetben egyszerűen nincs rá szükséged. Egy rosszul indokolt, ötagentes rendszer általában nem ötször okosabb, csak ötször annyi hibalehetőség: ötször annyi koordináció, ötször annyi elveszíthető kontextus, ötször annyi tokenszámla.

A helyes reflex az, amit az OpenAI és az Anthropic is javasol: először próbáld meg egyetlen jól felszerelt agenttel vagy egy determinisztikus workflow-val. Csak akkor bontsd több agentre, ha a felépítés maga indokolja — nem azért, mert a „multi-agent" jól hangzik egy architektúradiagramon.

Gondolj rá úgy, mint a mikroszolgáltatásokra a szoftverfejlesztésben. Egy jól megírt monolit sok esetben verhetetlen; a microservice-ekre bontás valódi előnyt hoz — külön skálázás, külön csapatok, külön deploy —, de csak akkor, ha a rendszer tényleg megköveteli. Aki csak azért darabolja szét, mert „ez a modern", általában egy elosztott monolitot kap: ugyanaz a bonyolultság, plusz hálózati hibák. A multi-agent rendszer pontosan ugyanez az alku.

Az elosztott monolit csapdája

A microservice-analógia nem véletlen: pontosan ugyanazok a buktatók köszönnek vissza. Egy csapat, amelyik túl korán, rossz határok mentén darabolja szét a rendszerét, olyan komponenseket kap, amelyek folyton egymásra várnak, egymás adatát kérdezgetik, és külön-külön nem is deployolhatók. Ezt hívják distributed monolith-nak: megvan a szétdaraboltság összes költsége, de az önállóság egyik előnye sincs meg. A multi-agent világban ez úgy néz ki, hogy három agent ugyanazon a feladaton „gondolkodik", folyamatosan átadják egymásnak a kontextust, és a végén senki nem tudja megmondani, ki hozta meg a döntést.

A jó határvonal ismérve egyszerű: egy agent akkor önálló, ha a saját részfeladatát a többiek gondolatmenetének ismerete nélkül is meg tudja oldani, csak egy tiszta bemenetből és egy tiszta kimenetből. Ha ehhez folyamatosan bele kell látnia a többi agent fejébe, akkor valójában egyetlen agentet daraboltál szét mesterségesen.

Egyetlen agent kontra több agent — döntési szempontok

Mielőtt topológiákról beszélnénk, tedd fel magadnak az első, legfontosabb kérdést: tényleg több agent kell? Az alábbi kétoszlopos összevetés segít gyorsan eldönteni, melyik irányba indulj.

Vedd észre, hogy a jobb oszlop minden pontja egy konkrét korlátot nevez meg. Ez a különbség a mérnöki döntés és a divatkövetés között: nem „legyen több agent", hanem „ezt a korlátot csak több agenttel tudom feloldani".

Mikor indokolt?

Van néhány jól körülhatárolható helyzet, amikor a több agent nem díszlet, hanem valódi mérnöki válasz egy konkrét korlátra. A közös bennük, hogy mindegyik egy olyan problémát old fel, amit egyetlen agenttel csak rosszabbul lehetne kezelni.

• Párhuzamos kutatást akarsz Amikor egy kérdés több független irányba ágazik szét — például „hasonlítsd össze öt versenytárs árazását és termékportfólióját" —, egy manager feloszthatja a munkát, és több worker egyszerre, párhuzamosan kutat. Ha egy versenytárs átvizsgálása sorosan mondjuk 40 másodperc, öt szál sorban 200 másodperc, párhuzamosan viszont közel marad a 40-hez — a wall-clock idő nagyságrendileg ötödére eshet. A kulcs a valódi függetlenség: ha az egyik szál eredménye kell a másikhoz, a párhuzamosítás előnye elolvad, és marad a koordináció költsége haszon nélkül. Mikor NE: ha a szálak folyamatosan hivatkoznak egymásra, ne párhuzamosíts.
• Elkülönített domain-context kell Ha egy feladat nagyon eltérő tudásterületeket érint — jogi, pénzügyi és műszaki elemzés egyszerre —, könnyen telezsúfolod egyetlen agent context window-ját egymásnak ellentmondó instrukciókkal és irreleváns dokumentumokkal. Külön agenteknek külön, tiszta contextet adhatsz, így mindegyik a maga szűk területén marad éles. Egy jogi agentnek a szerződéses klauzulák és a joggyakorlat kell, nem a P&L-tábla — és fordítva. Ez ugyanaz az elv, mint a context engineeringben: a fókuszált context jobb, mint a mindent-bele; a signal-to-noise arány romlásával a modell pontossága is romlik.
• Túl sok vagy egymáshoz hasonló tool van Ha egy agent 40-50 toolt kap, amelyek közül több is hasonló nevű vagy feladatú, a modell tévedni fog a választásnál — nem tudja megbízhatóan eldönteni, hogy a search_invoices vagy a search_orders kell-e. A tapasztalat az, hogy nagyjából 20 tool fölött a tool-választás pontossága érezhetően romlik, a szinonim nevek pedig külön rontják. Több specializált agent, mindegyik egy szűk, összetartozó toolkészlettel (jellemzően 5-10 tool), jóval pontosabban választ. A tool engineering határa itt találkozik a multi-agenttel: amikor a toolok számát már nem tudod tovább csökkenteni vagy összevonni, a felosztás segít.
• Külön jogosultságú szereplők vannak Ha a feladat egy része érzékeny műveletet igényel (adatmódosítás, pénzügyi tranzakció, ügyféladat olvasása), a least privilege elv szerint jobb, ha ezt egy külön, szűk jogkörű agent végzi. A „read-only" kutató agentnek soha nem kell írási joga, a végrehajtó agentnek pedig csak a saját, szigorúan behatárolt művelethez. Így egy prompt injection egyetlen agenten keresztül sem tud a teljes rendszerhez hozzáférni: ha a kutató agentet átveri egy weboldalba rejtett utasítás, akkor is csak olvasni tud, törölni vagy utalni nem — erről bővebben a 15. AI Security fejezet szól.
• Külön agent végzi a tervezést, végrehajtást és ellenőrzést A planner–executor–evaluator felosztás azért működik jól, mert más gondolkodásmódot kíván megtervezni egy megoldást, végrehajtani, és kritikusan ellenőrizni. Ha ugyanaz az agent írja és értékeli is a saját munkáját, hajlamos elnézni a saját hibáit — pont, mint amikor a saját szövegedet lektorálod, és átsiklasz a betűhibán, mert azt olvasod, amit írni akartál. Egy külön, „friss szemű" evaluator agent, amely csak a végeredményt és a kritériumokat látja (a végrehajtás gondolatmenetét nem), objektívebben talál hibát. Ez a generator–critic minta, ami az evalok LLM-as-judge megközelítésével rokon.
• Különböző modelleket használsz különböző feladatokra Nem minden részfeladathoz kell a legerősebb (és legdrágább) modell. A tervezést végezheti egy erős reasoning modell, a tömeges kinyerést vagy formázást egy olcsó, gyors modell — a kettő ára között akár egy nagyságrend is lehet a tokenárban. Ha ezeket külön agentekbe szervezed, mindegyikhez a hozzá illő modellt rendelheted: a drága modell csak ott gondolkodik, ahol tényleg számít, a rutinmunkát pedig egy gyors modell végzi. Ez közvetlenül csökkenti a költséget és a latenciát (lásd 12. Optimalizáció).
• A contextet tudatosan akarod szeparálni Néha az a cél, hogy egy agent szándékosan ne lássa a másik teljes gondolatmenetét, csak a letisztult végeredményt. Így a nyers kutatási zaj, a félbehagyott próbálkozások és a zsákutcák nem szennyezik be a döntéshozó agent contextjét. A szeparáció itt nem korlát, hanem eszköz: a köztes „szemetet" a worker megtartja, a manager csak a desztillált választ kapja. Ez a context isolation egyben tokent is spórol: nem kell a döntéshozónak ötezer token nyers keresési találatot végigolvasnia, elég a háromsoros összefoglaló.

Read-heavy kontra write-heavy feladatok

Egy praktikus szabály, amit érdemes megjegyezned: a multi-agent felosztás sokkal jobban működik olvasásintenzív (read-heavy) feladatoknál, mint írásintenzív (write-heavy) feladatoknál. Egy kutatás, ahol öt agent párhuzamosan gyűjt információt, majd egy manager összefésüli, természetesen párhuzamosítható — a részeredmények egymástól függetlenek, és a végén könnyen egyesíthetők.

Ezzel szemben egy olyan feladat, ahol több agentnek ugyanazt a kódfájlt, dokumentumot vagy állapotot kellene módosítania, gyorsan konfliktusba fut: kinek a változtatása a végleges? Ki írja felül kit? Ez ugyanaz a merge-conflict probléma, amit a verziókezelésből ismersz, csak most nemdeterminisztikus szereplőkkel. Ezért a párhuzamos írás jellemzően rossz ötlet — az írási műveleteket vagy sorosítsd egyetlen agentre, vagy particionáld úgy, hogy két agent soha ne ugyanazt a részt érintse.

Hogy lásd a különbséget: az alábbi táblázat összefoglalja, mit nyersz és mit fizetsz, amikor egyetlen agentről több agentre lépsz.

Architektúrák

Ha eljutottál oda, hogy tényleg több agent kell, a következő kérdés: hogyan kapcsolódjanak össze? Nincs egyetlen helyes válasz — a topológiát a feladat alakja határozza meg. Nézzük végig a fő mintákat, mindegyikhez egy konkrét use case-szel.

• Manager–worker Egy központi manager agent felbontja a feladatot részfeladatokra, kiosztja őket több worker agentnek, majd összegzi az eredményeiket. A workerek nem beszélnek egymással, csak a managerrel — mint egy projektmenedzser, aki delegál és integrál, de a beosztottak közvetlenül nem koordinálnak. Ez a leggyakoribb és leginkább ajánlott kiindulópont, mert a vezérlés egyetlen ponton fut össze, így könnyebb tracelni és leállítani. Use case: mélységi piackutatás, ahol a manager öt worker agentre bontja szét az öt versenytárs elemzését, majd egyetlen összehasonlító riportba fűzi őket.
• Supervisor–specialist Hasonló a manager–workerhez, de itt a workerek nem cserélhető munkások, hanem előre definiált, tartós szakértők: van egy SQL-specialista, egy dokumentum-specialista, egy kód-specialista. A supervisor a bejövő kérés jellege alapján irányítja a megfelelő szakértőhöz — a szerepe inkább routing, mint feldarabolás. Use case: vállalati asszisztens, ahol a supervisor eldönti, hogy a „mennyi volt a Q3 bevétel?" kérdés az adatbázis-specialistához, a „mit mond erről a szerződés?" pedig a dokumentum-specialistához megy. A különbség a manager–workerhez képest: itt a szakértők állandóak és a domain-jük szerint fixek, nem ad hoc jönnek létre.
• Peer-to-peer handoff Nincs központi vezető: az agentek egyenrangúak, és szükség szerint átadják egymásnak a vezérlést, a teljes beszélgetéssel együtt. Amelyik agent úgy ítéli, hogy a feladat már nem az ő hatásköre, átpasszolja a következőnek — mint egy ügyfélszolgálaton, ahol az általános ügyintéző átkapcsol a szakosított kollégához, és a fogadó fél „örökli" az egész eddigi beszélgetést. Use case: ügyfélszolgálati flow, ahol a triázs-agent handoffolja a kérést a számlázási, majd onnan a műszaki agentnek, ahogy a beszélgetés fejlődik. Kockázat: handoffnál könnyen elveszhet a kontextus, és két agent végtelen körbe passzolgathat.
• Blackboard architecture Az agentek nem közvetlenül egymással kommunikálnak, hanem egy közös, megosztott munkaterületre („feketetábla") írnak és olvasnak. Bármelyik agent hozzátehet a közös állapothoz, ha úgy látja, hogy a részmegoldásához hozzá tud járulni. Use case: komplex nyomozás vagy incidenselemzés, ahol több specializált agent (logelemző, metrika-elemző, konfigurációs auditor) ugyanarra a közös táblára gyűjti a nyomokat, amíg ki nem rajzolódik a teljes kép — pont mint egy krimiben a nyomozók fali táblája, tűzött cetlikkel és fonalakkal. A blackboard előnye a lazán csatolt együttműködés, ára a megosztott állapot konzisztenciájának kezelése.
• Hierarchical agent tree Több szintű fa: a top-level agent al-managereknek delegál, azok pedig saját workereiknek. A feladat rekurzívan bomlik egyre kisebb részekre lefelé, az eredmények pedig összegződve áramlanak felfelé. Mint egy nagyvállalat szervezeti ábrája: vezérigazgató → osztályvezetők → csapatok. Use case: egy teljes szoftvertermék specifikációból való megtervezése, ahol a felső agent modulokra bont, az almanagerek komponensekre, a levél-agentek pedig konkrét függvényeket írnak. Figyelmeztetés: minden szint hozzáad a hibaszorzáshoz és a latenciához — háromnál mélyebb fa ritkán éri meg.
• Event-driven agent mesh Az agentek lazán csatoltak: nem közvetlenül hívják egymást, hanem eseményeket publikálnak és eseményekre iratkoznak fel egy üzenetbuszon. Egy agent kimenete eseményként megjelenik, amire tetszőleges számú másik agent reagálhat. Use case: valós idejű monitoring-pipeline, ahol egy „anomália észlelve" esemény egyszerre triggereli a diagnosztikai, az értesítő és a naplózó agentet — mint egy hírszerkesztőségben, ahol egy befutó hír egyszerre több osztályt is mozgásba hoz. Ez épít a 13. Production architektúra event-driven alapjaira, és jól skálázódik, de a flow követése (ki mire reagált) nehéz observability nélkül.
• Agents-as-tools Egy agent egy másik agentet egyszerűen toolként hív meg: a hívó agent szempontjából a hívott agent csak egy függvény, ami bemenetet kap és strukturált választ ad vissza — a belső gondolkodása rejtve marad. Ez a legkevésbé „elosztott" minta, mert a vezérlés végig a hívónál marad, és pont ezért a legkönnyebben bevezethető is. Use case: egy fő asszisztens agent, amely egy „fordító agentet" hív meg toolként, amikor idegen nyelvű részletre bukkan, majd a tiszta fordítással dolgozik tovább. A határvonal a tool és az agent között itt elmosódik — erről a 7. Tool engineering fejezetben is szó lesz.
• Decentralized A2A kommunikáció A legnyitottabb minta: független, akár más szervezet által, más frameworkben megírt agentek fedezik fel egymást és működnek együtt egy közös protokollon keresztül. Nincs központi tulajdonos, aki mindegyiket irányítaná — az agentek discovery, taskdelegálás és üzenetváltás révén állnak össze. Use case: egy utazásszervező agent, amely egy külső légitársaság foglaló agentjével és egy szállodalánc agentjével egyeztet, holott egyiket sem te írtad. Ezt az Agent2Agent (A2A) protokoll hivatott szabványosítani — még korai fázisban lévő, de gyorsan formálódó terület, ahol a bizalom, az autentikáció és a hibakezelés messze nem megoldott.

Centralizált kontra decentralizált vezérlés

A nyolc minta mögött valójában egyetlen tengely húzódik: mennyire központosított a vezérlés? A manager–worker és a hierarchical tree erősen centralizált — egy pont dönt, delegál és integrál. A peer-to-peer handoff, a blackboard, az event-driven mesh és az A2A viszont egyre decentralizáltabb: a vezérlés szétoszlik az agentek között.

A gyakorlati tanulság egyszerű: kezdj a legcentralizáltabb mintával, amely megoldja a feladatot. A központi orchestrator sokkal könnyebben tracelhető, leállítható és debugolható, mert egy helyen látod a teljes döntéshozatalt. A decentralizáció rugalmasabb és jobban skálázódik, de cserébe minden koordinációs probléma (deadlock, elveszett kontextus, végtelen loop) sokkal nehezebben deríthető fel. Ne fizesd meg a decentralizáció árát, amíg nincs rá valódi szükséged.

Manager–worker példa kódban

Nézzük meg, milyen egyszerű valójában egy manager–worker orchestráció váza. A lényeg nem a keretrendszer, hanem a minta: a manager részfeladatokra bont, a workerek párhuzamosan futnak (tiszta, izolált contexttel), a manager pedig integrálja a desztillált eredményeket.

import asyncio

async def worker(competitor: str) -> str:
    # Minden worker tiszta, izolált contexttel indul:
    # csak a saját részfeladatát kapja, a többiek zaját nem.
    prompt = f"Elemezd {competitor} árazását és termékportfólióját."
    result = await run_agent(prompt, tools=[web_search], model="haiku")
    return summarize(result)  # csak a desztillált választ adja vissza

async def manager(competitors: list[str]) -> str:
    # A manager felbontja a feladatot és PÁRHUZAMOSAN futtatja a workereket.
    summaries = await asyncio.gather(*(worker(c) for c in competitors))
    # A manager csak a tiszta összefoglalókat látja, nem a nyers keresést.
    return await run_agent(
        "Készíts összehasonlító riportot ezekből:\n" + "\n".join(summaries),
        model="opus",  # a szintézishez erősebb modell
    )

report = asyncio.run(manager(["A Kft.", "B Zrt.", "C Nyrt."]))

Mit tanulj belőle: a workerek olcsó, gyors modellen futnak és izolált contextet kapnak, a drága modell csak a szintézishez lép be — ez a modelldiverzitás és a context-szeparáció a gyakorlatban. A párhuzamosítás (asyncio.gather) csak azért működik, mert a szálak függetlenek; ha egymásra épülnének, ez a minta összeomlana.

Orchestráció és kommunikáció

A topológia megmutatja, ki kihez kapcsolódik — de attól még nem tudod, hogyan beszélnek egymással az agentek, és ki tartja kézben a vezérlést. Ez az orchestráció, és pontosan itt dől el, hogy a rendszered működik-e, vagy csak drágán kaotikus.

Orchestrator kontra emergens koordináció

Két végpont van. Az egyik az explicit orchestrator: egy központi vezérlő (lehet maga is agent, de akár determinisztikus kód is) dönti el, melyik agent mikor fut, és fűzi össze a kimeneteket. A másik az emergens koordináció: nincs karmester, az agentek egymás jelzéseire reagálva „állnak össze". A determinisztikus orchestrator óriási előnye, hogy kiszámítható és tesztelhető — sok esetben a legjobb multi-agent rendszer valójában egy egyszerű workflow, amiben LLM-hívások vannak a csomópontokon, nem pedig egy szabadon garázdálkodó agentraj.

Hogyan adják át egymásnak a kontextust

Az agentek közötti kommunikációnak alapvetően három szintje van, és a választásod komoly hatással van a tokenköltségre és a megbízhatóságra:

• Teljes context átadása A fogadó agent megkapja a küldő teljes beszélgetését. Ez a peer-to-peer handoff alaphelyzete. Előny: semmi nem vész el. Hátrány: drága (minden token duplázódik), és a fogadó agent contextjét telezsúfolja irreleváns részletekkel. Mikor NE: ha a küldő gondolatmenete hosszú és tele van zsákutcával.
• Strukturált összefoglaló átadása A küldő agent egy tömör, jól definiált formátumú (pl. JSON, lásd 3. Structured output) kivonatot ad át. Ez a leggyakoribb és jellemzően a legjobb választás: olcsó, fókuszált, és a séma kényszeríti a lényeg átadását. Kockázat: ha a séma rosszul van megtervezve, pont a kritikus részlet marad ki.
• Megosztott állapoton keresztül Az agentek nem közvetlenül üzennek, hanem egy közös store-ba írnak és onnan olvasnak (blackboard, event log). Skálázható és laza csatolást ad, de itt jön be a state consistency problémája: ki írhat, mikor, és mit lát a másik. Erről lásd a 9. State és memory fejezetet.

Handoff strukturált átadással

A handoff a leggyakoribb pont, ahol a kontextus elveszik. A védekezés az, hogy nem szabad szöveget passzolgatni: kényszeríts strukturált átadást, ahol a séma explicit módon számonkéri a kritikus mezőket.

from pydantic import BaseModel

class Handoff(BaseModel):
    user_intent: str          # mit akar VALÓJÁBAN az ügyfél
    verified_facts: list[str] # amit már biztosan tudunk
    open_questions: list[str] # amit még tisztázni kell
    do_not_repeat: list[str]  # amit már megkérdeztünk tőle

# A küldő agent nem szabad szöveget ad át, hanem ezt a struktúrát tölti ki.
# A fogadó agent így pontosan tudja, hol tart a beszélgetés,
# és nem kérdez rá újra olyanra, amit már tisztáztak.
handoff = Handoff(
    user_intent="Sztornózni akarja a duplán terhelt számlát",
    verified_facts=["Ügyfélazonosító: 48213", "Két terhelés 2026-07-02-án"],
    open_questions=["Melyik terhelést tartsuk meg?"],
    do_not_repeat=["Ügyfélazonosító", "Terhelés dátuma"],
)

Mit tanulj belőle: a do_not_repeat és az open_questions mező pont azt a hibát előzi meg, amitől a handoffos rendszerek robotszerűnek hatnak (újra és újra rákérdeznek ugyanarra). A séma nem csak adatformátum: viselkedési szerződés az agentek között.

Nehézségek

Most jön az őszinte rész. Ezek nem elméleti aggályok, hanem valódi, ismétlődő problémák, amelyekbe minden multi-agent rendszer beleszalad. Mielőtt belevágsz, tudnod kell, mit veszel a nyakadba.

• Koordináció A legnagyobb kihívás: rávenni több önállóan „gondolkodó" agentet, hogy összehangoltan haladjanak egy közös cél felé. Ki mikor cselekszik, ki vár kire, hogyan bontják fel a feladatot félreértés nélkül — ezek egyike sem oldódik meg magától. Minél több agent, annál több lehetséges félrekoordináció; n agentnél a lehetséges páronkénti interakciók száma négyzetesen nő, ami gyorsan átláthatatlanná válik.
• State consistency Ha több agent ugyanazon az állapoton dolgozik, könnyen összeakadhatnak: az egyik olvas, míg a másik épp módosít, és inkonzisztens képet látnak a világról. Klasszikus race condition, csak most nemdeterminisztikus szereplőkkel, akik ráadásul „logikusan" félreértelmezhetik az elavult állapotot. Ez klasszikus elosztott rendszer probléma, amit AI-kontextusban is meg kell oldani — lásd a 9. State és memory fejezetet a megosztott állapot és a lockolás kezeléséről.
• Végtelen agent-loopok Két agent egymásnak passzolgathatja a feladatot a végtelenségig („ezt inkább te intézd" — „nem, inkább te"), vagy egy agent újra és újra ugyanazt a lépést próbálja. Kemény kilépési feltételek, max-turn limit és tokenbudget nélkül a rendszer nem áll le magától, csak amikor a pénztárcád leáll — és egy éjszakán át pörgő loop simán elköltheti egy havi keret jelentős részét.
• Hibák összegződése Ha minden egyes agent 90%-ban megbízható, az még nem jelenti, hogy a lánc is az. Öt agent sorba kötve már csak nagyjából 0,9⁵ ≈ 59% eséllyel ad hibátlan eredményt — a hibák nem összeadódnak, hanem szorzódnak. Tíz lépésnél ez már 0,9¹⁰ ≈ 35%. Minél hosszabb a lánc, annál törékenyebb a rendszer, és annál fontosabb a lépésenkénti validáció, hogy a hiba ne terjedjen tovább.
• Magas tokenköltség Minden agentnek saját contextje, saját system promptja és saját gondolkodási köre van — és a köztük folyó kommunikáció is tokenekbe kerül. Az Anthropic nyilvánosan megosztott mérése szerint a multi-agent kutatórendszerük nagyságrendileg tizenötszörös tokenmennyiséget fogyasztott egy sima chatbeszélgetéshez képest. Ez az egyik legerősebb ok, amiért nem szabad csak úgy több agentre bontani: a számla nem lineárisan, hanem sokszorosan nő.
• Attribution: melyik agent hibázott Amikor a végeredmény rossz, ki a felelős? A tervező, aki rossz részfeladatot adott ki, vagy a végrehajtó, aki jó feladatot rontott el? Egyetlen agentnél egy trajektóriát nézel végig; több agentnél egy elosztott, egymásba fonódó nyomozásba kezdesz — mint egy krimiben, ahol minden szereplőnek van alibije, és a hiba a szereplők közti résben történt. Alapos tracing nélkül reménytelen: minden agenthívást, minden handoffot és minden állapotváltozást naplózni kell.
• Context elvesztése handoffnál Amikor egy agent átadja a feladatot egy másiknak, a fontos részletek elveszhetnek vagy eltorzulhatnak — pont, mint a „súgó-búgó" gyerekjátékban, ahol a mondat körbeérve felismerhetetlenné válik. Ha a handoff csak egy rövid összefoglalót visz át, a fogadó agent kritikus kontextus nélkül dolgozik tovább, és rossz feltételezésekre épít. A védekezés a strukturált handoff (lásd fent) és a megosztott állapot, amiből visszaolvasható a teljes kép.
• Jogosultságdelegálás Ha egy agent egy másikat bíz meg egy művelettel, milyen jogosultsággal teszi? Könnyen létrejön a „confused deputy" helyzet, amikor egy alacsonyabb jogú agent egy magasabb jogú agenten keresztül olyasmit ér el, amihez önmagában nem lenne joga. A jogosultságokat végig kell vinni a delegálási láncon, nem elég az első kapunál ellenőrizni — minden agentnek a saját, legszűkebb jogkörével kell dolgoznia (lásd 15. AI Security).
• Deadlock és livelock Deadlock: két agent kölcsönösen egymás eredményére vár, így egyik sem halad — örök patthelyzet. Livelock: folyamatosan reagálnak egymásra és tesznek-vesznek, de érdemi előrelépés nélkül pörögnek. Mindkettő klasszikus elosztott rendszer betegség, ami itt is előjön, mihelyt az agentek egymásra vannak utalva — és nemdeterminisztikus szereplőkkel nehezebb kiszűrni, mert nem mindig reprodukálható.
• Nehezebb eval Egyetlen agentnél a trajektóriát és a végeredményt értékeled. Multi-agent rendszernél ez sokkal összetettebb: nem elég a végkimenetet nézni, mérned kell az egyes agentek részteljesítményét, a köztük folyó kommunikáció minőségét és a koordináció hatékonyságát is. Egy jó végeredmény is fakadhat véletlenül jó koordinációból, egy rossz pedig egyetlen gyenge láncszemből. Az eval itt önmagában egy mérnöki projekt — a legnehezebb részek egyike.
• Reprodukálhatóság Az LLM-ek eleve nemdeterminisztikusak; több agent párhuzamos, időzítéstől függő interakciója pedig tovább sokszorozza a variabilitást. Ugyanaz a bemenet két futásnál teljesen más útvonalat járhat be, ami rémálommá teszi a hibák megbízható újratermelését és a regressziók kiszűrését. A trajektóriák rögzítése (record/replay) és a seed-elés részben segít, de a párhuzamos időzítést nehéz teljesen determinisztikussá tenni.

Kemény korlátok: a rendszer ne tudjon elszabadulni

A végtelen loop és a szaladó tokenköltség nem „majd megnézzük" jellegű probléma — ezek ellen már az első verzióban kemény korlátokat kell építened. Ne bízz abban, hogy az agentek maguktól leállnak; a kilépési feltételt kódban kényszerítsd ki.

class BudgetGuard:
    def __init__(self, max_turns=20, max_tokens=200_000):
        self.max_turns = max_turns
        self.max_tokens = max_tokens
        self.turns = 0
        self.tokens = 0

    def check(self, tokens_used: int) -> None:
        self.turns += 1
        self.tokens += tokens_used
        if self.turns > self.max_turns:
            raise RuntimeError("Max-turn limit elérve – kilépés.")
        if self.tokens > self.max_tokens:
            raise RuntimeError("Tokenbudget kimerült – kilépés.")

# Minden agentlépés UTÁN ellenőrizd. A guard a teljes rendszerre közös,
# nem agentenként – különben n agent n-szeres budgetet éget el.
guard = BudgetGuard()
while not done:
    result = step()
    guard.check(result.tokens_used)

Mit tanulj belőle: a budget-guard a teljes rendszerre közös, nem agentenkénti — máskülönben pont az a sokszoros költség szabadul el, ami ellen védekezni akarsz. A max-turn limit a végtelen handoff-loopokat és a livelockot vágja el, a tokenbudget pedig a pénztárcádat védi.

Gyakori hibák multi-agent rendszereknél

• Túl korai felbontás A leggyakoribb hiba: több agentre bontani, mielőtt egyetlen agenttel egyáltalán megpróbáltad volna. Gyakran kiderül, hogy egy jól megírt system prompttal és a megfelelő toolokkal egyetlen agent is elvégzi a feladatot — a fele költségen, tizedannyi hibalehetőséggel.
• „Chatelő" agentek Ha az agentek szabad szöveggel, kötetlenül beszélgetnek egymással, a beszélgetés hosszú lesz, drága, és gyakran körbejár, mielőtt bármit is elvégeznének. A kommunikációt strukturáld (séma, definiált mezők), és korlátozd a köröket.
• Nincs egyetlen felelős a végeredményért Ha nincs egy agent (vagy determinisztikus lépés), amely explicit módon felel a végkimenet összeállításáért és validálásáért, a rendszer kimenete kiszámíthatatlan. Mindig legyen egy „utolsó szó" pont.
• Observability utólag A tracinget nem lehet a végén rácsavarni. Ha nem az elejétől naplózol minden hívást, handoffot és állapotváltozást, az attribution-probléma miatt vakon fogsz debugolni. Az observability az első osztályú követelmény, nem opcionális extra.

Ha mégis belevágsz: bevezetési stratégia

Tegyük fel, hogy őszintén végigmentél a döntési szempontokon, és tényleg van egy konkrét korlát, amit csak több agenttel tudsz feloldani. Ilyenkor sem ugrasz fejest — van egy józan sorrend, ami sok fájdalomtól megkímél.

• 1. Kezdj egyetlen agenttel, és mérj Építsd meg először egy agenttel, akkor is, ha tudod, hogy szét fogod bontani. Így lesz baseline-od: pontosan látod, hol bukik meg (túl sok tool, telített context, lassú soros futás), és így a felbontás egy konkrét mérési eredményre válaszol, nem egy sejtésre.
• 2. Válaszd a legcentralizáltabb működő topológiát Alapesetben manager–worker vagy agents-as-tools. Ne indíts A2A-val vagy event-driven meshsel, amíg egy egyszerűbb, tracelhetőbb minta is megoldja. A centralizált vezérlés a barátod, amíg tanulod a rendszered viselkedését.
• 3. Strukturáld a kommunikációt és a handoffot Séma minden agent közti üzenetre, explicit „mit ne ismételj" és „mi maradt nyitva" mezőkkel. Ez az egyetlen megbízható védekezés a handoffnál elvesző kontextus ellen.
• 4. Építs be kemény korlátokat az első naptól Max-turn limit, közös tokenbudget, timeout minden agentre, és egyértelmű terminációs feltétel. Ezek nélkül a rendszer előbb-utóbb elszabadul, és a legrosszabbkor.
• 5. Traceld és evalold már fejlesztés közben Minden hívás, handoff és állapotváltozás naplózva; és állíts fel evalt nemcsak a végeredményre, hanem a koordináció minőségére is. A multi-agent rendszer megbízhatósága nem a modellen, hanem ezen a mérnöki munkán múlik.

Összefoglalás

A multi-agent rendszer nem rangjelzés, hanem eszköz — és a legtöbb feladathoz nincs rá szükséged. A helyes kiindulópont mindig egyetlen, jól felszerelt agent vagy egy determinisztikus workflow; a több agentet konkrét korlátnak kell megindokolnia: valódi párhuzamosítás, context-szeparáció, jogosultsági határok, modelldiverzitás vagy a független ellenőrzés. Jó ökölszabály, hogy a felosztás read-heavy feladatoknál működik, write-heavy feladatoknál pedig ritkán éri meg. Ha megvan az indok, a topológiát a feladat alakja szabja meg — a manager–workertől az agents-as-tools mintán át a decentralizált A2A-ig —, és mindig a legcentralizáltabb működő mintával érdemes kezdeni.

Cserébe azonban komoly árat fizetsz: koordináció, sokszoros (akár nagyságrendileg tizenötszörös) tokenköltség, szorzódó hibák, nehezebb attribution és eval, valamint gyenge reprodukálhatóság. Ezek nem elkerülhetők, csak menedzselhetők — kemény kilépési feltételekkel, strukturált handoffal, közös tokenbudgettel, alapos tracinggel, lépésenkénti validációval és tudatos jogosultságkezeléssel. A jó senior mérnök nem attól ismerszik meg, hogy sok agentet rak egymásra, hanem attól, hogy pontosan tudja, mikor nem teszi — és amikor mégis, akkor a koordinációt, az observabilityt és az evalt már az első naptól komolyan veszi.