Claude Code’da ichma-ich subagentlardan foydalanib katta vazifani qanday topshirish mumkin
MarkdownClaude Code v2.1.172 subagentlarga 5 darajagacha o‘z subagentlarini yaratish imkonini berdi. Katta vazifalarni topshirish bo‘yicha ko‘rsatmalar.
Maqolani to‘liq o‘qish
Ailoot hujjatlari — xizmatdan foydalanish bo‘yicha ma’lumotnomalar.
Claude Code v2.1.172’da nima o‘zgardi?
Asosiy xulosa
Anthropic Claude Code v2.1.172’ni chiqardi va changelog’dagi birgina satr bilan ikki yillik qoidani bekor qildi. Endi subagentlar 5 darajagacha o‘z subagentlarini yaratishi mumkin. Bu funksiya tezlik yoki ko‘proq CPU haqida emas. Asosiy maqsad — shovqinli tayyorgarlik ishlarining asosiy kontekstingizni to‘ldirib yuborishiga yo‘l qo‘ymaslik.
So‘nggi bir necha oyda Claude Code’dagi AI agentlar haqida biror narsa o‘qigan bo‘lsangiz, ayni bir iboraga duch kelgansiz. U rasmiy hujjatlarda, mening subagentlar haqidagi qo‘llanmamda va har bir raqib tahlilida bor. U shunday: “subagent boshqa subagentni yarata olmaydi.” 2026-yil 11-iyun holatiga ko‘ra, bu jumla hali ham code.claude.com/docs/en/sub-agents sahifasining uchta joyida turibdi. Anthropic uni shunchaki hali yangilamagan.
10-iyun kuni soat 20:44 UTC’da Claude Code v2.1.172 GitHub Releases’da paydo bo‘ldi. Changelog’dagi asosiy yangilik bir satrdan iborat edi:
Subagentlar endi 5 darajagacha o‘z subagentlarini yaratishi mumkin.
Shu relizda faqat ichma-ich ishlashda yuz berishi mumkin bo‘lgan xato ham tuzatildi: ichki subagent ishga tushirgan subagent to‘xtatilganidan keyin ham, fon rejimidagi subagent agentlar panelida faol deb ko‘rinib qolardi.
Rasmiy hujjatlar chiqarilgan versiyaga hanuz zid bo‘lib turgan kamdan-kam holatlardan biri bu. Keyin ichma-ich ishlash parallel subagentlardan nimasi bilan farq qilishini, “5-daraja” nimani anglatishini va bugun u haqiqatan foydali bo‘ladigan uchta vaziyatni tushuntiraman.
Ichma-ich subagentlar parallel va ketma-ket subagentlardan nimasi bilan farq qiladi?
Asosiy xulosa
Agar chalkashib qolgan bo‘lsangiz, yolg‘iz emassiz. Parallel ishlash, zanjir va ichma-ich ishlash — o‘zaro mustaqil uchta topologiya. Parallel ishlash tezlikka, zanjir bajarilish tartibini belgilashga, ichma-ich ishlash esa butunlay boshqa narsaga xizmat qiladi: u shovqinli ishlarni asosiy oynangizdan yashiradi. Ularni chalkashtirsangiz, bir-ikki soat ichida tokenlarni sarflab yuborasiz, keyin esa xato qayerdaligini topa olmaysiz.
Men bu uch yondashuvni uzoq vaqt qo‘lda sinab ko‘rdim. Ularni shunday tushunaman: vazifani topshirishning uch o‘lchami bor — kenglik, uzunlik va chuqurlik. Har biri boshqa muammoni hal qiladi.
Kenglik — parallel subagentlar. Asosiy chat bir darajadagi N ta mustaqil subagentni ishga tushiradi. Har biriga tor doiradagi vazifa beriladi, u o‘zining ajratilgan oynasida ishlaydi va faqat natijani qaytaradi. Kenglik tezlik muammosini hal qiladi: parallel ishlayotgan 5 subagent bitta subagent ketma-ket bajaradigan ishni xuddi shu vaqt ichida tugatadi. Bu men worktree’lar yordamida parallel subagentlar haqidagi qo‘llanmamda yoritgan model.
Uzunlik — subagentlar zanjiri. A ishlaydi va natijani B’ga beradi, B ishlaydi va uni C’ga uzatadi. Har biri avvalgisidan kelgan ma’lumotni ko‘radi. Uzunlik tartibni belgilaydi: A’dan ma’lumot olmaguncha B ish boshlay olmaydi. Klassik misol: avval tadqiqot subagenti manbalarni to‘playdi, keyin tahrir subagenti shu manbalar asosida maqola yozadi, so‘ng tekshiruvchi subagent maqolani tekshiradi. Bu tekis ketma-ketlik; asosiy chat butun jarayonni kuzatib turadi.
Chuqurlik — ichma-ich subagentlar. A B’ni, B C’ni, C esa D’ni ishga tushiradi. Har bir quyi agent o‘zining ajratilgan oynasida, ota agentining ichida ishlaydi va ota agentiga faqat natijani qaytaradi. Asosiy chat bolalar, nevaralar va chevaralar darajasida nimalar bo‘layotganini ko‘rmaydi. v2.1.172’dagi yangilik shu.
Asosiy chalkashlik shundaki, odamlar 5-daraja “bir vaqtning o‘zida 5 ta subagentni ishga tushirish mumkin” degani deb o‘ylaydi. Unday emas. Chuqurlik bir vaqtdagi bolalar sonini emas, daraxtdagi vertikal darajani bildiradi. Har bir darajada bitta subagent ham, yuzta subagent ham bo‘lishi mumkin. 5-daraja degani topshirish zanjiri 5 qadam pastga tushishi mumkin: asosiy chat → 1-nevara → 2-nevara → 3-nevara → 4-nevara → 5-nevara. Har bir darajada tarmoqlanish ham mumkin.
Version 2.1.172 subagent boshqa subagentni ishga tushira olmasligi haqidagi qoidani olib tashladi.
Agar sizga tezlik kerak bo‘lsa, kenglikdan foydalaning. Bajarilish tartibi qat’iy bo‘lsa, uzunlik kerak. Chuqurlik faqat bitta holatda foydali: vazifalaringizdan biri shovqinli quyi vazifani (15 ta veb-so‘rov, jurnallarni ko‘zdan kechirish, o‘nlab fayllarni o‘qish) o‘z ichiga olganda va bu shovqin asosiy oynangizni to‘ldirib yuborishini istamasangiz.
“5 daraja chuqurlik” amalda nimani anglatadi?
Asosiy xulosa
5 daraja — asosiy chatdan eng uzoqdagi chevaragacha bo‘lgan vertikal masofaning eng katta qiymati. Bu server tomonidagi cheklov; uni bayroq yordamida oshira, kamaytira yoki o‘chira olmaysiz. Rasmiy manbalarda asosiy chatning o‘zi shu 5 darajaga kirishi-kirmasligi hamon aytilmagan.
Bu yerda ochiq aytishim kerak bo‘lgan muhim jihat bor. Anthropic aniq ta’rif bermaganini bilish uchun hujjatlar va hamjamiyat tahlillarini yarim kun o‘rgandim. Bilishingiz kerak bo‘lganlari quyidagilar.
Bu sozlama emas, qat’iy chegara.
Cheklov server tomonida o‘rnatilgan. v2.1.172 klientining teskari tahlilida MAX_DEPTH konstantasi topilmadi. Demak, tekshiruv kompyuteringizda emas, Anthropic API’ning qayeridadir bajariladi. Daraxtni chuqurlashtirish uchun --max-depth 7 o‘rnata olmaysiz. Xavfsizroq, pastroq chegara belgilash uchun --max-depth 2 ham o‘rnata olmaysiz. Sizdagi yagona boshqaruv vositasi frontmatter’dagi Agent(agent_type) ruxsat ro‘yxati, ammo u chuqurlikni emas, quyi agentlarning turlarini cheklaydi.
Anthropic “5” nimani anglatishini aniq belgilamagan. Bu ikkinchi muhim jihat:
Anthropic “5”ni aniq belgilamagan. Rasmiy manbalarda depth=5 ildizdan pastdagi besh darajani anglatadimi yoki ildizni ham qo‘shganda jami beshta agentni anglatadimi, ko‘rsatilmagan.
Hozircha uchinchi tomon integratsiyalari buni turlicha talqin qilmoqda. ruvnet/ruflo loyihasidagi ADR-147 “ildizdan pastda 5 ta quyi daraja = zanjirda 6 ta agent” deb hisoblaydi. Men ham tajribalarimda shu qoidaga amal qilaman: asosiy chat — 0-daraja, uning bevosita quyi agentlari — 1-daraja va shu tariqa 5-darajagacha. Ammo bu ommaviy hujjatlarda qayd etilmagan.
Cheklov allaqachon yoqilgan, bayroq kerak emas. Hech narsani faollashtirish shart emas. Claude Code’ni v2.1.172’ga yangilagandan so‘ng, quyi agentning tools ro‘yxatiga Agent qo‘shishingiz mumkin; u yana bir subagentni ishga tushiradi. Muhimi, ota agent bunga ruxsat berishi kerak (tools: Agent(...)).
Bugungi topshirishlaringiz qaysi turga kiradi: kenglikmi, uzunlikmi yoki chuqurlikmi?
Asosiy xulosa
Haqiqiy vibe-coding loyihalarida men deyarli har doim kenglikni, ba’zan esa uzunlikni ko‘raman. Chuqurlikni odamlar qo‘lda tashkil qiladi: yangi oyna ochadi, so‘rovni nusxalaydi, natija bilan qaytadi. 9-iyungacha bu imkoniyat ichki vosita sifatida mavjud emasdi. Shu sabab ko‘pchilik undan mahrum ekanini ham sezmaydi.
Oxirgi 5 ta so‘rovingizni ko‘zdan kechiring. Bu holat qanchalik tez-tez yuz bergan: vazifa boshlanadi, Claude fayllar bo‘ylab grep qila boshlaydi, 10 ta veb-so‘rov yuboradi, kontekstga ulkan jurnal matnini tashlaydi — 20 daqiqadan keyin esa oyna to‘lib bo‘lganini payqaysiz. Oraliq natijalar kontekstning 70 foizini egallab bo‘lgani uchun, yakuniy javobga juda kam token qoladi.
Bu — chuqurlik kerak bo‘ladigan holat. Parallel ishlash ham, zanjir ham emas — chuqurlik. Asosiy chat “tadqiqot”ni bitta subagentga topshirishi, u esa ichkaridan muayyan veb-qidiruvlar, fayllarni o‘qish va grep amallari uchun o‘z quyi agentlarini ishga tushirishi kerak. Quyi agentlar faqat xulosa qilingan fikrlarni qaytaradi. Nevara ota agentiga “topdim, tasdiqlandi” yoki “topilmadi, sababi X” deydi. Ota agent bularni bitta xulosaga jamlab, sizga qaytaradi. Asosiy chat toza qoladi.
9-iyungacha men buni qo‘lda taqlid qilardim. Claude Code’ning ikkinchi nusxasini ochib, “buni tadqiq qil” so‘rovini ko‘chirardim, ishga tushirardim, keyin natijani asosiy oynaga qo‘lda olib o‘tardim. Bu sozlamani ko‘plab AI agentlariga kod yozishni topshirish haqidagi qo‘llanmamda batafsil tasvirlaganman. v2.1.172 bilan buni orkestratorning tizim so‘rovida bevosita bayon qilishingiz mumkin — Claude daraxtni o‘zi quradi.
Ichma-ich subagentlar qaysi 3 ta vaziyatda haqiqatan foydali bo‘ladi?
Asosiy xulosa
Har bir vazifa uchun emas. Agar topshirilgan vazifada asosiy oynaga kiritishni istamaydigan shovqinli quyi vazifa bo‘lsa, chuqurlikdan foydalanish o‘rinli. Vibe-coderlar orasida qayta-qayta uchraydigan uchta odatiy vaziyatni ko‘rib chiqaman: manbalarni tekshirish bilan chuqur tadqiqot, katta repozitoriy tahlili va sxema yoki kontrakt o‘zgarishining bog‘liqliklarini boshidan oxirigacha tekshirish.
Vaziyat 1. Manbalarni tekshirish bilan chuqur tadqiqot
Maqola yoki tijorat taklifi uchun material to‘playapsiz, deylik. Avval ommaviy manbalardan 5–10 ta da’voni ajratib olishingiz, keyin har birini tekshirishingiz kerak — asl manbani topish, iqtibosning aynan mosligiga ishonch hosil qilish va haqiqiy raqamlarni hisoblash.
v2.1.172’dan oldin ikkita yo‘lingiz bor edi. Hammasini 30 ta veb-so‘rov yuborib, barcha ma’lumotni kontekstiga tiqishtiradigan bitta subagentga topshirishingiz mumkin edi. Yoki qo‘lda bo‘lib chiqardingiz: da’volarni ajratib olish uchun bitta so‘rov, keyin har bir da’vo bo‘yicha alohida subagent ishga tushiriladigan sikl. Asosiy chat oraliq ro‘yxatlarning ulkan matni bilan to‘lib ketardi.
Quyidagi retseptda asosiy chat research-orchestrator’ga topshiradi (1-daraja). U da’volarni o‘zi ajratib, har birini fact-verifier’ga beradi (2-daraja). Verifier aniq qidiruvlarni web-deep-search’ga topshiradi (3-daraja). Asosiy chat manbalari bilan birga tekshirilgan da’volar ro‘yxatinigina oladi. Qolgan hamma narsa quyi agentlar oynasida qoladi va kontekstingizga kirmaydi.
Vaziyat 2. Katta repozitoriyni tahlil qilish
Sizga 200 ta faylli loyiha berildi. Arxitekturani tushunish, asosiy modullarni topish va texnik qarzni baholash kerak. Glob va o‘nlab Read chaqiruvlarini qo‘lda bajarsangiz, 10 daqiqada oyna to‘ladi.
Chuqurlik buni quyidagicha hal qiladi: asosiy chat “architect” subagentini ishga tushiradi. Arxitektor ichkaridan uchta quyi agentni yaratadi — biri katalog tuzilishini tekshiradi (Glob ishga tushirib, xulosalaydi), ikkinchisi 5 ta muhim konfiguratsiya faylini o‘qiydi, uchinchisi esa asosiy andozalarni grep qiladi. Har biri arxitektorga qisqa xulosa qaytaradi. Arxitektor umumiy manzarani tuzib, asosiy chatga yarim ekranlik yakuniy hisobot beradi. Barcha fayllardan olingan cat chiqishlari asosiy kontekstni to‘ldirmasdan, loyiha xaritasini olasiz.
Vaziyat 3. Boshidan oxirigacha bo‘lgan bog‘liqliklarni tahlil qilish
Ma’lumotlar bazasi sxemasi, API kontrakti yoki umumiy konfiguratsiya faylini o‘zgartiryapsiz. O‘zgarish qayerlarda ta’sir ko‘rsatishini tushunishingiz kerak. Bu vazifa kontekstni eng tez to‘ldiradi, chunki bog‘liqliklar ko‘p va ularning har birini manba kodida tekshirish kerak.
Chuqurlik bilan asosiy chat “impact-analyzer”’ni ishga tushiradi (1-daraja). U ta’sirlangan har bir fayl uchun bittadan dependency-tracer’ni ishga tushiradi (2-daraja). Har bir kuzatuvchi ichkaridan consumer-finder’ni ishga tushiradi (3-daraja), u esa kod bazasidan ushbu bog‘liqlikdan foydalanuvchilarni grep orqali qidiradi. Har biri faqat qisqa xulosani qaytaradi: “mana shu uchta joy buziladi.” Asosiy chat grep natijalarini ko‘rmasdan “ta’sirlangan fayllar → ta’sir” jadvalini tuzadi.
Ichma-ich subagentlarni 10 daqiqada sozlash
Asosiy xulosa
Hech qanday bayroq yoki konfiguratsiya yangilanishi kerak emas. Shunchaki child agentning tools qatoriga Agent qo‘shing, shunda u o‘z subagentlarini ishga tushira oladi. Daraxt nazoratdan chiqib ketmasligi uchun Agent(name1, name2) ruxsat ro‘yxatidan foydalaning. Keyin nusxalab ishlatishingiz mumkin bo‘lgan uch darajali orkestrator uchun tayyor shablonni beraman.
1-qadam. v2.1.172 yoki undan yuqori versiyada ekaningizni tekshiring.
claude --version
Agar versiya pastroq bo‘lsa, yangilang. Relizning asosiy xususiyati o‘zgarishlar jurnalidagi bir satrda ifodalangan: “Subagentlar endi 5 darajagacha o‘z subagentlarini yaratishi mumkin” (to‘liq matn).
2-qadam. Farzandlarni ishga tushira oladigan ota agent yarating.
File .claude/agents/research-orchestrator.md:
---
name: research-orchestrator
description: Delegates research with a deep fact-check
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---
You are a research orchestrator. When you get a topic:
1. Berilgan materialni o‘qing yoki berilgan ommaviy URL’larni oling.
Ko‘pi bilan 5 aniq da’voni o‘zingiz ajrating. Har biriga matni,
manba URL yoki fayli va aynan asoslovchi parchani yozing.
Material berilmagan bo‘lsa, delegatsiyadan oldin so‘rang.
2. For each claim call fact-verifier - it spawns
its own child subagents for web search and cross-checking.
3. fact-verifier returns only the final verdicts to you -
do not load intermediate dumps into your context.
Final report - only an array { claim, sources[], confidence }.
tools qatori faqat fact-verifier turiga ruxsat beradi. Da’voni ajratish orkestratorning o‘z birinchi qadami, shuning uchun noma’lum claim-extractor fayli kerak emas. Tur ro‘yxati kim chaqirilishini cheklaydi, necha marta chaqirilishini emas. Dastlabki ajratishni ko‘pi bilan besh da’voda saqlang.
3-qadam. O‘zi nabira agentlarni ishga tushira oladigan child agent yarating.
File .claude/agents/fact-verifier.md:
---
name: fact-verifier
description: Checks a claim through child web searches
tools: Agent(web-deep-search), Read
model: sonnet
---
You are a fact-checker. When you get a claim:
1. Write 2-3 search queries.
2. For each one run web-deep-search - it will do
WebSearch and WebFetch itself and return verified snippets.
3. Combine them into one verdict: { claim, sources[], confidence }.
Asosiy qismni ko‘ryapsizmi? tools qatorida yana Agent(web-deep-search) deb yozilgan. Demak, fact-verifier (daraxtimizdagi 2-daraja) o‘zi yana bir subagentni ishga tushira oladi (3-daraja). Ilgari bu qator hech qanday ta’sir ko‘rsatmas edi — hujjatlarda hanuz quyidagi jumla bor:
Subagentlar boshqa subagentlarni ishga tushira olmaydi, shuning uchun subagent ta’riflarida Agent(agent_type) ishlamaydi.
v2.1.172 bilan bu jumla eskirdi. Sintaksis o‘sha-o‘sha, ammo endi u daraxtning istalgan chuqurligida ishlaydi.
4-qadam. Nabira agent yarating.
File .claude/agents/web-deep-search.md:
---
name: web-deep-search
description: Runs a web search and returns snippets
tools: WebSearch, WebFetch
model: haiku
---
You received a search query. Run WebSearch, pick the top 3
relevant URLs, use WebFetch to pull verbatim confirmations
of the claim. Return an array { url, snippet, supports_claim: yes|no }.
Nabira agentning tools qatorida Agent yo‘q, shuning uchun u daraxt bo‘ylab pastga qarab yana agentlarni ishga tushirmaydi.
5-qadam. Orkestratorni ishga tushiring.
claude --agent research-orchestrator
Chatga manba matni yoki ommaviy URL bering: «Shu manbalardan ko‘pi bilan 5 aniq da’voni ajratib tekshiring; da’vo, manba va ishonchni qaytaring». --agent research-orchestrator bilan seansning o‘zi orkestrator; undan pastda verifier va search ikki daraja qo‘shadi. Oddiy asosiy seans orkestratorga topshirsa, undan pastda uch daraja bo‘ladi.
Qaysi 5 ta noto‘g‘ri yondashuv tokenlarni behuda sarflab, kuzatuvchanlikni yo‘qotadi?
Asosiy xulosa
Chuqurlik qimmatga tushadi. Har bir keyingi daraja tokenlar sonini ko‘paytiradi va bu ko‘payish jamlanib boradi. Quyida ichma-ich tuzilma zarar keltiradigan beshta holat keltirilgan. Bunday qilmang — aks holda bir soat ichida kunlik limitingiz tugaydi, daraxtning to‘rtinchi qavatida xato qayerda yuz berganini ham topolmaysiz.
Noto‘g‘ri yondashuv 1. Vazifa bitta oynaga sig‘adi.
Agar bitta subagent vazifani ortiqcha shovqinsiz bajara olsa, darajalar qo‘shmang: ichma-ich tuzilma befoyda xarajat va kechikish qo‘shadi.
Noto‘g‘ri yondashuv 2. Sizga ajratish emas, tezlik kerak.
Tezlik kerak bo‘lsa, sizga chuqurlik emas, parallel ishlash kerak. Zanjir tuzish o‘rniga bir darajada yonma-yon 5 ta subagentni ishga tushiring. Chuqurlik shovqinli tayyorgarlik ishlarini child agentning oynasiga ko‘chirish uchun kerak; u ishlarni tezlashtirmaydi.
Noto‘g‘ri yondashuv 3. Ishning o‘zi yuzaki.
“Bu faylni topib, menga ko‘rsat” — bu ikki bosqichli so‘rov; unga uch darajali iyerarxiya kerak emas. Vazifada shovqinli bir kichik vazifa bo‘lsa, ichma-ich tuzilma o‘zini oqlaydi. Shovqin bo‘lmasa, subagentlar qo‘shmang.
Noto‘g‘ri yondashuv 4. Birinchi darajadagi noaniq so‘rovlar.
Bu eng xavfli holat. 1-darajali orkestratorga noaniq so‘rov bersangiz, noaniqlik ko‘payadi. 1-darajadagi bitta noaniq so‘rov 2-darajada 4 ta, 3-darajada esa 16 ta noaniq so‘rovga aylanadi. Nabira agentlar ish boshlaguniga qadar ular nimani izlayotganini ham bilmay qoladi.
Noto‘g‘ri yondashuv 5. Xarajatning geometrik o‘sishi.
Asosiy iqtisodiy dalil: ichma-ich tuzilma token sarfini ko‘paytiradi, bu ko‘payish esa chuqurlik oshgani sayin jamlanadi.
Taxminiy hisob: har bir darajada ko‘p tarmoqlanish soni 3 bo‘lgan, 3-darajali zanjirda 27 ta subagent bo‘ladi. Bu oddiy so‘rovga nisbatan kamida 27 baravar ko‘p token degani. Claude’ning Pro rejasi bilan bu hisob kunlik limitni bir necha soatda tugatadi. Max rejasida bo‘lsangiz, bir haftalik limitni bir kunda sarflaysiz.
Qo‘shimcha noto‘g‘ri yondashuv (mening tajribam): “Bekorchi ish qilayotgan 50 ta agent.”
Boshqalarning loyihalarini ko‘rganimda, buni tez-tez uchrataman: “Menda 50 ta agent ishlayapti.” Ulardan nima qilayotganini so‘rayman. Ma’lum bo‘lishicha, bu 50 ta agent bekorchi ish bilan band. Ular keraksiz natijalar uyumini, juda ko‘p xom xulosalarni, takroriy materiallarni va uzun loglarni hosil qiladi. Har biri “umuman olganda foydali” nimadir qiladi, natijada kontekstga ma’lumot to‘lib ketadi va kichik kompaniyanikidek token hisobi keladi. 5-daraja bu muammoni hal qilmaydi — uni yanada kuchaytiradi. Agar 1-darajada kim nima qilayotgani allaqachon noaniq bo‘lsa, 5-daraja besh qatlamli chalkashlikni anglatadi.
Har qanday subagentni ishga tushirishdan oldin, 4 savolga yarim daqiqada javob berib, uni sinab ko‘ring:
- U aynan nima qiladi (bir jumlada)?
- Qaysi fayllarga tegadi?
- Ota agentga nima qaytaradi?
- Uni kim tekshiradi?
Agar 30 soniyada javob bera olmasangiz, bu subagent kerak emas. Men bu qoidani parallel subagentlar haqidagi qo‘llanmamda alohida tushuntirganman.
Kontekstni muhandisona tashkil qilmasdan ichma-ich tuzilma ishlatish nega 5 darajali gallyutsinatsiyalarga olib keladi?
Asosiy xulosa
Chuqur delegatsiya tuzog‘i — yetishmagan vazifa konteksti. Child ota suhbatining hammasi yoki o‘qilgan barcha faylni avtomatik olmaydi. Maxsus subagentlar, o‘chirilmagan bo‘lsa, tegishli CLAUDE.md’ni odatda yuklaydi; bu biznes havolalari mazmunini to‘liq yuklamaydi. Har topshirishda aniq manba, yo‘l va natija kontraktini uzating. Loyihangizda puxta kontekst tuzilmasi bo‘lmasa, daraxt qanchalik chuqur bo‘lsa, har bir nabira shunchalik xayolotga berilib ketadi. Gallyutsinatsiyaning 5 qavati bo‘ladi, bittadan har bir darajada.
Bu yerda odamlar tez-tez shunday so‘rashadi: “Claude Code’ni yangiladim, tools ga Agent qo‘shdim, daraxt tuzilyapti, ammo yakuniy javob baribir noto‘g‘ri. Nega?”
Javob oddiy. Claude Code’dagi har bir subagent boshidan boshlaydi. Rasmiy hujjatlardan:
Har bir subagent yangi, ajratilgan oynada boshlaydi. U suhbat tarixini, siz avval chaqirgan ko‘nikmalarni yoki Claude allaqachon o‘qigan fayllarni ko‘ra olmaydi.
1-darajada bu boshqariladigan holat: orkestrator bolaga qisqa vazifa tavsifini uzatadi. Ammo 3-darajada nabira agent ota agentidan topshiriq xabarini oladi, u ota agent ham faqat topshiriq xabarini olgan edi. Har bir daraja ozgina ma’lumot uzatadi. 5-darajaga kelib, oynasida “X da’vosini tekshir” degan jumladan boshqa hech narsasi yo‘q subagent paydo bo‘ladi. U qaysi loyihada ishlayotganini, qanday vazifani bajarayotganini yoki nimaga e’tibor qaratishi kerakligini bilmaydi.
CLAUDE.md bo‘lmasa, beshinchi darajadagi nabira agent butun umrida birinchi marta hech qanday yo‘l-yo‘riqsiz ofisga kelgan xodimga o‘xshaydi. Unga vazifa berilgani uchun nimadir qiladi. Ammo bu loyiha ehtiyojiga mos ish bo‘lmaydi.
Ichma-ich tuzilishdan tashqari v2.1.172 da yana nimalar o‘zgardi?
Asosiy xulosa
Reliz to‘liq subagentlarga bag‘ishlangan. Asosiy xususiyat bilan birga delegatsiya infratuzilmasiga oid 4 ta tuzatish ham bor. Ulardan biri faqat ichma-ich ishlashda yuz berishi mumkin bo‘lgan xatoni tuzatadi.
v2.1.172 dagi to‘liq o‘zgarishlar jurnalini ochsangiz, relizning hammasi subagentlarga bag‘ishlanganini ko‘rasiz.
Tuzatish 1. Fon rejimidagi subagent o‘zi ishga tushirgan ichki subagent to‘xtatilgach, agentlar panelida faol holatda “qotib qolmaydi”. Bu xato faqat ichma-ich tuzilmada yuz berishi mumkin.
Tuzatish 2. availableModels cheklovlari endi subagentlarga ham tatbiq etiladi. Ilgari jamoa ishlatishi mumkin bo‘lgan modellarni cheklasangiz (masalan, pul tejash uchun opus’ni taqiqlasangiz), subagentlar o‘z konfiguratsiyasidagi override orqali bu qoidani chetlab o‘ta olardi. v2.1.172 da qoida hamma joyda amal qiladi.
Tuzatish 3. So‘rovlar tarixidagi yuqoriga strelka endi asosiy agentning emas, subagentning joriy tabidagi so‘rovlarni ko‘rsatadi. Bu kuzatuvchanlikka oid mayda yaxshilanish.
Tuzatish 4. Bekor turgandagi protsessor sarfi kamaydi: /goal indikatori bo‘sh paytda terminalni endi 5 Hz tezlikda qayta chizmaydi, parallel subagentlar ishlayotganda esa interfeys kamroq qayta chiziladi.
To‘rtta tuzatishning barchasi subagentlarga tegishli ekanini ta’kidlamoqchiman. Demak, Anthropic faqat o‘zgarishlar jurnalidagi bitta satrni emas, ichma-ich tuzilmaning butun infratuzilma qatlamini chiqargan. Nashrdan ancha oldin Anthropic ichida ichma-ich tuzilma allaqachon ishlatilgan edi.
Ichma-ich tuzilma qachon yordam berishi va qachon zarar keltirishi: tekshiruv ro‘yxati
Asosiy xulosa
Har safar yangi subagentni ishga tushirishdan oldin, vazifani 6 ta mezon bo‘yicha tekshiring. Agar kamida 3 ta javob “ha, chuqurlikdan foydalaning” bo‘lsa, shunday qiling. Aks holda parallel ishlashni yoki bitta subagentni tanlang. Bu tokenlar, asablar va 27 ta ichma-ich ishga tushirish zanjiri aslida nima qilganini aniqlashga ketadigan bir necha soatni tejaydi.
Ichma-ich tuzilmadan quyidagi hollarda foydalaning:
- Vazifada ko‘p sonli veb-so‘rovlar, grep qidiruvlari yoki fayl o‘qishlarni talab qiladigan kichik vazifa bor.
- Shu kichik vazifani yo‘qotish mumkin bo‘lsa (nabira agent “hech narsa topilmadi” deb qaytarsa ham, orkestrator davom eta oladi).
- Asosiy oynada oraliq natijalar kerak bo‘lmasa.
- Sizda
CLAUDE.mdva subagent tayanishi mumkin bo‘lgan yig‘ilgan loyiha konteksti bo‘lsa. - Har bir daraja nima qaytarishini (kirish, chiqish, format) aniq tasvirlay olsangiz.
- Max rejasida bo‘lsangiz yoki ×27 token uchun zaxirangiz bo‘lsa.
Quyidagi hollarda ichma-ich tuzilmadan foydalanmang:
- Bitta subagent vazifani ortiqcha shovqinsiz hal qila olsa.
- Asosiy oynada oraliq natijalar kerak bo‘lsa (demak, sizga parallel ishlash kerak).
- Loyihada CLAUDE.md bo‘lmasa yoki unda biznes konteksti juda kam bo‘lsa.
- 1-darajadagi so‘rovlar noaniq bo‘lsa (noaniqlik daraxt bo‘ylab eksponensial ko‘payadi).
- Tezlik kerak bo‘lsa — taqqoslanadigan natija uchun parallel ishlash chuqurlikdan tezroq.
- Pro rejasida bo‘lib, kun bo‘yi ishlasangiz — limitingiz bir necha soatda tugaydi.
Manbalar
Qo‘shimcha materiallar Ailoot saytida mavjud.
Batafsil
Ko‘p beriladigan savollar
Nusxalanadigan retsept uchun claim-extractor yaratish kerakmi?
Yo‘q. Tuzatilgan research-orchestrator berilgan materialdan ko‘pi bilan beshta da’voni o‘zi ajratadi. Ko‘rsatilgan uch faylni yarating: research-orchestrator, fact-verifier, web-deep-search. Keyin manba matni yoki URL bering.
Faqat fact-verifier ruxsati child chaqiruvlar sonini cheklaydimi?
Yo‘q. Tur allowlist’i qaysi tur chaqirilishini cheklaydi, urinish sonini emas. Retsept dastlabki da’volarni alohida beshtaga cheklaydi. Haqiqiy chaqiruv va token sarfini kuzating.