Mennyibe kerül a koordináció?
Egy számmal kezdve, mert ez adja a mérce alját. A gyártói közlés szerint az agentek nagyjából négyszer annyi tokent használnak, mint egy sima beszélgetés; a multi-agent rendszerek tizenötször annyit.
[Saját számítás] Ebből: a multi-agent felépítés nagyjából négyszeresére emeli a tokenköltséget egyetlen agenthez képest.
Ez a szám a belépő. Ha a felbontás nem hoz négyszeres értéket, akkor veszteséges — és ezt előre tudni kell, nem utólag a számlából. Arról, hogy miért nem a párhuzamosításban van a haszon, a subagent és a párhuzamos munka című írás szól részletesen; ez a cikk innentől a mintázatokról.
Öt rendszer, mért eredmények
A legjobb hozzáférhető adat erre egy 1 642 annotált futásnyomot feldolgozó akadémiai vizsgálat, ami hét multi-agent keretrendszert nézett meg. Ötről közölt összevethető sikerrátát:
| Mit csinál a rendszer | Feladattípus | Siker |
|---|---|---|
| Matematikai szöveges feladatok | számolás | 84,8% |
| Programfejlesztő rendszer A | kódírás | 66,0% |
| Hibajavító rendszer | valódi hibajegyek | 25,3% |
| Programfejlesztő rendszer B | kódírás | 25,0% |
| Alkalmazáshasználó rendszer | eszközhívások láncban | 13,3% |
A vizsgálat nyitómondata pedig ez: a multi-agent rendszerek iránti lelkesedés ellenére a népszerű benchmarkokon elért nyereségük gyakran minimális.
Nézd meg a táblázat alakját. A jól sikerült sorok mind zárt, rövid, ellenőrizhető feladatok. A rosszul sikerült sorok mind hosszúak, nyitottak és sok lépésből állnak. Ez nem véletlen — és pontosan ez a mintázatválasztás lényege.
A hat mintázat
Az elsődleges dokumentáció hat felépítést különböztet meg. Érdemes megtanulni a nevüket, mert ezzel a szótárral a „használjunk több agentet" mondat konkrét tervezési döntéssé válik:
| Mintázat | Mit csinál |
|---|---|
| Láncolás | A feladatot rögzített lépéssorra bontja; minden hívás az előző kimenetét dolgozza fel. |
| Útválasztás | Besorolja a bemenetet, és a megfelelő szakosított kezelésre irányítja. |
| Párhuzamosítás | Több hívás dolgozik egyszerre, a kimeneteket kóddal összesítjük. |
| Karmester és munkások | Egy központi modell menet közben bont fel, delegál, majd összefűzi az eredményt. |
| Értékelő és javító | Az egyik hívás válaszol, a másik értékeli és visszajelez, ciklusban. |
| Autonóm agent | Önállóan tervez és cselekszik, emberhez csak információért vagy döntésért fordul vissza. |
A hat közül négy jellemzően megtéríti a koordináció költségét, kettő pedig csak ritkán.
A négy, ami megtérül
1. Útválasztás — a legolcsóbb nyereség
Egy kis, gyors modell besorolja a bemenetet, és onnantól a megfelelő szakosított prompt kezeli. A többletköltség egyetlen rövid hívás, a nyereség pedig az, hogy minden ág fókuszált rendszerpromptot kap.
Akkor jó, ha a kategóriák tényleg elkülönülnek, és a besorolás megbízható. Akkor rossz, ha a határeset gyakori — mert akkor a rossz ágba került feladat végig rossz ágon marad.
2. Láncolás — pontosság latenciáért
Rögzített lépéssor: vázlat, majd ellenőrzés, majd kifejtés. Nem dinamikus, nem dönt semmiről — ettől kiszámítható és hibakereshető.
Ez a legalulértékeltebb mintázat. Nem izgalmas, de a legtöbb üzleti feladat pont ilyen: a lépések előre ismertek. A tokenköltség itt nem négyszereződik, csak a lépésszámmal nő, és minden lépés kimenete ellenőrizhető. Ha a lépések között strukturált formátumot adsz át, a lánc robusztusabb lesz — ehhez ad fogódzót a strukturált kimenet című bevezető.
3. Párhuzamosítás — ha a részek tényleg függetlenek
Két esete van, és érdemes megkülönböztetni őket:
- Felosztás: a bemenet független darabokra vágható (száz dokumentum, száz hívás).
- Több nézőpont: ugyanazt a feladatot több szempontból futtatod, és az egyezés növeli a bizalmat.
A kulcsszó a definícióban az, hogy a kimeneteket kóddal összesítjük. Amint az összefűzést is egy modellre bízod, átléptél a karmester-mintázatba, és vele együtt annak a hibáiba is.
4. Értékelő és javító — az egyetlen, amire kemény bizonyíték van
Ez a legjobban alátámasztott mintázat, és két, egymást kiegészítő mérés áll mögötte.
Az egyik negatív: egy 2024-es akadémiai eredmény szerint a modellek külső visszajelzés nélkül nem tudják kijavítani magukat — sőt, az önjavítás után a teljesítményük időnként romlik. Vagyis a „gondold át még egyszer" típusú önellenőrzés nem éri meg.
A másik pozitív: ugyanabban a multi-agent vizsgálatban két beavatkozást is kipróbáltak, ugyanazzal az alapmodellel, csak a rendszer felépítését változtatva:
| Beavatkozás | Javulás |
|---|---|
| Pontosabb szerep- és munkafolyamat-definíció | +9,4 százalékpont |
| Megerősített ellenőrzési lépés | +15,6 százalékpont |
Ez a cikk legfontosabb üzenete. A különbség nem a modellben van, hanem abban, hogy van-e a rendszerben külső ellenőrzési pont. Az önellenőrzés nem javít; a másik hívás, ami kívülről nézi, javít — és a determinisztikus, kóddal írt ellenőrzés még inkább.
Fontos fenntartás viszont: a +15,6 pont egy 25%-os alapról indult. Az ellenőrzés javít, de nem ment meg egy rossz alapfelépítést.
A kettő, ami ritkán térül meg
5. Karmester és munkások
Ez az, amit a legtöbben „multi-agent rendszernek" hívnak: egy vezető modell menet közben dönti el, mire van szükség, és delegál.
Ez a legerősebb mintázat — és a legdrágább. Itt lakik a tizenötszörös tokenszorzó, és itt csoportosulnak a koordinációs hibák is. A dokumentált korai hibák konkrétak és tanulságosak:
- ötven subagent indítása egyszerű kérdésekre;
- vég nélküli keresgélés nem létező források után;
- három subagent közül az egyik egészen másról gyűjtött adatot, kettő pedig ugyanazt a munkát végezte;
- annyira homályos delegálási utasítások, hogy a subagentek félreértették a feladatot.
Akkor éri meg, ha a részfeladatok előre tényleg nem definiálhatók — jellemzően nyitott végű kutatásnál. Akkor nem, ha a lépések előre ismertek: ott a láncolás ugyanazt adja, negyedáron.
A gyártó saját dokumentációja két helyen is óvatosságra int: a kódolási feladatok többségében kevesebb a valóban párhuzamosítható rész, mint a kutatásban, és — egy 2026-os írásukban — „a hagyományos kódolási feladatok többségéhez nincs szükség ötfős bírálóbizottságra".
6. Teljesen autonóm, egymással beszélgető agentek
A mért táblázat két alsó sora ilyen rendszer. 25,0% és 13,3%.
A legjobb magyarázat erre egy eszközgyártó 2025-ös írásából jön, ami két alapelvet fogalmaz meg: oszd meg a teljes nyomvonalat, ne csak az üzeneteket, és a cselekvések rejtett döntéseket hordoznak, az egymásnak ellentmondó döntések pedig rossz eredményt adnak.
A hozzá tartozó példa a téma legjobb illusztrációja. A feladat: készíts el egy egyszerű ügyességi játékot. A felbontás után az egyik subagent félreérti a stílust, és egy teljesen más játékra emlékeztető hátteret készít; a másik olyan főszereplőt rajzol, ami nem illik hozzá. A záró agent lehetetlen feladatot kap: össze kell illesztenie két összeférhetetlen darabot.
És vedd észre a csavart: egyik subagent sem hibázott. Mindkettő értelmes munkát végzett — csak más feltevésekkel. A koordinációs hiba nem rossz válaszokból áll össze, hanem össze nem illő jó válaszokból.
Hol romlik el pontosan?
A teljes hibatipológia, 1 642 futásnyomból, három kategóriában:
| Kategória | Arány | A kategória legnagyobb hibamódja |
|---|---|---|
| Rendszertervezési hibák | 44,2% | lépésismétlés — 15,7% |
| Agentek közti félreértés | 32,3% | érvelés és cselekvés eltérése — 13,2% |
| Ellenőrzés hiánya | 23,5% | hibás ellenőrzés — 9,1% |
Ebből egy meglepő olvasat jön. A hibák legnagyobb része nem az agentek közti kommunikációból ered, hanem a rendszer tervezéséből — abból, hogy az agent ismétel, nem tudja, mikor van kész, vagy nem tartja be a kapott specifikációt.
Ez jó hír: a legnagyobb kategória az, amin a promptok és a keretek megváltoztatásával lehet javítani, nem az, ami modellcserét igényelne. A második legnagyobb tétel, az érvelés és a cselekvés eltérése — amikor az agent leírja, mit fog tenni, aztán mást tesz — szintén ellenőrzéssel fogható meg: ha a tervet strukturáltan kéred, és kóddal veted össze a végrehajtott lépésekkel, a hibamód láthatóvá válik.
A lépésszám és a megbízhatóság összefüggéséről külön írás szól: az agent-megbízhatóság matematikája poszt levezeti, miért nem elég a 95%-os lépéspontosság.
Egy 2026-os fejlemény, ami átrendezi a képet
Az újabb modellek dokumentációjában megjelent egy mondat, amit érdemes komolyan venni: az új modellgeneráció készségesebben delegál subagenteknek, mint a korábbi. Az ajánlás ugyanonnan: adj kifejezett útmutatást arról, mely helyzetek indokolják a delegálást, vagy korlátozd a subagentek számát.
Ez azt jelenti, hogy a multi-agent viselkedés már nem csak architektúrális döntés, hanem modellverzió-függő viselkedés is. Ugyanaz a prompt ugyanazzal a felépítéssel új modellen több agentet indíthat, több tokent fogyaszthat és máshogy bukhat el.
Gyakorlati következmény: modellváltáskor a felbontási szabályokat újra kell nézni, nem csak a promptokat. És ha a költséged hirtelen megugrott egy frissítés után, itt érdemes először keresni.
A döntési sorrend
1. VAN ELŐRE ISMERT LÉPÉSSOR?
-> LÁNCOLÁS. Olcsó, kiszámítható, hibakereshető.
2. ELKÜLÖNÜLŐ KATEGÓRIÁK, KÜLÖN KEZELÉSSEL?
-> ÚTVÁLASZTÁS. Egy rövid hívás a teljes költség.
3. FÜGGETLEN DARABOK, KÓDDAL ÖSSZEFŰZHETŐ?
-> PÁRHUZAMOSÍTÁS. De az összegzést NE modell
végezze.
4. VAN VILÁGOS ÉRTÉKELÉSI SZEMPONT?
-> ÉRTÉKELŐ-JAVÍTÓ. Erre van a legerősebb mérés:
+15,6 pont. De KÜLSŐ ellenőrzés kell, az
önellenőrzés nem javít.
5. TÉNYLEG NEM DEFINIÁLHATÓK ELŐRE A LÉPÉSEK?
-> KARMESTER ÉS MUNKÁSOK. Egy agenthez képest 4x
tokenköltséggel, és korlátozd a subagentek
számát.
6. MINDEN MÁS ESETBEN
-> EGY AGENT. Ez a helyes alapértelmezés.
Az első négy pont a legtöbb üzleti feladatot lefedi — és egyikhez sem kell az, amit köznyelven multi-agent rendszernek hívunk.
Tipikus félreértések
- „A multi-agent rendszer erősebb." A mérésben 13,3% és 84,8% között szórtak. A felépítés dönt, nem a darabszám.
- „Ha a feladat összetett, több agent kell." Az összetettség önmagában nem indok. A kérdés az, hogy a lépések előre definiálhatók-e: ha igen, a láncolás olcsóbban ugyanazt adja.
- „Az agentek majd egyeztetnek egymással." A mért hibáknak közel harmada pont az egyeztetés kudarca — és a leggyakoribb formája nem a rossz válasz, hanem az össze nem illő feltevés.
- „Adjunk hozzá egy ellenőrző agentet, és rendben lesz." Segít — mérhetően, plusz 15,6 ponttal —, de az a mérés 25%-os alapról indult. Az ellenőrzés nem javítja meg a rossz felépítést.
- „Kérjük meg a modellt, hogy ellenőrizze magát." Külső visszajelzés nélkül az önjavítás nem javít, és időnként ront.
- „A kódolás a multi-agent rendszerek terepe." Az elsődleges dokumentáció szerint a kódolási feladatokban kevesebb a valóban párhuzamosítható rész, mint a kutatásban.
- „Ugyanaz a felépítés új modellen ugyanúgy fog működni." Az újabb modellek készségesebben delegálnak. Ugyanaz a prompt drágábban futhat.
Amit érdemes elvinni
A kérdés nem az, hogy „hány agentet használjak", hanem hogy melyik mintázat illik a feladathoz. A hat közül négy — a láncolás, az útválasztás, a párhuzamosítás és az értékelő-javító páros — olcsó és kiszámítható. A maradék kettő erős, de drága, és a mért hibák többsége ott keletkezik.
Egyetlen szám, amit érdemes megjegyezni: plusz 15,6 pont egy külső ellenőrzési lépéstől, ugyanazzal a modellel. Ha egy dolgot építesz be, ezt építsd be — és ne a modelltől kérd, hanem kívülről tedd oda.
És a legjobb önellenőrző kérdés tervezés előtt: le tudod írni előre a lépéseket? Ha igen, nincs szükséged multi-agent rendszerre — láncra van szükséged. Hogy a kész rendszert hogyan méred és figyeled, azt az agentek tesztelése és felügyelete témájú poszt veszi végig.