Kako delegirati veliko nalogo v Claude Code z uporabo ugnezdenih podagentov

Kaj se je spremenilo v Claude Code v2.1.172?#

Če si v zadnjih mesecih bral karkoli o agentih umetne inteligence v Claude Code, si naletel na isti stavek. Pojavlja se v uradni dokumentaciji, v mojem vodniku o podagentih in v vsaki analizi konkurence. Glasi se: »podagent ne more ustvariti drugega podagenta«. Na dan 11. junija 2026 je ta vrstica še vedno na treh različnih mestih na strani code.claude.com/docs/en/sub-agents. Anthropic je preprosto še ni posodobil.

10. junija ob 20:44 UTC se je Claude Code v2.1.172 pojavil na GitHub Releases. Glavni element dnevnika sprememb je bila ena vrstica:

Ista izdaja je odpravila tudi napako, ki se je lahko pojavila samo pri gnezdenju: podagent v ozadju je ostal označen kot aktiven na plošči agentov, čeprav je bil ugnezdeni podagent, ki ga je zagnal, že ustavljen.

Redko se zgodi, da je uradna dokumentacija še vedno v nasprotju z izdano različico. V nadaljevanju bom pojasnil, v čem se gnezdenje razlikuje od vzporednih podagentov, kaj pomeni »globina 5« in kateri so trije scenariji, v katerih je danes resnično uporabno.

Kako se ugnezdeni podagenti razlikujejo od vzporednih in zaporednih?#

Dolgo sem ročno preizkušal te tri pristope in razmišljam o njih takole: delegiranje ima tri razsežnosti. Širino, dolžino in globino. Vsaka rešuje drugačen problem.

Širina — vzporedni podagenti. Glavni klepet zažene N neodvisnih podagentov na isti ravni. Vsak dobi ozko nalogo, dela v svojem izoliranem oknu in vrne samo rezultat. Širina rešuje problem hitrosti: 5 podagentov, ki delajo vzporedno, konča v času, ki bi ga en sam potreboval za isto delo po korakih. Ta model sem predstavil v vodniku o vzporednih podagentih z uporabo worktreejev.

Dolžina — veriga podagentov. A dela in preda rezultat B-ju, B dela in ga preda C-ju. Vsak vidi vhod prejšnjega. Dolžina vzpostavlja vrstni red: B ne more začeti, dokler od A ne dobi podatkov. Klasičen primer: najprej raziskovalni podagent zbere vire, nato uredniški podagent na njihovi podlagi napiše članek, za njim pa podagent za preverjanje dejstev članek preveri. To je ravno zaporedje; glavni klepet ohranja celotno zgodbo.

Globina — ugnezdeni podagenti. A zažene B, B zažene C, C pa D. Vsak otrok dela znotraj svojega nadrejenega, v lastnem izoliranem oknu, in nadrejenemu vrne samo rezultat. Glavni klepet ne vidi ničesar od tega, kar se dogaja pri otrocih, vnukih in pravnukih. To je novost v v2.1.172.

Glavni nesporazum je, da ljudje mislijo, da globina 5 pomeni »hkrati lahko zaženeš 5 podagentov«. To ne drži. Globina je navpična raven v drevesu, ne število sočasnih otrok. Na vsaki ravni je lahko en podagent ali sto. Globina 5 pomeni, da se veriga delegiranja lahko spusti za 5 korakov: glavni klepet → vnuk-1 → vnuk-2 → vnuk-3 → vnuk-4 → vnuk-5. Na vsaki ravni se lahko tudi razveji.

Različica 2.1.172 je odpravila pravilo, da podagent ne more ustvariti drugega podagenta.

Če ti gre za hitrost, potrebuješ širino. Če imaš strog vrstni red izvajanja, potrebuješ dolžino. Globina je uporabna natanko v enem primeru: ko ena od tvojih nalog vsebuje hrupno podnalogo (15 spletnih zahtev, pregledovanje dnevnikov, branje ducata datotek) in nočeš, da ta hrup preplavi tvoje glavno okno.

Kaj v praksi pomeni »globina 5 ravni«?#

Tu je pomembno, da sem iskren. Pol dneva sem porabil za pregled dokumentacije in analiz skupnosti, da bi ugotovil, da Anthropic ni podal natančne opredelitve. Vedeti moraš naslednje.

Gre za omejitev, ne za nastavitev.

