Nagy feladat delegálása a Claude Code-ban beágyazott alügynökökkel

Mi változott a Claude Code v2.1.172-ben?#

Ha az elmúlt hónapokban bármit olvastál a Claude Code AI-ügynökeiről, biztosan találkoztál ugyanazzal a mondattal. Benne van a hivatalos dokumentációban, az alügynökökről szóló útmutatómban, és minden versenytárselemzésben. Így hangzik: „egy alügynök nem indíthat másik alügynököt”. 2026. június 11-én ez a mondat még mindig három különböző helyen szerepel a code.claude.com/docs/en/sub-agents oldalon. Az Anthropic egyszerűen még nem frissítette a dokumentációt.

Június 10-én, 20:44 UTC-kor megjelent a Claude Code v2.1.172 a GitHub Releases oldalon. A fő changelog-bejegyzés egyetlen sor volt:

Ugyanez a kiadás egy csak beágyazás esetén előforduló hibát is kijavított: egy háttérben futó alügynök aktívként maradt kiemelve az ügynökpanelen, miután az általa elindított beágyazott alügynököt már leállították.

Ritka eset, hogy a hivatalos dokumentáció még ellentmond a kiadott verziónak. A következőkben elmagyarázom, miben különbözik a beágyazás a párhuzamos alügynököktől, mit jelent az „5-ös mélység”, és melyik az a három helyzet, ahol ma valóban hasznos.

Miben különböznek a beágyazott alügynökök a párhuzamos és a soros alügynököktől?#

Sokáig próbálgattam kézzel ezt a három megközelítést. Így gondolok rájuk: a delegálásnak három dimenziója van. Szélesség, hosszúság és mélység. Mindegyik más problémát old meg.

Szélesség — párhuzamos alügynökök. A fő csevegés N egymástól független alügynököt indít ugyanazon a szinten. Mindegyik szűk feladatot kap, saját, elkülönített ablakában dolgozik, és csak az eredményt adja vissza. A szélesség a sebességet szolgálja: 5 párhuzamosan dolgozó alügynök annyi idő alatt végez, amennyi alatt egyetlen alügynök sorban elvégezné ugyanazt a munkát. Erről a modellről írtam a worktree-ket használó párhuzamos alügynökökről szóló útmutatómban.

Hosszúság — alügynöklánc. A dolgozik, átadja az eredményt B-nek, B dolgozik, majd átadja C-nek. Mindegyik az előző bemenetét látja. A hosszúság a sorrendet határozza meg: B nem kezdhet addig, amíg meg nem kapta az adatokat A-tól. Klasszikus példa: először egy kutató alügynök összegyűjti a forrásokat, aztán egy szerkesztő alügynök cikket ír ezek alapján, végül pedig egy tényellenőrző alügynök ellenőrzi a cikket. Ez egy lapos sorozat; a fő csevegés tartja kézben a teljes történetet.

Mélység — beágyazott alügynökök. A elindítja B-t, B elindítja C-t, C pedig D-t. Minden gyermek a szülőjén belül, saját elkülönített ablakban dolgozik, és csak az eredményt adja vissza a szülőjének. A fő csevegés nem látja, mi történik a gyermekeknél, unokáknál és dédunokáknál. Ez az újdonság a v2.1.172-ben.

A fő félreértés az, hogy sokan azt gondolják, az 5-ös mélység azt jelenti: „egyszerre 5 alügynököt indíthatsz”. Ez nem így van. A mélység a fa függőleges szintje, nem az egyidejű gyermekek száma. Minden szinten lehet egy alügynök vagy száz. Az 5-ös mélység azt jelenti, hogy a delegálási lánc 5 lépéssel lejjebb mehet: fő csevegés → unoka-1 → unoka-2 → unoka-3 → unoka-4 → unoka-5. És minden szinten lehetnek elágazások.

A 2.1.172-es verzió eltávolította azt a szabályt, amely megtiltotta, hogy egy alügynök másik alügynököt indítson.

