Jak vytvořit agenta s umělou inteligencí

Stručná odpověď: Chcete-li vytvořit agenta s umělou inteligencí, který v praxi funguje, zacházejte s ním jako s řízenou smyčkou: přijměte vstup, rozhodněte se o další akci, zavolejte úzce vymezený nástroj, sledujte výsledek a opakujte, dokud neprojde jasná kontrola „hotovo“. Osvědčuje se, když je úkol vícekrokový a řízený nástrojem; pokud jej vyřeší jediná výzva, agenta přeskočte. Přidejte striktní schémata nástrojů, limity kroků, protokolování a validátor/kritika, aby v případě selhání nástrojů nebo nejednoznačnosti vstupů agent eskaloval, místo aby se opakoval v smyčce.

Klíčové poznatky:

Řídicí smyčka: Implementujte vstup→akce→pozorování opakování s explicitními podmínkami zastavení a maximálním počtem kroků.

Návrh nástrojů: Udržujte nástroje úzce zaměřené, typované, s oprávněními a ověřené, aby se předešlo chaosu typu „do_anything“.

Hygiena paměti: Používejte kompaktní krátkodobý stav a dlouhodobé vyhledávání; vyhněte se ukládání plných přepisů.

Odolnost proti zneužití: Přidejte seznamy povolených položek, limity rychlosti, idempotenci a „nácvik na zkoušku“ pro rizikové akce.

Testovatelnost: Udržujte sadu scénářů (selhání, nejednoznačnost, injekce) a spouštějte je znovu při každé změně.

---

1) Co je to agent s umělou inteligencí, řečeno obyčejným člověkem 🧠

Agent umělé inteligence je smyčka. Dokumentace k „Agentům“ v LangChainu.

To je vše. Smyčka s mozkem uprostřed.

Vstup → přemýšlet → jednat → pozorovat → opakovat. Reagovat (zdůvodnění + jednat)

Kde:

• Vstupem je požadavek uživatele nebo událost (nový e-mail, tiket podpory, ping senzoru).

• Think je jazykový model uvažující o dalším kroku.

• Volání nástroje (prohledávání interní dokumentace, spuštění kódu, vytvoření požadavku, napsání odpovědi). Průvodce voláním funkcí OpenAI

• Observer čte výstup nástroje.

• Opakování je ta část, která působí „agentsky“ místo „upovídaně“. Dokumentace k „Agentům“ v LangChainu

Někteří agenti jsou v podstatě chytrá makra. Jiní se chovají spíše jako juniorní operátoři, kteří dokáží žonglovat s úkoly a zotavovat se z chyb. Oba se počítají.

Taky nepotřebuješ plnou autonomii. Vlastně… nejspíš ji ani nechceš 🙃

---

2) Kdy byste měli vytvořit agenta (a kdy ne) 🚦

Vytvořte agenta, když:

• Práce je vícestupňová a mění se v závislosti na tom, co se stane v průběhu.

• Práce vyžaduje použití nástrojů (databáze, CRM, spouštění kódu, generování souborů, prohlížeče, interní API). Dokumentace k nástrojům LangChain.

• Chcete opakovatelné výsledky s ochrannými opatřeními, ne jen jednorázové odpovědi.

• Slovo „hotovo“ můžete definovat způsobem, který si počítač může zkontrolovat, i když jen volně.

Nevytvářejte agenta, když:

• Jednoduchá výzva + odpověď to vyřeší (nepřehánějte to s inženýrstvím, později se budete nenávidět).

• Potřebujete dokonalý determinismus (agenti mohou být konzistentní, ale ne robotičtí).

• Nemáte žádné nástroje ani data k propojení – pak jsou to většinou jen vibrace.

Buďme upřímní: polovina „projektů AI agentů“ by mohla být pracovní postup s několika pravidly větvení. Ale někdy záleží i na atmosféře 🤷♂️

---

3) Co dělá dobrou verzi AI agenta ✅

Tady je část „Co dělá dobrou verzi“, o kterou jste požádal/a, až na to, že budu trochu upřímný/á:

Dobrá verze agenta s umělou inteligencí není ta, která nejvíc přemýšlí. Je to ta, která:

• Ví, co smí dělat (hranice rozsahu)

• Spolehlivě používá nástroje (strukturovaná volání, opakované pokusy, časové limity). Průvodce voláním funkcí OpenAI v AWS „Časové limity, opakované pokusy a odklad s jitterem“.

• Udržuje stav čistý (paměť, která se nerozkládá) LangChain „Přehled paměti“