Omejitev je vgrajena na strani strežnika. Pri obratnem inženiringu odjemalca v2.1.172 niso našli konstante MAX_DEPTH. To pomeni, da se preverjanje zgodi nekje v Anthropic API-ju, ne lokalno na tvojem računalniku. Z nastavitvijo --max-depth 7 ne moreš poglobiti drevesa. Prav tako z --max-depth 2 ne moreš določiti nižje, varnejše omejitve. Edini nadzor, ki ga imaš, je seznam dovoljenih Agent(agent_type) v sprednji metapodatkovni glavi — vendar ta omejuje vrste podrejenih agentov, ne globine.

Anthropic ni natančno opredelil, kaj pomeni »5«. To je druga pomembna točka:

Anthropic ni natančno opredelil, kaj pomeni »5«. Uradni viri ne določajo, ali depth=5 pomeni pet ravni pod korenom ali skupno pet agentov, vključno s korenom.

Integracije tretjih oseb to za zdaj razlagajo različno. ADR-147 v projektu ruvnet/ruflo predpostavlja »5 podrejenih ravni pod korenom = 6 agentov v verigi«. V svojih poskusih uporabljam isto konvencijo: glavni klepet je raven 0, njegovi neposredni otroci so raven 1 in tako naprej do ravni 5. Toda to ni zapisano v javni dokumentaciji.

Omejitev je že omogočena; zastavice niso potrebne. Ničesar ti ni treba aktivirati. Po posodobitvi Claude Code na v2.1.172 lahko dodaš Agent v tools podrejenega agenta, ta pa bo zagnal še enega podagenta. Pomembno je, da mora nadrejeni agent to dovoliti (tools: Agent(...)).

Kje se tvoje delegiranje dogaja danes: po širini, dolžini ali globini?#

Preglej zadnjih 5 pozivov. Kako pogosto si naredil tole: začne se naloga, Claude začne iskati po datotekah, pošlje 10 spletnih zahtev, v kontekst prilepi cel zid dnevnikov — 20 minut pozneje pa ugotoviš, da je okno polno. Končni odgovor nastaja z bornim proračunom žetonov, ker je 70 odstotkov konteksta porabilo vmesno izpisovanje.

To je primer, ko potrebuješ globino. Ne vzporednosti, ne verige — globino. Glavni klepet naj delegira »raziskavo« enemu podagentu, ta pa naj nato od znotraj zažene svoje otroke za posamezna spletna iskanja, branje datotek in iskanje z grep. Otroci vrnejo samo zgoščene ugotovitve. Pravnuk nadrejenemu pove »našel, potrjeno« ali »nisem našel, razlog X«. Nadrejeni to sestavi v en sam povzetek in ti ga vrne. Glavni klepet ostane pregleden.

Pred 9. junijem sem to posnemal ročno. Odprl sem drugi primerek Claude Code, kopiral poziv »raziskuj to«, ga zagnal in nato ročno prenesel rezultat nazaj v glavno okno. To postavitev sem podrobno opisal v vodniku o delegiranju programiranja številnim agentom umetne inteligence. Z v2.1.172 lahko to neposredno opišeš v sistemskem pozivu orkestratorja — Claude bo drevo zgradil sam.

V katerih 3 scenarijih so ugnezdeni podagenti dejansko uporabni?#

Scenarij 1. Poglobljeno raziskovanje s preverjanjem dejstev

Recimo, da zbiraš gradivo za članek ali prodajni predlog. Najprej moraš iz javnih virov pridobiti 5–10 trditev, nato pa preveriti vsako posebej — poiskati izvirni vir, se prepričati, da je navedek natančen, in izračunati dejanske številke.

Pred v2.1.172 si imel dve možnosti. Ali si vse opravil z enim podagentom, ki je prečesal 30 spletnih zahtev in si vse naložil v kontekst, ali pa si delo ročno razdelil: en poziv za pridobivanje trditev, nato pa zanka čez trditve, v kateri si za vsako zagnal ločen podagent. Glavni klepet bi se napolnil z zidovi vmesnih seznamov.

V spodnjem receptu glavni klepet nalogo preda research-orchestrator (raven 1). Orkestrator sam izlušči trditve, vsako pošlje fact-verifier (raven 2), vsak preverjevalec pa usmerjeno iskanje preda web-deep-search (raven 3). Glavni klepet prejme samo seznam preverjenih trditev z viri. Vse drugo ostane v otroških oknih in nikoli ne vstopi v tvoj kontekst.