Ha a sebesség a cél, szélességre van szükséged. Ha szigorú végrehajtási sorrend kell, hosszúságra. A mélység pontosan egy esetben hasznos: ha valamelyik feladatod tartalmaz egy zajos részfeladatot (15 webes kérés, naplók bejárása, egy tucat fájl elolvasása), és nem akarod, hogy ez a zaj elárassza a főablakot.

Mit jelent a gyakorlatban az „5 szint mélység”?#

Fontos, hogy őszinte legyek. Fél napot töltöttem a dokumentáció és a közösségi elemzések átnézésével, hogy kiderítsem: az Anthropic nem adott pontos meghatározást. Ezt kell tudnod.

Ez korlát, nem beállítás.

A korlát a szerveroldalon van beépítve. A v2.1.172-es kliens visszafejtése során nem találtak MAX_DEPTH konstansot. Ez azt jelenti, hogy az ellenőrzés valahol az Anthropic API-ban történik, nem a számítógépeden. Nem állíthatod be a --max-depth 7 értéket, hogy mélyebb legyen a fa. A --max-depth 2 értékkel sem állíthatsz be alacsonyabb, biztonságosabb korlátot. Az egyetlen vezérlési lehetőséged az előlapban megadott Agent(agent_type) engedélyezési lista — ez viszont a gyermekügynökök típusait, nem a mélységet korlátozza.

Az Anthropic nem határozta meg pontosan az „5” jelentését. Ez a második fontos szempont:

Az Anthropic nem határozta meg pontosan az „5” jelentését. A hivatalos források nem részletezik, hogy a depth=5 öt, a gyökér alatti szintet jelent-e, vagy összesen öt ügynököt, a gyökeret is beleértve.

A külső integrációk egyelőre eltérően értelmezik ezt. A ruvnet/ruflo projekt ADR-147-es döntése abból indul ki, hogy „5 gyermekszint a gyökér alatt = 6 ügynök a láncban”. A kísérleteimben én is ezt a konvenciót használom: a fő csevegés a 0. szint, közvetlen gyermekei az 1. szinten vannak, és így tovább az 5. szintig. Ez azonban nincs rögzítve a nyilvános dokumentációban.

A korlát már aktív, nincs szükség kapcsolókra. Nem kell semmit bekapcsolnod. A Claude Code v2.1.172-es verzióra frissítése után az Agent értéket felveheted egy gyermekügynök tools mezőjébe, és így az elindíthat egy másik alügynököt. A lényeg, hogy a szülőügynöknek engedélyeznie kell ezt (tools: Agent(...)).

Ma hogyan delegálsz: szélességgel, hosszúsággal vagy mélységgel?#

Nézd át az utolsó 5 utasításodat. Hányszor történt meg, hogy elkezdődött egy feladat, Claude fájlokban kezdett keresni, 10 webes kérést indított, egy egész falnyi naplót töltött be a kontextusba, majd 20 perccel később rájöttél, hogy megtelt az ablak? A végső válasz már szűkös tokenkeretből készül, mert a kontextus 70 százalékát a köztes adathalmazok emésztették fel.

Ez az a helyzet, amikor mélységre van szükséged. Nem párhuzamosságra, nem láncra — mélységre. A fő csevegésnek a „kutatást” egyetlen alügynökre kell bíznia, amely aztán a saját gyermekügynökeit indítja el konkrét webes keresésekhez, fájlolvasáshoz és grep-keresésekhez. A gyermekek csak tömörített következtetéseket adnak vissza. Egy unoka ezt mondja a szülőjének: „megtaláltam, megerősítve” vagy „nem találtam meg, az ok: X”. A szülő egyetlen összefoglalóvá állítja össze az eredményeket, és visszaküldi neked. A fő csevegés tiszta marad.

