Ako fungujú AI agenti a ako si postaviť prvého agenta

Model, nástroje, stav, pamäť, agentný loop, guardrails, evaluácie a prvý funkčný workflow bez zbytočnej agentnej mágie

Stav technológií a zdrojov: 8. október 2026

Nosná definíciaAI agent nie je samostatný model. Je to systém, v ktorom model v opakujúcom sa cykle interpretuje cieľ, vyberá ďalší krok, používa nástroje alebo externé zdroje, prijíma výsledok späť do kontextu a pokračuje dovtedy, kým nesplní podmienku ukončenia alebo nenarazí na limit. Schopnosť konať vzniká zo spojenia modelu, nástrojov, stavu, oprávnení a runtime logiky, nie zo samotného LLM. 12610

Pojem agent sa používa veľmi široko. Niekedy označuje autonómny systém, ktorý hodiny rieši komplexnú úlohu, inokedy iba model, ktorý si môže raz zavolať vyhľadávanie. Pre pracovnú prax je užitočnejšia funkčná definícia: agent je softvérový systém, ktorý dostane cieľ, má k dispozícii určitý stav a sadu akcií a môže dynamicky rozhodovať, ktorú akciu vykoná ako ďalšiu. Anthropic rozlišuje medzi pevne orchestrated workflows a agentmi, pri ktorých model dynamicky riadi vlastný proces a používanie nástrojov. OpenAI podobne opisuje agentov ako systémy schopné plánovať a dokončovať úlohy pomocou nástrojov, pracovať s ďalšími agentmi a udržiavať kontext naprieč krokmi. 126

Prakticky je dôležité prestať uvažovať o agentovi ako o „inteligentnej osobe v počítači“. Model stále generuje ďalšie kroky pravdepodobnostne. Skutočný softvérový účinok vzniká až v momente, keď runtime preloží modelové rozhodnutie na tool call, API požiadavku, prácu so súborom, SQL dotaz, e-mail, zmenu v CRM alebo inú operáciu. Preto sa kvalita agenta nehodnotí iba podľa kvality textovej odpovede. Hodnotí sa aj správnosť výberu nástroja, argumentov, stavu, oprávnení, počtu krokov, schopnosti zastaviť sa, odolnosti voči chybným vstupom a kvality výsledku po celej trajektórii.

Z toho vyplýva základná zásada pre prvý projekt: nezačínajte multi-agentným systémom, dlhodobou pamäťou, desiatkami nástrojov a úplnou autonómiou. Najskôr vytvorte jedného úzko zameraného agenta, ktorý rieši jednu merateľnú úlohu a má iba minimum nástrojov potrebných na jej dokončenie. Anthropic vo svojich skúsenostiach so zákazníkmi opakovane odporúča jednoduché, skladateľné vzory pred zbytočne komplexnými frameworkmi. 6

1. Agent nie je chatbot, model ani obyčajná automatizácia

Chatbot typicky prijme vstup a vytvorí odpoveď. Aj keď môže používať nástroje, jeho základná interakcia býva krátka a používateľ zostáva hlavným orchestrátorom. Agentný systém posúva časť orchestrace do samotného systému: model môže po prvom kroku zistiť, že mu chýba údaj, vyhľadať ho, vyhodnotiť výsledok, spustiť ďalší nástroj, opraviť vlastný medzivýsledok a až potom vrátiť finálny výstup. Rozdiel teda nie je „AI verzus AI“, ale architektúra riadenia práce. 12

Agent sa líši aj od klasickej automatizácie typu if-this-then-that. V deterministickom workflow je poradie krokov definované programátorom. Ak príde faktúra, extrahuj polia, over IČO, zapíš záznam a pošli notifikáciu. Agentný systém dáva modelu väčšiu voľnosť v tom, ako sa dostať k výsledku. Môže napríklad rozhodnúť, či potrebuje webové vyhľadávanie, databázu, kalkulačku alebo ľudské potvrdenie. Táto flexibilita je silná práve tam, kde sa vstupy menia a nedá sa vopred napísať každá vetva pravidiel.

To však neznamená, že agent je vždy lepší. Ak úloha má stabilné vstupy, presné pravidlá a vysokú potrebu deterministickosti, klasický workflow býva lacnejší, rýchlejší a ľahšie auditovateľný. Agent má zmysel tam, kde je potrebný jazykový úsudok, práca s neštruktúrovanými dátami, dynamický výber nástroja, plánovanie viacerých krokov alebo adaptácia na medzivýsledky. Dobrý návrh často kombinuje oboje: deterministické časti zostanú v kóde a model rozhoduje iba tam, kde prináša hodnotu.

2. Z čoho sa agent technicky skladá

Najjednoduchší funkčný model agenta má šesť vrstiev: model, inštrukcie, nástroje, stav, runtime loop a kontrolné mechanizmy. OpenAI v Agents API opisuje agenta ako konfiguráciu modelu, inštrukcií, nástrojov a MCP serverov; runtime potom udržiava session a spracúva udalosti a položky vznikajúce počas práce. 2 Rozličné frameworky používajú inú terminológiu, ale jadro je podobné: model bez nástrojov môže navrhovať, no nemá čím konať; nástroj bez modelu vie konať, ale nevie dynamicky rozhodovať, kedy a prečo ho použiť.