Scenarij 2. Analiza velikega repozitorija

Dobil si projekt z 200 datotekami. Razumeti moraš arhitekturo, najti glavne module in oceniti tehnični dolg. Če ročno zaženeš Glob in ducat klicev Read, bo okno polno v 10 minutah.

Globina to reši takole: glavni klepet zažene podagenta »architect«. Ta znotraj zažene tri otroke — eden pregleda strukturo imenikov (zažene Glob in povzame ugotovitve), drugi prebere 5 ključnih konfiguracijskih datotek, tretji pa z grep poišče glavne vzorce. Vsak architectu vrne jedrnat povzetek. Architect sestavi celoto in glavnemu klepetu poda končno poročilo, dolgo približno polovico zaslona. Dobiš zemljevid projekta, ne da bi kontekst preplavil zid izpisa ukaza cat za vse datoteke.

Scenarij 3. Analiza odvisnosti od začetka do konca

Spreminjaš shemo zbirke podatkov, pogodbo API-ja ali skupno konfiguracijsko datoteko. Razumeti moraš, kje se bodo pokazale posledice. Ta naloga najhitreje izčrpa kontekst, ker je veliko odvisnosti in vsako je treba preveriti v izvorni kodi.

Z globino glavni klepet zažene »impact-analyzer« (raven 1). Ta za vsako prizadeto datoteko zažene enega dependency-tracer (raven 2). Vsak tracer znotraj zažene consumer-finder (raven 3), ki v kodni zbirki z grep poišče uporabnike te odvisnosti. Vsak nato vrne le bistvo: »te tri lokacije se bodo pokvarile«. Glavni klepet sestavi tabelo »prizadete datoteke → vpliv«, ne da bi poznal rezultate grep iskanja.

Kako v 10 minutah nastaviti ugnezdene podagente?#

1. korak. Prepričaj se, da uporabljaš v2.1.172 ali novejšo različico.

claude --version

Če je starejša, jo posodobi. Glavna funkcija izdaje je opisana v eni vrstici dnevnika sprememb: »Podagenti lahko zdaj ustvarijo svoje podagente do globine 5 ravni« (celotno besedilo).

2. korak. Ustvari nadrejenega agenta, ki lahko zažene otroke.

Datoteka .claude/agents/research-orchestrator.md:

---
name: research-orchestrator
description: Delegira raziskovanje s poglobljenim preverjanjem dejstev
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---

Ti si raziskovalni orkestrator. Ko prejmeš temo:
1. Preberi priloženo gradivo ali pridobi priložene javne URL-je virov.
   Sam izlušči do 5 konkretnih trditev. Za vsako zabeleži besedilo trditve,
   URL ali datoteko vira in točen podporni odlomek.
   Če gradivo ni priloženo, ga zahtevaj pred delegiranjem.
2. Za vsako trditev pokliči fact-verifier — sam ustvari
   svoje podrejene podagente za spletno iskanje in preverjanje.
3. fact-verifier ti vrne samo končne sodbe —
   v svoj kontekst ne nalagaj vmesnih izpisov.

Končno poročilo naj bo samo seznam { claim, sources[], confidence }.

Vrstica tools dovoljuje samo vrsto otroka fact-verifier. Izluščitev trditev je prvi korak samega orkestratorja, zato nedefinirana datoteka claim-extractor ni potrebna. Seznam dovoljenih vrst omeji, kateri otrok se sme klicati, ne pa števila njegovih zagonov. Recept ohrani omejen na največ pet izluščenih trditev.

3. korak. Ustvari podrejenega agenta, ki lahko sam ustvari pravnuke.

Datoteka .claude/agents/fact-verifier.md:

---
name: fact-verifier
description: Preverja trditve prek podrejenih spletnih iskanj
tools: Agent(web-deep-search), Read
model: sonnet
---

Ti si preverjevalec dejstev. Ko prejmeš trditev:
1. Sestavi 2-3 iskalne poizvedbe.
2. Za vsako zaženi web-deep-search — ta sam izvede
   WebSearch in WebFetch ter vrne preverjene izseke.
3. Sestavi eno sodbo: { claim, sources[], confidence }.