Június 9. előtt ezt kézzel utánoztam. Megnyitottam a Claude Code egy másik példányát, bemásoltam a „kutass utána” utasítást, lefuttattam, majd kézzel átvittem az eredményt a főablakba. A v2.1.172-vel közvetlenül az orkesztrátor rendszerutasításában írhatod le ezt — Claude maga építi fel a fát.

Melyik az a 3 helyzet, amikor valóban hasznosak a beágyazott alügynökök?#

1. helyzet: Mély kutatás tényellenőrzéssel

Tegyük fel, hogy egy cikkhez vagy értékesítési ajánlathoz gyűjtesz anyagokat. Először 5–10 állítást kell összegyűjtened nyilvános forrásokból, majd mindegyiket ellenőrizned kell: megkeresni az eredeti forrást, meggyőződni az idézet pontosságáról, és kiszámítani a tényleges értékeket.

A v2.1.172 előtt két lehetőséged volt. Vagy egyetlen alügynökkel végezted el az egészet, amely 30 webes kérést dolgozott fel, és mindent a saját kontextusába zsúfolt. Vagy kézzel szétosztottad a munkát: egy utasításban összegyűjtötted az állításokat, majd végigmentél rajtuk, mindegyikhez külön alügynököt indítva. A fő csevegést köztes listák falai töltötték meg.

Az alábbi receptben a fő csevegés a research-orchestrator ügynöknek delegál (1. szint). Az orkesztrátor maga gyűjti ki az állításokat, mindegyiket a fact-verifier ügynöknek küldi (2. szint), és az ellenőrök a web-deep-search ügynöknek adnak célzott kereséseket (3. szint). A fő csevegés csak az ellenőrzött állítások tömbjét kapja meg a forrásokkal együtt. Minden más a gyermekablakokban marad, és sosem kerül be a kontextusodba.

2. helyzet: Egy nagy kódtár elemzése

Kapsz egy 200 fájlból álló projektet. Meg kell értened az architektúrát, meg kell találnod a fő modulokat, és fel kell mérned a technikai adósságot. Ha kézzel végrehajtasz egy Glob műveletet és egy tucat Read hívást, 10 perc alatt megtelik az ablak.

A mélység ezt a problémát így oldja meg: a fő csevegés elindít egy „architect” alügynököt. Az architect belsőleg három gyermekügynököt indít: az egyik megvizsgálja a könyvtárstruktúrát (Glob-ot futtat és összefoglalja az eredményt), a második elolvas 5 fontos konfigurációs fájlt, a harmadik pedig grep segítségével megkeresi a fő mintákat. Mindegyik tömör összefoglalót küld az architectnek. Az architect összeállítja a képet, és egy fél képernyőnyi végső jelentést ad a fő csevegésnek. Így áttekintést kapsz a projektről anélkül, hogy az összes fájl cat-kimenetének fala elárasztaná a kontextust.

3. helyzet: Végponttól végpontig tartó függőségek elemzése

Módosítasz egy adatbázissémát, egy API-szerződést vagy egy megosztott konfigurációs fájlt. Tudnod kell, hol jelennek majd meg a változás hatásai. Ez a feladat meríti ki a leggyorsabban a kontextust, mert sok függőséget kell ellenőrizni a forráskódban.

A mélység használatával a fő csevegés elindít egy „impact-analyzer” ügynököt (1. szint). Ez minden érintett fájlhoz elindít egy dependency-tracer ügynököt (2. szint). Mindegyik tracer belsőleg elindít egy consumer-finder ügynököt (3. szint), amely grep segítségével megkeresi a kódbázisban az adott függőség használóit. Végül mindegyik csak a lényeget küldi vissza: „ez a három hely fog elromlani”. A fő csevegés az érintett fájlokat és a hatásokat összefoglaló táblázatot állít össze anélkül, hogy látná a grep-eredményeket.

Hogyan állítsunk be beágyazott alügynököket 10 perc alatt?#

1. lépés: Győződj meg róla, hogy a v2.1.172-es vagy újabb verziót használod.

claude --version

