Postman ukazuje, prečo produkčný AI agent potrebuje menej nástrojov a presnejší kontext

Postman a Amazon Web Services zverejnili technický pohľad na prevádzku Agent Mode, teda asistenta, ktorý v Postmane dokáže prirodzeným jazykom skúmať API, pripravovať testy, opravovať požiadavky, generovať dokumentáciu a vykonávať ďalšie úlohy. Nejde pritom o tvrdenie, že všetkých 40 miliónov vývojárov používajúcich platformu sú aktívnymi používateľmi agenta. Uvedené číslo opisuje veľkosť komunity, pre ktorú musí byť služba pripravená. Dôležitejšie než samotný rozsah je to, čo Postman označil za skutočné prekážky: priveľa dostupných nástrojov, kontext vytvorený pre používateľské rozhranie namiesto uvažovania modelu a náklady na opakované spracovanie rovnakých údajov.

Skúsenosť je zaujímavá aj mimo Postmanu. Mnohé firmy stavajú prvú verziu agenta ako model obklopený desiatkami funkcií, dokumentáciou a históriou konverzácie. Takýto prototyp môže fungovať pri starostlivo vybranom deme, no v produkcii narazí na meniaci sa stav aplikácie, oprávnenia, neúplné údaje, latenciu a nepredvídateľné používateľské požiadavky. Postman preto opisuje agenta skôr ako distribuovaný softvérový systém než ako rozšírený chatbot. Model je iba jedna vrstva; rovnako dôležité sú dátové rozhrania, orchestrace, pozorovateľnosť, bezpečnostné hranice a spôsob, akým sa do kontextu vyberajú informácie.

Viac nástrojov nemusí znamenať schopnejšieho agenta

Postman začínal s množstvom malých, presne vymedzených nástrojov. Takéto funkcie sa ľahšie kontrolujú a každá z nich môže mať jasnú schému vstupov. Pri zložitejšom pracovnom postupe však agent musí vykonať dlhý reťazec volaní, pričom sa po každom kroku vracia k modelu. Výsledkom je vyššia latencia a používateľ sleduje sériu úkonov, ktoré by človek vnímal ako jedinú operáciu. Podľa interného testovania Postmanu začali chyby vo výbere nástroja pribúdať, keď model súčasne videl približne viac než 40 nástrojov. Novšie a väčšie modely problém zmiernili, ale neodstránili.

Produkčná architektúra preto neponúka modelu celý katalóg. Koreňový agent vyhľadáva v reprezentáciách viac než 170 nástrojov, pre konkrétnu požiadavku vyberie približne 15 relevantných a odovzdá ich kontextovo oddelenému podagentovi. Čísla sú výsledkom implementácie Postmanu, nie univerzálnym limitom pre každý model. Všeobecný princíp je však prenosný: opisy nástrojov spotrebúvajú kontext a podobné funkcie zvyšujú riziko zámeny. Vývojový tím by preto mal merať nielen úspešnosť jednotlivých volaní, ale aj presnosť výberu nástroja pri reálnom zložení katalógu.

Ďalším problémom bolo prepojenie interných rozhraní so stavom aplikácie. Niektoré operácie predpokladali otvorenú kartu alebo pri čítaní údajov menili používateľské rozhranie. Pre človeka je takýto postup prirodzený, no agent potom namiesto práce s dátami napodobňuje klikanie. Postman postupne oddeľuje operácie od otvorených kariet, aby agent mohol požiadavky čítať či odosielať na pozadí. Ak operácia mení stav aplikácie, používateľ ju stále musí schváliť. To je dôležitá hranica medzi automatizáciou prípravy práce a autonómnym vykonaním potenciálne nevratnej zmeny.

Kontext sa musí navrhovať pre rozhodovanie, nie pre obrazovku

Najväčším obmedzením podľa Postmanu nebol nedostatok schopností, ale neúplný alebo nesprávne pripravený kontext. Dátový objekt vhodný na vykreslenie obrazovky často obsahuje veľa prezentačných detailov a zároveň nezdôrazňuje vzťahy potrebné na rozhodnutie. Pri jednoduchom odoslaní celého modelu používateľského rozhrania do promptu preto rastie objem tokenov bez zodpovedajúceho rastu presnosti. Postman vytvoril osobitné kontextové adaptéry, ktoré z každého typu entity vyberajú informácie potrebné pre agenta.

Systém rozlišuje široký, ale plytký kontext zbieraný automaticky a hlboký kontext k objektom, ktoré používateľ vybral. Druhá vrstva môže obsahovať napríklad kolekciu, špecifikáciu alebo konkrétnu požiadavku. Ani účelové adaptéry však neriešia všetko. Popisy, OpenAPI dokumenty a telá požiadaviek majú neobmedzenú veľkosť, takže môžu vytlačiť užitočné údaje z kontextového okna. Tím preto skúma súborovo orientovaný prístup, pri ktorom agent načíta detail až vtedy, keď ho potrebuje, namiesto toho, aby každý adaptér implementoval vlastné pravidlá skracovania.