Vidiš ključni del? V tools je znova zapisano Agent(web-deep-search). To pomeni, da lahko preverjevalec dejstev (2. raven našega drevesa) sam zažene še enega podagenta (3. raven). Prej ta vrstica ni imela učinka — dokumentacija še vedno vsebuje stavek:

Z v2.1.172 je ta vrstica zastarela. Sintaksa je enaka, zdaj pa deluje na kateri koli globini drevesa.

4. korak. Ustvari pravnuka.

Datoteka .claude/agents/web-deep-search.md:

---
name: web-deep-search
description: Izvaja spletno iskanje in vrača izseke
tools: WebSearch, WebFetch
model: haiku
---

Prejel si iskalno poizvedbo. Izvedi WebSearch, izberi 3 najbolj
relevantne URL-je in z WebFetch pridobi dobesedne potrditve
trditve. Vrni seznam { url, snippet, supports_claim: yes|no }.

Pravnuk v tools nima Agent, zato ne zažene ničesar nižje v drevesu.

5. korak. Zaženi orkestrator.

claude --agent research-orchestrator

Nato v klepet priloži izvorno besedilo ali javne URL-je virov: »Iz teh virov izlušči in preveri do 5 konkretnih trditev; vrni trditve, vire in zanesljivost.« Z --agent research-orchestrator je orkestrator sama seja; njeni otroci za preverjanje in iskanje dodajo dve delegirani ravni pod njo. Če navadna glavna seja nalogo preda temu orkestratorju, so pod njo tri delegirane ravni.

Katerih 5 antipatternov zapravlja žetone in uničuje preglednost?#

Antipattern 1. Naloga gre v eno okno.

Če jo lahko en podagent opravi brez hrupa, ne dodajaj ravni.

Če lahko en podagent opravi nalogo brez hrupa, gnezdenje samo po nepotrebnem poveča stroške in zakasnitev.

Antipattern 2. Želiš si hitrosti, ne izolacije.

Če želiš hitrost, potrebuješ vzporednost, ne globine. Zaženi 5 podagentov vzporedno na isti ravni, namesto da gradiš verigo. Globina je namenjena prenosu hrupnega pripravljalnega dela v otroško okno, ne pospeševanju dela.

Antipattern 3. Delo je že po naravi plitvo.

»Poišči to datoteko in mi jo pokaži« je zahteva z dvema korakoma; ne potrebuje hierarhije s tremi ravnmi. Gnezdenje se splača, ko naloga vsebuje hrupno podnalogo. Če ni hrupa, ne dodajaj podagentov.

Antipattern 4. Nejasni pozivi na prvi ravni.

To je najnevarnejši scenarij. Če orkestratorju na ravni 1 daš nejasen poziv, se nejasnost pomnoži. En nejasen poziv na ravni 1 postane 4 nejasne pozive na ravni 2 in 16 na ravni 3. Ko začnejo delati vnuki, sploh ne vedo več, kaj iščejo.

Antipattern 5. Geometrijska rast stroškov.

Glavni ekonomski argument:

Gnezdenje poveča porabo žetonov, ta pa se z globino kopiči.

Groba računica: veriga z globino 3 in razvejanjem po 3 na vsaki ravni pomeni 27 podagentov. To je vsaj 27-krat več žetonov kot pri preprosti zahtevi. Pri Claudeovem paketu Pro ta računica v nekaj urah porabi dnevno omejitev. Če imaš paket Max, boš v enem dnevu porabil tedenski dodatek.

Dodatni antipattern (moja izkušnja): »50 agentov opravlja nesmiselno delo.«

Ko gledam projekte drugih ljudi, pogosto vidim tole: »Imam 50 agentov, ki delajo.« Vprašam, kaj počnejo. In teh 50 agentov opravlja nesmiselno delo. Ustvarjajo kupe nepotrebnih izpisov, množico surovih povzetkov, podvojene vsebine in stene dnevnikov. Vsak počne nekaj »na splošno koristnega«, rezultat pa je kontekst, ki se utaplja v informacijah, in račun za žetone, kakršnega bi imelo manjše podjetje. Globina 5 tega problema ne reši — še poslabša ga. Če že na ravni 1 ni jasno, kdo kaj počne, globina 5 pomeni pet ravni zmede.

Preden zaženeš katerega koli podagenta, v pol minute odgovori na 4 vprašanja:

• Kaj natančno počne (v enem stavku)?
• Katere datoteke spreminja?
• Kaj vrne nadrejenemu?
• Kdo to preveri?

