Budování rozšiřitelných AI agentů: Hloubkový pohled na middleware architekturu

Úvod

FlowHunt využívá na backendu knihovnu LangChain a v tomto blogovém příspěvku se podívám na její middleware architekturu a na to, jak nám umožňuje vytvářet sofistikovanější AI agenty. Vývoj AI agentů dosáhl zásadního zlomu. Jak se jazykové modely stávají schopnějšími, roste poptávka po sofistikovaných architekturách agentů, které zvládnou komplexní, vícestupňová workflow. LangChain 1.0 přináší paradigmatickou změnu v tom, jak vývojáři agenty staví, a to díky inovativní middleware architektuře, která zásadně mění přístup k rozšiřitelnosti a skládání agentů. Tento komplexní průvodce se věnuje kompletnímu přepisu deep agentů na základě LangChain 1.0 a zkoumá, jak middleware proměňuje vývoj agentů z rigidního, monolitického přístupu do flexibilního, kompozitelného systému, který dává vývojářům do rukou nástroje pro stavbu výkonných agentů šitých na míru jejich potřebám.

Pochopení deep agentů: Za hranice jednoduchého volání nástrojů

Než se ponoříme do technické architektury, je důležité pochopit, čím se deep agenty liší od běžných systémů volajících nástroje. Deep agenty jsou v jádru sofistikované smyčky volající nástroje, rozšířené o specifické vestavěné schopnosti, díky nimž zvládnou komplexní vícestupňová workflow s minimálním zásahem člověka. Zatímco jednoduché agenty vykonávají úkoly sekvenčně voláním nástrojů a zpracováním výsledků, deep agenty zavádějí vrstvu inteligence a struktury, která zásadně mění přístup k řešení problémů.

Základy deep agentů stojí na čtyřech klíčových pilířích. Prvním jsou plánovací schopnosti, které agentům umožňují tvořit a následovat strukturované to-do seznamy, rozdělit složité úkoly na zvládnutelné kroky ještě před samotným provedením. Tato fáze plánování je zásadní, protože umožňuje agentovi promyslet celé workflow, identifikovat závislosti a optimalizovat pořadí operací. Druhým pilířem je přístup k souborovému systému, který agentům poskytuje trvalé úložiště pro odkládání kontextu – mohou zapisovat informace do souborů pro pozdější využití, místo aby vše uchovávaly v historii konverzace. To je zvláště cenné při správě velkého objemu dat nebo při udržení stavu napříč více operacemi. Třetím pilířem je spouštění podagentů, které umožňuje hlavnímu agentovi delegovat práci specializovaným podagentům pro dílčí úkoly, čímž vzniká hierarchická struktura zvyšující efektivitu a umožňující doménovou specializaci. Posledním pilířem jsou detailní systémové prompty, které poskytují komplexní instrukce k používání nástrojů, takže agent rozumí nejen tomu, jaké nástroje má k dispozici, ale i kdy a jak je optimálně využít.

Tyto schopnosti se ukázaly jako neocenitelné v produkčních systémech jako Manus a Cloud Code, kde agenti musí zvládat komplexní workflow, spravovat velké množství kontextu a inteligentně rozhodovat o delegaci úkolů. Cílem balíčku deep agentů je demokratizovat přístup k této sofistikované architektuře a umožnit vývojářům jednoduše stavět výkonné agenty bez nutnosti vymýšlet vše od začátku nebo do detailu chápat každou implementační nuanci.

Vývoj architektury agentů: Od monolitu k modularitě

Tradiční přístup ke stavbě agentů spočíval v tvorbě monolitických struktur, kde byla veškerá funkcionalita – plánování, správa nástrojů, manipulace se stavem i práce s prompty – pevně provázána v jednom kódu. Tento přístup vedl k několika problémům: rozšiřování agentů vyžadovalo zásahy do jádra, opětovné využití komponent mezi různými agenty bylo obtížné a testování jednotlivých funkcí izolovaně téměř nemožné. Vývojáři tak často buď přijímali omezení, nebo se pouštěli do rozsáhlých refaktoringů při přidávání nových schopností.

