Subagenti nejsou organizační schéma

V Anthropicově výzkumu je číslo, které agentní roje prodává velmi účinně. Systém s vedoucím agentem na Claude Opusu, který deleguje na subagenty běžící na Claude Sonnetu, porazil jednoho Opuse o 90,2 % v jejich interním výzkumném hodnocení.

Je tam druhé číslo od téže organizace, které by vás mělo od sahání po něm zdržet: implementace s více agenty spotřebují na srovnatelné práci třikrát až desetkrát víc tokenů než jeden agent.

A je tam věta z vlastního návodu Anthropicu, kdy systémy s více agenty používat, kterou skoro nikdo necituje:

„Dobře navržený jediný agent s vhodnými nástroji zvládne mnohem víc, než většina vývojářů čeká."

To je firma s nejsilnějším obchodním důvodem doporučit vám deset agentů, jak vám radí začít jedním. Stojí za to rozumět proč.

Co subagent doopravdy je

Odloupněte řeči o týmech a osádkách a zbude úzký, mechanický princip.

Subagent je samostatná instance modelu s vlastním kontextovým oknem, vlastním systémovým promptem a vlastním omezeným seznamem nástrojů. Vedoucí agent jí zadá vymezený úkol. Ona odejde a pracuje — často spotřebuje desetitisíce tokenů zkoumáním, čtením a zahazováním — a vrátí se se zhuštěným shrnutím, obvykle o jednom až dvou tisících tokenů.

V té nesouměrnosti je celý nápad. Vedoucí agent nikdy neuvidí těch čtyřicet tisíc tokenů slepých uliček. Uvidí závěr. Jeho vlastní kontext zůstane dost čistý na to, aby mohl dál přemýšlet o skutečném problému.

Proč se za čistý kontext vyplatí platit

Důvod, proč to pomáhá, je vlastnost samotných modelů — a stojí za to ji znát, protože vysvětluje většinu chování agentů, které lidem přijde záhadné.

Anthropic popisuje rozpočet pozornosti, který se s přibývajícími tokeny vyčerpává. Transformery vztahují každý token ke každému jinému — vztah roste s druhou mocninou — takže s rostoucím kontextem se „schopnost modelu tyto párové vztahy podchytit tenčí". Ten publikovaný jev má jméno: context rot, hniloba kontextu. S rostoucím počtem tokenů klesá přesnost vybavování.

Dlouhé sezení tedy není neutrální. Každý nepotřebný výsledek hledání, každý soubor, který jste přečetli jednou a už ho nepotřebovali, každý opuštěný přístup — to všechno tam pořád leží a soupeří o pozornost s tím, na čem vám záleží.

A přesně tenhle problém subagent řeší. Ne „víc pracantů". Míň šumu v kontextu, na kterém záleží.

Rozdělení, které skoro každý zvorá

Tady je část, kvůli které stojí za to tenhle článek psát, protože je kontraintuitivní a právě v ní většina týmů o ten přínos přijde.

Přirozený způsob, jak práci mezi agenty rozdělit, je podle rolí. Plánovač. Programátor. Tester. Revizor. Přesně tak byste obsadili tým lidí, sedí to na pracovní pozice, které každý zná, a je to struktura, ke které většina agentních frameworků svádí.

Anthropic to pojmenovává jako selhání:

Rozklad podle typu problému — dělení práce podle rolí — vytváří „ztrátu kontextu při každém předání" a ruší přínosy více agentů.

Ten mechanismus je snadno vidět, jakmile se na něj podíváte. Váš plánovač si vybuduje bohaté porozumění problému a pak předá tři odstavce. Váš programátor si to porozumění postaví znovu od nuly, hůř, a předá diff. Váš tester netuší, které části byly rizikové a které samozřejmé. Každá hranice zahodí přesně ten kontext, kvůli kterému byla předchozí fáze užitečná — a Anthropic výsledek popisuje bez obalu: „agenti utratí víc tokenů za koordinaci než za samotnou práci".

Alternativou je dělit podle kontextu: podle toho, jaký soubor informací který kus práce potřebuje. Tři subagenti, z nichž každý prohledává jiný podsystém, je dobré rozdělení, protože žádný z nich nepotřebuje to, co četli ostatní. Plánovač a programátor je špatné rozdělení, protože programátor potřebuje všechno, co se plánovač dozvěděl.