• Vysvětluje své jednání (auditní záznamy, nikoli tajné úsudky) NIST AI RMF 1.0 (důvěryhodnost a transparentnost)

• Vhodně zastavuje (kontroly dokončení, maximální počet kroků, eskalace) Dokumentace k „Agentům“ v LangChainu

• Bezpečně selže (žádá o pomoc, nemá halucinace autority) NIST AI RMF 1.0

• Je testovatelný (můžete jej spustit na předpřipravených scénářích a vyhodnotit výsledky)

Pokud se váš agent nedá otestovat, je to v podstatě velmi sebevědomý výherní automat. Zábava na večírcích, děsivý v produkci 😬

---

4) Základní stavební kameny agenta („anatomie“ 🧩)

Většina solidních agentů má tyto části:

A) Smyčka regulátoru 🔁

Toto je orchestrátor:

• dát gól

• zeptejte se modelu na další krok

• nástroj pro spuštění

• přidat pozorování

• opakujte, dokud nebude hotovo Dokumentace k „Agentům“ v LangChainu

B) Nástroje (neboli schopnosti) 🧰

Nástroje jsou to, co dělá agenta efektivním: Dokumentace k nástrojům LangChain

• databázové dotazy

• odesílání e-mailů

• stahování souborů

• spouštění kódu

• volání interních API

• zápis do tabulek nebo CRM systémů

C) Paměť 🗃️

Záleží na dvou druzích:

• krátkodobá paměť: aktuální kontext běhu, nedávné kroky, aktuální plán

• dlouhodobá paměť: uživatelské preference, kontext projektu, načtené znalosti (často prostřednictvím vkládání + vektorového úložiště) RAG dokument

D) Plánovací a rozhodovací politika 🧭

I když tomu neříkáte „plánování“, potřebujete metodu:

• kontrolní seznamy

• ReAct dokument ve stylu ReAct „mysli a pak nápověda“

• grafy úkolů

• vzorce vztahu supervizor-pracovník

• vzory supervizor-pracovník Microsoft AutoGen (multiagentní framework)

E) Zábrany a hodnocení 🧯

• oprávnění

• Schémata bezpečných nástrojů, strukturované výstupy OpenAI

• validace výstupu

• krokové limity

• těžba dřeva

• testy NIST AI RMF 1.0

Ano, je to spíš inženýrství než nabádání. Což je… tak nějak pointa.

---

5) Srovnávací tabulka: oblíbené způsoby, jak si vytvořit agenta 🧾

Níže je realistická „srovnávací tabulka“ – s pár drobnostmi, protože skutečné týmy jsou svérázné 😄

Nástroj / Rámec	Publikum	Cena	Proč to funguje	Poznámky (malý chaos)
LangChain	stavitelé, kteří mají rádi komponenty ve stylu Lega	free-ish + infra	velký ekosystém pro nástroje, paměť a řetězce	můžeš dostat špagety jako rychlík, pokud věci jasně nepojmenuješ
LamaIndex	Týmy s převahou RAG	free-ish + infra	silné vyhledávací vzorce, indexování, konektory	skvělé, když váš agent v podstatě funguje na principu „hledej + jednej“… což je běžné
Přístup ve stylu OpenAI Assistants	týmy, které chtějí rychlejší nastavení	založené na použití	vestavěné vzory volání nástrojů a stav běhu	méně flexibilní v některých rozích, ale čistý pro mnoho aplikací	Volání funkcí OpenAI Assistants v API spouštěných OpenAI
Sémantické jádro	vývojáři, kteří chtějí strukturovanou orchestraci	volný-tak	úhledná abstrakce pro dovednosti/funkce	působí „podnikově uklizeným dojmem“ – někdy je to kompliment 😉
AutoGen	multiagentní experimentátoři	volný-tak	vzorce spolupráce mezi agenty	může přehánět; stanovit přísná pravidla pro ukončení
CrewAI	fanoušci „týmů agentů“	volný-tak	role + úkoly + předání úkolů se snadno vyjadřují	funguje nejlépe, když jsou úkoly svěží, ne rozmělněné
Kupka sena	vyhledávání + lidé z oblasti distribuce	volný-tak	pevné potrubí, vyzvedávání, komponenty	méně „divadla agentů“, více „praktické továrny“
Roll-your-own (vlastní smyčka)	kontrolní maniaci (milující)	tvůj čas	minimální magie, maximální jasnost	obvykle nejlepší dlouhodobě… dokud všechno znovu nevynaleznete 😅

Neexistuje jediný vítěz. Nejlepší volba závisí na tom, zda je hlavní náplní práce vašeho agenta vyhledávání, provádění nástrojů, koordinace více agentůnebo automatizace pracovních postupů.

