Náhodné tirády o tom, jak jsme na tom s AI agenty:

Někteří jim neříkají agenti, ale "agenti pracovních postupů" s deterministickými toky jsou všude a fungují. kdokoli může vytvářet jednoduché workflow agenty, dokonce i začít bez kódových nástrojů jako Zapier a n8n. Agenti složitých pracovních postupů vyžadují mnohem více přemýšlení, aby je bylo možné vytvořit spolehlivě a efektivně. komplexní pracovní postup pro běžný a hodnotný případ použití, s příslušnými integracemi, může stát samostatně jako podnik a také skvělý GTM, který lze později rozšířit do dalších pracovních postupů nebo autonomnější práce.

Dynamičtější/autonomnější agenti začínají pracovat a jsou užiteční pro výzkum (zejména pokud je založen na webu) a kódování. méně spolehlivé, jakmile začnete přidávat další datové zdroje (např. API). Agenti pouze pro čtení se cítí bezpečně a snadno se testují, ale nechat autonomní agenty provádět akci (zápis) je děsivé. (Náhodný nápad na toto: bylo by skvělé, kdyby vám nástroje jako CRM umožnily "rozvětvit" vývojářské zrcadlo a spouštět automatizační experimenty, které můžete vrátit zpět nebo sloučit zpět.)

Dynamičtí agenti fungují dobře, když mohou (1) vytvořit a sledovat dobrý plán a (2) správně provádět úkoly a zároveň (3) najít správný kontext, který se vloží do každého kroku (jak plánování, tak každého úkolu). A konečně musí (4) průběžně reflektovat (ať už s lidským zásahem nebo bez něj), aby mohl vhodně upravit plán a také zlepšit způsob, jakým provádí neúspěšné nebo špatně fungující úkoly.

Plánování úkolů: Schopnosti uvažování LLM Funguje dobře pro jednoduché seznamy úkolů, které nevyžadují žádný soukromý kontext (jako je hloubkový výzkum, pouze řada vyhledávání na webu při shrnutí). Pokud chcete zkoumat mnoho entit, hloubkový výzkum nefunguje tak dobře, protože správa seznamu úkolů je relativně základní. Nástroje umělé inteligence založené na tabulkovém procesoru fungují lépe při zkoumání mnoha entit, protože efektivně přenášíte správu úkolů do tabulky, protože předávání dlouhých seznamů úkolů mezi výzvami zde nefunguje. Správa úloh v agentech kódování funguje s jednoduchými problémy, jednoduchým kódem nebo když začínáte od nuly. Jakmile se pustíte do složitějších již existujících projektů, jsou méně spolehlivé – a vývojáři zvyšují spolehlivost tím, že dokumentují, jak jejich kód funguje a je organizován (soubory .md), což agentovi umožňuje vytvářet informovanější seznamy úkolů. Složitý kód vyžaduje více dokumentů a nakonec z těchto dokumentů dynamicky přetahovat pouze relevantní kontext. Mnoho lidí/podniků má silné nezdokumentované názory na správné pořadí/přístup/nástroje pro řešení projektu a my potřebujeme více přístupů k tomu, abychom to zdokumentovali předem a za běhu. Dalším důvodem, proč kódovací a weboví výzkumní agenti dobře fungují, je to, že všichni používají stejnou sadu nástrojů, takže není třeba se "učit", jak tyto nástroje používat (více o tom dále).

Provádění úkolů: Úkoly jsou obvykle volání API (vyžadující autentizaci a pochopení toho, jak používat API, a základní datovou strukturu - která může být jedinečná jako v CRM nebo DB s vlastními tabulkami/sloupci), uvažování LLM (např. Shrnutí), kombinaci a dokonce i agenty pracovního postupu*. Výzkumný agent je ve skutečnosti jen webové vyhledávání a shrnutí ve smyčce. kódovací agenti jsou CRUD na vaší kódové základně, a možná webové vyhledávání pro výuková API. Auth a základní přístup k API se zdá být vyřešen (MCP se sem hodí), ale rád bych viděl více kolem kontextu specifického nástroje (zeptejte se uživatele, ale také analyzujte při počátečním připojení, ponořte se do existujících dat, abyste pochopili, jak se nástroj používá, jak jsou data strukturována, pro jaké scénáře/projekty nástroj používáme.), chyby/reflexe/zpětná vazba se musí proměnit v organizované učení, které se v případě potřeby vrací zpět do kontextu. Stejné nástroje lze použít pro různé účely a různými způsoby mezi organizacemi a my to musíme nějak zachytit/zdokumentovat, abychom úkoly dobře plnili.

