--- title: "Méně subagentů čili když příliš agentů v Claude škodí..." description: "Svádí to. Agenta rozdělíte na specialisty, každý tým si vezme svůj kousek a nahoře je spojí orchestrátor. Konečně na vás pracují desítky agentů! Vypadá to čistě, roste to spolu s organizací a každý ví, za co odpovídá. Anthropic po zkušenostech z podnikových nasazení tvrdí, že takový agent často dopadá hůř, je pomalejší a stojí víc než jeden agent se Skills. Kdy tedy subagenty slučovat, kdy si je nechat a jak poznat, že jste sloučením něco nerozbili?" date: 2026-10-26 author: "Patrick Zandl" url: https://www.vibecoding.cz/articles/claude-code/mene-subagentu-cili-kdyz-prilis-agentu-skodi/ --- > Markdown verze článku z Vibecoding.cz. HTML verze: https://www.vibecoding.cz/articles/claude-code/mene-subagentu-cili-kdyz-prilis-agentu-skodi/ > Přehled veškerého obsahu webu: https://www.vibecoding.cz/llms.txt # Méně subagentů čili když příliš agentů v Claude škodí... Anthropic 22. října zveřejnil [článek Diane Sarkis z týmu Applied AI](https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop), tedy lidí, kteří firmám pomáhají stavět agenty na Claude Platform. Článek je dlouhý a nese několik samostatných témat. Tady se podíváme na jedno z nich: co dělat se subagenty, které už máte v provozu. Je to důležité téma, protože se s ním setkávám často v praxi. Lidé pod dojmem nejrůznější AI slop článků vyžadují spouštění desítek agentů, protože taková je móda. Jenže často to nepomáhá, ba naopak je to kontraproduktivní. --- ## Proč se subagenti tak rozšířili (nejenom ve vývoji) Subagent je agent s vlastním kontextovým oknem, vlastními nástroji a vlastními instrukcemi, kterého řídí koordinátor. Anthropic je sám používá, například ve svém [výzkumném systému](https://www.anthropic.com/engineering/multi-agent-research-system). Dobře slouží k ověřování, k paralelní práci a k oddělení oprávnění nebo také k úspoře kontextu. Ve firmách se z nich ale stal organizační nástroj. Každý tým nebo každý typ problému dostane svého subagenta a centrální platformní tým nad ně postaví orchestrátor. Anthropic to v článku nazývá prostě Conwayovým zákonem: systém kopíruje komunikační strukturu organizace, která ho staví (Melvin Conway to formuloval už v roce 1967, takže nic nového pod sluncem). Upřímně, mě to nepřekvapuje. Rozdělit agenta podle týmů je politicky nejsnazší řešení. Nikdo nemusí nic předávat a každý má svůj píseček. --- ## Kde multi-agentní architektura ztrácí **Každé předání něco ztratí.** Subagent vrací orchestrátoru shrnutí, nikoli surová data. Hlavní agent tak pracuje s výtahem z výtahu. Anthropic to přirovnává k tiché poště: s každým předáním informace řídne. **Každé volání stojí čas.** Volání subagenta je další vnořená smyčka modelu se vším, co k tomu patří. Jeden zákazník při srovnání naměřil u jednoho agenta zhruba dvakrát kratší běh než u své multi-agentní varianty. **Subagenti bují.** Když si každý tým nasadí svého, firma skončí se stovkami překrývajících se agentů bez společných pravidel a bez konkrétního vlastníka. Do společného system promptu mezitím každý tým připíše svou větu. Anthropic tomu říká Frankenprompt: protichůdná pravidla a žádný jednotný hlas. Jedna firma podle článku zjistila, že kvůli tuctu specialistů v zákaznickém agentovi nedokáže udržet jednotný tón značky. A přidaná latence kazila zážitek zákazníkům. --- ## Co Anthropic navrhuje místo toho Jeden model, jedno kontextové okno a otevřená smyčka s nástroji. Limity (počet kol, rozpočet na volání, schvalování zápisů) hlídá harness. V každém kole model vydá dávku volání nástrojů. Harness je spustí paralelně a vrátí výsledky v surové podobě témuž modelu. Ten rozhodne, co dál: další dávka, dotaz na uživatele, nebo odpověď. **Kdo plánuje, ten i provádí.** Model si v prvním kole sepíše plán do kontextu a podle výsledků ho průběžně upravuje. Tohle je podle Anthropicu hlavní rozdíl proti orchestrátoru se specialisty. Plán už nepíše jeden agent a neprovádí jiný, takže ho jde změnit uprostřed práce. **Kontext se odkrývá postupně.** Model zpočátku vidí jen krátké popisy Skills a nástrojů. Celé znění si načte, až když ho potřebuje. Tím mizí hlavní důvod, proč týmy práci dřív dělily: obava, že se všechno do jednoho promptu nevejde. **Sdílený kontext dává lepší odpovědi.** Agent, který viděl výsledky všech předchozích kroků, je dokáže propojit. Sada shrnutí od subagentů tohle neumí. Postupy a doménové znalosti se přesouvají do Skills, akce a tvrdá omezení do nástrojů. Jak přesně tu hranici vést, je samostatné téma na další díl. --- ## Kdy si subagenty nechat Anthropic dává tři jasné podmínky, kdy si subagenty nechat či je zavádět: - jeden agent měřitelně ztrácí výkon kvůli přeplněnému kontextu, - potřebujete souběžně řešit víc úloh, z nichž každá dostane čisté kontextové okno, které po dokončení zahodíte, - agent neumí vybrat správný nástroj nebo má v system promptu protichůdné pokyny. K tomu dál platí nezávislé ověřování, kdy kontrolor nemá vidět, jak výsledek vznikal. **Hranici vést podle kontextu.** Dobrý subagent dostane kus práce, který od zbytku systému potřebuje málo, a vrátí kompaktní výsledek. Typicky nezávislé větve rešerše, komponenty s čistým rozhraním nebo ověřování naslepo. Když agenty rozdělíte podle typu problému, začne tichá pošta. Vezměte si český e-shop s agentem, který má specialistu na reklamace, na dopravu a na platby. Zákazník se zeptá: „Kdy mi přijde náhradní kus za reklamovaný mixér a vrátíte mi rozdíl v ceně?“ Na odpověď potřebujete všechny tři a orchestrátor mezi nimi přenáší shrnutí sem a tam. --- ## Začínáte? Postavte to rovnou správně Pokud agenta teprve navrhujete, máte výhodu: nic nemusíte slučovat. Stačí se vyhnout tomu, abyste si multi-agentní strukturu postavili z opatrnosti. **Výchozí volbou je jeden agent.** Subagenta přidáte, až měření ukáže jednu z podmínek z předchozí části. Dopředu ho přidávat nemusíte jen pro jistotu. Rozdělit hotového agenta je mnohem snazší než ho později slepovat zpátky. **Limity patří do harnessu.** Maximální počet kol, rozpočet na jeden úkol a schválení před každou zápisovou operací (vrácení peněz, změna objednávky). Model si v těchto mezích dělá, co uzná za vhodné. **Každá věc má své místo:** | **Co** | **Kam** | **Příklad z e-shopu** | | --- | --- | --- | | Postup, pravidla, úsudek | Skill | jak posoudit reklamaci, kdy eskalovat na člověka | | Akce a živá data | Nástroj | stav objednávky, vystavení dobropisu | | Podmínky a oprávnění | Uvnitř nástroje | „nejdřív ověř totožnost zákazníka“ | | Referenční materiál potřebný občas | Znalostní báze s vyhledáváním | obchodní podmínky, parametry výrobků | | Levné a skoro vždy potřebné | Kód před spuštěním agenta | dohledání zákazníka podle e-mailu | **Nástroje seskupte podle toho, co chce uživatel udělat.** Jeden nástroj na každý endpoint API rychle nafoukne jejich počet. Nad 30-50 definic se podle Anthropicu výběr nástroje zhoršuje. Pak pomůže tool search, který modelu ukáže jen krátké popisy a celou definici načte, až když ji potřebuje. **Tvrdá pravidla vynuťte v nástroji.** Prompt je doporučení a model ho občas obejde. Když nesmí odpovědět na termín doručení bez dotazu na dopravce, ať ten údaj nástroj pro stav objednávky dotáhne sám. Proč na tom tolik záleží, ukáže příběh s dopravcem níže. **Oprávnění řeší taky nástroje.** Každý nástroj zkontroluje, co smí volající uživatel vidět a dělat, a vrátí odmítnutí, kterému model rozumí. Jeden agent tak obslouží zákazníka, operátora podpory i vedoucího směny bez zvláštního agenta pro každou roli. **Eval od prvního dne.** Deset reálných úloh, každou pouštějte několikrát a hodnoťte podle rubriky. K tomu logujte, který Skill agent načetl a které nástroje zavolal. Až jednou budete zvažovat subagenta, budete mít s čím porovnávat. (Upřímně, tohle je ta nejnudnější a zároveň nejdůležitější rada celého článku.) --- ### Jak slučovat po krocích Máte-li subagenty už v provozu, Anthropic doporučuje postupovat pomalu a pokaždé měřit. **Nejdřív eval, potom změny.** Eval (sada testovacích úloh s hodnocením výsledku) postavíte dřív, než sáhnete na první subagenty. Na začátek stačí deset vzorových příkladů. Osvědčila se jedna společná end-to-end sada, kterou drží centrální tým, a k tomu malé sady, které s každým Skillem dodává tým, jenž ho vlastní. Na začátku stačí hodnotit závěrečnou odpověď podle rubriky. Dokud máte orchestrátor, sledujte i přesnost směrování: vybral správného subagenta? Po sloučení se ptáte jinak: načetl agent správný Skill, zavolal správný nástroj? Časem je dobré dojít k evalu, který měří dokončení celého úkolu, protože právě ten rozhoduje při srovnání architektur. Kde se interní systémy špatně přehrávají, pomáhá podle Anthropicu zaznamenávat časové značky důležitých událostí. Později z nich jde sestavit cílené testy. **Subagenty nejdřív volejte jako nástroje.** Hlavní agent drží konverzaci s uživatelem a subagenty volá jako nástroj se společným schématem odpovědi. Nemusíte nic přepisovat a získáte výchozí měření, se kterým budete porovnávat. Plné předání konverzace subagentovi má smysl jen tehdy, když musí s uživatelem mluvit přímo. Ztráty při předávání a latence vnořených smyček tím ovšem nezmizí. Je to mezikrok. **Slučujte nejdřív těsně provázané dvojice.** Podívejte se do provozu. Když velká část požadavků projde specialistou A a hned potom specialistou B, je to kandidát na sloučení. Stejně tak specialisté, kteří sahají na stejná data. **Pak po jednom do Skills a nástrojů.** Prompt subagenta se stane Skillem, jeho volání API nástroji přes MCP. Porovnáte eval se subagentem a bez něj. Subagenta si necháte jen tehdy, když sloučená verze dopadne hůř. --- ## Příběh s dopravcem Tohle je podle mě nejcennější místo celého článku. Praktická zkušenost. Anthropic zkoušel slučování na ukázkovém agentovi zákaznické podpory. Sloučení jednoho subagenta do jiného snížilo latenci. Zároveň přestala procházet úloha, která předtím fungovala. Agent měl po ruce nástroj na dohledání objednávky, a tak odpověděl sám. Specialisty na dopravu se na termín doručení vůbec nezeptal. A teď to podstatné: chyba se projevila jen v jednom ze dvou běhů. Z toho Anthropic vyvozuje tři pravidla: - dívejte se, které konkrétní úlohy se překlopily z úspěchu na selhání, protože celkové skóre takovou ztrátu snadno schová, - eval musí obsahovat úlohu pro každý řetězec agentů, který v provozu běží společně, a pro každé pravidlo, které agent nesmí porušit, - každou úlohu pusťte víckrát. Já bych z toho vyvodil ještě jednu věc. Struktura subagentů nesla nepsané pravidlo „na termín doručení se ptej dopravy“. Nikdo ho nikam nezapsal, protože ho zajišťovalo samo rozdělení práce. Při sloučení tiše zmizelo. Každá odstraněná vrstva architektury v sobě může nést pravidla, o kterých nevíte, dokud se nerozbijí. Proto je potřeba je při slučování výslovně přenést do Skillu nebo do nástroje. --- ## Migrační kit Anthropic k tomu vydal na GitHubu [single-agent-loop-kit](https://github.com/anthropics/single-agent-loop-kit). Je to řízený postup, který pomůže zmapovat současnou architekturu, vyhodnotit varianty a ověřit, která obstojí. Obsahuje demo na simulovaném systému, takže si ho můžete vyzkoušet dřív, než ho pustíte na skutečného agenta. Kit řetězí několik [Skills pro Claude API](https://code.claude.com/docs/en/commands): - **build-eval** pomáhá sestavit první end-to-end sadu i malé sady k jednotlivým Skills, - **hillclimb** postupně ladí aplikaci proti existujícímu evalu, takže po sloučení subagenta můžete nechat doladit popisy Skillu a nástrojů a zjistit, jestli sloučená verze dožene původní, - **prompt-audit** hledá v promptech pokyny psané pro starší modely, - **cost-optimize** ukazuje, kam jdou volání, a navrhuje úspory. Slučovat za vás nic nebude. Pomůže měřit, a to je na celé věci to podstatné. --- ## Co si z toho odnést S diagnózou souhlasím. Spousta multi-agentních architektur je kopií organizačního schématu a technickou nutnost v nich člověk hledá marně. A musím říct, že pokud se vám rozmnoží sub-agenti v systému, budete mít potíže se jich zbavit, stejně jako zbytečných pracovníků ve firmě. Budete si muset dát dost práce s tím, identifikovat je. Je ale také fér připomenout, kdo to píše. Výrobce modelů tvrdí, že jeho modely zvládnou v jedné smyčce víc, než čekáte, a že strukturu kolem nich můžete zahodit. To se mu samozřejmě hodí, už proto, abyste neměli hříšnou myšlenku přejít na levnější modely. Tvrdých čísel je v článku málo: dvojnásobné zrychlení u jednoho zákazníka bez popsané metodiky (a to je hodně chatrný doklad). A vlastní příklad s dopravcem ukazuje, že zjednodušení má cenu, kterou bez dobrého evalu neuvidíte. Bez výhrad bych si vzal jen samotnou metodu: měnit jednu věc po druhé, měřit a nechat jen to, co obstojí. Pokud máte agenta s pěti subagenty a žádný eval, začněte evalem. Slučování počká. --- *Zdroje: [Building agents: When to fold subagents into your main agent loop](https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop) (Anthropic, 22. 10. 2026), [single-agent-loop-kit](https://github.com/anthropics/single-agent-loop-kit). Stav k 24. 10. 2026.*