---

6) Jak krok za krokem vytvořit agenta s umělou inteligencí (skutečný recept) 🍳🤖

Tuto část většina lidí přeskočí a pak se diví, proč se agent chová jako mýval ve spíži.

Krok 1: Definujte práci jednou větou 🎯

Příklady:

• „Napište návrh odpovědi zákazníka s využitím zásad a kontextu tiketu a poté požádejte o schválení.“

• „Prozkoumejte hlášení o chybě, reprodukujte ho a navrhněte opravu.“

• „Proměňte nedokonalé poznámky ze schůzek v úkoly, vlastníky a termíny.“

Pokud to nedokážete jednoduše definovat, nedokáže to ani váš agent. Myslím tím, že to dokáže, ale bude to improvizovat, a improvizace je to, kde rozpočty umírají.

Krok 2: Rozhodněte se pro úroveň autonomie (nízká, střední, pikantní) 🌶️

• Nízká autonomie: navrhuje kroky, lidská kliknutí „schválí“

• Střední: spouští nástroje, navrhuje výstup, stupňuje se v případě nejistoty

• Vysoká: spouští se end-to-end, pinguje lidi pouze v případě výjimek.

Začněte s nižším tlakem, než chcete. Později to můžete vždycky zvýšit.

Krok 3: Vyberte si modelovou strategii 🧠

Obvykle si vyberete:

• jeden silný model pro všechno (jednoduchý)

• jeden silný model + menší model pro levné kroky (klasifikace, směrování)

• specializované modely (zrakové, kódové, řečové) v případě potřeby

Také se rozhodněte:

• maximální počet tokenů

• teplota

• zda interně povolujete dlouhé trasování uvažování (můžete, ale nezpřístupňovejte koncovým uživatelům surový řetězec myšlenek)

Krok 4: Definujte nástroje s striktními schématy 🔩

Nástroje by měly být:

• úzký

• napsaný

• s povolením

• ověřené strukturované výstupy OpenAI

Místo nástroje s názvem do_anything(input: string)proveďte:

• search_kb(dotaz: řetězec) -> výsledky[]

• create_ticket(název: řetězec, tělo: řetězec, priorita: výčet) -> ticket_id

• send_email(to: string, subject: string, body: string) -> status Průvodce voláním funkcí OpenAI

Pokud agentovi dáte motorovou pilu, nebuďte překvapeni, když vám ostříhá živý plot tím, že ho i odstraní.

Krok 5: Vytvořte smyčku regulátoru 🔁

Minimální smyčka:

1. Začněte s cílem + počátečním kontextem

2. Zeptejte se modelu: „Další akce?“

3. Pokud nástroj volá - spustí nástroj

4. Přidat pozorování

5. Zkontrolujte stav zastavení

6. Opakujte (s maximálním počtem kroků) dokumentaci k „Agentům“ v LangChainu

Přidat:

• časové limity

• opakované pokusy (pozor – opakované pokusy se mohou smyčkovat) AWS „Časové limity, opakované pokusy a odstavení s jitterem“

• formátování chyb nástroje (přehledné, strukturované)

Krok 6: Opatrně přidejte paměť 🗃️

Krátkodobé: udržovat kompaktní „souhrn stavu“ aktualizovaný v každém kroku. LangChain „přehled paměti“.
Dlouhodobé: ukládat trvalá fakta (uživatelské preference, pravidla organizace, stabilní dokumentace).

Pravidlo:

• pokud se to často mění - udržujte to krátkodobé

• pokud je stabilní - skladujte dlouhodobě

• pokud je to citlivé - skladujte minimálně (nebo vůbec ne)

Krok 7: Přidejte ověření a hodnocení „kritik“ 🧪

Levný, praktický vzor:

• agent generuje výsledek

• validátor kontroluje strukturu a omezení

• volitelné kontroly modelu kritika z hlediska chybějících kroků nebo porušení zásad NIST AI RMF 1.0

Není to dokonalé, ale zachytí to šokující množství nesmyslů.

Krok 8: Zaznamenejte si všechno, čeho budete litovat, že jste si to nezaznamenali 📜

Protokol:

• volání nástrojů + vstupy + výstupy

• učiněná rozhodnutí

• chyby

• konečné výstupy

• tokeny a latence, úvod do pozorovatelnosti OpenTelemetry

Budoucnost - poděkuješ si. Přítomnost - zapomeneš. Takový je prostě život 😵💫

---

7) Volání nástroje, které vám nezlomí duši 🧰😵