Tři případy, kdy to opravdu vyhrává

Anthropic jmenuje tři a všechny jsou variantou téhož.

Ochrana kontextu. Když dílčí úkol zaplaví pracovní kontext informacemi, které další kroky nikdy nevyužijí — logy, výsledky hledání, celé adresáře přečtené kvůli jedné odpovědi. Pošlete to pryč, vraťte si odpověď.

Paralelizace. Nezávislý průzkum nebo ověřování běžící současně. Deset hledání napříč kódem, každé s vlastním kontextem, hotové v čase jednoho.

Specializace. Skutečně odlišné sady nástrojů nebo domény, kde úzký seznam nástrojů usnadní každému agentovi rozhodování. Anthropicův návod ke kontextu je v tom výslovný: nabobtnalé sady nástrojů „vedou k nejednoznačným rozhodovacím bodům o tom, který nástroj použít". Kratší seznam není jen úhlednější, on i líp funguje.

A případy, kdy ne

Tentýž návod je stejně jasný v tom, co nechat v jednom agentovi:

• Po sobě jdoucí fáze jedné úlohy. Plánování, pak implementace, pak testování téhož kusu práce.
• Těsně provázané komponenty, které se spolu musí neustále domlouvat.
• Cokoli se sdíleným stavem, který se musí držet synchronizovaný.

Je tu ještě jedno selhání, které stojí za pojmenování, protože je drahé a tváří se jako úspěch. Anthropic mu říká problém předčasného vítězství: ověřovací subagenti označí práci za v pořádku po minimálním testování, bez důkladné validace.

Jestli vám to zní povědomě, je to tatáž díra, na kterou jsme narazili u výsledku Firefoxu: kontrolor bez skutečné definice správnosti schválí skoro cokoli. Přidání „revizního agenta" rozhodčího nevytvoří. Vytvoří druhý názor od téhož modelu, což má mnohem menší cenu, než jak to působí.

Co to stojí a kdy se to vyplatí

Berte ta čísla vážně, protože rozhodují častěji než architektura.

To poslední číslo je nejzajímavější. Ten zisk nebyl záhadná emergentní týmová spolupráce — vznikl hlavně z toho, kolik přemýšlení ta architektura umožnila, rozprostřeného přes nezávislá kontextová okna. Což znamená, že poctivý popis systému s více agenty zní: kupujete si víc uvažování a platíte za ně po tokenech.

Otázka tedy nikdy nezní „máme použít agenty". Zní, jestli tahle konkrétní odpověď stojí za desetinásobek výpočtu. U výzkumné úlohy, auditu nebo revize, která by člověku zabrala dva dny — samozřejmě ano. U něčeho, co běží tisíckrát denně na rutinních vstupech — samozřejmě ne, a kdo to zjistí až v provozu, zjistí to na faktuře.

Jak bychom začali

Začněte jedním agentem a lepšími nástroji. Většina toho, na co lidé sahají po druhém agentovi, se ukáže jako špatný seznam nástrojů nebo vágní systémový prompt. To se opravuje levněji a každé pozdější rozdělení pak funguje líp.

Rozdělte, až když umíte pojmenovat kontext, který chráníte. Když je odpověď na otázku „co tenhle subagent drží mimo hlavní okno?" mlhavá, je to rozdělení jen ozdoba.

Dejte každému subagentovi nejmenší seznam nástrojů, který mu stačí. Nejednoznačnost v tom, který nástroj použít, je reálný a změřený náklad.

Nikdy nedělte práci, která se sama se sebou musí domlouvat. Když se dva kusy potřebují dohadovat, patří do jednoho kontextu.

Naceňte si to dřív, než to postavíte. Tři až deset násobek je publikované rozpětí. Rozhodněte předem, jakou cenu pro vás odpověď má.

Poctivé shrnutí

Subagenti jsou technika správy kontextu, která shodou okolností vypadá jako organizační schéma. Brát tu podobnost jako podstatu — najmout plánovače, programátora, testera a revizora — reprodukuje koordinační režii lidského týmu bez čehokoli, díky čemu lidské týmy fungují.

Dělte podle toho, co který kus potřebuje vědět, ne podle toho, jak byste tu pozici pojmenovali. A ujistěte se, že ta odpověď stojí za svou cenu, protože tohle je jediná část AI, kde účet přichází úměrně přemýšlení.

Často kladené dotazy