Če v 30 sekundah ne moreš odgovoriti, ta podagent ne bi smel obstajati. To pravilo sem posebej pojasnil v vodniku o vzporednih podagentih.

Zakaj gnezdenje brez inženiringa konteksta pomeni 5 ravni halucinacij?#

Tu me ljudje pogosto vprašajo: »Posodobil sem Claude Code, dodal Agent v tools in drevo se gradi — zakaj je končni odgovor še vedno napačen?«

Odgovor je preprost. Vsak podagent v Claude Code začne znova. Uradna dokumentacija pravi:

Na ravni 1 je to obvladljivo: orkestrator otroku posreduje kratek opis naloge. Na ravni 3 pa pravnuk od nadrejenega prejme delegacijsko sporočilo, njegov nadrejeni pa je imel prav tako samo delegacijsko sporočilo. Vsak je posredoval le malo informacij. Na ravni 5 imaš podagenta, v čigar oknu piše »preveri trditev X«, nič drugega. Ne ve, v katerem projektu dela, katero nalogo rešuje ali na kaj naj se osredotoči.

Brez datoteke CLAUDE.md je pravnuk na peti ravni kot zaposleni, ki prvič v življenju pride v pisarno brez uvajanja. Nekaj bo naredil, ker je dobil nalogo. Toda ne bo naredil tistega, kar projekt potrebuje.

Kaj se je v v2.1.172 spremenilo poleg gnezdenja?#

Odpri celoten dnevnik sprememb v2.1.172 in videl boš, da se celotna izdaja vrti okoli podagentov.

Popravek 1. Podagent v ozadju po ustavitvi ugnezdenega podagenta, ki ga je zagnal, ne ostane več »zataknjen« kot aktiven na plošči agentov. Ta napaka se lahko pojavi samo pri gnezdenju.

Popravek 2. Omejitve availableModels zdaj veljajo tudi za podagente. Prej so podagenti lahko obšli pravilo z izjemo v lastni konfiguraciji, če si omejil, katere modele sme uporabljati ekipa (na primer prepovedal opus, da bi prihranil denar). Z v2.1.172 pravilo velja povsod.

Popravek 3. Puščica navzgor v zgodovini pozivov zdaj prikazuje pozive s trenutnega zavihka podagenta, ne glavnega agenta. Izboljšava preglednosti.

Popravek 4. Poraba procesorja v mirovanju je manjša: indikator /goal v mirovanju ne izrisuje več terminala pri 5 Hz, uporabniški vmesnik pa se redkeje izriše, medtem ko delajo vzporedni podagenti.

Poudaril bom, da se vsi štirje popravki nanašajo na podagente. To pomeni, da je Anthropic izdal celoten sklad infrastrukture za gnezdenje, ne samo ene vrstice v dnevniku sprememb. Gnezdenje so pri Anthropic uporabljali že nekaj časa pred objavo.

Kontrolni seznam: kdaj gnezdenje pomaga in kdaj škoduje#

Gnezdenje uporabi, če:

• Naloga vsebuje podnalogo z velikim številom spletnih zahtev, iskanj z grep ali branja datotek.
• Sprejemljivo je, da podnalogo izgubiš (če pravnuk vrne »ničesar nisem našel«, lahko orkestrator nadaljuje).
• V glavnem oknu ne potrebuješ vmesnih rezultatov.
• Imaš CLAUDE.md in sestavljen kontekst projekta, na katerega se podagent lahko opre.
• Znaš jasno opisati, kaj bo vrnila vsaka raven (vhod, izhod, oblika).
• Uporabljaš paket Max ali imaš zalogo za ×27 žetonov.

Gnezdenja ne uporabljaj, če:

• En podagent lahko reši nalogo brez hrupa.
• Potrebuješ vmesne rezultate v glavnem oknu (to pomeni, da želiš vzporednost).
• Projekt nima CLAUDE.md ali vsebuje le malo poslovnega konteksta.
• So pozivi na ravni 1 nejasni (nejasnost se bo eksponentno pomnožila po drevesu).
• Potrebuješ hitrost — pri primerljivem rezultatu je vzporednost hitrejša od globine.
• Uporabljaš paket Pro in delaš ves dan — v nekaj urah boš porabil omejitev.

Več gradiva je na voljo na Ailoot.