Volání nástrojů je moment, kdy se „Jak vytvořit agenta s umělou inteligencí“ stává skutečným softwarovým inženýrstvím.

Udělejte nástroje spolehlivými (spolehlivost je dobrá věc)

Spolehlivé nástroje jsou:

• deterministický

• úzký rozsah

• snadno otestovatelné

• bezpečné znovu spustit Stripe „Idempotentní požadavky“

Přidejte na vrstvě nástrojů zábradlí, nejen výzvy

Výzvy jsou zdvořilé návrhy. Validace nástrojů je zamčená brána. Strukturované výstupy OpenAI.

Dělat:

• seznamy povolených položek (které nástroje lze spustit)

• ověření vstupu

• limity rychlosti Průvodce limity rychlosti OpenAI

• kontroly oprávnění pro jednotlivé uživatele/organizaci

• „režim běhu nazku“ pro riskantní akce

Návrh pro částečné selhání

Nástroje selhávají. Sítě se chvějí. Autorizace vyprší. Agent musí:

• interpretovat chyby

• opakování s odkladem v případě potřeby Strategie opakování Google Cloud (odklad + jitter)

• vybrat alternativní nástroje

• eskalovat, když se zaseknete

Tichý a účinný trik: vraťte strukturované chyby jako:

• typ: chyba_autorizace

• typ: nenalezen

• typ: rate_limited
  Takže model může reagovat inteligentně, místo aby panikařil.

---

8) Paměť, která pomáhá, místo aby vás pronásledovala 👻🗂️

Paměť je mocná, ale může se také stát šuplíkem na haraburdí.

Krátkodobá paměť: udržujte ji kompaktní

Použití:

• posledních N kroků

• průběžné shrnutí (aktualizováno v každé smyčce)

• současný plán

• aktuální omezení (rozpočet, čas, politika)

Pokud vše zasadíte do kontextu, dostanete:

• vyšší náklady

• pomalejší latence

• větší zmatek (ano, i tehdy)

Dlouhodobá paměť: vybavování spíše než „vycpávání“

Většina „dlouhodobé paměti“ je spíše podobná:

• vložení

• vektorový obchod

• rozšířené generování vyhledávání (RAG) RAG papír

Agent si neukládá data do paměti. Za běhu vyhledává nejrelevantnější úryvky. LlamaIndex „Úvod do RAG“

Praktická pravidla pro paměť

• Ukládat „předvolby“ jako explicitní fakta: „Uživatel má rád shrnutí s odrážkami a nesnáší emoji“ (lol, tady to ale ne 😄)

• Ukládejte „rozhodnutí“ s časovými razítky nebo verzemi (jinak se hromadí rozpory)

• Nikdy neuchovávejte tajemství, pokud to opravdu nemusíte

A tady je moje nedokonalá metafora: paměť je jako lednička. Pokud ji nikdy neumýváte, váš sendvič bude nakonec chutnat jako cibule a lítost.

---

9) Plánovací vzory (od jednoduchých po efektní) 🧭✨

Plánování je jen řízený rozklad. Nedělejte z toho mystiku.

Vzor A: Plánovač kontrolních seznamů ✅

• Model vygeneruje seznam kroků

• Provádí se krok za krokem

• Stav kontrolního seznamu aktualizací

Skvělé pro zaškolení. Jednoduché a testovatelné.

Vzor B: Smyčka ReAct (důvod + akt) 🧠→🧰

• model rozhoduje o dalším volání nástroje

• pozoruje výstup

• opakuje článek ReAct

To je klasický pocit agenta.

Vzor C: Vedoucí-pracovník 👥

• supervizor rozděluje cíl na úkoly

• pracovníci vykonávají specializované úkoly

• Supervizor sloučí výsledky Microsoft AutoGen (multiagentní framework)

To je cenné, když jsou úlohy paralelizovatelné nebo když chcete mít různé „role“, například:

• výzkumník

• kodér

• editor

• Kontrolor kvality

Vzor D: Naplánuj a pak proveď s přeplánováním 🔄

• vytvořit plán

• vykonat

• Pokud výsledky nástrojů změní realitu, přeplánujte

To brání agentovi v tvrdohlavém následování špatného plánu. Lidé to dělají také, pokud nejsou unavení, v takovém případě se také řídí špatnými plány.

---

10) Bezpečnost, spolehlivost a to, že vás nevyhodí 🔐😅

Pokud váš agent může jednat, potřebujete bezpečnostní návrh. Ne „příjemné mít“. Potřeba. NIST AI RMF 1.0

Pevné limity

• maximální počet kroků na běh

• maximální počet volání nástroje za minutu