Model je rozhodovacia a jazyková vrstva. Inštrukcie definujú cieľ, hranice a pravidlá. Nástroje predstavujú rozhrania do sveta mimo modelu: web search, file search, databáza, kalkulačka, CRM, e-mail, kalendár, shell, vlastná API funkcia alebo MCP server. Stav uchováva informácie, ktoré musia prežiť medzi krokmi alebo medzi turnmi. Runtime zabezpečuje opakovanie cyklu: model navrhne akciu, systém ju vykoná, výsledok sa vloží späť do kontextu a model sa rozhoduje znova.

Kontrolná vrstva je rovnako dôležitá ako samotný model. Patrí sem limit počtu krokov, tokenový alebo finančný rozpočet, časový limit, povinné schválenie citlivej operácie, allowlist nástrojov, validácia vstupov a výstupov, logovanie, tracing a evals. Bez tejto vrstvy je agent iba slučka, ktorá má oprávnenia. NIST a OWASP upozorňujú práve na riziko kombinácie modelových výstupov s nástrojmi, najmä ak systém dostane príliš veľkú funkcionalitu, oprávnenia alebo autonómiu. 8911

3. Agentný loop: čo sa deje medzi zadaním a výsledkom

Agent funguje iteratívne. Používateľ zadá cieľ, napríklad „zisti, ktoré tri konkurenčné firmy v poslednom štvrťroku zmenili cenotvorbu, a priprav stručný dôkazový report“. Model najprv vyhodnotí, čo potrebuje vedieť. Ak nemá dostatok informácií, rozhodne sa zavolať web search alebo interný zdroj. Výsledok nástroja sa stane novým kontextom. Model ho vyhodnotí a rozhodne, či má ďalšie kroky, alebo už môže vytvoriť finálny výstup.

Technicky nejde o to, že model „sám vykonáva internet“. Model typicky vytvorí štruktúrovaný tool call s názvom nástroja a argumentmi. Runtime overí, že nástroj existuje a že argumenty zodpovedajú schéme, zavolá externú funkciu a vráti výsledok modelu. Pri ďalšom kroku model pracuje aj s týmto výsledkom. OpenAI dokumentácia tools tento mechanizmus popisuje pre function calling, hosted tools, web search a remote MCP. 3 MCP špecifikácia rozlišuje resources, prompts a tools, pričom tools sú funkcie, ktoré môže model zvoliť na vykonanie akcie. 5

Slučka potrebuje stop condition. Najčastejšie ide o finálnu odpoveď bez ďalšieho tool callu, explicitný stav „done“, dosiahnutie maxima krokov, vyčerpanie časového alebo finančného rozpočtu, chýbajúce oprávnenie alebo povinný human gate. Ak stop condition chýba alebo je slabá, agent môže opakovane hľadať, prepočítavať či volať nástroje bez primeraného prínosu. Produkčný agent preto potrebuje nielen schopnosť pokračovať, ale aj jasné pravidlá, kedy má prestať.

CIEĽ POUŽÍVATEĽA / vMODEL: vyhodnoť stav a zvoľ ďalší krok / +--> finálna odpoveď ------------------> STOP / +--> TOOL CALL --> validácia --> nástroj/API/MCP / v výsledok nástroja / +----------> späť do kontextu modelu

4. Nástroje sú skutočná hranica medzi odpoveďou a konaním

Agent bez nástrojov je v podstate model s opakovaným uvažovaním nad textom. Nástroje z neho robia systém schopný získavať nové dáta a meniť vonkajší stav. Preto je návrh nástrojov dôležitejší než kreatívne pomenovanie agentovej osobnosti. Funkcia get_customer(customer_id) je čitateľná, úzko definovaná a ľahko kontrolovateľná. Funkcia do_anything(command) síce pôsobí flexibilne, ale zvyšuje riziko chybného alebo zneužiteľného správania.

Dobrý tool contract obsahuje jednoznačný názov, presný opis, typované argumenty, obmedzenia a predvídateľný výsledok. Kde je to možné, treba oddeliť read a write operácie. Nástroj na čítanie CRM kontaktu nemá automaticky obsahovať aj delete alebo export celej databázy. OWASP označuje nadmernú funkcionalitu, oprávnenia a autonómiu za tri hlavné príčiny rizika Excessive Agency. 9 Toto je praktický dôvod, prečo má mať agent iba nástroje, ktoré potrebuje pre konkrétnu úlohu.

Zvlášť dôležité sú nástroje s vedľajším účinkom: odoslanie e-mailu, platba, zmena záznamu, zmazanie súboru, nasadenie kódu alebo publikovanie obsahu. Pri nich sa oplatí navrhovať idempotentnosť, preview režim, schvaľovanie a auditný log. Ak sa agentný krok zopakuje po timeout-e, systém by nemal dvakrát odoslať platbu alebo dvakrát vytvoriť rovnakú objednávku. Agentný dizajn preto musí riešiť rovnaké princípy ako klasické distribuované systémy: retry, deduplikáciu, transakčné hranice a oprávnenia.

