Kalmár Dániel · Útmutató

A multi-agent munkafolyamat, ahogy a gyakorlatban felépül

Egy nagyobb fejlesztési feladatot ritkán érdemes egyetlen AI ügynökre bízni. Nem azért, mert az ügynök gyenge, hanem mert egy hosszú, sok részből álló munkán a figyelem és a kontextus előbb vagy utóbb szétesik. A multi-agent orchestration erre ad választ. A feladatot több, egymásra épülő szerepre bontjuk, és minden szerepet a rá legalkalmasabb ügynök végez. Ez az útmutató egy bevált mintát mutat be, amely a gyakorlatban stabilan működik.

Kalmár Dániel · Vissza az útmutatókhoz


A probléma

Miért akad el egyetlen ügynök egy nagy feladaton

Egy AI ügynök egy dolgot csinál nagyon jól. Végigvisz egy jól körülhatárolt feladatot elejétől a végéig. A gond akkor kezdődik, amikor a feladat túl nagy. Egy komplett funkció megtervezése, több fájlon átívelő átírása és leellenőrzése annyi lépésből áll, hogy a rendszer figyelme közben menthetetlenül felhígul. A korábbi döntések kicsúsznak a kontextusból, a végén már nem emlékszik pontosan arra, amit az elején eldöntött.

Ehhez jön még két gyengeség. Az egyik, hogy egyetlen ügynök sorban dolgozik, egyszerre csak egy szálon halad, tehát egy nagy feladat hosszú ideig tart. A másik, hogy a saját munkáját maga ellenőrzi, márpedig aki írta a megoldást, az hajlamos elnézni a saját hibáját. Ez a három tényező együtt magyarázza, miért lesz egy magányos ügynök megbízhatatlan, amint a feladat mérete átlép egy határt.


Az orchestration minta

A minta hat lépése

A megoldás nem egy okosabb modell, hanem egy jobb munkamegosztás. A feladatot szerepekre bontjuk, és minden szerepet külön ügynök visz. A párhuzamosítható részeket egyszerre indítjuk, a döntési pontokat pedig egy erős, dedikált ügynökre bízzuk. Az alábbi minta hat jól elkülönülő lépésből áll.

1 · FELTÁRÁS 2 · TERVEZÉS 3 · VÉGREHAJTÁS 4 · LEZÁRÁS Feltáró 1 Feltáró 2 Feltáró 3 Tervező összerakja a tervet Végrehajtó 1 saját worktree Végrehajtó 2 saját worktree Végrehajtó 3 saját worktree Összefésülés Review ügynök PR / kész munka
A feladat több feltáró ügynökkel indul, egy tervező összerakja a tervet, több végrehajtó dolgozik külön worktree-ben, majd az összefésült eredményt egy független review nézi át, végül PR lesz belőle.
1
Feltáró ügynökök (Explore). Több ügynök egyszerre térképezi fel a feladatot és a kódbázist, mindegyik más szögből. Az egyik az adatmodellt nézi, a másik a meglévő függőségeket, a harmadik a hasonló, korábbi megoldásokat. A cél nem a megoldás, hanem egy alapos, több nézőpontú helyzetkép.
2
Tervező ügynök (High Planning). A feltárások eredményéből egy erős, dedikált tervező ügynök összerakja a tervet. Ő látja egyben az összes nézőpontot, eldönti a lépések sorrendjét, és felbontja a munkát olyan darabokra, amelyek egymástól függetlenül elvégezhetők.
3
Végrehajtó ügynökök (Implement) külön worktree-ben. A terv darabjait több végrehajtó ügynök kapja meg, és párhuzamosan dolgoznak rajtuk. Mindegyik a kódbázis saját, izolált másolatán, egy külön worktree-ben, így egyszerre nyúlhatnak a fájlokhoz anélkül, hogy egymás munkájába gázolnának.
4
Összefésülés (Merge). Amikor a párhuzamos szálak elkészültek, egy lépés egyesíti a részeket egyetlen közös állapotba. Itt derül ki, illeszkednek-e a darabok, és itt kezelhető, ha két szál mégis ugyanahhoz a ponthoz nyúlt.
5
Review ügynök. Az összefésült eredményt egy független ügynök nézi át, szándékosan kritikus, adversariális szemmel. Nem az a dolga, hogy megdicsérje a munkát, hanem hogy megtalálja benne a gyenge pontot, mielőtt bárki más látná.
6
Kimenet (PR). Ha a review átengedte, az eredmény kész, átadható munkacsomaggá áll össze, jellemzően egy pull requestté. Innen már ember veszi át a fonalat, és lát egy letisztult, előszűrt eredményt, nem egy nyers vázlatot.

Az előny

Miért megbízhatóbb, mint egyetlen ügynök

A minta ereje nem az egyes ügynökökben van, hanem a felosztásban. Négy külön ok teszi megbízhatóbbá, mint a mindent egyben elvégző magányos ügynököt.

Párhuzamosság

A munka egyszerre több szálon halad.