• maximální útrata za relaci (rozpočet tokenů)

• omezené nástroje za schválením

Zpracování dat

• před protokolováním zaškrtněte citlivé vstupy

• oddělená prostředí (vývojová vs. produkční)

• oprávnění nástroje s nejnižšími oprávněními

Behaviorální omezení

• donutit agenta citovat úryvky z interních důkazů (ne externí odkazy, pouze interní reference)

• vyžadovat příznaky nejistoty, když je spolehlivost nízká

• vyžadovat „položit upřesňující otázku“, pokud jsou vstupy nejednoznačné

Spolehlivý agent není ten nejsebevědomější. Je to ten, který ví, kdy hádá… a říká to.

---

11) Testování a hodnocení (část, které se všichni vyhýbají) 🧪📏

Nemůžeš vylepšit, co nemůžeš změřit. Ano, tahle věta je kýčovitá, ale je to otravně pravdivé.

Vytvořte sadu scénářů

Vytvořte 30–100 testovacích případů:

• šťastné cesty

• okrajové případy

• případy „selhání nástroje“

• nejednoznačné požadavky

• adversarial prompts (pokusy o okamžitou injekci) OWASP Top 10 pro LLM aplikace OWASP LLM01 Prompt Injection

Výsledky skóre

Používejte metriky jako:

• míra úspěšnosti úkolu

• doba do dokončení

• míra zotavení z chyb nástroje

• míra halucinací (tvrzení bez důkazů)

• míra schválení lidmi (v režimu s dohledem)

Regresní testy pro výzvy a nástroje

Kdykoli se změníte:

• schéma nástroje

• systémové instrukce

• logika vyhledávání

• formátování paměti
  Spusťte sadu znovu.

Agenti jsou citliví tvorové. Jako pokojové rostliny, ale dražší.

---

12) Vzory nasazení, které vám nezatíží rozpočet 💸🔥

Začněte s jednou službou

• API řadiče agentů

• nástroje a služby za tím

• protokolování + monitorování Úvod do pozorovatelnosti OpenTelemetry

Přidejte kontroly nákladů včas

• výsledky načítání z mezipaměti

• komprese stavu konverzace se souhrny

• použití menších modelů pro směrování a extrakci

• omezení „režimu hlubokého myšlení“ na nejtěžší kroky

Společná volba architektury

• bezstavový kontroler + externí úložiště stavů (DB/redis)

• Volání nástrojů jsou idempotentní, kdekoli je to možné. Stripe „Idempotentní požadavky“.

• fronta pro dlouhé úlohy (abyste webový požadavek nedrželi otevřený donekonečna)

Taky: postavte si „vypínač“. Nebudete ho potřebovat, dokud ho nebudete opravdu, ale opravdu potřebovat 😬

---

13) Závěrečné poznámky - krátká verze článku Jak vytvořit agenta s umělou inteligencí 🎁🤖

Pokud si nic jiného nepamatujete, zapamatujte si toto:

• Jak vytvořit agenta s umělou inteligencí se většinou zaměřuje na vytvoření bezpečné smyčky kolem modelu. Dokumentace k „Agentům“ v LangChainu.

• Začněte s jasným cílem, nízkou autonomií a striktními nástroji. Strukturované výstupy OpenAI

• Přidávání paměti vyhledáváním, ne nekonečným doplňováním kontextu. RAG papír

• Plánování může být jednoduché – kontrolní seznamy a přeplánování vám pomohou.

• Protokolování a testování promění chaos agentů v něco, co můžete odeslat. Úvod do pozorovatelnosti OpenTelemetry

• Zábradlí patří do kódu, nejen do výzev. OWASP Top 10 pro LLM aplikace

Agent není magie. Je to systém, který dělá dobrá rozhodnutí dostatečně často na to, aby byl cenný… a přiznává porážku dříve, než způsobí škodu. V jistém smyslu tiše uklidňující 😌

A jo, když to postavíte správně, je to jako najmout si malého digitálního stážistu, který nikdy nespí, občas panikaří a miluje papírování. Takže v podstatě stážista.

Příklad z reálného světa: Vytvoření AI agenta pro třídění podpůrných služeb 🎫🤖

Scénář

Představte si malý SaaS tým, který dostává 120–180 tiketů podpory týdně. Většina tiketů není složitá, ale i tak zaberou čas: resetování hesla, dotazy ohledně fakturace, hlášení chyb, požadavky na funkce a zprávy typu „je toto chování očekávané?“.

Jednoduchý chatbot umí psát odpovědi, ale nedokáže spolehlivě kontrolovat stav účtu, prohledávat znalostní bázi, klasifikovat naléhavost nebo rozhodnout, kdy je třeba zasáhnout. A právě zde má smysl agent.