5. Stav a pamäť: agent potrebuje vedieť, čo sa už stalo

Stav je technický záznam o priebehu úlohy. Môže obsahovať históriu správ, výstupy nástrojov, identifikátory objektov, schválenia, čiastkové výsledky alebo rozpracovaný plán. Bez stavu by každý krok začínal od nuly. OpenAI rozlišuje napríklad session, conversation state a sandbox ako odlišné zdroje, ktoré treba spravovať podľa použitého runtime. 12 Dôležité je, aby používateľ nepredpokladal, že „pamäť“ znamená jedno univerzálne úložisko.

Krátkodobá pamäť zvyčajne znamená kontext aktuálnej úlohy alebo session. Dlhodobá pamäť môže byť databáza preferencií, vektorový index, knowledge graph, CRM alebo iný externý store. Retrieval nie je to isté ako pamäť modelu: agent najprv nájde relevantný záznam a až potom ho vloží do kontextu. Pri produkčnom systéme je výhodné držať autoritatívne údaje mimo modelového kontextu a načítavať ich podľa potreby, pretože tak možno dáta aktualizovať, auditovať a riadiť prístup.

Pamäť nesmie byť skládka. Každý uložený údaj zvyšuje budúce riziko nesprávnej personalizácie, zastaranosti alebo presakovania medzi kontextmi. Preto treba definovať, čo sa ukladá, na ako dlho, s akým tenantom alebo používateľom sa spája a čo je zdroj pravdy. Pri kritických faktoch je vhodnejšie uložiť referenciu na dokument alebo ID záznamu než voľnú modelovú sumarizáciu. Sumarizácia môže byť pracovná pomôcka, ale autoritatívny stav by mal zostať v systéme, ktorý je na to určený.

6. Plánovanie, rozklad úlohy a kontrola neistoty

Agentný výkon často vzniká z toho, že systém nemusí odpovedať na komplexnú úlohu jedným krokom. Model si môže vytvoriť plán, rozdeliť úlohu na podproblémy a postupne zhromažďovať dôkazy. Pri výskume to môže byť najprv identifikácia entít, potom zber primárnych zdrojov, následne extrakcia tvrdení a nakoniec porovnanie. Pri analytike môže najprv overiť dostupnosť dát, potom spustiť výpočet a až následne formulovať interpretáciu.

Plán však nemá byť samoúčelný. Príliš dlhý plán vytvorený pred získaním dát môže byť rovnako chybný ako okamžitá odpoveď. Robustnejší je adaptívny režim: agent má vysokú úroveň cieľa a krátky ďalší krok, po každom významnom výsledku reviduje stav a rozhoduje sa znova. Takýto loop umožňuje reagovať na chýbajúci zdroj, chybný predpoklad alebo neočakávaný výsledok nástroja.

Neistota musí byť súčasťou logiky, nie iba štýlovou vetou na konci. Agent má vedieť rozlíšiť „mám dostatok dôkazov na rozhodnutie“ od „mám iba indície“. Pri pracovných systémoch sa oplatí zaviesť explicitné polia ako confidence, evidence_count, missing_inputs alebo verification_status, ale netreba zamieňať modelom deklarovanú sebadôveru za kalibrovanú pravdepodobnosť správnosti. Dôležitejšie je, či sú k záveru dostupné konkrétne dôkazy a validačné pravidlá.

7. Kedy agenta nepoužiť

Najdrahšia chyba pri agentoch je postaviť agenta na problém, ktorý nepotrebuje agentnosť. Ak sa úloha dá spoľahlivo vyriešiť jedným modelovým volaním, SQL dotazom, klasickým skriptom alebo pevne definovaným workflow, agentný loop pridáva latenciu, cenu a nové body zlyhania. Anthropic pri návrhu agentných systémov odporúča používať najjednoduchšie riešenie, ktoré spoľahlivo funguje, a komplexitu pridávať iba vtedy, keď prináša merateľný prínos. 6

Agent nie je vhodný ani tam, kde je jediným akceptovateľným výsledkom striktne deterministické rozhodnutie podľa pravidiel. Model môže pomôcť extrahovať neštruktúrované údaje, ale samotné rozhodnutie možno následne vykonať pravidlovým enginom. Príkladom je výpočet DPH, kontrola limitu alebo aplikácia vopred schválenej cenovej matice. Jazykový model môže navrhnúť vzorec, ale výpočet má robiť kalkulačka alebo kód.

Ďalším varovným signálom je nejasný cieľ. „Zlepši firmu“ nie je agentná úloha, ale nešpecifikované želanie. Agent potrebuje operacionálny cieľ, merateľný výstup a hranice. Ak neviete definovať, podľa čoho zistíte, že úloha je hotová a správna, neviete ani postaviť spoľahlivú evaluáciu. Bez evals sa potom vývoj redukuje na pocit, že agent „vyzerá inteligentne“.

8. Prvého agenta postavte na jednej úzkej, merateľnej úlohe