LangChain 1.0 tyto výzvy řeší revolučním konceptem: middleware. Middleware představuje posun paradigmat v architektuře agentů – přináší vrstvitelnou abstrakci, která vývojářům umožňuje skládat schopnosti agenta jako stavební bloky. Místo úpravy jádra smyčky agenta middleware zachytává a rozšiřuje konkrétní body v exekučním toku agenta, což umožňuje čisté oddělení zodpovědností a maximální znovupoužitelnost. Tato architektonická inovace mění vývoj agentů z monolitického “všechno nebo nic” přístupu na modulární, kompozitní systém, kde lze každou část funkcionality vyvíjet, testovat a nasazovat nezávisle.

Krása middleware spočívá v jeho vrstvitelném charakteru. Vývojáři mohou definovat více middleware komponent a aplikovat je v pořadí, přičemž každá vrstva přidává vlastní rozšíření stavu, nástroje a úpravy systémových promptů. Díky tomu může jediný agent těžit z plánování, přístupu k souborovému systému, podagentů i vlastních doménových rozšíření – to vše hladce skloubeno. Na pořadí aplikace middleware záleží, protože každá vrstva staví na předchozí a vytváří kumulativní efekt vedoucí k vysoce schopnému agentovi.

Jak middleware proměňuje schopnosti agentů

Porozumění middleware vyžaduje pohled na to, jak modifikuje základní ReAct (Reasoning + Acting) smyčku agenta. ReAct vzor, který se stal standardem pro agenty volající nástroje, spočívá v tom, že model nejprve zvažuje, jakou akci provést, akci vykoná prostřednictvím nástroje, sleduje výsledek a cyklus opakuje, dokud úkol nesplní. Middleware tuto smyčku nenahrazuje, ale cíleně ji rozšiřuje.

Middleware funguje třemi hlavními mechanismy. Nejprve rozšiřuje schéma stavu, přidává nové klíče a datové struktury, ke kterým má agent přístup a které může měnit. To umožňuje různým middleware komponentám spravovat vlastní stav, aniž by si navzájem překážely. Dále přidává nové nástroje do výbavy agenta, což modelu poskytuje další možnosti k dosažení cílů. Nakonec modifikuje požadavek na model, obvykle přidáním vlastních instrukcí do systémového promptu, které vysvětlují, jak nové nástroje používat a kdy je vhodné je použít.

Tento trojjediný přístup zajišťuje, že rozšíření pomocí middleware jsou komplexní a dobře integrovaná. Pouhé přidání nástroje bez rozšíření stavu či poskytnutí instrukcí by bylo neúčinné – model by nemusel chápat, jak nástroj použít nebo kdy jej vyvolat. Kombinací všech tří mechanismů vzniká soudržné rozšíření, které model dokáže efektivně využít.

Plánovací middleware: Strukturovaná dekompozice úkolů

Plánovací middleware je příkladem, jak middleware architektura umožňuje sofistikované schopnosti agentů. Tento middleware rozšiřuje schéma stavu agenta o to-do seznam, jednoduchou, ale mocnou datovou strukturu, která agentovi umožňuje udržovat strukturovaný plán postupu. Implementace je elegantní ve své jednoduchosti: middleware přidá jediný klíč do stavu, ale tento klíč odemyká výrazné schopnosti.

Aby byl plánovací nástroj efektivní, middleware poskytuje nástroj pro zápis úkolů, který modelu umožňuje vytvářet, aktualizovat a spravovat to-do seznam. Když agent narazí na složitý úkol, může nástroj využít k rozdělení úkolu na menší, zvládnutelné kroky. Místo snahy vyřešit vše najednou agent vytvoří plán, vykoná jednotlivé kroky a plán podle potřeby aktualizuje. Tento strukturovaný přístup má několik výhod: činí uvažování agenta transparentním a auditovatelným, umožňuje lepší zotavení z chyb (pokud selže jeden krok, agent upraví zbytek plánu) a často vede k efektivnějšímu provedení, protože agent promyslel celý postup dopředu.