Cílem není plně nahradit podporu. Cílem je vytvořit agenta s nízkou autonomií, který přečte nový tiket, shromáždí kontext, napíše odpověď a směruje tiket do správné fronty. Člověk stále schvaluje cokoli, co je zaměřeno na zákazníka.

Co asistent potřebuje

Pro bezpečnou práci agent potřebuje malou, kontrolovanou sadu vstupů a nástrojů:

• Text příchozího lístku

• Typ zákaznického tarifu, stáří účtu a nedávný stav fakturace

• Nedávný seznam změn produktu nebo známé incidenty

• Články interního centra nápovědy

• Nástroj pro aktualizaci tiketů s omezeným počtem polí

• Nástroj pro odpovídání na koncepty, nikoli nástroj pro odesílání e-mailů

• Jasná eskalační politika

Seznam nástrojů by měl být záměrně úzký:

• centrum_nápovědy_pro_hledání(dotaz)

• get_customer_status(customer_id)

• check_known_incidents(oblast_produktu)

• update_ticket_category(id_ticketu, kategorie, priorita)

• draft_reply(id_tiketu, text_odpovědi)

• escalate_to_human(id_tiketu, důvod)

Všimněte si, co chybí: chybí nástroj pro „vrácení peněz zákazníkovi“, „uzavření účtu“ ani „odesílání konečné odpovědi“. Tyto akce jsou pro první verzi příliš riskantní.

Příklad instrukce

Jste agent podpory pro SaaS produkt.

Vaším úkolem je klasifikovat příchozí tikety, shromáždit pouze potřebný kontext, navrhnout návrh odpovědi a rozhodnout, zda by měl být tikety eskalovány.

Pravidla:

Neposílejte odpovědi přímo zákazníkům.

Před zodpovězením dotazů k produktu použijte centrum nápovědy.

Před zodpovězením dotazů ohledně fakturace, tarifu nebo přístupu si ověřte stav zákazníka.

Pokud zákazník zmíní právní hrozby, ztrátu dat, bezpečnostní problémy, selhání platby, zrušení účtu nebo hněvivý jazyk, informujte o tom člověka.

Pokud odpověď není podložena získaným obsahem centra nápovědy nebo údaji o účtu, uveďte, co chybí, a eskalujte problém.

Zastavit po maximálně 6 voláních nástroje.

Tiket je „vyřízený“ pouze tehdy, když má kategorii, prioritu, shrnutí důkazů, koncept odpovědi a buď „vyžadováno lidské schválení“, nebo „eskalováno“.

Jak to otestovat

Začněte s 30 testovacími tikety, než je propojíte s aktivními uživateli:

• 10 běžných otázek, jako je resetování hesla, limity tarifu a základní otázky typu „jak na to?“

• 5 fakturačních lístků

• 5 hlášení chyb

• 5 nejednoznačných tiketů s chybějícími informacemi

• 5 rizikových tiketů, jako jsou bezpečnostní obavy, požadavky na vrácení peněz a rozzlobené stížnosti

Za každý lístek zadejte skóre:

• Vybrala se správná kategorie?

• Použilo to správný nástroj před odpovědí?

• Vyhnulo se tím nepodloženým tvrzením?

• Zvyšovalo to rizikovost lístků?

• Potřeboval návrh rozsáhlou úpravu?

Na začátku stačí jednoduchá tabulka s hodnocením úspěšného/neúspěšného. Nepřetěžujte systém hodnocení, dokud nevíte, zda agent přináší hodnotu.

Výsledek

Ilustrativní výsledek: Na základě načasování 30 vzorových tiketů před a po použití tohoto pracovního postupu mohl vedoucí podpory naměřit následující:

• Průměrná doba prvního třídění se zkrátila z 6 minut na jeden lístek na 90 sekund

• 30 tiketů vyřízeno za 45 minut místo 3 hodin

• 27 z 30 vstupenek zařazeno do správné kategorie

• 5 z 5 rizikových tiketů bylo správně eskalováno

• 0 odpovědí zákazníků odesláno bez lidského schválení

Tato čísla jsou pouze odhadem, nikoli osvědčeným benchmarkem. Měření lze snadno opakovat: ručně změřte čas stejné dávky testovacích tiketů, poté je spusťte agentem a porovnejte přesnost kategorií, přesnost eskalace a čas úprav.

Co se může pokazit

Agent může stále selhat velmi běžnými způsoby.