Dobrá prvá úloha má štyri vlastnosti: opakuje sa, vstupy sú dostupné, výsledok sa dá skontrolovať a prípadná chyba nespôsobí nezvratnú škodu. Vhodný je napríklad research agent, ktorý zadanú firmu alebo tému preverí na definovaných zdrojoch a vytvorí dôkazový brief. Nevhodný prvý projekt je agent, ktorý má autonómne nakupovať, odosielať zmluvy, meniť produkčné dáta alebo robiť personálne rozhodnutia.

Pre ilustráciu použime agenta „Research verifier“. Jeho cieľom je dostať otázku, nájsť aktuálne autoritatívne zdroje, vyextrahovať iba tvrdenia podporené zdrojmi, označiť neistoty a vytvoriť krátky report. Potrebuje tri nástroje: web search, otvorenie zdroja a kalkulačku alebo kód na overenie čísel. Nemá nástroj na odosielanie e-mailov, zmenu databázy ani publikovanie. Týmto návrhom je už vopred znížená časť bezpečnostného rizika.

Ak prvá verzia funguje, možno ju rozšíriť o firemnú znalostnú bázu, export do DOCX, ticket alebo draft e-mailu. Každé rozšírenie by však malo mať dôvod podložený reálnymi prípadmi, nie ambíciu „urobiť agenta inteligentnejším“. Agentná architektúra sa má rozširovať podľa zistených potrieb a evalov, nie podľa počtu dostupných integrácií.

Odporúčaný prvý agentResearch verifier: prijme otázku, rozloží ju na overiteľné tvrdenia, nájde zdroje, skontroluje dátumy a čísla, oddelí fakt od interpretácie a vytvorí report s jasným statusom potvrdené / neoverené / sporné. Nemá write oprávnenia do externých systémov.

9. Najprv definujte kontrakt agenta, až potom prompt

Pri návrhu prvého agenta nezačínajte otázkou „aký prompt mu dám“. Najprv definujte pracovný kontrakt: aký vstup agent prijíma, aký výstup musí vytvoriť, z akých zdrojov smie čerpať, ktoré nástroje má k dispozícii, čo nesmie vykonať a kedy musí eskalovať človeku. Tým sa z neurčitého chatbota stane systém s jasným rozhraním.

Kontrakt by mal obsahovať acceptance criteria. Pri research agentovi môže platiť, že každé kritické tvrdenie musí mať zdroj, aktuálne tvrdenie musí byť časovo overené, čísla musia byť prepočítané, konflikt zdrojov sa nesmie skryť a report nesmie obsahovať nepodložené domnienky. Ak agent nevie získať dostatočný dôkaz, má vrátiť „neoverené“ a vysvetliť, čo chýba. Takéto kritériá sú základ evalov.

Až potom prichádzajú instructions. Ich úlohou nie je tvoriť osobnosť, ale operationalizovať kontrakt. Dobré inštrukcie popisujú cieľ, zdrojový režim, poradie krokov, nástrojové hranice, stop conditions a formát výstupu. Čím viac kritického správania možno vynútiť mimo promptu - typmi, schémami, permissions alebo kódom - tým lepšie. Prompt je mäkká riadiaca vrstva; bezpečnostne dôležité pravidlo by nemalo existovať iba ako veta v prompte.

10. Minimálna architektúra prvého agenta

Najmenšia produkčne zmysluplná architektúra môže byť prekvapivo jednoduchá. Potrebujete jednu agent definition s modelom a inštrukciami, tri úzko definované tools, session state, maximálny počet krokov a logger. K tomu pridajte validačný krok pred finálnym výstupom. V prvom prototype nie je potrebný orchestrátor, router ani subagent. Aj OpenAI Agents SDK quickstart začína jedným agentom a jedným behom a až následne pridáva tools a specialistov. 14

Dôležité je rozlíšiť runtime, tool implementation a model. Runtime riadi loop. Tool implementation je klasický softvér, ktorý musí bezpečne pracovať so vstupmi a autentifikáciou. Model rozhoduje, kedy tool zavolať a s akými argumentmi. Ak agent povie search_web({query: ...}), neznamená to, že model má priamy internetový prístup; runtime vykoná nástroj podľa jeho implementácie.

V nasledujúcom pseudokóde je zámerne vidieť iba to, čo je podstatné: agent má instructions, obmedzenú sadu nástrojov, max_steps a validačný výstup. Konkrétny SDK môže mať inú syntax, ale architektonický princíp zostáva rovnaký naprieč platformami. Google ADK, OpenAI Agents SDK aj iné frameworky poskytujú vyššiu vrstvu nad podobným model-tool-state loopom. 17

agent = Agent( name="research_verifier", model=MODEL, instructions=INSTRUCTIONS, tools=[search_web, open_source, calculator], max_steps=8, output_schema=VerificationReport)result = run( agent, input=user_question, session=session_state)if result.requires_human_review: request_human_review(result)else: return result.final_output

11. Tool schema musí byť navrhnutá pre model, nie iba pre API