A feltárás és a végrehajtás párhuzamosítható részei nem egymás után, hanem egyidejűleg futnak. Ez érdemben gyorsítja a folyamatot, mert a teljes idő a leghosszabb szálhoz közelít, nem az összes lépés összegéhez.

Több szög a feltárásban

A helyzetkép alaposabb, mert több irányból készül.

Egyetlen ügynök egy fő szálon vizsgálja a feladatot, és könnyen elsiklik egy fontos részlet fölött. Ha viszont több ügynök más-más nézőpontból térképez fel, a vakfoltok nagy része már a tervezés előtt kiderül.

Izolált worktree

A párhuzamos munkák nem ütköznek.

Mivel minden végrehajtó a saját izolált másolatán dolgozik, egyszerre nyúlhatnak a kódhoz anélkül, hogy felülírnák egymást. Az ütközés kezelése egyetlen jól látható pontra, az összefésülésre korlátozódik, ahelyett hogy végig ott lebegne a folyamat fölött.

Független review

Az ellenőrzést nem az végzi, aki a munkát írta.

A saját megoldását mindenki elfogultan nézi. Egy külön, kritikus szemű review ügynök épp azt keresi, ami a végrehajtónak jónak tűnt, de nem az. Ez a második pár szem szűri ki a hibát, mielőtt emberi kézbe kerülne.


Egy konkrét példa

Így néz ki egy fejlesztőcsapatnál

Vegyünk egy elképzelt magyar céget, a Rendelgo nevű webshop csapatát. A feladat, hogy lecseréljék a régi fizetési modult egy újra, és közben átírják a pénztár folyamatot. Ez épp az a fajta nagy, több fájlt érintő munka, amelyen egyetlen ügynök könnyen elveszik.

Először három feltáró ügynök indul. Az egyik feltérképezi, hol hívja a kód a jelenlegi fizetési szolgáltatót, a másik a pénztár felület logikáját nézi át, a harmadik pedig azt, milyen adatokat vár és ad vissza az új szolgáltató. A tervező ügynök ebből a három képből rakja össze a haladási tervet, és három, egymástól független darabra bontja a munkát. Az egyik darab a szolgáltató illesztése, a másik a pénztár felület, a harmadik a rendelés visszaigazolása.

A három végrehajtó ügynök ezután párhuzamosan dolgozik, mindegyik a saját worktree-ben, így nem gázolnak egymás fájljaiba. Amikor mind elkészült, az összefésülés egyesíti a három szálat, és kiderül, tisztán illeszkednek-e. Végül a review ügynök adversariálisan átnézi a teljes eredményt, keresi az elrontott hibakezelést és a kihagyott peremeseteket. Csak ha ezen is átment, akkor áll össze a PR, amit a csapat fejlesztője már előszűrt, letisztult formában kap kézhez.


Döntés

Mikor éri meg, és mikor nem

Ez a minta erős, de nem ingyen van. Több ügynök koordinálása magával hozza a felbontás, az összefésülés és az ellenőrzés többletmunkáját. Egy apró feladatnál ez a többlet nagyobb, mint a nyereség, ezért érdemes tudatosan eldönteni, mikor nyúlunk hozzá.

A feladat jellege Éri meg a multi-agent minta?
Nagy feladat, amely tisztán felbontható független részekre Igen, ez az ideális eset
Több nézőpontú feltárást kíván, mert nagy a kódbázis Igen, a párhuzamos feltárás sokat ad
Magas a tét, egy elnézett hiba drága Igen, a független review megéri
Kicsi, egyszerű, néhány perces módosítás Nem, egyetlen ügynök gyorsabb
A részek szorosan összefonódnak, nem bonthatók szét Nem, a felbontás több kárt okoz, mint hasznot

A vezérelv egyszerű. Ha a feladat szétszedhető olyan darabokra, amelyeken egyszerre lehet dolgozni, és ha a hiba ára magas, a minta bőven megtérül. Ha viszont a munka kicsi vagy egyben tartandó, a sok ügynök csak lassít.

Összefoglalva. A multi-agent orchestration egy nagy feladatot szerepekre bont. Több feltáró párhuzamosan térképez, egy erős tervező összerakja a tervet, több végrehajtó dolgozik külön worktree-ben, az összefésült eredményt egy független review nézi át, végül PR lesz belőle. A párhuzamosság gyorsít, a több szög alaposabbá tesz, az izolált worktree megelőzi az ütközést, a független review pedig kiszűri a hibát. A minta nagy, felbontható feladaton téríti meg magát, egy apró módosításnál nem.

KD Academy

Multi-agent munkafolyamatok kurzus

Ha ezt a mintát a saját munkádban is fel akarod építeni, a KD Academy multi-agent workflows kurzusa lépésről lépésre végigveszi az orchestrator-worker architektúrát, a feladatlebontást, a subagentek tervezését és a termelési megbízhatóságot.

Irány a kurzus →

Kalmár Dániel
Kalmár Dániel AI Transformation Consultant LinkedIn profil →