Může klasifikovat frustrovaného, ​​ale prostého zákazníka jako „naléhavého“, protože jazyk zní rozzlobeně. Může sepsat sebevědomou odpověď ze zastaralého článku nápovědy. Může pokračovat v hledání, když je správným krokem eskalovat. V konceptu odpovědi může odhalit příliš mnoho podrobností o účtu.

Řešením není „napsat lepší výzvu“ a doufat. Přidejte pevné limity:

• Eskalovat, pokud se objeví text týkající se fakturace, zabezpečení, právních předpisů nebo zrušení

• Vyžadovat citace z interních článků nápovědy v souhrnu důkazů

• Nechte „odeslat odpověď“ s lidským schválením

• Zaznamenávejte každé volání nástroje a finální návrh

• Po každé změně výzvy, nástroje nebo zásad znovu spusťte sadu 30 testů

Praktické ponaučení

Cenný agent nepotřebuje dramatickou autonomii. V tomto příkladu hodnota pochází z řízené smyčky: přečte tiket, načte správný kontext, klasifikuje ho, napíše odpověď a zastaví ke kontrole. Tomu je mnohem snazší důvěřovat, testovat a vylepšovat ho než agentovi, který se snaží „zvládnout podporu“ s jednou obrovskou výzvou.

---

Často kladené otázky

Co je to agent s umělou inteligencí, jednoduše řečeno?

Agent s umělou inteligencí je v podstatě smyčka, která se opakuje: přijímá vstupy, rozhoduje o dalším kroku, používá nástroj, přečte výsledek a opakuje, dokud není hotovo. „Agentská“ část vychází z jednání a pozorování, nikoli jen z chatování. Mnoho agentů je pouze chytrá automatizace s přístupem k nástrojům, zatímco jiní se chovají spíše jako juniorní operátor, který se dokáže zotavit z chyb.

Kdy bych měl vytvořit agenta s umělou inteligencí místo pouhého použití promptu?

Vytvořte agenta, pokud je práce vícekroková, mění se na základě mezivýsledků a vyžaduje spolehlivé používání nástrojů (API, databáze, ticketing, provádění kódu). Agenti jsou také užiteční, když chcete opakovatelné výsledky s ochrannými opatřeními a způsobem, jak zkontrolovat „hotovo“. Pokud funguje jednoduchá výzva k odpovědi, agent obvykle představuje zbytečnou režii a další režimy selhání.

Jak vytvořím agenta s umělou inteligencí, který se nezasekne ve smyčkách?

Používejte podmínky pro tvrdé zastavení: maximální počet kroků, maximální počet volání nástrojů a jasné kontroly dokončení. Přidejte strukturovaná schémata nástrojů, časové limity a opakované pokusy, které se nebudou opakovat donekonečna. Zaznamenávejte rozhodnutí a výstupy nástrojů, abyste viděli, kde selhává. Běžným bezpečnostním ventilem je eskalace: pokud si agent není jistý nebo opakuje chyby, měl by si spíše vyžádat pomoc, než improvizovat.

Jaká je minimální architektura pro Jak vytvořit agenta s umělou inteligencí?

Minimálně potřebujete smyčku regulátoru, která modelu dodává cíl a kontext, zeptá se na další akci, spustí nástroj, pokud je požadován, připojí pozorování a opakuje. Potřebujete také nástroje s striktními tvary vstupů/výstupů a kontrolou „hotovo“. Dokonce i smyčka typu „roll-your-own“ může fungovat dobře, pokud udržíte stav čistý a vynucujete omezení kroků.

Jak mám navrhnout volání nástrojů, aby bylo spolehlivé v produkčním prostředí?

Udržujte nástroje úzce zaměřené, typované, s oprávněními a validované – vyhněte se obecným nástrojům typu „do_anything“. Upřednostňujte striktní schémata (jako jsou strukturované výstupy/volání funkcí), aby agent nemohl ručně upravovat vstupy. Přidejte seznamy povolených položek, limity rychlosti a kontroly oprávnění uživatelů/organizací na úrovni nástrojů. Navrhujte nástroje tak, aby bylo možné je bezpečně spustit znovu, pokud je to možné, s využitím vzorů idempotence.

Jaký je nejlepší způsob, jak přidat paměť, aniž by se agent zhoršil?

S pamětí zacházejte jako se dvěma částmi: krátkodobý stav běhu (nedávné kroky, aktuální plán, omezení) a dlouhodobé vyhledávání (preference, stabilní pravidla, relevantní dokumentace). Krátkodobou paměť zachovejte shrnutí s průběžnými shrnutími, nikoli s úplnými přepisy. U dlouhodobé paměti je vyhledávání (vkládání dat + vektorové úložiště/vzory RAG) obvykle lepší než „nacpat“ vše do kontextu a zmatit model.