Ha régebbi, frissítsd. A kiadás fő funkcióját egyetlen changelog-sor írja le: „Az alügynökök most már saját alügynököket indíthatnak, legfeljebb 5 szint mélységig” (a teljes szöveg).

2. lépés: Hozz létre egy gyermekeket indítani képes szülőügynököt.

Fájl: .claude/agents/research-orchestrator.md:

---
name: research-orchestrator
description: Kutatás mélyreható delegálása tényellenőrzéssel
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---

Te vagy a kutatás orkesztrátora. Ha kapsz egy témát:
1. Olvasd el a kapott anyagot, vagy töltsd le a megadott nyilvános forrás-URL-eket.
   Magad gyűjts ki legfeljebb 5 konkrét állítást. Mindegyiknél rögzítsd az állítás szövegét,
   a forrás URL-jét vagy fájlját és a pontos alátámasztó részletet.
   Ha nem kaptál forrásanyagot, delegálás előtt kérd be.
2. Minden állításhoz hívd meg a fact-verifiert — ő maga indítja el
   a saját gyermek-alügynökeit a webes kereséshez és az egyeztetéshez.
3. A fact-verifier csak a végső ítéleteket adja vissza neked —
   ne töltsd be a köztes kimeneteket a saját kontextusodba.

A zárójelentés csak egy tömb: { claim, sources[], confidence }.

A tools sor csak a fact-verifier gyermektípust engedélyezi. Az állítások kigyűjtése az orkesztrátor saját első lépése, ezért nincs szükség nem definiált claim-extractor fájlra. A típusengedélylista a meghívható típust korlátozza, nem annak indítási darabszámát. A receptet tartsd legfeljebb öt kigyűjtött állításnál.

3. lépés: Hozz létre egy saját unokákat indítani képes gyermekügynököt.

Fájl: .claude/agents/fact-verifier.md:

---
name: fact-verifier
description: Állítást ellenőriz gyermek webes keresésekkel
tools: Agent(web-deep-search), Read
model: sonnet
---

Te vagy a tényellenőrző. Ha kapsz egy állítást:
1. Fogalmazz meg 2-3 keresési lekérdezést.
2. Mindegyikhez indítsd el a web-deep-search-öt — ő önállóan lefuttatja
   a WebSearch-öt és a WebFetch-et, és ellenőrzött idézeteket ad vissza.
3. Állíts össze egyetlen ítéletet: { claim, sources[], confidence }.

Látod a fontos részt? A tools mezőben ismét az Agent(web-deep-search) szerepel. Ez azt jelenti, hogy a tényellenőrző (a fánk 2. szintjén) maga is elindíthat egy újabb alügynököt (a 3. szinten). Korábban ennek a sornak nem volt hatása — a dokumentáció még mindig ezt írja:

A v2.1.172-vel ez a sor elavult. A szintaxis ugyanaz, de most már a fa bármely mélységében működik.

4. lépés: Hozz létre egy unokaügynököt.

Fájl: .claude/agents/web-deep-search.md:

---
name: web-deep-search
description: Webes keresést végez és idézeteket ad vissza
tools: WebSearch, WebFetch
model: haiku
---

Kaptál egy keresési lekérdezést. Futtasd a WebSearch-öt, válaszd ki a 3
legrelevánsabb URL-t, és a WebFetch-csel nyerd ki az állítás szó szerinti
megerősítéseit. Adj vissza egy tömböt: { url, snippet, supports_claim: yes|no }.

Az unokaügynök tools mezőjében nincs Agent, tehát nem indít további alügynököket a fában lejjebb.

5. lépés: Futtasd az orkesztrátort.

claude --agent research-orchestrator

Ezután add meg a forrásszöveget vagy a nyilvános forrás-URL-eket a csevegésben: „Gyűjts ki és ellenőrizz legfeljebb 5 konkrét állítást ezekből a forrásokból; állításokat, forrásokat és bizonyosságot adj vissza.” A --agent research-orchestrator használatakor maga a munkamenet az orkesztrátor; ellenőr- és keresőgyermekei két további delegált szintet adnak alá. Ha egy szokásos fő munkamenet delegál az orkesztrátornak, három delegált szint van a fő munkamenet alatt.