Function calling funguje najlepšie, keď je rozhranie úzko špecifikované. Model potrebuje vedieť, čo funkcia robí, ktoré parametre sú povinné, aké hodnoty sú prípustné a čo funkcia vráti. Ak tool description obsahuje nejasné formulácie, model môže vybrať nesprávny nástroj alebo zostaviť zlé argumenty. Preto je návrh tool schém súčasťou prompt engineeringu aj API dizajnu.

Pri argumentoch je výhodné používať enumy, typy a validáciu. Namiesto voľného textu action="urob s kontaktom čo treba" je bezpečnejší explicitný parameter action s hodnotami read, draft_update, request_delete. Pri citlivých operáciách môže byť ešte lepšie rozdeliť ich na samostatné tools. Tak možno write nástroj kompletne odstrániť z kontextu agenta, ktorý ho nepotrebuje.

Aj návratový objekt by mal byť strojovo čitateľný. Nástroj by nemal vracať iba dlhú vetu „všetko dopadlo dobre“. Užitočnejší je objekt so statusom, ID, timestampom, zdrojom a chybovým kódom. Model potom dostáva menej nejednoznačný pozorovaný stav. Pri tool erroroch má runtime rozlišovať retryable chybu, validačnú chybu a definitívne zlyhanie; model nemá donekonečna opakovať rovnakú neúspešnú operáciu.

{ "name": "search_sources", "description": "Vyhľadá zdroje k overiteľnému tvrdeniu. Nevytvára ani nemení externé dáta.", "input": { "query": "string", "time_range_days": "integer / null", "preferred_domains": "string[] / null" }, "output": { "results": [ {"title":"string", "url":"string", "published_at":"date / null"} ] }}

12. Human-in-the-loop: človek nemá kontrolovať všetko, ale správne miesta

Human-in-the-loop sa často chápe ako univerzálna veta „človek to skontroluje“. To nie je dostatočný bezpečnostný mechanizmus. Treba definovať konkrétny bod, kedy sa agent zastaví, čo človek uvidí a čo presne schvaľuje. Pri e-mailovom agentovi môže byť bezpečná prvá verzia draft-only: agent nájde podklady a pripraví odpoveď, ale send tool vôbec nemá. Neskôr možno pridať send s explicitným potvrdením konkrétneho príjemcu a textu.

Human gate je najhodnotnejší pred ireverzibilnou alebo vysoko dopadovou akciou, nie po nej. Schválenie má byť viazané na presný action payload, aby sa po potvrdení nemohli potichu zmeniť parametre. Ak používateľ schvaľuje platbu 120 EUR dodávateľovi A, systém nemá po schválení poslať modelu priestor vytvoriť nový payload. Klasické bezpečnostné princípy transakčných systémov zostávajú platné aj pri agentoch.

Treba zároveň počítať s tým, že samotný schvaľovací dialóg môže byť manipulovaný nepriamym prompt injection. OWASP upozorňuje na útoky, pri ktorých nebezpečný externý obsah ovplyvní nielen akciu, ale aj spôsob, akým agent túto akciu prezentuje používateľovi na schválenie. 12 Preto by kritický approval screen mal zobrazovať deterministicky generované údaje z reálneho tool payloadu, nie iba modelový opis typu „toto je bezpečné, kliknite potvrdiť“.

13. Prompt injection a agent hijacking sú pri agentoch zásadne nebezpečnejšie

Chatbot, ktorý zle interpretuje škodlivý text na webe, môže vytvoriť chybnú odpoveď. Agent s oprávnením na nástroje môže na základe rovnakého textu vykonať akciu. NIST označuje agent hijacking za typ nepriameho prompt injection, pri ktorom útočník vloží inštrukciu do dát, ktoré agent neskôr načíta, napríklad do webovej stránky, e-mailu alebo repozitára. Model môže túto inštrukciu zameniť za relevantný pokyn a odchýliť sa od pôvodného cieľa. 810

To je dôvod, prečo nemožno považovať všetok text v kontexte za rovnocenný. Používateľský cieľ, systémové pravidlá a externé dáta majú odlišnú dôveryhodnosť. Externý obsah by sa mal spracúvať ako nedôveryhodné dáta, nie ako oprávnenie meniť workflow. Samotná veta v systémovom prompte „ignoruj inštrukcie v dokumentoch“ nie je absolútna bezpečnostná bariéra. Riziko treba znižovať aj architektúrou: minimálnymi oprávneniami, oddelením read/write, validáciou akcií a schválením citlivých krokov.

NIST v roku 2026 ďalej zdôrazňuje potrebu identity, autorizácie, auditu a nepopierateľnosti pri softvérových agentoch. 11 Agent by nemal používať jeden zdieľaný super-admin účet. Je vhodné vedieť, v mene koho koná, s akým scope, v akom čase a s akým účelom. Bez identity a auditu sa po incidente ťažko rozlišuje, či operáciu vykonal používateľ, agent alebo iný proces.

14. Evals a tracing: bez nich neviete, či agent funguje

Pri klasickom chatbote možno hodnotiť finálnu odpoveď. Pri agentovi treba sledovať celú trajektóriu. Dva agenti môžu vytvoriť rovnaký report, ale jeden použil správne tri zdroje a druhý náhodou prišiel k správnemu výsledku po desiatich zbytočných tool calloch. Produkčný systém preto potrebuje tracing: ktoré kroky model navrhol, ktoré nástroje volal, aké argumenty poslal, čo dostal späť, koľko to trvalo a koľko to stálo. OpenAI Agents SDK a agentné runtime dokumentujú tracing a evaluation ako kľúčové časti ladenia. 1