Klíčové je, že plánovací middleware nepřidává jen nástroj – modifikuje i systémový prompt detailními instrukcemi k efektivnímu využití nástroje pro zápis úkolů. Tyto instrukce vysvětlují, kdy je plánování vhodné, jak plán správně strukturovat a jak jej aktualizovat podle postupu agenta. Tato úprava promptu je zásadní, protože řídí chování modelu a zajišťuje, že plánovací nástroj bude využíván strategicky, nikoli nahodile.

Middleware souborového systému: Odkládání a perzistence kontextu

Zatímco plánovací middleware se zaměřuje na rozklad úkolů, middleware souborového systému řeší jinou, stejně důležitou výzvu: správu kontextu a udržení stavu napříč operacemi. Tento middleware rozšiřuje stav agenta o slovník souborů, čímž vytváří virtuální souborový systém, do kterého může agent zapisovat a ze kterého může číst.

Na rozdíl od plánovacího middleware, který poskytuje jediný nástroj, middleware souborového systému nabízí více nástrojů pro různé operace se soubory. Agent může vypsat dostupné soubory, načítat obsah do kontextu, zapisovat nové soubory pro uchování informací a upravovat existující soubory pro aktualizaci dat. Tento přístup odráží realitu, že práce se souborovým systémem je různorodá a vyžaduje různé operace podle situace.

Middleware souborového systému je zvláště cenný při správě velkého objemu dat či udržení stavu napříč více operacemi. Namísto uchovávání všeho v historii konverzace (což by spotřebovalo tokeny a mohlo překročit limity kontextu) může agent informace zapisovat do souborů a načítat je dle potřeby. Například agent řešící výzkumný projekt může zapisovat zjištění do souborů, třídit je podle témat a při syntéze závěrů načítat relevantní soubory. Tento přístup výrazně zvyšuje efektivitu a umožňuje agentům pracovat s mnohem většími datovými sadami, než by bylo možné při omezení na kontextové okno.

Stejně jako plánovací middleware i middleware souborového systému zahrnuje vlastní systémové prompty, které vysvětlují efektivní využití nástrojů pro práci se soubory. Prompty radí, kdy informace zapisovat, jak soubory organizovat pro snadné vyhledávání a jak nejlépe spravovat virtuální souborový systém.

Middleware podagentů: Delegace a specializace

Middleware podagentů představuje nejsložitější část architektury deep agentů. Tento middleware umožňuje hlavnímu agentovi spouštět specializované podagenty pro izolované úkoly, čímž vzniká hierarchická struktura zvyšující efektivitu a umožňující doménovou odbornost. Implementace je složitější než u plánovacího či souborového middleware, protože musí zvládnout více scénářů a konfigurací.

Základem je nástroj pro úkoly, který hlavnímu agentovi umožňuje delegovat práci podagentům. Hlavní agent tímto nástrojem určí, který podagent má úkol řešit, a předá mu potřebné informace. Podagent úkol zpracuje a hlavnímu agentovi vrátí kompletní odpověď. Tento model delegace má několik výhod: izoluje kontext (podagent pracuje jen s relevantními informacemi), umožňuje specializaci (různí podagenti mohou mít různé nástroje a prompty) a často vede k čistšímu a efektivnějšímu provedení.

Middleware podagentů podporuje dva hlavní scénáře tvorby podagentů. Prvním je izolace kontextu, kdy univerzální podagent dostává stejné nástroje jako hlavní agent, ale řeší pouze úzký úkol. Podagent úkol vyřeší a vrátí čistou odpověď bez mezivýsledků, které by zahltily historii hlavního agenta. Tento přístup šetří tokeny a čas tím, že omezuje akumulaci zbytečného kontextu. Druhým scénářem je doménová specializace, kdy je podagent vytvořen s vlastním promptem a specifickou sadou nástrojů pro konkrétní doménu či typ úkolu. Například výzkumný agent může mít podagenta specializovaného na rešerše s přístupem k akademickým databázím, zatímco jiný podagent je zaměřen na analýzu dat s přístupem ke statistickým nástrojům.

