A gyártói szám, és miért nem elég
A leggyakrabban idézett adat egy 2025 júniusi gyártói közlésből származik: egy erősebb vezető agent és gyengébb subagentek kombinációja 90,2%-kal felülmúlta ugyanazt az erős modell t egyedül.
Három dolog tartozik hozzá, és mindhármat ugyanaz a forrás írja le:
- Az értékelés belső, és a feladat egy tőzsdeindex informatikai szektorának igazgatósági tagjait kereste. Ez szélesség jellegű, párhuzamosítható keresés — a legkedvezőbb eset a többagentes felállásnak.
- A tokenköltség: az agentek nagyjából négyszer annyi tokent használnak, mint egy beszélgetés; a többagentes rendszerek tizenötször annyit.
- És a legfontosabb: „a tokenfogyasztás önmagában a variancia 80%-át magyarázza."
Az utolsó mondat gyakorlatilag kimondja, hogy a javulás nagy része nem az architektúrából jön, hanem abból, hogy többet számoltak.
(Belső, nem publikált kiértékelés, közölt módszertan és mintanagyság nélkül — így kell hivatkozni rá.)
Az ellenbizonyíték: azonos tokenbüdzsé mellett
Egy 2026 áprilisi tanulmány pontosan ezt a kérdést tette fel: mi marad a különbségből, ha a számítási költséget rögzítjük?
A megfogalmazásuk szó szerint: a többagentes rendszerekről jelentett erős eredményeket „gyakran összezavarja a megnövelt következtetési számítás. Amikor a számítást normalizáljuk, az egyagentes rendszerek felérnek a többagentessel, vagy felül is múlják."
Három modellcsaládon, több többagentes architektúrával, azonos gondolkodási tokenbüdzsével mérve: az egyagentes rendszer következetesen felérte vagy felülmúlta a többagentest a többlépcsős érvelési feladatokon.
És van egy elméleti alap is mögötte, plusz egy előrejelzés, ami pontosan ennek a cikknek a tézise:
A többagentes felállás akkor lesz versenyképes, amikor az egyagentes rendszer kontextushasznosítása romlik — vagy amikor több számítást költesz.
Vagyis: nem a párhuzamosság az érték, hanem az, hogy a részfeladat tiszta ablakban fut.
A kontextus romlása, mérve
Ha a tézis a tiszta kontextus, akkor meg kell mutatni, mennyit romlik a piszkos.
Egy 18 modellt vizsgáló méréssorozat fő megállapítása szó szerint: a modellek nem egyenletesen használják a kontextust — a teljesítményük egyre megbízhatatlanabb, ahogy nő a bemenet hossza.
És a legélesebb részeredmény: már egyetlen oda nem illő elem is ront az alapesethez képest.
Erre van független, számszerű megerősítés is. Egy függvényhívási benchmark külön méri a több körös feladatot alap- és hosszú kontextusú változatban, ugyanazokon a modelleken:
| Több kör, alap | Több kör, hosszú kontextussal | Esés | |
|---|---|---|---|
| Az élmezőny | 63–81% | 56–70% | modellenként −0,5 … −10,5 pont |
(Saját számítás a nyilvános ranglista adataiból. A hét vizsgált modell mediánja 8 pont; egyetlen modellnél volt csak 0,5 pont az esés — a hatás modellfüggő.)
Ez a cikk tézisének számszerű alapja: a hosszabb kontextus önmagában, a lépésszámtól függetlenül, mérhető veszteség.
Ehhez jön a régóta ismert lelet, hogy a modellek a kontextus elejére és végére tett információt jobban használják, mint a közepére tettet — és egy magyarázat, amit érdemes megjegyezni: a modellnek figyelmi büdzséje van, és minden hozzáadott token fogyaszt belőle.
Innen érthető, mit csinál valójában a subagent: saját, tiszta ablakban dolgozik, akár tízezres nagyságrendű tokent használ el — és 1 000–2 000 tokenes sűrített összefoglalót ad vissza. A fő agent kontextusába nem a munka kerül be, hanem az eredmény.
Mikor éri meg?
Erre van mérés is. Egy 2025-ös vizsgálat két dimenzió mentén nézte a feladatokat: mélység (milyen hosszú az érvelési lánc) és szélesség (hányféle képesség kell hozzá).
A megállapítás: a többagentes felállás előnye mindkét dimenzióval nő, és a mélységgel erősebben.
Gyakorlati szabállyá fordítva: a felbontás akkor térül meg, ha a részfeladatok függetlenek, és más-más képességet igényelnek. Ha egymásra épülnek, nem.
Mikor nem?
Erre a legjobb forrás az elsődleges dokumentáció, ami kimondja a negatív eseteket:
NE HASZNÁLJ SUBAGENTET, HA
- a feladat gyakori oda-vissza egyeztetést vagy
iteratív finomítást igényel;
- több szakasz OSZTOZIK jelentős kontextuson
(tervezés, megvalósítás, tesztelés együtt);
- gyors, célzott változtatásról van szó;
- a késleltetés számít.
És egy technikai részlet, ami ebből következik: a subagent friss, izolált ablakban indul. Nem látja a beszélgetés előzményét, nem látja, mit olvastál el eddig. Ez pont az előnye — és pont ezért drága, ha a feladat közös kontextust igényel.
Amit viszont jól tud, ugyanebből a dokumentációból: kontextus megőrzése (a felderítés kimarad a fő beszélgetésből), költségkontroll (a részfeladat mehet gyorsabb, olcsóbb modellre), korlátozás (a subagent kevesebb eszközt kap), és szakosítás (fókuszált rendszerprompt).
Két gyártó, egy nap különbséggel
Ez a téma legjobb illusztrációja, hogy mennyire nincs konszenzus.
2025. június 12.: az egyik eszközgyártó közzétesz egy írást „Ne építs többagentes rendszert" címmel. Két alapelvet fogalmaz meg: oszd meg a kontextust, és ne csak az üzeneteket, hanem a teljes nyomvonalat; illetve a cselekvések rejtett döntéseket hordoznak, és az egymásnak ellentmondó döntések rossz eredményt adnak. A legélesebb mondata: 2025-ben több agent együttes futtatása „csak törékeny rendszereket eredményez".
2025. június 13. — másnap: egy másik gyártó közzéteszi a 90,2%-os többagentes eredményét.
(Az első írás nem tartalmaz mért számot — tapasztalat és álláspont. A második belső evalt idéz. Egyik sem független mérés.)
Koordinációs hibák, mérve
Végül a számok arról, mi romlik el, ha mégis felbontod. Ugyanaz az 1 642 annotált futást feldolgozó vizsgálat, ami a hibatipológiát adta:
Az agentek közti félreértés a hibák 32,3%-a. Ezen belül:
| Hibamód | Arány |
|---|---|
| Érvelés–cselekvés eltérése (leírja, mit fog tenni, aztán mást tesz) | 13,2% |
| Feladat elsodródása | 7,4% |
| Nem kérdez vissza tisztázásért | 6,8% |
| Beszélgetés újraindul | 2,2% |
| Másik agent inputjának figyelmen kívül hagyása | 1,9% |
| Információ visszatartása (az „elveszett átadás") | 0,8% |
Ehhez jön külön a lépésismétlés 15,7%-a — ez a duplikált munka mérőszáma.
És a vizsgálat saját keretezése, amit érdemes idézni: a többagentes rendszerek iránti lelkesedés ellenére „a népszerű benchmarkokon elért teljesítménynyereségük gyakran minimális."
A how-to
1. ELŐBB KÉRDEZD MEG: FÜGGETLEN-E?
Ha a részfeladatok egymásra épülnek, ne bontsd fel.
A mérés szerint a haszon a függetlenséggel jön.
2. A SUBAGENT EREDMÉNYT AD VISSZA, NEM MUNKÁT
1-2 ezer tokenes összefoglaló. Ha a teljes nyomvonalat
visszaadja, elvesztetted a tiszta kontextus előnyét.
3. ADD MEG NEKI A TELJES FELADATOT
Friss, izolált ablakban indul: nem látja, amit te
tudsz. Amit nem írsz le neki, az nincs.
4. KEVESEBB ESZKÖZT ADJ NEKI, NE TÖBBET
A szűkítés itt ingyen van, és a választási pontosságot
javítja.
5. OLCSÓBB MODELL A RÉSZFELADATRA
Ez a felbontás egyik valódi, mérhető haszna.
6. MÉRD A DUPLIKÁCIÓT
A leggyakoribb koordinációs hiba a lépésismétlés.
Ha két subagent ugyanazt csinálja, a felbontás rossz.
A harmadik pont a leggyakoribb hiba. A subagent nem tudja, mit beszéltetek eddig — és ez nem hiányosság, hanem a lényeg. De ezért a feladatleírásnak önállóan is teljesnek kell lennie.
Tipikus félreértések
- „Több agent jobb eredményt ad." Azonos tokenbüdzsé mellett a mérés szerint nem. A javulás nagy része a többletszámításból jön.
- „A felbontás gyorsít." A késleltetés csökkenhet, de a tokenköltség a közölt szorzók szerint a többszörösére nő.
- „A subagent látja, amit eddig csináltunk." Nem. Friss, izolált ablakban indul.
- „A kódolás jó terep a felbontásra." Az elsődleges dokumentáció szerint a kódolási feladatok nagy részében kevesebb a valóban párhuzamosítható rész, mint a kutatásban.
- „Ha nem működik, adjunk hozzá még egy agentet." A mért koordinációs hibák aránya harminc százalék fölött van — minden újabb agent ezt is növeli.
- „A 90,2% bizonyíték." Belső kiértékelés, a legkedvezőbb feladattípuson, és ugyanaz a forrás írja, hogy a variancia 80%-át a tokenfogyasztás magyarázza.
Amit érdemes elvinni
A subagent nem párhuzamosítási eszköz, hanem kontextuskezelési eszköz. Ez a különbség dönti el, mikor éri meg.
A gyakorlati kérdés ezért nem az, hogy „hány agentre bontsam", hanem hogy melyik részfeladat rondítja el a fő kontextust. A felderítés, a hosszú keresés, a sok fájl átnézése — ezek tipikusan igen. A tervezés, a megvalósítás és a tesztelés együtt, közös háttérrel — tipikusan nem.
És egy ellenőrzés, ami olcsó: ha a subagent ugyanolyan hosszú választ ad vissza, mint amilyen hosszan dolgozott, akkor a felbontás nem hozott semmit. A lényeg a sűrítés.
Hogy miért romlik a megbízhatóság a lépésszámmal — és miért nem segít az önellenőrzés —, arról az agent-megbízhatóság matematikája poszt szól számolással; a memória és a felejtés kérdéséről pedig az agent memory poszt.