Jak delegovat rozsáhlý úkol v Claude Code pomocí vnořených subagentů
MarkdownVe verzi v2.1.172 Anthropic umožnil subagentům Claude Code spouštět vlastní subagenty až do hloubky 5 úrovní. Návod, jak delegovat rozsáhlý úkol.
Přečíst celý článek
Dokumentace Ailoot — referenční materiály o používání služby.
Co se změnilo v Claude Code v2.1.172?
Klíčové sdělení
Anthropic vydal verzi Claude Code v2.1.172 a jediným řádkem v záznamu změn zrušil dva roky staré pravidlo. Subagenti nyní mohou spouštět vlastní subagenty až do hloubky 5 úrovní. Tato funkce není o rychlosti ani o větším počtu procesorů. Hlavní myšlenkou je, aby hlučná přípravná práce nezaplevelovala hlavní kontext.
Pokud jste za posledních několik měsíců četli něco o AI agentech v Claude Code, narazili jste na stejnou větu. Je v oficiální dokumentaci, v mém průvodci o subagentech i v analýzách konkurence. Zní takto: „subagent nemůže spustit dalšího subagenta“. K 11. červnu 2026 je tato věta stále na třech různých místech na code.claude.com/docs/en/sub-agents. Anthropic ji jednoduše ještě neaktualizoval.
- června ve 20:44 UTC se Claude Code v2.1.172 objevil na GitHub Releases. Hlavní položka záznamu změn měla jediný řádek:
Subagenti nyní mohou spouštět vlastní subagenty až do hloubky 5 úrovní.
Toto vydání také opravilo chybu, která mohla nastat pouze při vnořování: subagent spuštěný na pozadí zůstával v panelu agentů zvýrazněný jako aktivní i poté, co byl zastaven vnořený subagent, kterého spustil.
Jde o vzácný případ, kdy oficiální dokumentace stále odporuje vydané verzi. Dále vysvětlím, jak se vnořování liší od paralelních subagentů, co znamená „hloubka 5“ a ve kterých třech scénářích je dnes skutečně užitečné.
Jak se vnoření subagenti Claude Code liší od paralelních a sekvenčních?
Klíčové sdělení
Pokud v tom máte zmatek, nejste sami. Paralelismus, řetězení a vnořování jsou tři na sobě nezávislé topologie. Paralelismus se týká rychlosti, řetězení nastavení pořadí provádění a vnořování něčeho úplně jiného: skrývá hlučnou práci před hlavním oknem. Když si je spletete, během pár hodin spálíte tokeny a pak nebudete vědět, kde hledat chybu.
Dlouho jsem tyto tři přístupy zkoušel ručně a představuji si je takto: delegování má tři rozměry — šířku, délku a hloubku. Každý řeší jiný problém.
Šířka — paralelní subagenti. Hlavní chat spustí N nezávislých subagentů na stejné úrovni. Každý dostane úzce vymezený úkol, pracuje ve vlastním izolovaném okně a vrátí pouze výsledek. Šířka řeší rychlost: 5 paralelně pracujících subagentů skončí za dobu, kterou by jednomu zabralo provést stejnou práci postupně. Tento model jsem popsal v průvodci o paralelních subagentech používajících worktree.
Délka — řetězec subagentů. A pracuje, předá výsledek B, B pracuje a předá jej C. Každý vidí vstup od předchozího. Délka nastavuje pořadí: B nemůže začít, dokud nedostane data od A. Klasický příklad: nejprve výzkumný subagent shromáždí zdroje, potom redakční subagent napíše článek na jejich základě a nakonec subagent pro ověřování faktů článek zkontroluje. Je to plochá posloupnost; hlavní chat drží celý příběh.
Hloubka — vnoření subagenti. A spustí B, B spustí C, C spustí D. Každé dítě pracuje uvnitř svého rodiče, ve vlastním izolovaném okně, a vrací rodiči pouze výsledek. Hlavní chat nevidí nic z toho, co se děje u dětí, vnoučat a pravnoučat. To je novinka ve verzi v2.1.172.
Nejčastější zmatek spočívá v tom, že si lidé myslí, že hloubka 5 znamená „můžeš současně spustit 5 subagentů“. Tak to není. Hloubka je svislá úroveň ve stromu, nikoli počet současně spuštěných dětí. Na každé úrovni může být jeden subagent nebo sto. Hloubka 5 znamená, že řetězec delegování může klesat o 5 kroků: hlavní chat → pravnuk-1 → pravnuk-2 → pravnuk-3 → pravnuk-4 → pravnuk-5. Na každé úrovni se navíc může větvit.
Verze 2.1.172 odstranila pravidlo, podle kterého subagent nemohl spustit dalšího subagenta.
Pokud vám jde o rychlost, potřebujete šířku. Pokud máte přísné pořadí provádění, potřebujete délku. Hloubka je užitečná přesně v jednom případě: když některý váš úkol obsahuje hlučný dílčí úkol (15 webových požadavků, procházení logů, čtení tuctu souborů) a nechcete, aby tento šum zaplavil hlavní okno.
Co v praxi znamená „hloubka 5 úrovní“?
Klíčové sdělení
5 úrovní je maximální svislá vzdálenost od hlavního chatu k nejvzdálenějšímu pravnoučeti. Jde o limit na straně serveru; nelze ho zvýšit, snížit ani vypnout příznakem. Oficiální zdroje také stále neuvádějí, zda se do těchto 5 úrovní počítá i samotný hlavní chat.
Je důležité být v tomto ohledu upřímný. Půl dne jsem procházel dokumentaci a komunitní analýzy, abych zjistil, že Anthropic neposkytl přesnou definici. Tady je to, co potřebujete vědět.
Jde o limit, nikoli nastavení.
Limit je zabudovaný na straně serveru. Reverzní analýza klienta v2.1.172 neodhalila konstantu MAX_DEPTH. To znamená, že kontrola probíhá někde v API Anthropic, nikoli lokálně na vašem počítači. Nemůžete nastavit --max-depth 7 a tím strom prohloubit. Stejně tak nemůžete nastavit --max-depth 2, abyste vytvořili nižší a bezpečnější limit. Jedinou možností, kterou máte pod kontrolou, je seznam povolených Agent(agent_type) ve frontmatteru — omezuje však typy podřízených agentů, nikoli hloubku.
Anthropic přesně nedefinoval, co znamená „5“. To je druhý důležitý bod:
Anthropic přesně nedefinoval, co znamená „5“. Oficiální zdroje neuvádějí, zda depth=5 znamená pět úrovní pod kořenem, nebo celkem pět agentů včetně kořene.
Integrace třetích stran to zatím vykládají různě. ADR-147 v projektu ruvnet/ruflo předpokládá „5 úrovní potomků pod kořenem = 6 agentů v řetězci“. Ve svých experimentech používám stejnou konvenci: hlavní chat je úroveň 0, jeho přímé děti jsou úroveň 1 a tak dále až po úroveň 5. Ve veřejné dokumentaci to ale zaznamenáno není.
Limit je už aktivní a není třeba používat příznaky. Nemusíte nic aktivovat. Po aktualizaci Claude Code na v2.1.172 můžete do tools podřízeného agenta přidat Agent a ten spustí dalšího subagenta. Klíčové je, že to rodičovský agent musí povolit (tools: Agent(...)).
Jak dnes delegujete: šířkou, délkou, nebo hloubkou?
Klíčové sdělení
V reálných projektech vibe-codingu téměř vždy vídám šířku a občas délku. Hloubku lidé dělají ručně: otevřou nové okno, zkopírují prompt a s výsledkem se vrátí. Před 9. červnem nebyla zabudovaná. Proto si většina lidí ani neuvědomuje, že jim chybí.
Projděte si posledních 5 promptů. Jak často jste udělali toto: začne úkol, Claude začne prohledávat soubory pomocí grepu, provede 10 webových požadavků, nasype do kontextu celou stěnu logů — a o 20 minut později zjistíte, že je okno plné. Závěrečná odpověď už běží s mizerným rozpočtem tokenů, protože 70 percent kontextu spotřebovaly průběžné výpisy.
To je situace, kdy potřebujete hloubku. Ne paralelismus ani řetězec — hloubku. Hlavní chat by měl delegovat „výzkum“ jednomu subagentovi, který pak zevnitř spustí vlastní děti pro konkrétní webová hledání, čtení souborů a grepy. Děti vracejí pouze shrnuté závěry. Pravnuk řekne rodiči „našel jsem to, potvrzeno“ nebo „nenašel jsem to, důvod X“. Rodič z toho sestaví jediné shrnutí a vrátí vám ho. Hlavní chat zůstane přehledný.
Před 9. červnem jsem to napodoboval ručně. Otevřel jsem druhou instanci Claude Code, zkopíroval prompt „prozkoumej to“, spustil ho a pak výsledek ručně přenesl zpět do hlavního okna. Toto uspořádání jsem podrobně popsal v průvodci o delegování programování na mnoho AI agentů. Ve verzi v2.1.172 ho můžete popsat přímo v systémovém promptu orchestrace — Claude si strom vytvoří sám.
Ve kterých 3 scénářích jsou vnoření subagenti skutečně užiteční?
Klíčové sdělení
Ne pro každý úkol. Hloubka má smysl, když delegování obsahuje hlučný dílčí úkol, který nechcete umístit do hlavního okna. Popíšu tři typické scénáře, které se mezi tvůrci používajícími vibe-coding opakují: hloubkový výzkum s ověřováním faktů, analýza velkého repozitáře a audit závislostí od začátku do konce při změně schématu nebo kontraktu.
Scénář 1. Hloubkový výzkum s ověřováním faktů
Představte si, že shromažďujete podklady pro článek nebo obchodní nabídku. Nejprve potřebujete z veřejných zdrojů získat 5–10 tvrzení a potom každé ověřit — najít původní zdroj, ujistit se, že citace přesně souhlasí, a spočítat skutečné hodnoty.
Před v2.1.172 jste měli dvě možnosti. Buď jste vše svěřili jednomu subagentovi, který se prodíral 30 webovými požadavky a cpal vše do svého kontextu. Nebo jste práci rozdělili ručně: jeden prompt pro vytažení tvrzení a potom smyčku přes jednotlivá tvrzení, při níž se pro každé spouštěl samostatný subagent. Hlavní chat by se zaplnil stěnami průběžných seznamů.
V receptu níže hlavní chat deleguje na research-orchestrator (úroveň 1). Ten tvrzení vytáhne sám, každé předá fact-verifier (úroveň 2) a ověřovatel deleguje cílené hledání na web-deep-search (úroveň 3). Hlavní chat obdrží pouze pole ověřených tvrzení se zdroji. Všechno ostatní zůstane v oknech dětí a nikdy nevstoupí do vašeho kontextu.
Scénář 2. Analýza velkého repozitáře
Dostali jste projekt s 200 soubory. Potřebujete pochopit architekturu, najít hlavní moduly a posoudit technický dluh. Ručně spustíte Glob a tucet volání Read a za 10 minut zaplníte okno.
Hloubka to řeší takto: hlavní chat spustí subagenta „architect“. Architect interně vytvoří tři děti — jedno zkontroluje strukturu adresářů (spustí Glob a shrne výsledky), druhé přečte 5 klíčových konfiguračních souborů a třetí vyhledá hlavní vzory pomocí grepu. Každé vrátí architectovi stručné shrnutí. Architect sestaví celkový obraz a předá hlavnímu chatu závěrečnou zprávu dlouhou půl obrazovky. Získáte přehled projektu, aniž by kontext zaplavila stěna výstupu cat ze všech souborů.
Scénář 3. Analýza závislostí od začátku do konce
Měníte schéma databáze, kontrakt API nebo sdílený konfigurační soubor. Potřebujete zjistit, kde se změna projeví. Tento úkol vyčerpá kontext nejrychleji, protože závislostí je mnoho a každou je třeba zkontrolovat ve zdrojovém kódu.
Při použití hloubky spustí hlavní chat agenta „impact-analyzer“ (úroveň 1). Ten spustí jednoho dependency-tracer pro každý dotčený soubor (úroveň 2). Každý tracer interně spustí consumer-finder (úroveň 3), který prohledá kódovou základnu a najde uživatele dané závislosti. Každý vrátí jen to podstatné: „rozbijí se tato tři místa“. Hlavní chat sestaví tabulku „dotčené soubory → dopad“, aniž by znal výsledky grep.
Jak nastavit vnořené subagenty za 10 minut
Klíčové sdělení
Nepotřebujete žádné příznaky ani aktualizace konfigurace. Stačí přidat Agent do tools podřízeného agenta a ten může spouštět vlastní subagenty. Aby se strom nezměnil v kasino, použijte seznam povolených Agent(name1, name2). Dále vám dám připravenou šablonu tříúrovňového orchestru, kterou můžete zkopírovat.
Krok 1. Ověřte, že používáte v2.1.172 nebo novější.
claude --version
Pokud je verze nižší, aktualizujte ji. Hlavní funkce vydání je jednou větou v záznamu změn: „Subagenti nyní mohou spouštět vlastní subagenty až do hloubky 5 úrovní“ (úplné znění).
Krok 2. Vytvořte rodičovského agenta, který může spouštět děti.
Soubor .claude/agents/research-orchestrator.md:
---
name: research-orchestrator
description: Deleguje výzkum s hloubkovým ověřováním faktů
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---
Jsi orchestrátor výzkumu. Po obdržení tématu:
1. Přečti dodaný materiál nebo načti dodané veřejné URL.
Sám vytáhni nejvýše 5 konkrétních tvrzení. U každého zaznamenej text,
zdrojovou URL či soubor a přesnou podpůrnou pasáž.
Pokud materiál chybí, vyžádej jej před delegováním.
2. Pro každé tvrzení zavolej fact-verifier — sám spustí
své podřízené agenty pro webové hledání a ověřování.
3. fact-verifier ti vrátí jen konečné verdikty —
nenačítej průběžné výpisy do svého kontextu.
Závěrečná zpráva má obsahovat pouze pole { claim, sources[], confidence }.
Řádek tools povoluje jen typ dítěte fact-verifier. Extrakce tvrzení je prvním krokem samotného orchestrátoru, takže nedefinovaný soubor claim-extractor není potřeba. Seznam typů omezuje volatelné děti, nikoli počet spuštění typu. Recept omezte na nejvýše pět vytěžených tvrzení.
Krok 3. Vytvořte podřízeného agenta, který může sám spouštět pravnoučata.
Soubor .claude/agents/fact-verifier.md:
---
name: fact-verifier
description: Ověřuje tvrzení pomocí podřízeného webového vyhledávání
tools: Agent(web-deep-search), Read
model: sonnet
---
Jsi ověřovatel faktů. Po obdržení tvrzení:
1. Formuluj 2-3 vyhledávací dotazy.
2. Pro každý spusť web-deep-search — sám provede
WebSearch a WebFetch a vrátí ověřené úryvky.
3. Shrň je do jednoho verdiktu: { claim, sources[], confidence }.
Vidíte tu klíčovou část? tools znovu uvádí Agent(web-deep-search). To znamená, že fact-verifier (úroveň 2 našeho stromu) může sám spustit dalšího subagenta (úroveň 3). Dříve tento řádek neměl žádný účinek — dokumentace stále obsahuje tuto větu:
Subagenti nemohou spouštět další subagenty, proto Agent(agent_type) v definicích subagentů nefunguje.
Ve verzi v2.1.172 je tato věta zastaralá. Syntaxe je stejná, ale nyní funguje v jakékoli hloubce stromu.
Krok 4. Vytvořte pravnuka.
Soubor .claude/agents/web-deep-search.md:
---
name: web-deep-search
description: Vyhledává na webu a vrací úryvky
tools: WebSearch, WebFetch
model: haiku
---
Dostal jsi vyhledávací dotaz. Proveď WebSearch, vyber 3 nejrelevantnější
URL a přes WebFetch získej doslovná potvrzení
tvrzení. Vrať pole { url, snippet, supports_claim: yes|no }.
Pravnuk nemá v tools položku Agent, takže už nepokračuje dál do stromu.
Krok 5. Spusťte orchestrátor.
claude --agent research-orchestrator
Poté v chatu dodejte text nebo veřejné URL: „Z těchto zdrojů vytáhni a ověř nejvýše 5 konkrétních tvrzení; vrať tvrzení, zdroje a jistotu.“ Při --agent research-orchestrator je orchestrátorem samotná relace; ověřovatel a hledání přidávají dvě delegované úrovně pod ní. Pokud běžná hlavní relace deleguje na orchestrátor, jsou pod ní tři delegované úrovně.
Kterých 5 anti-vzorů plýtvá tokeny a ničí pozorovatelnost?
Klíčové sdělení
Hloubka je nákladná. Každá další úroveň násobí počet tokenů a násobení se kumuluje. Tady je pět scénářů, ve kterých vnořování škodí. Nedělejte to — jinak za hodinu vyčerpáte denní limit a ztratíte přehled o chybě čtyři patra hluboko ve stromu.
Anti-vzor 1. Úkol se vejde do jednoho okna.
Pokud jeden subagent zvládne úkol bez šumu, nepřidávejte další úrovně: vnořování zbytečně zvyšuje náklady a latenci.
Anti-vzor 2. Jde vám o rychlost, ne o izolaci.
Pokud chcete rychlost, potřebujete paralelismus, nikoli hloubku. Spusťte 5 subagentů vedle sebe na stejné úrovni místo budování řetězce. Hloubka slouží k přesunutí hlučné přípravné práce do okna dítěte, nikoli ke zrychlení práce.
Anti-vzor 3. Práce je ze své podstaty mělká.
„Najdi tento soubor a ukaž mi ho“ je dvoukrokový požadavek; nepotřebuje tříúrovňovou hierarchii. Vnořování má smysl, když úkol obsahuje hlučný dílčí úkol. Pokud žádný šum není, nepřidávejte subagenty.
Anti-vzor 4. Nejasné prompty na první úrovni.
To je nejnebezpečnější scénář. Pokud dáte orchestrátoru na úrovni 1 nejasný prompt, nejasnost se znásobí. Jeden nejasný prompt úrovně 1 se změní na 4 nejasné prompty na úrovni 2 a 16 na úrovni 3. V době, kdy pravnoučata začnou pracovat, nebudou ani vědět, co mají hledat.
Anti-vzor 5. Geometrický růst nákladů.
To je hlavní ekonomický argument: vnořování násobí spotřebu tokenů a tento efekt se s hloubkou kumuluje.
Hrubý výpočet: řetězec hloubky 3 s rozvětvením 3 na každé úrovni znamená 27 subagentů. To je nejméně 27krát více tokenů než u jednoduchého požadavku. V tarifu Claude Pro tento výpočet vyčerpá denní limit za pár hodin. Pokud máte tarif Max, za den vyčerpáte týdenní příděl.
Bonusový anti-vzor (z vlastní zkušenosti): „50 agentů dělá zbytečnou práci“.
Když se dívám na projekty jiných lidí, často vidím toto: „Mám 50 agentů v práci.“ Ptám se, co dělají. A těch 50 agentů dělá zbytečnou práci. Vytvářejí hromady nepotřebných výstupů, spoustu nezpracovaných shrnutí, duplicity a stěny logů. Každý dělá něco „obecně užitečného“, výsledkem je ale topící se kontext a účet za tokeny jako v malé firmě. Hloubka 5 tento problém neřeší — zhoršuje ho. Pokud už na úrovni 1 není jasné, kdo co dělá, hloubka 5 znamená pět úrovní zmatku.
Před spuštěním jakéhokoli subagenta si za půl minuty odpovězte na 4 otázky:
- Co přesně dělá (jednou větou)?
- Kterých souborů se dotýká?
- Co vrátí rodiči?
- Kdo to zkontroluje?
Pokud nedokážete odpovědět do 30 sekund, tento subagent by neměl existovat. Toto pravidlo jsem samostatně vysvětlil v průvodci o paralelních subagentech.
Proč vnořování bez kontextového inženýrství znamená 5 úrovní halucinací?
Klíčové sdělení
Hlavní past hlubokého delegování je chybějící kontext úkolu. Dítě automaticky nedostává celou konverzaci rodiče ani všechny přečtené soubory. Vlastní podagenti běžně načítají platné CLAUDE.md, pokud to konfigurace nevypne; tím se ale automaticky nenačtou všechny odkazované firemní soubory. Při každém předání dodejte přesné podklady, cesty a kontrakt výsledku. Pokud váš projekt nemá promyšlenou strukturu kontextu, čím hlubší strom, tím více se každé pravnukovské dítě vzdaluje realitě. Dostanete 5 pater halucinací, jedno na každé úrovni.
Právě v této chvíli se lidé často ptají: „Aktualizoval jsem Claude Code, přidal Agent do tools, strom se vytváří — ale konečná odpověď je pořád mimo. Proč?“
Odpověď je jednoduchá. Každý subagent v Claude Code začíná od začátku. Oficiální dokumentace uvádí:
Každý subagent začíná v novém, izolovaném okně. Nevidí historii konverzace, dovednosti, které jste už vyvolali, ani soubory, které Claude už přečetl.
Na úrovni 1 se to dá zvládnout: orchestrátor předá dítěti stručný popis úkolu. Na úrovni 3 ale pravnuk dostává od rodiče delegovací zprávu, přičemž i rodič měl jen delegovací zprávu. Každý předá dál jen malý kousek. Na úrovni 5 máte subagenta, v jehož okně je pouze fráze „zkontroluj tvrzení X“ a nic dalšího. Neví, na jakém projektu pracuje, jaký úkol řeší ani na co se má zaměřit.
Bez CLAUDE.md je pravnuk na páté úrovni jako zaměstnanec, který poprvé v životě přijde do kanceláře bez jakéhokoli zaškolení. Něco udělá, protože dostal úkol. Nebude to ale to, co projekt potřebuje.
Co dalšího se ve v2.1.172 změnilo kromě vnořování?
Klíčové sdělení
Vydání se celé týká subagentů. Vedle hlavní funkce obsahuje 4 opravy infrastruktury delegování. Jedna z nich opravuje chybu, k níž může dojít pouze při vnořování.
Otevřete úplný záznam změn v2.1.172 a uvidíte, že celé vydání se týká subagentů.
Oprava 1. Subagent běžící na pozadí už nezůstává v panelu agentů „zaseknutý“ jako aktivní po zastavení vnořeného subagenta, kterého spustil. Tato chyba může nastat pouze při vnořování.
Oprava 2. Omezení availableModels se nyní vztahují také na subagenty. Dříve mohli subagenti obejít omezení týmových modelů (například zákaz opus kvůli úspoře peněz) přepsáním vlastního nastavení. Ve v2.1.172 platí pravidlo všude.
Oprava 3. Šipka nahoru v historii promptů nyní zobrazuje prompty z aktuální karty subagenta, nikoli hlavního agenta. Jde o vylepšení pozorovatelnosti.
Oprava 4. Snížilo se využití CPU v nečinnosti: indikátor /goal už v nečinnosti nepřekresluje terminál frekvencí 5 Hz a uživatelské rozhraní se překresluje méně často, když pracují paralelní subagenti.
Chci zdůraznit, že všechny čtyři opravy se týkají subagentů. To znamená, že Anthropic vydal celou sadu infrastruktury pro vnořování, nikoli jen jeden řádek v záznamu změn. Vnořování se v Anthropic používalo už nějakou dobu před zveřejněním.
Kontrolní seznam: kdy vnořování pomáhá a kdy škodí
Klíčové sdělení
Před každým spuštěním nového subagenta projděte úkol pomocí 6 kontrol. Pokud alespoň 3 odpovědi zní „ano, použij hloubku“, udělejte to. Pokud jich je méně, zůstaňte u paralelismu nebo jediného subagenta. Ušetříte tokeny, nervy a pár hodin zjišťování, co vlastně dělal řetězec 27 vnořených spuštění.
Vnořování použijte, pokud:
- Úkol obsahuje dílčí úkol s velkým množstvím webových požadavků, grepů nebo čtení souborů.
- Je přijatelné o tento dílčí úkol přijít (pokud pravnuk vrátí „nic jsem nenašel“, orchestrátor může pokračovat).
- Nepotřebujete průběžné výsledky v hlavním okně.
- Máte
CLAUDE.mda sestavený kontext projektu, o který se subagent může opřít. - Dokážete jasně popsat, co každá úroveň vrátí (vstup, výstup, formát).
- Máte tarif Max nebo rezervu na ×27 tokenů.
Vnořování nepoužívejte, pokud:
- Jeden subagent dokáže úkol vyřešit bez šumu.
- Potřebujete průběžné výsledky v hlavním okně (to znamená, že chcete paralelismus).
- Projekt nemá CLAUDE.md nebo obsahuje jen málo obchodního kontextu.
- Prompty na úrovni 1 jsou nejasné (nejasnost se bude stromem šířit exponenciálně).
- Potřebujete rychlost — při srovnatelném výsledku je paralelismus rychlejší než hloubka.
- Máte tarif Pro a pracujete celý den — za pár hodin vyčerpáte limit.
Zdroje
Další materiály najdete na Ailoot.
Další podrobnosti
Časté otázky
Musím pro zkopírovaný recept vytvořit claim-extractor?
Ne. Opravený research-orchestrator sám vytáhne až pět tvrzení z dodaných podkladů. Vytvořte tři uvedené soubory: research-orchestrator, fact-verifier a web-deep-search, pak dodejte text zdroje či URL.
Omezuje povolení pouze fact-verifier počet spuštěných dětí?
Ne. Seznam typů agentů omezuje druhy, nikoli počet jejich vyvolání. Recept zvlášť omezuje úvodní extrakci na pět tvrzení; sledujte skutečná volání a tokeny.