Middleware umožňuje definovat podagenty dvěma způsoby. Podagenty volající nástroje jsou vytvořeni od nuly s vlastním promptem a sadou nástrojů. Tyto podagenty mohou mít zcela jiné nástroje než hlavní agent a umožňují tak skutečnou specializaci. Vývojáři mohou také každému podagentovi přiřadit vlastní model, což umožňuje využít různé modely pro různé úkoly. Vlastní podagenty poskytují ještě větší flexibilitu – vývojáři mohou přímo předat existující LangGraph grafy jako podagenty. To je zvláště cenné, pokud již mají vybudované sofistikované workflow a chtějí je hlavnímu agentovi zpřístupnit jako podagenty.

Důležité je, že také podagenti dostávají middleware, takže mohou využívat plánování, práci se souborovým systémem i další rozšíření. Podagenti tedy nejsou omezeni na jednoduché volání nástrojů – mohou být stejně sofistikovaní jako hlavní agent, mít vlastní plánování, přístup k souborům a dokonce i své podagenty.

Správa kontextu a middleware pro sumarizaci

Jak agenti vedou delší konverzace a řeší komplexnější úkoly, stává se limitem velikost kontextového okna. Middleware pro sumarizaci tento problém řeší tím, že automaticky spravuje kontext, když se příliš zvětší. Middleware sleduje historii konverzace a jakmile počet tokenů dosáhne limitu, automaticky historii zhušťuje sumarizací starších zpráv a zachováním těch aktuálních.

Tento middleware je zásadní pro produkční agenty, kteří musí udržovat kontext v rámci dlouhých konverzací. Bez něj by agenti narazili na limity kontextu a přišli o důležité historické informace. Díky sumarizaci si agenti udrží přehled o minulých interakcích a zároveň zůstanou v rámci limitů. Middleware inteligentně vyvažuje potřebu zachovat aktuální kontext (který je často nejrelevantnější) s potřebou sumarizovat starší kontext (který lze komprimovat bez ztráty klíčových informací).

Tento přístup ke správě kontextu odráží obecnější princip v návrhu agentů: kontext je vzácný zdroj, který je třeba spravovat pečlivě. Každý token použitý na kontext je token, který není k dispozici pro uvažování nebo výstup nástrojů. Automatickou sumarizací kontextu middleware zajišťuje, že agenti mohou efektivně fungovat i při dlouhodobém provozu.

Human-in-the-Loop: Middleware pro kritické aplikace

Pro kritické aplikace, kde agenti musí volat citlivé nástroje (například odesílání e-mailů, eskalace incidentů nebo finanční transakce), nabízí human-in-the-loop middleware zásadní ochranné mechanismy. Tento middleware umožňuje vývojářům určit, které nástroje mají být před spuštěním přerušeny, aby člověk mohl provést revizi a schválit (nebo upravit) volání nástrojů ještě před jejich vykonáním.

Human-in-the-loop middleware přijímá konfiguraci nástrojů, kde se určí, které nástroje mají být přerušeny a jaké akce může člověk s těmito voláními provést. Například před použitím citlivého nástroje na odesílání e-mailu lze middleware nastavit tak, že člověk musí akci schválit, upravit parametry nebo dát agentovi zpětnou vazbu, jak má dále postupovat. Tak vzniká spolupracující workflow, kde agent obstarává uvažování a plánování, ale lidé si zachovávají kontrolu nad kritickými akcemi.

Tento middleware je ukázkou toho, jak middleware architektura umožňuje vývojářům přidávat do agentů pokročilé prvky správy a bezpečnosti bez zásahu do core logiky. Různé aplikace vyžadují různou úroveň lidského dohledu a middleware přístup umožňuje každé aplikaci nastavit vhodnou míru zapojení člověka podle jejích potřeb.

Stavba rozšiřitelných agentů s vlastním middleware

Ačkoliv LangChain 1.0 nabízí několik předpřipravených middleware komponent, skutečná síla architektury spočívá v její rozšiřitelnosti. Vývojáři mohou vytvářet vlastní middleware rozšířením základní třídy middleware agenta a přidávat tak nové klíče stavu, nástroje a úpravy systémových promptů přesně podle svých potřeb.