Melyik az az 5 rossz minta, amely tokeneket pazarol és megsemmisíti a megfigyelhetőséget?#

1. rossz minta: A feladat elfér egy ablakban.

Ha egyetlen alügynök zaj nélkül el tudja végezni, ne adj hozzá további szinteket: a beágyazás csak költséget és késleltetést okoz, minden haszon nélkül.

2. rossz minta: Sebességet akarsz, nem elkülönítést.

Ha sebességre van szükséged, párhuzamosságot használj, ne mélységet. Indíts el egymás mellett 5 alügynököt ugyanazon a szinten ahelyett, hogy láncot építenél. A mélység célja a zajos előkészítő munka gyermekablakba helyezése, nem a gyorsítás.

3. rossz minta: A munka eleve sekély.

„Keresd meg ezt a fájlt, és mutasd meg” egy kétlépéses kérés; nincs szüksége háromszintű hierarchiára. A beágyazás akkor éri meg, ha a feladat zajos részfeladatot tartalmaz. Ha nincs zaj, ne adj hozzá alügynököket.

4. rossz minta: Homályos utasítások az első szinten.

Ez a legveszélyesebb helyzet. Ha homályos utasítást adsz az 1. szintű orkesztrátornak, a homályosság megsokszorozódik. Egy homályos, 1. szintű utasításból 4 homályos utasítás lesz a 2. szinten, és 16 a 3. szinten. Mire az unokaügynökök munkához látnak, már azt sem tudják, mit kell keresniük.

5. rossz minta: A költség geometriai növekedése.

A fő gazdasági érv.

Egy durva számítás: egy 3 mélységű lánc, ahol minden szinten 3 ág indul, 27 alügynököt jelent. Ez legalább 27-szer annyi token, mint egy egyszerű kérésnél. A Claude Pro csomagban ez néhány óra alatt elégeti a napi keretet. Max csomaggal egy nap alatt egy heti keretet használsz fel.

Bónusz rossz minta (saját tapasztalat): „50 ügynök értelmetlen munkát végez.”

Amikor mások projektjeit nézem, gyakran ezt látom: „50 ügynököm dolgozik.” Megkérdezem, mit csinálnak. És ez az 50 ügynök értelmetlen munkát végez. Felesleges kimenetek, nyers összefoglalók, ismétlések és naplófalak halmait gyártják. Mindegyik csinál valami „általában hasznosat”, az eredmény pedig egy kontextusba fulladó munkamenet és egy kisvállalatéhoz hasonló tokenköltség. Az 5-ös mélység nem oldja meg ezt a problémát — súlyosbítja. Ha már az 1. szinten sem világos, ki mit csinál, az 5-ös mélység a zavar öt szintjét jelenti.

Mielőtt bármilyen alügynököt elindítasz, fél perc alatt válaszolj erre a 4 kérdésre:

• Pontosan mit csinál (egy mondatban)?
• Melyik fájlokhoz nyúl hozzá?
• Mit ad vissza a szülőjének?
• Ki ellenőrzi?

Ha 30 másodpercen belül nem tudsz válaszolni, ennek az alügynöknek nem kellene léteznie. Ezt a szabályt külön is elmagyaráztam a párhuzamos alügynökökről szóló útmutatómban.

Miért jelent 5 szintnyi hallucinációt a kontextustervezés nélküli beágyazás?#

Itt szokták sokan megkérdezni: „Frissítettem a Claude Code-ot, hozzáadtam az Agentet a tools mezőhöz, a fa felépül — de a végső válasz még mindig pontatlan. Miért?”

A válasz egyszerű. A Claude Code minden alügynöke a nulláról indul. A hivatalos dokumentáció szerint:

