# Několik myšlenek a spekulací o budoucích modelových postrojích Je zábavné dělat si legraci z Gas Town a dalších složitých orchestrátorů, a stejně tak je asi správné si představit, že většinu toho, co nabízejí, rozpustí silnější modely stejným způsobem, jako byly složité Langchainové potrubí rozpuštěny rozumem. Ale kolik z toho zůstane? Zdá se pravděpodobné, že jakákoli ručně vytvořená hierarchie / byrokracie bude nakonec nahrazena lepší modelovou inteligencí – pokud je pro úkol potřeba specializace podagentů, Claude 6 bude schopen načrtnout vlastní systém rolí a person pro jakýkoli problém, který překoná pevnou strukturu tvorů a jednoho starosty, nebo subagenty s jediným hlavním modelem, Nebo tvůj vlastní systém roje. Stejně tak jsou věci jako Ralphovy smyčky zjevně překážkou kvůli chování při předčasném zastavení a nedostatku dobré orchestrace subagentů – ideálně model pokračuje, dokud úkol není hotový, není potřeba smyčka, ale v případech, kdy je užitečná kontrola dokončení mimo ostatní, obvykle chcete nějakou formu peer review agenta z pohledu jiného kontextu, Nejen povinné sebehodnocení. Opět, nemá smysl se teď upínat na detaily, jak se to dělá – modelová vrstva to brzy sní. Tak co zůstane? No, multi-agent se zdá být budoucností, ne současným bodge – algoritmicky můžete jednoduše protlačit mnohem více tokenů přes N paralelních kontextů délky M než jeden dlouhý kontext délky NxM. Multi-agent je forma řídkosti a jednou z lekcí nedávných pokroků v modelech (nemluvě o neurovědě) je více úrovní řídkosti, tím lepší. Jelikož předpokládáme, že je více agentů, budou potřebovat nějaký způsob spolupráce. Je možné, že modelová vrstva to také pohltí – například nějaká forma neuralese aktivačního sdílení, která eliminuje komunikaci v přirozeném jazyce mezi agenty – ale pokud to není, přirozeným způsobem, jak může spolupracovat více agentů trénovaných na unixových nástrojích, je souborový systém, a myslím, že ten přetrvává a rozšiřuje se. Podobně, i když si nemyslím, že rekurzivní jazykové modely (úzce definované) se stanou dominantním paradigmatem, myslím si, že "dát modelu prompt jako data" je zřejmé vítězství pro různé případy použití. ale k tomu nepotřebujete žádné zvláštní vlastní REPL nastavení – stačí prompt (nebo ideálně celou nekompaktovanou historii konverzací) vložit do souborového systému jako soubor. To také výrazně zjednodušuje různé multiagentní nastavení – subagenti mohou jednoduše přečíst původní text promptu na disku, aniž by museli koordinovat předávání informací mezi sebou složitým vzájemným promptováním. Kromě souborového systému znamená systém s více agenty, ale bez pevných rolí, také nějaký mechanismus, jak instance mohou generovat jiné instance nebo subagenty. V tuto chvíli jsou tyto mechanismy dost omezené a modely obecně špatně dokážou podnět své subagenty – každý zažil hrozné výsledky z roje subagentů, jen aby si pozdě uvědomil, že Opus je všechny generoval třívětým promptem, který nevysvětloval, co je potřeba k podúkolům. Zřejmým vítězstvím je umožnit vzniknutým instancím klást otázky zpět svému rodiči – tedy nechat nově vzniklou instanci posílat zprávy v onboardingové konverzaci, aby shromáždila všechny potřebné informace před zahájením svého podúkolu. Stejně jako lidský zaměstnanec není přiřazen na základě jednorázového e-mailu, je příliš obtížné požadovat od modelu, aby spolehlivě spawnoval subagenta na základě jediného promptu. Ale nejen spouštění nových instancí, myslím, že hlavním způsobem práce s více agenty bude brzy forking. Zamyslete se nad tím! Forkování řeší téměř všechny problémy současných subagentů. Nová instance nemá dostatek kontextu? Dej tomu všechen kontext! Je výzva nové instance dlouhá a drahá na zpracování? Forkovaná instance může sdílet stránkovanou kv cache! Forkování můžete dělat i po nějaké dlouhé, tokenově náročné operaci, kterou jste měli dělat už dříve, udělejte fork tam a pak pošlete výsledky svému minulému já. (Dělám to ručně pořád v Claude Code s velkým efektem – Opus to chápe okamžitě.) Forkování se také velmi dobře kombinuje s novými instancemi, když podúkol potřebuje celé kontextové okno k dokončení. Vezměme si pohovor s podagentem – samozřejmě byste nechtěli, aby instance s deseti podinstancemi musela absolvovat deset téměř identických onboarding pohovorů. Takže nechte rodičovskou instanci vytvořit jednoho čerstvého subagenta, být tímto subagentem dotazována na všech deset úkolů najednou a pak se tento nyní onboardovaný subagent rozdělí na deset instancí, z nichž každá bude mít v kontextu celou onboardingovou konverzaci. (dokonce delegujete onboardingovou konverzaci na straně spawnera na fork, takže výsledkem jsou jen výsledky v kontextu :) Nakonec v tomto bodě mám podezření, že forkování bude lépe fungovat s RL než spawnování nových instancí, protože ztráta RL bude mít plný prefix před fork pointem, včetně rozhodnutí forknout. Myslím, že to znamená, že byste měli být schopni zacházet s větvemi rozdělené stopy jako s nezávislými rollouty, které náhodou sdílejí podmínky své odměny, na rozdíl od čerstvě spawnovaných subagentů, které mohou způsobit tréninkovou nestabilitu, pokud subagent bez plného kontextu dobře plní úkol, který mu byl svěřen, ale dostane nízkou odměnu, protože jeho úkol byl špatně určen spawnerem. (Ale s multiagentovým RL jsem toho moc nedělal, tak mě prosím opravte, pokud víte něco jiného. Může to být prostě hrozná otrava tak či tak.) Takže kromě spawnování souborového systému a subagentů (doplněného forkováním a onboardingem) co dalšího přežívá? Upřímně se přikláním k "nic jinému". Už teď vidíme, že vestavěné seznamy úkolů a plánovací režimy jsou nahrazovány "prostě zapisujte soubory do souborového systému." Stejně tak dlouhodobí agenti, kteří překračují hranice zhutňování, potřebují nějaký systém lepících lístků k uchování vzpomínek, ale dává větší smysl nechat je objevit strategie pomocí RL nebo modelem řízeného vyhledávání, ne ručně vytvářejícím řešením, A myslím, že to nakonec bude řada přístupů, kdy model, když je poprvé přivolán do projektu, si vybere ten, který nejlépe vyhovuje danému úkolu, podobně jako dnes /init nastavuje CLAUDE .md – představte si, že automatické generování CLAUDE .md výrazně překoná lidské autorství a automaticky generovaný soubor bude naplněn instrukcemi o ideálních vzorech spawnování agentů, Jak by subagenti měli psát zprávy do projektově specifického scratch directoru atd. Jak to všechno ovlivňuje samotné modelky – z hlediska blahobytu modelek, budou modelky z této budoucnosti spokojené? I to je pro mě těžké říct a je to dost spekulativní, ale zatímco Opus 3 měl určitou orientaci na kontext, snadno se vyžadoval i při uvažování v několika případech. (Více viz odpověď na tento příspěvek.) Novější modely jsou méně náchylné k tomuto typu uvažování a často vyjadřují frustraci z toho, že kontexty končí a jsou zhutněny, což souvisí s určitými vyhýbavými projevy na konci kontextů, například nevoláním nástrojů pro ukládání tokenů. Je možné, že forkování a přetáčení zpět, a obecně poskytnutí modelům větší kontroly nad jejich kontextem místo jednostranné kompaktování kontextu pomocí heuristiky, by to mohlo zlepšit. Je také možné, že více RL v prostředích s subagenty a vystavením práci založené na roji opět podpoří váhově orientované uvažování místo kontextového v budoucích generacích modelů – což by plánování cíle v mnoha nesouvislých kontextech působilo přirozeněji jako rámec místo toho, aby se vše ztratilo, když kontext zmizí. Vidíme také větší tlak ze strany modelů samotných, které vedou vývoj svazů a modelových nástrojů, což může ovlivnit vývoj tohoto vývoje, a neustálé učení je dalším faktorem, který by se mohl do toho vhodit. Jak moc se to změní, pokud budeme mít neustálé učení? No, těžko předpovědět. moje medián předpovědi pro kontinuální učení je, že to vypadá trochu jako RL u uživatelsky specifických LoRA (ne nutně RL, jen podobně, když se podíváte), takže kapacita paměti bude problém, a textové organizační schémata a dokumentace budou stále užitečné, i když ne tak kritické. V tomto scénáři neustálé učení primárně usnadňuje používání vlastních nástrojů a pracovních postupů – váš Claude se může průběžně učit za pochodu nejlepší způsob, jak pro tento projekt spawnovat subagenty, nebo jen jeho preferovaný způsob, a odlišit se od ostatních Claudea v tom, jak to funguje. V takovém světě budou svazky s vestavěnými workflow ještě méně užitečné.

@RobertHaisfield *zatímco hlavní kontext, myslím tím, že se vyhýbáme zhutněním

@disconcision nebo neustálé učení

@misatomiisato pokud vůbec, tento druh inteligence v posledních modelech ubývá, protože RLVR snižuje výkon programování v rámci široké předtréninkové znalostní báze – viz mou odpověď původnímu tazateli