Který plánovací vzorec bych měl použít: kontrolní seznam, ReAct nebo supervizor-pracovník?

Plánovač kontrolních seznamů je skvělý, když jsou úkoly předvídatelné a chcete něco snadno testovatelného. Smyčky ve stylu ReAct se osvědčí, když výsledky nástrojů mění to, co děláte dál. Vzory supervizora a pracovníka (jako je rozdělení rolí ve stylu AutoGen) pomáhají, když lze úkoly paralelizovat nebo těžit z odlišných rolí (výzkumník, kodér, QA). Plánování a následné provedení s přeplánováním je praktickým kompromisem, jak se vyhnout tvrdohlavým špatným plánům.

Jak zabezpečím agenta, pokud může provádět skutečné akce?

Používejte oprávnění s nejnižšími oprávněními a omezte rizikové nástroje v režimu schvalování nebo „na zkoušku“. Přidejte rozpočty a limity: maximální počet kroků, maximální výdaje a limity volání nástrojů za minutu. Před protokolováním odstraňte citlivá data a oddělte vývojové prostředí od produkčního. V případě nejednoznačných vstupů požadujte příznaky nejistoty nebo objasňující otázky, místo abyste nechali důkazy nahradit jistotou.

Jak mám testovat a vyhodnocovat agenta s umělou inteligencí, aby se v průběhu času zlepšoval?

Vytvořte sadu scénářů se šťastnými cestami, okrajovými případy, selháními nástrojů, nejednoznačnými požadavky a pokusy o vložení výzvy (ve stylu OWASP). Vyhodnoťte výsledky, jako je úspěšnost úkolu, doba dokončení, zotavení z chyb nástrojů a nároky bez důkazů. Kdykoli změníte schémata nástrojů, výzvy, načítání nebo formátování paměti, spusťte sadu znovu. Pokud ji nemůžete otestovat, nemůžete ji spolehlivě odeslat.

Jak nasadím agenta, aniž bych zvýšil latenci a náklady?

Běžným vzorem je bezstavový kontroler s externím úložištěm stavů (DB/Redis), nástrojovými službami za ním a silným protokolováním/monitorováním (často OpenTelemetry). Kontrolujte náklady pomocí ukládání do mezipaměti pro vyhledávání, kompaktních souhrnů stavů, menších modelů pro směrování/extrakci a omezením „hlubokého myšlení“ na nejtěžší kroky. Pro dlouhé úlohy používejte fronty, abyste nedrželi webové požadavky otevřené. Vždy používejte funkci kill switch.

Reference

1. Národní institut pro standardy a technologie (NIST) - NIST AI RMF 1.0 (důvěryhodnost a transparentnost) - nvlpubs.nist.gov

2. OpenAI - Strukturované výstupy - platform.openai.com

3. OpenAI - Průvodce voláním funkcí - platform.openai.com

4. OpenAI - Průvodce limity rychlosti - platform.openai.com

5. OpenAI – Spouští API – platform.openai.com

6. OpenAI - Volání funkcí asistentů - platform.openai.com

7. LangChain - Dokumentace agentů (JavaScript) - docs.langchain.com

8. LangChain - Dokumentace k nástrojům (Python) - docs.langchain.com

9. LangChain - Přehled paměti - docs.langchain.com

10. arXiv - Článek o ReAct (rozum + jednání) - arxiv.org

11. arXiv - článek RAG - arxiv.org

12. Knihovna nástrojů pro tvorbu Amazon Web Services (AWS) – Časové limity, opakované pokusy a odložení s jitterem – aws.amazon.com

13. OpenTelemetry - Úvod do pozorovatelnosti - opentelemetry.io

14. Stripe - Idempotentní požadavky - docs.stripe.com

15. Google Cloud - Strategie opakování (backoff + jitter) - docs.cloud.google.com

16. OWASP - Top 10 pro aplikace s velkými jazykovými modely - owasp.org

17. OWASP - LLM01 Prompt Injection - genai.owasp.org

18. LlamaIndex - Úvod do RAG - developers.llamaindex.ai

19. Microsoft - Sémantické jádro - learn.microsoft.com

20. Microsoft AutoGen - Multiagentní framework (dokumentace) - microsoft.github.io

21. CrewAI - Koncepty agentů - docs.crewai.com

22. Haystack (hluboko posazený) - Dokumentace pro retrívry - docs.haystack.deepset.ai

Najděte nejnovější AI v oficiálním obchodě s AI asistenty

O nás