Kontext: Představte si, že jste novým zaměstnancem ve společnosti. Během onboardingu se toho hodně naučíte (a čím lepší je onboarding, tím efektivnější jste od začátku) a pak je tu učení se za pochodu, které se rozpadá na učení se ze zkušeností organizace ("takhle děláme věci") a učení se z vlastních zkušeností - to první převládá ve velkých organizacích. Správa kontextu je podobná. Existují vrstvy kontextu, jako je meta (uživatel/společnost), specifické pro projekt/oddělení, specifické pro úkol, specifické pro nástroj atd. Vyvinuli jsme se od jednoduchých systémových výzev k hybridním strategiím RAG (vektor, klíčové slovo, graf), ale kromě toho, že máme data/kontext, potřebujeme pokyny, kdy a jak načíst kontext, který dnes vidíme v raných verzích - ale je zde spousta prostoru pro zlepšení. Nejedná se pouze o technický problém, ale také o obchodní problém - protože v podstatě musíte vytvořit onboarding doc, který pokryje každý scénář, který očekáváte. Jak se projekty stávají složitějšími, je třeba více přemýšlet o správném ořezávání kontextu, aby se do výzvy zahrnuly pouze relevantní informace a zároveň se minimalizoval irelevantní kontext.

Reflexe: máme nástroje pro monitorování agentů, které pokrývají náklady na LLM/api, pozorování, ale přiřazení úspěchu/neúspěchu je výzva - jednou z oblastí, kde mají kódovací agenti náskok před ostatními, je deterministický způsob, jak si všimnout selhání (prostřednictvím testování kódu). U mnoha dalších agentických úloh stále zjišťujeme správný způsob, jak shromažďovat lidské vstupy, abychom zlepšili budoucí výstupy. AFAIK, reflexe je dnes člověkem ve smyčce, kde je zpětná vazba z velké části přiváděna lidským vývojářům, aby vylepšili agenta, ale odemknutí přichází, když zjistíme, jak proměnit reflexi v sebezdokonalování – kde agent čerpá poznatky z neúspěchů při generování seznamu úkolů a provádění úkolů, aby to příště udělal lépe. V podstatě se reflexe musí proměnit v dobře organizovaný kontext, který lze vtáhnout do výzev kdykoli a pouze tehdy, když je to relevantní. to se vyvine do jemného doladění částí agenta a poté agentického RL prostředí - zde se stále zdá být docela brzy

*Dříve jsem zmínil předávání úkolů workflow agentům, které začíná dávat smysl, když by vašemu agentovi prospělo, kdyby neměl žádné workflow agenty jako nástroje (oproti tomu, že by pokaždé zjišťoval známý seznam úkolů), nebo když je váš systém dostatečně komplikovaný, aby specializovaní agenti se specializovaným kontextem a nástroji fungovali lépe. Nebo pokud využíváte agenty vytvořené jinými PPL (jeden vzorec, který jsem zde začal vidět, jsou koncové body API v přirozeném jazyce pro snadnější spolupráci agentů).

pokud bychom měli dnešní model Quality s nekonečným oknem obsahu (bez snížení kvality), nekonečnými výpočetními prostředky, nekonečným úložištěm, přístupem k prohlížeči a platební metodou, jedna smyčka LLM by pravděpodobně stačila k tomu, abychom udělali hodně práce pointou výše uvedeného nesmyslného bodu (nic není nekonečné) je, že orchestrace agentů je z velké části o řízení omezení tím, že navrhuje způsoby, jak odlehčit práci z LLM prostřednictvím struktury a kódu.

Agenti ve výrobě přicházejí v různých variantách: jako interní nástroje, jako samostatný produkt, který kombinuje různé nástroje, a zapečené jako funkce do základního nástroje. Mohou být obecné nebo specializované. Agenti chatu, hlasu a na pozadí se zdají být nejběžnějším rozhraním uživatelského rozhraní pro spouštění agentických toků.

Co mi ještě chybí?