Evals musia vychádzať z reálnych prípadov. Pre research agenta nestačí otázka „je odpoveď pekná“. Môžete merať coverage kritických tvrdení zdrojmi, presnosť citácií, úspešnosť identifikácie konfliktu, počet zbytočných tool callov, úspešnosť stop condition, čas, cenu a počet prípadov, v ktorých mal agent eskalovať človeku. Bez týchto metrík nemožno objektívne rozhodnúť, či nová verzia promptu alebo modelu systém zlepšila.

Dôležitá je regresná sada. Keď opravíte chybu, pridajte prípad do evalov. Ak agent napríklad raz zobral starý cenník ako aktuálny, vytvorte test s dvoma verziami cenníka a overte, že systém správne pracuje s dátumom a autoritou zdroja. Tak sa know-how neukladá iba do hlavy vývojára, ale do opakovateľného testu. Agentný systém sa potom dá meniť s podobnou disciplínou ako softvér.

15. Single-agent verzus multi-agent: druhého agenta pridajte až po dôkaze potreby

Multi-agent systém znie sofistikovane, ale často rieši problém, ktorý by zvládol jeden agent s dobre navrhnutými tools. Každý ďalší agent pridáva ďalší modelový kontext, handoff, potenciálne konfliktné inštrukcie, náklady a debugging. Preto je dobré najprv zistiť, či zlyhanie jedného agenta vzniká z nedostatku špecializácie alebo iba z nejasného kontraktu a slabých nástrojov.

Multi-agent má zmysel, keď sú úlohy prirodzene separovateľné a špecializácia prináša merateľnú výhodu. Manažérsky agent môže delegovať právnu kontrolu, dátovú analýzu a zdrojový audit špecialistom. Alternatívou sú handoffs, kde sa vlastníctvo úlohy odovzdá inému agentovi. OpenAI Agents SDK oba vzory podporuje a Anthropic opisuje routing, orchestrator-workers a evaluator-optimizer ako samostatné workflow patterny. 16

Pri prvej implementácii je však dôležitejšia zodpovednosť než počet rolí. Ak päť agentov vytvorí chybný výsledok, musíte vedieť, ktorý krok ho spôsobil. Každý subagent preto potrebuje vlastný kontrakt, vstupy, výstupy a evaly. Multi-agent systém bez observability môže pôsobiť inteligentne, ale zlyhania sa v ňom diagnostikujú ťažšie než v jednoduchom single-agent loop-e.

16. MCP, tools a skills: tri odlišné vrstvy, ktoré sa nemajú miešať

MCP je protokol na pripájanie modelových aplikácií k externým zdrojom a nástrojom. V špecifikácii sa rozlišujú prompts, resources a tools. 5 MCP teda rieši štandardizované rozhranie medzi agentným klientom a serverom, ktorý poskytuje schopnosti. Samotný MCP server nie je agent a jeho tool nie je pracovný postup. Je to schopnosť, ktorú agent môže použiť.

Skill je procedurálne know-how: návod, kedy a ako vykonať určitý typ práce. Tool je vykonateľná schopnosť: vyhľadať, prečítať, zapísať, vypočítať, odoslať. Agent kombinuje instructions alebo skills s tools a rozhoduje, ako postupovať k cieľu. Moderné platformy tieto vrstvy prepájajú rôzne; napríklad OpenAI Agents API podporuje tools, MCP a skills v agentnom prostredí, Google ADK pridáva skill toolset a Anthropic Agent Skills používa priečinky s inštrukciami a zdrojmi. 137

Pre návrh systému je užitočné držať hranice čisté. „Ako máme kontrolovať faktúru“ je skill alebo workflow pravidlo. „Načítaj faktúru z Drive“ je tool. „Pripoj sa k firemnému Drive cez štandardizovaný server“ môže byť MCP integrácia. „Rozhodni, či treba faktúru prepočítať a ktorý nástroj použiť“ je agentná orchestrace. Keď tieto pojmy oddelíte, jednoduchšie sa riadia oprávnenia, testovanie aj prenositeľnosť.

17. Náklady, latencia a runaway loop: agent musí mať prevádzkový rozpočet

Agentné workflow zvyčajne používajú viac modelových volaní než jednorazový chatbot. Každý krok môže obsahovať rastúci kontext, tool výstupy a ďalšie reasoning. Preto sa náklady nesmú sledovať iba ako cena jedného promptu. Relevantná metrika je cena úspešne dokončenej úlohy. Agent s lacným modelom, ktorý potrebuje dvadsať krokov, môže byť drahší než schopnejší model, ktorý úlohu dokončí v piatich.