Pri štruktúrovaných dátach Postman obmedzil počet jednoúčelových čítacích nástrojov ešte iným spôsobom. Agent dostane schému tabuliek a zostaví dotaz s filtrami, spojeniami či agregáciami. Jeden kontrolovaný dotazovací nástroj tak môže nahradiť množstvo funkcií určených pre jednotlivé analytické otázky. Takéto riešenie prenáša časť práce z tvorby nástrojov do kvalitného dátového modelu. Zároveň však vyžaduje prístupové pravidlá, obmedzenia dotazov a ochranu pred tým, aby model získal údaje mimo oprávneného priestoru používateľa.

Produktové znalosti nie sú vložené celé do statického systémového promptu. Postman používa znalostnú bázu s vyhľadávaním relevantných článkov podľa požiadavky a aktívneho kontextu. Keď používateľ pracuje napríklad s mock serverom, systém môže doplniť príslušnú dokumentáciu bez načítania celej znalostnej vrstvy platformy. Praktickým dôsledkom je nová povinnosť pri vývoji produktu: dokumentácia pre agenta musí byť aktualizovaná spolu s funkciou. Zastaralá znalostná báza môže viesť k presvedčivému, ale neplatnému postupu aj vtedy, keď samotný model a nástroje fungujú správne.

Prevádzka znamená smerovanie, cache aj geografické pravidlá

Agent Mode používa modely Claude dostupné cez Amazon Bedrock a konkrétny model môže voliť podľa požadovanej rýchlosti, ceny a náročnosti úlohy. Postman využíva aj medzi-regiónové inferenčné profily. Geografický profil obmedzuje spracovanie na podporované regióny v určenej oblasti, napríklad v Európskej únii, zatiaľ čo globálny profil uprednostňuje širšiu dostupnosť kapacity. AWS upozorňuje, že profil, kvóty a pravidlá IAM musia povoľovať všetky možné cieľové regióny. Európskym firmám preto nestačí zapnúť automatické smerovanie bez kontroly zmluvných, bezpečnostných a dátových požiadaviek.

Veľká časť vstupu sa medzi krokmi nemení: systémové pravidlá, základný katalóg nástrojov, vybraná dokumentácia a časť histórie sa posielajú opakovane. Postman preto využíva viacúrovňovú promptovú cache. Stabilné jadro má v opísanej konfigurácii hodinový kontrolný bod a premenlivejšia vrstva päťminútový. Podpora, ceny a dostupné časy platnosti závisia od modelu, takže nejde o nastavenie použiteľné bez merania. Bedrock poskytuje počty tokenov zapísaných do cache a načítaných z cache; tím môže porovnať úsporu s cenou zápisu a so zmenou času do prvého tokenu.

Bezpečnostná vrstva zahŕňa schvaľovanie operácií meniacich stav a voliteľné redigovanie osobných údajov pomocou Bedrock Guardrails. AWS zároveň uvádza, že prompty a odpovede nepoužíva na trénovanie svojich modelov ani ich neposkytuje tretím stranám. Postman deklaruje režim nulového uchovávania pri podporovaných modeloch, no dostupnosť tejto vlastnosti je závislá od modelu. Organizácia preto musí posudzovať každý nasadený model samostatne a nemala by prenášať garanciu jedného poskytovateľa alebo konfigurácie na celý viacmodelový systém.

Čo si z toho môžu odniesť slovenské tímy

Pre menší slovenský produkt nemusí byť medzi-regiónové škálovanie prvou starosťou, ale princípy výberu nástrojov a tvorby kontextu sa prejavia už pri desiatkach používateľov. Užitočný začiatok je evidovať úspešnosť celej úlohy, počet modelových a nástrojových krokov, chybne vybrané funkcie, spotrebu vstupných tokenov a zásahy človeka. Ak tím sleduje iba kvalitu konečnej textovej odpovede, môže prehliadnuť, že agent použil nesprávny zdroj, vykonal nadbytočné volania alebo dospel k správnemu výsledku náhodou.

Postman zatiaľ nezverejnil produkčnú implementáciu ako otvorený repozitár a publikované výsledky neobsahujú nezávislý benchmark úspešnosti, latencie ani nákladov. Hranica približne 40 viditeľných nástrojov, výber približne 15 funkcií a opísané vrstvy cache preto treba chápať ako prípadovú štúdiu jednej rozsiahlej aplikácie. Hodnota zverejnených poznatkov je inde: ukazujú, že cesta od dema k spoľahlivému agentovi vedie cez zjednodušenie rozhraní, explicitné oprávnenia, účelový kontext a merateľnú prevádzku, nie iba cez nasadenie výkonnejšieho modelu.