Vývoj vlastního middleware se řídí stejným vzorem jako vestavěné middleware: rozšíří se stav o nové klíče, přidají se nástroje pracující s tímto stavem a systémový prompt se upraví instrukcemi pro efektivní využití nových nástrojů. Tento konzistentní vzor usnadňuje vývoj nových middleware komponent, které plynule spolupracují s těmi existujícími.

Například vývojář stavící agenta pro zákaznickou podporu může vytvořit vlastní middleware, které přidá nástroj na práci se zákaznickou databází, nástroj pro správu ticketů a nástroj pro vyhledávání v znalostní bázi. Takto rozšířený agent získá schopnosti specifické pro zákaznický servis, ale zároveň může využívat plánování, souborový systém i podagenty z vestavěných middleware.

Možnost tvorby vlastního middleware znamená, že vývojáře nelimitují vestavěné schopnosti. Pokud agent potřebuje specifický nástroj nebo správu stavu, lze jej implementovat jako middleware a hladce integrovat do agentí architektury.

FlowHunt a zjednodušený vývoj agentů

Zatímco LangChain 1.0 poskytuje architektonický základ pro stavbu sofistikovaných agentů, platformy jako FlowHunt posouvají vývoj agentů na další úroveň tím, že nabízejí no-code rozhraní pro tvorbu, nasazení a správu AI agentů. Komponenta AI Agenta ve FlowHunt využívá principy architektury založené na middleware a umožňuje vývojářům vytvářet výkonné agenty bez psaní kódu.

Přístup FlowHuntu k vývoji agentů je v naprostém souladu s filozofií middleware: kompozitelnost, rozšiřitelnost a jednoduchost použití. Vývojáři nemusí rozumět detailům implementace middleware – FlowHunt nabízí vizuální rozhraní, kde se schopnosti agenta skládají propojením komponent. Platforma zajišťuje orchestraci middleware na pozadí, takže vývojáři se mohou soustředit na definici cílů agenta, ne na to, jak je technicky implementovat.

Agenti ve FlowHunt lze nakonfigurovat s plánovacími schopnostmi, přístupem k souborům, podagenty i vlastními nástroji – vše přes intuitivní vizuální rozhraní. Tím se vývoj agentů demokratizuje a zpřístupňuje i těm, kdo nemají hluboké znalosti LangChainu nebo architektury agentů. Navíc FlowHunt poskytuje funkce jako podrobné logy agentů, sledování historie a nákladů, což vývojářům pomáhá pochopit chování agentů a optimalizovat jejich výkon.

Praktická implementace: Vytvoření deep agenta

Porozumění teorii architektury middleware je cenné, ale skutečná síla se projeví v praktické implementaci. Vytvoření deep agenta v LangChain 1.0 využívá funkci create_deep_agent, která poskytuje předpřipravené rozhraní pro konstrukci agentů se všemi výše popsanými schopnostmi.

Funkce create_deep_agent přijímá několik klíčových parametrů. Vývojáři předávají nástroje, ke kterým má mít agent přístup, vlastní instrukce popisující chování a cíle agenta a podagenty, kterým může hlavní agent delegovat práci. Funkce poté využije agent builder k sestavení agenta tak, že aplikuje jednotlivé middleware v daném pořadí.

Agent builder je místo, kde se odehrává magie. Nejprve vybere model (výchozí je Claude Sonnet 3.5, ale lze zvolit libovolný podporovaný model), pak aplikuje middleware ve specifickém pořadí. Nejprve se aplikuje plánovací middleware, který rozšiřuje stav o to-do seznam a přidává nástroj pro zápis úkolů. Následuje middleware souborového systému, který přidává nástroje a stav pro práci se soubory. Poté se aplikuje middleware podagentů, který umožňuje delegaci úkolů. Nakonec se použije middleware pro sumarizaci, který se stará o správu kontextu.