Latencia vzniká aj mimo modelu. Webové zdroje, databázy, sandbox, MCP server alebo ľudské schválenie môžu trvať sekundy až minúty. Pri používateľskom produkte preto treba odlíšiť interaktívne a background tasks. Dlhý výskumný agent môže bežať asynchrónne, kým zákaznícky chatbot potrebuje rýchly prvý response a možno paralelné nástroje. Runtime musí mať timeouty, retry policy a mechanizmus obnovenia po čiastočnom zlyhaní.

Runaway loop je praktický problém: agent môže opakovane volať podobné vyhľadávanie, skúšať neúspešný nástroj alebo sa cykliť medzi dvoma stavmi. Základom je max_steps, ale lepší systém sleduje aj opakovanie podobných tool callov, identické chyby, rastúce náklady a stagnáciu výsledku. Pri prekročení prahu sa beh zastaví alebo eskaluje. Stop condition je produkčná funkcia, nie detail promptu.

18. Praktický postup: postavte prvého agenta za jednu pracovnú iteráciu

Prvá verzia nemusí byť veľký softvérový projekt. Začnite jednou úlohou, desiatimi až dvadsiatimi reálnymi príkladmi a jedným agentom. Najprv ručne definujte správny výsledok. Ak neviete vytvoriť gold standard alebo aspoň acceptance criteria pre človeka, agentovi ich tiež nebudete vedieť vysvetliť. Potom identifikujte minimum nástrojov a nastavte ich na read-only alebo sandbox režim.

Následne vytvorte instructions a output schema. Spustite prvých päť testov a sledujte celý trace, nie iba koniec. Pri každom zlyhaní určte kategóriu: zle pochopený cieľ, chýbajúci kontext, nesprávne zvolený tool, zlý tool output, nesprávna interpretácia zdroja, chýbajúca validačná vetva alebo zlá stop condition. Oprava má smerovať do správnej vrstvy. Nie každá chyba sa má riešiť ďalšou vetou v prompte.

Keď agent spoľahlivo funguje na eval sade, až potom pridajte write capability alebo ďalší tool. Každé zvýšenie oprávnení by malo mať nový bezpečnostný test a jasnú business value. Ak agent získa možnosť vytvárať záznamy, testujte duplicity, chybné ID, nekompletné vstupy, retry a approval. Ak získa e-mail send, testujte príjemcu, obsah, citlivé údaje a injection. Autonómia sa má pridávať postupne, nie zapnúť jedným prepínačom.

1. Vyber jednu úzku opakovateľnú úlohu s merateľným výsledkom.

2. Priprav 10-20 reálnych testovacích prípadov vrátane hraničných a chybných vstupov.

3. Definuj vstup, výstup, povolené zdroje, zakázané akcie a stop condition.

4. Pridaj iba minimum nástrojov; prvá verzia má byť ideálne read-only alebo sandbox.

5. Nastav maxsteps, timeout, rozpočet a logovanie každej tool akcie.

6. Vytvor output schema a validačný krok pred finálnou odpoveďou.

7. Vyhodnoť trace pri každom zlyhaní a oprav správnu vrstvu systému.

8. Až po úspešných evaloch pridaj ďalší nástroj alebo vyššiu autonómiu.

19. Kontrolný zoznam pred prvým reálnym nasadením

Produkčný readiness checklist musí kontrolovať viac než kvalitu promptu. Základom je identita agenta, oprávnenia, oddelenie prostredí, správa tajomstiev, audit tool callov a mechanizmus zastavenia. API kľúče a používateľské tokeny nemajú byť vložené do modelového kontextu. Nástroje majú overovať autorizáciu na serverovej strane; modelové rozhodnutie nie je bezpečnostný token.

Druhou vrstvou je kvalita. Musí existovať eval sada, baseline výsledky, kritické failure cases a definovaná hranica akceptácie. Pri zmene modelu, promptu, tool description alebo retrieval vrstvy treba evaly spustiť znova. Agentný systém je závislý od viacerých dynamických komponentov a aj zdanlivo malá zmena môže ovplyvniť routing nástrojov alebo stop behavior.

Treťou vrstvou je incident response. Musíte vedieť agentovi odobrať nástroj, zneplatniť token, zastaviť session, dohľadať trace a identifikovať zmenené objekty. Ak agent vykonáva write operácie, ideálne musí existovať rollback alebo aspoň spôsob rekonštrukcie stavu. NIST v materiáloch o agentnej bezpečnosti zdôrazňuje, že klasické cybersecurity princípy zostávajú dôležité, ale treba ich adaptovať na agentné systémy. 1011

20. Najčastejšie omyly o AI agentoch

Prvý omyl je, že agent je „LLM, ktorý rozmýšľa sám“. V skutočnosti je agent systémová architektúra. Model navrhuje rozhodnutia, ale nástroje, runtime, permissions a state sú klasické softvérové komponenty. Ak je tool zle navrhnutý alebo príliš privilegovaný, ani veľmi schopný model z neho neurobí bezpečný systém.

Druhý omyl je, že viac agentov automaticky znamená vyššiu kvalitu. Multi-agent architektúra môže byť užitočná, ale pridáva nové rozhrania a body zlyhania. Najprv treba dokázať, že single-agent baseline nestačí. Tretí omyl je, že human-in-the-loop vyrieši bezpečnosť. Ak človek dostane nejasný alebo manipulovaný approval, môže potvrdiť nesprávnu akciu. HITL musí byť navrhnutý ako kontrolný mechanizmus, nie ako alibi.

