Agentová infraštruktúra: prečo klasický cloud nestačí

Agentová infraštruktúra sa od klasického cloudu líši v jednej veci: agent nebeží ako krátky HTTP request, ale ako dlhý proces so stavom, pamäťou a desiatkami volaní nástrojov. Bežné webové aplikácie sú optimalizované na milióny krátkych bezstavových požiadaviek. Agent je opak: má málo behov, každý je dlhý, nepredvídateľný a drahý. To láme predpoklady, na ktorých stojí štandardný stack.

Píšem to z pozície človeka, ktorý agentové systémy nasadzuje do produkcie a platí za ne účty. Rozdiel medzi prototypom v notebooku a spoľahlivým behom pre reálnych používateľov je práve v infraštruktúre, nie v modeli.

Prečo agent zaťažuje infraštruktúru inak než webová aplikácia?

Klasická aplikácia spracuje požiadavku za stovky milisekúnd a uvoľní zdroje. Agent naopak beží minúty až hodiny, drží kontext, volá externé API a čaká na odpovede. Medzi volaniami väčšinou nič nepočíta, len drží stav. Pre bežný cloud je to drahý a neefektívny vzorec.

Predstavte si agenta, ktorý spracúva reklamáciu. Prečíta objednávku, zavolá skladový systém, počká na odpoveď, vygeneruje návrh a čaká na potvrdenie človekom. Väčšinu tohto času nerobí nič náročné, no server musí zostať nažive so všetkým kontextom v pamäti. Za nečinnosť platíte plnú cenu.

Kde presne to zlyháva

• Autoscaling^?Automatické pridávanie a uberanie serverov podľa zaťaženia. Pri agentoch zlyháva, ak sa riadi len vyťažením procesora. podľa CPU: škálovanie podľa vyťaženia procesora nedáva zmysel, keď agent 90 percent času čaká na API. Metrika je slepá voči skutočnému zaťaženiu.
• Timeouty: load balancery a brány sú nastavené na sekundy, nie na hodinové behy. Agent spadne na infraštruktúre skôr, než dokončí úlohu.
• Stav a pamäť: bezstavové servery predpokladajú, že požiadavku dokončí ktokoľvek. Agent potrebuje pokračovať tam, kde skončil, aj po výpadku.

Čo je najdrahšia časť agentovej infraštruktúry v produkcii?

Nie je to inferencia^?Samotný beh jazykového modelu, teda výpočet odpovede na základe zadania. Býva len jednou z nákladových položiek agenta. modelu. Najdrahšie a najkrehkejšie je udržať desiatky nástrojov spoľahlivo pospájané, izolovať ich navzájom a nezaplatiť za behy, ktoré nič nerobia. Orchestrácia^?Riadenie poradia a spolupráce viacerých krokov a nástrojov, ktoré agent počas jednej úlohy volá., izolácia a účtovanie nečinného času sú tri miesta, kde produkčné projekty najčastejšie krvácajú.

Analýza spoločnosti Solix v článku o tom, prečo agenti v podniku zlyhávajú, upozorňuje na rovnaký vzorec: chyba nebýva v jazykovom modeli, ale v tom, ako sú agenti napojení na dáta, nástroje a procesy firmy. Model je zvyčajne to najspoľahlivejšie z celej reťaze.

Kým dáme agentovi ďalší nástroj, počítame cenu chyby, nie cenu volania. Zle prečítaný sklad je nepríjemný. Zle zapísaná objednávka je drahá. Preto oddeľujeme čítanie od zápisu: agent smie sám čítať, každý zápis prechádza cez potvrdenie človekom. Je to konzervatívne, no za mesiace prevádzky nám tento princíp ušetril viac problémov než ladenie promptov.

Ak práve staviate prvé produkčné nasadenie a narazili ste na to, že prototyp funguje, no spoľahlivá prevádzka je iná disciplína, oplatí sa pozrieť na dvojdňový workshop k produkčnej AI, RAG a architektúre agentov pre CTO a architektov. Vedú ho ľudia, ktorí agentové systémy reálne prevádzkujú na AWS; má zmysel, ak už máte prototyp a riešite škálovanie, nie ak ešte len zisťujete, čo agent je.

Ako navrhnúť infraštruktúru, aby agent v produkcii vydržal?

Zjednodušene: navrhnite ju na dlhé, nárazové a stavové behy, nie na krátke bezstavové požiadavky. Znamená to prispôsobiť škálovanie, izoláciu aj účtovanie skutočnému správaniu agentov, nie predpokladom prevzatým z webových služieb.

1. Škálujte podľa počtu behov, nie podľa CPU. Relevantné je, koľko agentov beží súčasne a koľko drží pamäť, nie koľko počítajú.
2. Oddeľte výpočet od čakania. Keď agent čaká na externé API, nemal by blokovať drahé zdroje. Najviac šetrí pauzovanie a obnovenie stavu.
3. Izolujte spúšťanie nástrojov. Agent, ktorý spúšťa kód alebo volá systémy, potrebuje sandbox^?Izolované prostredie, v ktorom agent spúšťa kód alebo nástroje tak, aby prípadná chyba neohrozila zvyšok systému.. Chyba v jednom nástroji nesmie zhodiť celý beh ani ohroziť iných agentov.
4. Merajte náklad na jednu dokončenú úlohu. Nie cenu za token ani za hodinu servera, ale koľko stojí, kým agent reálne dotiahne úlohu do konca.

Podobný posun v myslení sme popísali aj pri orchestrácii agentov a dokumentácii pre code agenta: bez jasného rozdelenia úloh a spoľahlivého prostredia sa aj dobrý model stratí v reťazi krokov.

Kedy má vlastná agentová infraštruktúra pre firmu zmysel?

Vlastnú alebo špecializovanú infraštruktúru pre agentov riešte až vtedy, keď máte reálny objem behov a merateľné náklady na nečinnosť. Pre jeden interný nástroj s pár desiatkami behov denne stačí bežná serverless platforma. Investícia do špecializovaného stacku sa vráti až pri stovkách paralelných, dlhých agentových behov.

Triezve odporúčanie: začnite jednoducho, merajte cenu za dokončenú úlohu a chybovosť. Ak vám náklady na nečinné behy alebo timeouty začnú kaziť ekonomiku, potom je čas riešiť infraštruktúru navrhnutú priamo pre agentov. A skôr než agentovi dovolíte konať samostatne, ujasnite si, kto nesie zodpovednosť za jeho rozhodnutia; je to téma pre vedenie, nie len pre inžinierov, ako ukazujú aj prvé žaloby okolo AI systémov.