Toto sekvenční vrstvení middleware je zásadní: každá vrstva staví na předchozí, čímž vzniká kumulativní efekt. Systémový prompt je rozšiřován instrukcemi jednotlivých middleware v pořadí, takže model dostává komplexní návod, jak všechny schopnosti využívat. Schéma stavu se s každým middleware rozšiřuje, takže agent může udržovat více typů stavu. Sada nástrojů se s každým middleware rozrůstá, což modelu dává více možností k dosažení cílů.

Vývojáři mají možnost tento proces přizpůsobit volbou, které middleware použijí. Pokud agent nepotřebuje přístup k souborům, middleware souborového systému lze vynechat. Pokud nepotřebuje podagenty, middleware podagentů lze přeskočit. Tato flexibilita zajišťuje, že agenti mají přesně ty schopnosti, které potřebují – bez zbytečné zátěže.

Pokročilé vzory: Orchestrací více agentů

S rostoucí složitostí aplikací agentů potřebují vývojáři často orchestraci více agentů, kteří spolupracují na dosažení komplexních cílů. Middleware architektura umožňuje elegantní řešení orchestrací více agentů právě díky systému podagentů.

Jedním z mocných vzorů je hierarchická delegace, kdy hlavní agent rozdělí složitý úkol na podúkoly a každý deleguje specializovanému podagentovi. Například výzkumný agent může svěřit rešerši literatury jednomu podagentovi, analýzu dat druhému a syntézu závěrů třetímu. Každý podagent je optimalizován pro svůj konkrétní úkol, má vlastní prompty a nástroje šité na danou doménu. Hlavní agent koordinuje celý workflow, zajišťuje správné pořadí a integraci výstupů podagentů.

Dalším vzorem je paralelní provádění, kdy více podagentů současně řeší různé aspekty problému. Současná implementace zpracovává podagenty sekvenčně, ale architektura podporuje i paralelní vzory, kdy je více podagentů spuštěno najednou a jejich výsledky jsou agregovány. To je zvláště cenné u úloh, které lze rozdělit na nezávislé podúkoly.

Třetím vzorem je iterativní zpřesňování, kdy hlavní agent spouští podagenty pro vytvoření prvotních řešení, jejichž výstupy následně využívá k dalšímu zpřesnění a spouštění dalších podagentů pro hlubší analýzu. Tento vzor je vhodný pro komplexní úlohy, kde více iterací analýzy a zpřesňování vede k lepším výsledkům.

Tyto vzory ukazují, jak middleware architektura umožňuje sofistikované multi-agentní systémy bez nutnosti stavět složitou orchestraci od nuly. Middleware podagentů řeší mechaniku delegace a komunikace, takže vývojáři se mohou soustředit na definici workflow a schopností jednotlivých agentů.

Efektivita tokenů a optimalizace nákladů

Jednou z nejpraktičtějších výhod architektury deep agentů je její vliv na efektivitu spotřeby tokenů a optimalizaci nákladů. Kombinací plánování, přístupu k souborovému systému a delegace na podagenty mohou deep agenty řešit komplexní úkoly při výrazně nižší spotřebě tokenů než jednodušší agenty.

Plánování snižuje spotřebu tokenů tím, že agent promyslí workflow dopředu a vyhne se zbytečnému zkoušení a vracení se zpět. Agent tak najde efektivní cestu k řešení hned napoprvé. Přístup k souborovému systému snižuje spotřebu tokenů tím, že agent odkládá kontext do trvalého úložiště místo zachovávání všeho v historii konverzace. Informace, které nejsou okamžitě potřeba, lze uložit do souborů a načíst později, čímž se aktivní kontext udržuje úsporný. Delegace na podagenty snižuje spotřebu tokenů izolací kontextu – podagenti vidí jen informace relevantní k jejich úkolu, čímž se zabrání zbytečné akumulaci kontextu.

Middleware pro sumarizaci dále optimalizuje spotřebu tokenů automatickým zhušťováním historie, když přesáhne limit. Namísto ztráty přístupu k důležitým historickým informacím nebo překročení limitů middleware sumarizuje starší zprávy, zachová klíčové informace a uvolní tokeny pro aktuální u