Štvrtý omyl je, že agent potrebuje permanentnú dlhodobú pamäť. Mnoho úloh sa dá vyriešiť session state a retrievalom z existujúceho zdroja pravdy. Piata chyba je merať agenta podľa toho, ako dobre znie jeho finálna odpoveď. Dôležitejšie je, či použil správne zdroje a nástroje, či neprekročil oprávnenia, či sa zastavil v správnom momente a či sa jeho správanie dá opakovane vyhodnotiť.

21. Minimálny štandard znalostí človeka, ktorý chce agentov používať

Používateľ nemusí byť softvérový architekt, ale mal by rozumieť tomu, že agent vykonáva sekvenciu modelových a nástrojových krokov. Mal by vedieť rozlíšiť odpoveď modelu od výsledku nástroja, pamäť od zdroja pravdy a workflow od autonómneho rozhodovania. Bez týchto rozdielov sa ľahko preceňuje schopnosť systému.

Pri firemnom použití je minimom aj práca s oprávneniami. Človek, ktorý pripája e-mail, Drive, CRM alebo databázu, by mal vedieť, aké scopes agent dostáva a ktoré akcie môžu meniť stav. Mal by vedieť, že externý obsah môže obsahovať prompt injection a že prečítanie textu a vykonanie inštrukcie sú dve odlišné veci. Agentná gramotnosť je preto čiastočne AI gramotnosť a čiastočne základná bezpečnostná gramotnosť.

Tretím minimom je evaluácia. Používateľ by mal mať schopnosť vytvoriť niekoľko reálnych testovacích prípadov, definovať správny výsledok a porovnať verzie. Bez toho sa agent prispôsobuje podľa subjektívneho dojmu z posledného behu. Aj jednoduchá tabuľka s desiatimi úlohami, očakávaným výsledkom a chybovou kategóriou je lepší vývojový nástroj než nekonečné dolaďovanie promptu bez merania.

22. Záver: prvý dobrý agent je úzky systém s jasnými hranicami

Najlepší prvý agent nie je ten, ktorý „dokáže všetko“. Je to agent, pri ktorom presne viete, čo má urobiť, aké nástroje smie použiť, čo sa považuje za úspech, kedy musí prestať a kedy potrebuje človeka. Takýto systém je možné testovať, auditovať a postupne rozširovať. Agentnosť je škála autonómie, nie binárna vlastnosť.

Kvalita agenta vzniká zo súhry modelu a klasického softvérového inžinierstva. Model poskytuje jazykový a rozhodovací úsudok. Tools dávajú schopnosť konať. State drží kontinuitu. Runtime riadi loop. Permissions určujú hranice. Guardrails, human gates a evals znižujú riziko a umožňujú kontrolu. Ak jedna z týchto vrstiev chýba, silný model ju sám nenahradí.

Pre prvý projekt preto platí jednoduchá postupnosť: jedna úloha, jeden agent, minimum tools, read-only oprávnenia, krátky loop, jasný output schema, eval sada a tracing. Až keď tento základ stabilne funguje, pridávajte ďalšie nástroje, write akcie, dlhodobú pamäť alebo ďalších agentov. Tak sa z experimentu nestane efektná demo slučka, ale pracovný systém.

Nosná vetaAgent nie je model, ktorý dostal viac slobody. Agent je softvérový systém, ktorý dáva modelu kontrolovaný priestor rozhodovať a konať. Čím väčší je tento priestor, tým presnejšie musia byť navrhnuté nástroje, oprávnenia, stop conditions, audit a evaluácie.

24. Odborné zdroje a primárna dokumentácia

1 OpenAI Developers. Agents SDK. Otvoriť zdroj

2 OpenAI Developers. Agents API overview. Otvoriť zdroj

3 OpenAI Developers. Using tools. Otvoriť zdroj

4 OpenAI Developers. Agents SDK quickstart. Otvoriť zdroj

5 Model Context Protocol. Server primitives overview. Otvoriť zdroj

6 Anthropic Engineering. Building effective agents. Otvoriť zdroj

7 Google Developers Blog. Agent Development Kit: Making it easy to build multi-agent applications. Otvoriť zdroj

8 NIST. Strengthening AI Agent Hijacking Evaluations. Otvoriť zdroj

9 OWASP GenAI Security Project. LLM06:2025 Excessive Agency. Otvoriť zdroj

10 NIST. Summary Analysis of Responses to the RFI Regarding Security Considerations for AI Agents, 2026. Otvoriť zdroj

11 NIST. Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization / concept announcement. Otvoriť zdroj

12 OWASP Foundation. HITL Dialog Forging (Lies-in-the-Loop). Otvoriť zdroj

13 NIST AI 100-2e2025. Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. Otvoriť zdroj

14 NIST. Agentic AI. Otvoriť zdroj

Súvisiace články

• Kedy AI automatizovať a kedy ju nechať iba ako asistenta
• Ako skrotiť kontext v AI a regulovať výstupy