Az 1. szinten ez még kezelhető: az orkesztrátor rövid feladatleírást ad a gyermekének. A 3. szinten viszont az unoka a szülőjétől kap delegálási üzenetet, aki szintén csak egy delegálási üzenetet kapott. Mindegyik csak egy kicsit ad tovább. Az 5. szinten olyan alügynököd van, amelynek ablakában csak annyi áll: „ellenőrizd az X állítást”, semmi más. Nem tudja, melyik projekten dolgozik, milyen feladatot old meg, vagy mire kell összpontosítania.

A CLAUDE.md nélkül az ötödik szintű unokaügynök olyan, mint egy alkalmazott, aki életében először érkezik az irodába, mindenféle eligazítás nélkül. Csinál majd valamit, mert kapott feladatot. De az nem az lesz, amire a projektnek szüksége van.

Mi változott még a v2.1.172-ben a beágyazás mellett?#

Nyisd meg a teljes v2.1.172-es changelogot, és látni fogod, hogy az egész kiadás az alügynökökről szól.

1. javítás. A háttérben futó alügynök már nem marad „beragadva” aktív állapotban az ügynökpanelen, miután az általa elindított beágyazott alügynököt leállították. Ez a hiba csak beágyazáskor fordulhat elő.

2. javítás. Az availableModels korlátozások mostantól az alügynökökre is érvényesek. Korábban, ha korlátoztad, hogy a csapat mely modelleket használhatja (például pénzmegtakarítás céljából megtiltottad az opus használatát), az alügynökök saját konfigurációjuk felülbírálásával megkerülhették a szabályt. A v2.1.172-ben a korlátozás mindenhol érvényes.

3. javítás. Az utasításelőzményekben a felfelé mutató nyíl mostantól az alügynök aktuális lapjának utasításait jeleníti meg, nem a főügynökét. Megfigyelhetőségi finomítás.

4. javítás. Csökkent az üresjárati CPU-használat: a /goal jelző üresjáratban már nem rajzolja újra 5 Hz-es frekvenciával a terminált, a felület pedig ritkábban frissül, miközben párhuzamos alügynökök dolgoznak.

Megjegyzem, hogy mind a négy javítás az alügynököket érinti. Ez azt jelenti, hogy az Anthropic a beágyazáshoz szükséges teljes infrastruktúrát kiadta, nem csupán egyetlen sort a changelogban. A közzététel előtt egy ideje már használták a beágyazást az Anthropicnál.

Ellenőrzőlista: mikor segít és mikor árt a beágyazás?#

Használj beágyazást, ha:

• A feladat olyan részfeladatot tartalmaz, amely sok webes kérést, grep-keresést vagy fájlolvasást igényel.
• Elfogadható, ha elveszíted ezt a részfeladatot (ha az unokaügynök azt mondja, hogy „nem találtam semmit”, az orkesztrátor folytathatja).
• Nincs szükséged köztes eredményekre a főablakban.
• Van CLAUDE.md fájlod és összeállított projektkontextusod, amelyre az alügynök támaszkodhat.
• Világosan meg tudod határozni, hogy az egyes szintek mit adnak vissza (bemenet, kimenet, formátum).
• Max csomagot használsz, vagy van tartalékod ×27-nyi tokenre.

Ne használj beágyazást, ha:

• Egyetlen alügynök is képes zaj nélkül megoldani a feladatot.
• Köztes eredményekre van szükséged a főablakban (ez azt jelenti, hogy párhuzamosságot szeretnél).
• A projektben nincs CLAUDE.md, vagy kevés üzleti kontextust tartalmaz.
• Az 1. szintű utasítások homályosak (a homályosság exponenciálisan megsokszorozódik a fa mélyén).
• Sebességre van szükséged — hasonló eredmény esetén a párhuzamosság gyorsabb a mélységnél.
• Pro csomagot használsz és egész nap dolgozol — néhány óra alatt elhasználod a keretet.

További anyagok az Ailoot oldalán érhetők el.