AI agent vs. chatbot (2026): rozdíly a kdy co použít

Při výběru konverzační AI pro podporu, prodej nebo interní nástroje narazíte na různá použití názvů „chatbot“ a „AI agent“. Některé produkty označené jako agent jsou jen rozhraním jazykového modelu bez nástrojů. Některé chatboty naopak samostatně volí více kroků než produkty prodávané jako agenti.

Chatbot je konverzační rozhraní; AI agent představuje jeden způsob řízení práce za ním. Skriptovaný chatbot může volat API a uchovávat stav. Agent může vybrat další krok z povolených nástrojů, ale tím nepotvrzuje identitu uživatele, oprávnění k zápisu ani úspěch operace. Porovnáme tři architektury na hypotetické žádosti o vrácení zboží.

Poznámka k terminologii

Jednotné oborové definice neexistují. Následující tři pracovní kategorie proto popisují architekturu, nikoli vlastnosti odvozené z názvu produktu:

1. Pravidlový chatbot: Další krok určuje klasifikace záměru, extrakce entit a předem definovaný dialog. Odpovědi tvoří šablony, nikoli LLM. Postup může uchovávat stav, volat API a vyžadovat schválení.

2. LLM chatbot pouze pro odpovědi: Model odpovídá z dodaného kontextu, často získaného ze znalostní báze. V tomto příkladu nemá nástroje pro provádění akcí. Jiné produkty nazývané chatbot nebo copilot mohou mít nástroje, více volání modelu i schvalování člověkem.

3. AI agent: LLM vybírá kroky a nástroje v nakonfigurované smyčce podle pozorovaných výsledků. Paměť, oprávnění, podmínky ukončení a lidská kontrola závisejí na implementaci. Autonomii omezují skutečně dostupné nástroje a oprávnění.

Jde o schematické příklady. Větší podíl modelu na řízení nezaručuje vyšší přesnost, nižší náklady ani dokončený obchodní výsledek.

Užitečné rozlišení se týká toho, kdo vybírá další krok: předem napsaná aplikační logika, nebo model. Průvodce Anthropic pracovními postupy a agenty tento rozdíl popisuje a doporučuje začít nejjednodušším řešením, které úkol splní. Hybrid může obě možnosti kombinovat.

Zákazník například napíše: „Dostal jsem jiné zboží. Jaké jsou podmínky vrácení a můžete vrácení zahájit?“ Následuje hypotetický návrh, nikoli zaznamenaný běh Quickchat AI nebo vestavěný proces vrácení peněz.

Deterministický postup může realizovat všechny čtyři fáze. Systém pouze pro odpovědi může vysvětlit podmínky a odkázat zákazníka na autentizovanou službu. Agent může vybírat nakonfigurované kroky, ale musí splnit stejné požadavky na přístup a důkazy.

Co je pravidlový chatbot?

Pravidlový chatbot vede textový nebo hlasový rozhovor podle předem definované logiky. Kombinuje klasifikaci záměru, extrakci entit a skriptované dialogové postupy.

Jak pravidloví chatboti fungují

Typická architektura má tři části:

1. Porozumění přirozenému jazyku (NLU): Zprávu analyzuje, rozpozná záměr uživatele a vybere údaje, například datum, název produktu nebo číslo objednávky. NLU obvykle kombinuje regulární výrazy, klíčová slova a trénované klasifikátory.

2. Správce dialogu: Stavový automat určuje další krok podle stavu rozhovoru a rozpoznaného záměru. Každý stav má povolené přechody, kterými postup prochází.

3. Generátor odpovědí: Vybere šablonu spojenou s aktuálním stavem. V jednoduché variantě jde o tabulku odpovědí; složitější šablona obsahuje pole doplněná extrahovanými údaji.

Zjednodušený hypotetický průběh po autentizaci zákazníka a ověření přístupu k objednávce:

Uživatel: „Jaký je stav objednávky #12345?“
  → NLU: intent=order_status, entity={order_id: 12345}
  → Správce dialogu: state=check_order → autorizované order_status_api(12345)
  → Odpověď: „Objednávka #12345 byla odeslána 7. dubna, doručení se očekává 11. dubna.“

Architektura vypadá takto:

To se hodí pro úlohy s uzavřeným rozsahem, kde je množina záměrů malá a jasná. Takto lze vytvořit FAQ, rezervaci termínů i kontrolu stavu objednávky.

Omezení pravidlové architektury

Stavový automat potřebuje výslovně obsloužené podporované cesty. Praktické limity závisejí na klasifikátoru, návrhu postupu a pokrytí integrací:

• Pokrytí záměrů: Požadavek musí spadat do podporovaného záměru nebo fallbacku. Neobvyklá formulace může být zařazena chybně, přestože trénovaný klasifikátor zobecňuje i mimo přesné fráze. Překrývající se záměry vyžadují vyhodnocování a údržbu.

• Předem určené větvení: Správce dialogu může spojovat údaje z několika tahů a podle nich větvit. Nový druh rozhodnutí však potřebuje pravidla nebo jinou rozhodovací část; graf za běhu nevytváří nový postup.

• Křehká extrakce entit: Vyplňování polí funguje pro strukturované vstupy, například data, čísla a SKU, ale obtížněji zpracovává volné popisy, nejednoznačné odkazy a vícedílné požadavky.

• Údržba postupu: Nové úlohy mohou vyžadovat záměry, větve, šablony či integrace. Opakovaně použitelné části pomáhají, ale potřebnou práci je nutné měřit, ne předpokládat její pevné tempo růstu.

Vývoj architektur popisuje článek Od NLP chatbotů ke generativní AI.

Co je AI agent?

AI agent zde znamená systém, v němž LLM vybírá další krok nebo nástroj podle úlohy a pozorování. Může být součástí širšího skriptovaného procesu. Trvalá paměť i oprávnění měnit vnější systémy jsou volitelné vlastnosti, nikoli důsledky označení.

Pojem agent má ve výzkumu AI i širší historii: systém vnímá prostředí a jedná směrem k cíli. Tento článek řeší řízení pomocí LLM, v němž se pozorování, plánování, použití nástroje a vyhodnocení mohou opakovat do splnění podmínky ukončení.

Jak AI agenti fungují

Základem popisované architektury je smyčka uvažování, někdy označovaná ReAct podle práce ReAct, která vzor formalizovala. Má čtyři fáze:

1. Pozorování: Agent obdrží zprávu, historii rozhovoru, systémové instrukce a získaný kontext, například relevantní články znalostní báze.

2. Uvažování: LLM podle kontextu zvolí odpověď, doplňující otázku nebo volání nástroje. Na rozdíl od pevného přechodu ve stavovém grafu rozhoduje za běhu. Výběr může být chybný a potřebuje vyhodnocení.

3. Akce: Model navrhne strukturované volání, například search_knowledge_base(query="return policy") nebo create_return_request(order_id=12345). Aplikační kontroly a cílové API musejí před spuštěním vynutit povolenou operaci a rozsah. Návrh volání není oprávnění.

4. Vyhodnocení: Systém prohlédne výsledek a rozhodne o pokračování, odpovědi nebo lidské kontrole. Závěr modelu, že skončil, není nezávislým důkazem úspěšné obchodní operace. Omezte smyčku a podle potřeby ověřte vnější stav.

Stejný příklad vrácení lze zapsat jako návrh řízení. Níže uvedená volání ani výsledky nebyly provedeny či pozorovány. Názvy operací jsou ilustrativní, nejde o konfiguraci Quickchat AI k vložení do účtu.

Zákazník: „Dostal jsem jiné zboží. Můžete zahájit vrácení?“

[Podmínky] Načtěte platné podmínky vrácení a uveďte jejich omezení.
[Čtení]    Vyžadujte ověřeného zákazníka a přístup k objednávce.
           Načtěte příslušnou objednávku autorizovanou službou.
           „Nesprávné zboží“ berte jako tvrzení zákazníka, dokud se neověří.
[Kontrola] Ověřte podmínky, oprávnění k zápisu a požadované potvrzení.
           Při chybějící podmínce požádejte o upřesnění nebo věc předejte.
[Zápis]    Odešlete žádost až po samostatném schválení zápisu.
[Výsledek] Přijetí potvrďte pouze tehdy, když je potvrzuje vnější systém.
           Přijatá žádost neznamená vyplacení peněz.
           Při nejistotě ověřte stav nebo věc předejte; neopakujte slepě.
[Předání]  Zaznamenejte nevyřešené skutečnosti a známou frontu či příjemce.
           Netvrďte, že člověk již odpověděl.

Agentní částí je výběr dalšího povoleného kroku podle kontextu. Služba stále potřebuje definované nástroje, pravidla, ověření identity a obsluhu chyb. Pevný postup může provést stejné operace; architektura mění řízení, ne práva zákazníka.

Používání nástrojů a volání funkcí

Použití nástrojů neboli volání funkcí propojuje model s vyhledáváním nebo vnějšími operacemi. LLM dostává schémata s názvy, typy a popisy parametrů. Může navrhnout dostupné volání; aplikace určí, zda je povolené a jak zpřístupnit jeho výsledek.

Běžné skupiny nástrojů pro zákaznické agenty:

Schéma určuje podobu volání, neověřuje zákazníka ani nevynucuje obchodní pravidla. Kontrolujte parametry a přístup v cílovém systému, omezte vracená pole a rozlišujte čtení od změny stavu. Samotný prompt není bezpečnostní hranice.

Návod na agenta vykonávajícího skutečné akce vysvětluje popsaný HTTP požadavek volaný během rozhovoru. Navazující text o pořadí Actions, podmínkách a uložených výsledcích ukazuje Run only when a Save to memory. Tyto prvky neověřují identitu a nezajišťují idempotenci zápisu; nadále jsou potřebná důvěryhodná metadata a autorizace v cíli. Odkazované demonstrace mají vlastní kontext; zdejší hypotetické vrácení nebylo otestováno.

Paměť a správa kontextu

Skriptovaný chatbot může ukládat pole jako order_id=12345 a intent=order_status, historii i další stav. Agenti často kombinují více druhů kontextu pro otevřené požadavky. Ani jedna architektura automaticky neposkytuje bezpečnou paměť mezi relacemi.

Užitečné vrstvy kontextu:

• Historie rozhovoru: Posloupnost zpráv v aktuální relaci.
• Pracovní paměť: Mezikroky a výsledky nástrojů ovlivňující další rozhodnutí.
• Vyhledaný kontext: Články znalostní báze, dokumentace nebo zákaznické záznamy získané pomocí RAG pro aktuální dotaz.
• Dlouhodobá paměť (volitelná): Fakta přenášená mezi relacemi, například jazyk, předchozí potíže nebo tarif.

Kontextové okno LLM je technické omezení. Shrnování, posuvná okna a selektivní vyhledávání omezují objem kontextu, ale mohou vypustit důležité podrobnosti. Identitu, oprávnění a závazný stav transakcí uchovávejte v důvěryhodných systémech, nikoli jen ve shrnutí modelu.

Střední cesta: LLM chatboti a copiloti

LLM chatbot pouze pro odpovědi může vyhledat relevantní znalosti, předat je modelu se zprávou a vrátit odpověď. Tento jednoduchý návrh nemá modelově řízenou smyčku akcí. Je to jedna implementace, ne definice všech chatbotů a copilotů.

Pro otázky k pravidlům může vyhledání a odpověď stačit. Model zvládá různá znění bez samostatného záměru pro každou formulaci. Kvalitu vyhledávání, jazyků a zdrojů je přesto třeba hodnotit.

V příkladu vrácení takový systém vysvětlí zveřejněné podmínky, ale nepřečte soukromou objednávku ani nezaloží žádost. Potřebujete-li tyto operace, přidejte autentizovaný postup nebo omezené nástroje. Provést je může i skriptovaná integrace.

Možné jsou hybridy: LLM klasifikuje požadavek, deterministický postup vynucuje kontroly a model připraví odpověď. Zkoumejte, kde se rozhoduje, co je povoleno a jaké důkazy systém vrací; neodvozujte to z označení chatbot, copilot nebo agent.

Porovnání vedle sebe

Prostřední sloupec popisuje zdejší příklad systému pouze pro odpovědi. RAG, trvalý stav i API lze spojovat s různými architekturami.

Dávají pravidloví chatboti ještě smysl?

Ano. Vyberte nejjednodušší architekturu splňující požadavky na kvalitu, kontrolu a odezvu. Skript může stačit pro stabilní formulář, schválené odpovědi nebo autorizovaný dotaz s pevnými kroky. Přidání modelu neodstraňuje údržbu integrací a pravidel.

Předdefinované postupy mohou být vhodné v několika situacích:

Odpovědi musejí mít schválené znění. Šablony zachovají zkontrolovaný text. Jde o jednu kontrolu, ne důkaz souladu s předpisy; způsobilost, povinné informace, přístup i kontrolní povinnosti závisejí na nasazení.

Jednoduché opakované operace. Známá sekvence může zabránit zbytečným voláním modelu při jakémkoli provozu. Porovnejte skutečné náklady hostingu, licencí, API a údržby místo obecného objemového prahu.

Fungující integrace. Zachovejte spolehlivé procesy a doplňujte jazykové porozumění nebo nástroje tam, kde vyhodnocení prokáže přínos. Nahrazení všech záměrů a postupů není podmínkou použití LLM.

Agentní návrh stojí za hodnocení, když se potřebné kroky mění a model může jejich výběrem pomoci. Ověřujte to na reprezentativních úlohách a chybách; název architektury nedává výchozí úspěšnost.

Kde jsou AI agenti nejsilnější

Modelové řízení je vhodné zkoumat, pokud jsou požadavky dostatečně proměnlivé, aby výběr kroku za běhu pomáhal. Následují možnosti, ne naměřená tvrzení o převaze:

Podpora napříč systémy. Příklad vrácení spojuje podmínky, autorizované čtení a samostatně autorizovanou žádost. Model může vybírat relevantní krok, ale pevný postup zůstává platnou možností.

Otevřené produktové dotazy. Velikost týmu, kanály a limity tarifu mohou vyžadovat spojení více doložených faktů. Vyhledávání pomůže chatbotu pouze pro odpovědi i agentovi. Ani jeden nemá odvozovat právní soulad nebo nedoložená oprávnění z popisu produktu.

Prodejní rozhovory. Model může získat požadavky a povolený kontext CRM. Před tvrzením o vyšší efektivitě porovnejte správnost doporučení, souhlas a užitečné výsledky se stávajícím postupem.

Vícejazyčná podpora. Modely omezují potřebu samostatně psaných odpovědí, ale jazyky a kvalita se liší. Hodnoťte terminologii, tón, věrnost pravidlům a eskalaci v každém jazyce. Vícejazyčné odpovědi nepotřebují agentní smyčku a neruší lokalizační práci.

Eskalace. Pravidla a úsudek modelu mohou rozpoznat chybějící znalosti nebo žádost o člověka. Jistota modelu ani sentiment nejsou spolehlivým důkazem správnosti rozhodnutí. Předání a personální zajištění ověřujte odděleně od odpovědi AI.

Součásti platforem popisuje průvodce konverzačními AI platformami.

Jak AI agenti fungují v produkci

Produkční systémy kombinují chování modelu s aplikačními kontrolami. Obdobné kontroly mohou podporovat skriptované procesy; nejsou výlučné pro agenty.

Omezení a pravidla chování. Instrukce určují rozsah, tón a eskalaci. Aplikační kontroly omezují operace a podmínky ukončení. Testujte odmítnutí a chyby vedle běžných požadavků; prompt nezaručuje dodržení pravidel každou odpovědí.

Opora ve znalostech (RAG). Vyhledávání poskytne zdroj před generováním a může omezit nepodložené odpovědi. Správnost však nezaručí. Kontrolujte zdroj i výsledné tvrzení pomocí dohledatelnosti, kterou implementace skutečně poskytuje. Více vysvětluje text o halucinacích AI.

Přístup k nástrojům a oprávnění. API nebo servery MCP mohou poskytovat čtení i zápis. Omezte pověření a operace, vynuťte zákaznický přístup v cíli a vracený text považujte za data. Nástroj ani parametry navržené modelem neudělují přístup k cizí objednávce či neschválené refundaci.

Quickchat AI Agents podporuje odpovědi ze Knowledge Base a nastavené API a MCP Actions. API Actions mohou používat Run only when ověřované mimo model; podmínky zakládejte na důvěryhodných metadatech a zachovejte autorizaci cílového API. Human Handoff pozastaví odpovědi AI a vloží rozhovor do Inbox, při výběru kolegy směrováním jako přiřazený, jinak nepřiřazený. Přiřazení nezaručuje okamžitou odpověď člověka. Navržené vrácení vyžaduje vhodné externí služby a konfiguraci; nejde o příslib nativního vyřízení vratek či refundací.

Kompromisy mezi náklady a výkonem

Volba mezi chatbotem a agentem AI je zčásti architektonické a zčásti ekonomické rozhodnutí.

Ekonomika chatbotů

Skriptovaný postup může obejít inferenci LLM, ale jeho mezní náklad nemusí být nulový. Zahrňte hosting, licence, navazující API, monitoring a lidskou práci. Jednoduché vyhledání může být levné v obou architekturách; změřte konkrétní nasazení.

Údržba zahrnuje postupy, šablony, integrace a testy. Agentní systém přidává práci s prompty, vyhledáváním, nástroji a vyhodnocením. Odhadujte obě řešení pro stejný rozsah a období, místo předpokladu nižší údržby jednoho z nich.

Ekonomika AI agentů

Inference a nástroje spotřebovávají zdroje, ale platforma může účtovat kredity, rozhovory, vyřešené případy, uživatele nebo předplatné. Interní cena tokenů nemusí být fakturační jednotkou zákazníka.

Porovnejte aktuální podmínky přímo: Quickchat AI, Intercom a Salesforce Agentforce mají vlastní jednotky a podmínky. Ověřte základní poplatek, minimální závazek, zahrnuté využití, překročení a definici účtovaného výsledku. Rozhovor není totéž co ověřené vyřešení. Průvodce cenovými modely AI agentů pomáhá porovnat rozsahy bez ztotožnění inzerovaných sazeb.

Náklad na ověřený výsledek odhadujte ze své skupiny způsobilých požadavků. Zahrňte neúspěšné pokusy, opakované kontakty, lidské opravy, průběžné náklady a zavedení. Cena lidské podpory také závisí na kanálu a rozsahu nákladů; obecná oborová hodnota není srovnatelným výchozím stavem. Uvolněný čas je kapacita, ne peněžní úspora, pokud neklesne skutečný náklad nebo se nevyhnete plánovanému výdaji.

Výpočet za společné období popisuje návod k ROI chatbota. Nepředpokládáme vyšší míru vyřešení ani procentní úsporu. Měřte první užitečnou odpověď i ověřené dokončení, včetně navazujících služeb a předání; ani jedna architektura nemá univerzální interval latence.

Měření úspěchu jinak

Pro srovnání používejte společná kritéria výsledků a doplňte diagnostiku různých způsobů selhání.

Diagnostika postupu zahrnuje rozpoznané záměry, důvody fallbacku, změny stavů, chyby API a dokončení povinných kroků. Dokončený postup nemusí znamenat vyřešený problém zákazníka.

Výsledkové metriky zahrnují ověřená vyřešení mezi způsobilými požadavky, opakované kontakty, lidské opravy, spokojenost spolu s počtem odpovědí v průzkumu a náklad na ověřený výsledek. U agentů kontrolujte i nepodložená tvrzení, výběr nástroje, odmítnutí přístupu a nejisté zápisy. Vygenerovaná odpověď, přijatá žádost a dokončená refundace nejsou stejný výsledek.

Průvodce analytikou chatbotů rozlišuje pozorování dostupná v produktu od metrik vyžadujících externí důkazy a obsahuje syntetický list. Před srovnáním stanovte jmenovatel i období; list není benchmark.

Uchovejte důkazy pro samostatnou kontrolu odpovědi k pravidlům, autorizovaného čtení, vnější změny a předání. Zdroje, výsledky nástrojů a autoritativní stav systému mají různé účely. Používejte syntetické nebo náležitě chráněné záznamy a nesdílejte soukromá zákaznická data v příkladech.

FAQ

Můžu svého stávajícího chatbota převést na AI agenta?

Často lze postupně přidat porozumění jazyku nebo vybrané nástroje a zachovat užitečné postupy, znalosti i integrace. Výběr nástrojů modelem je architektonická změna vyžadující vyhodnocení. Zachovejte autorizaci, požadovaná schválení a spolehlivé deterministické kroky, neodstraňujte je jen kvůli názvu agent.

Jsou AI agenti dražší než chatboti?

Univerzální odpověď neexistuje. Porovnejte předplatné, jednotky, využití, zavedení, údržbu a lidské opravy pro stejné úkoly a období. Volání modelu přidávají zdrojové náklady, ale zákaznické účtování se liší. Vyšší míru vyřešení i peněžní úspory je třeba měřit; uvolněný čas není automaticky ušetřená hotovost.

Halucinují AI agenti?

Ano. Vyhledávání může dodat relevantní zdroje, ale nezaručuje správnou odpověď. Ověřte, zda tvrzení ze zdrojů vyplývá a zda výsledek nástroje potvrzuje uváděný výsledek operace. Stejnou kontrolu používejte i u LLM chatbotů pouze pro odpovědi a při nedostatku důkazů věc předejte člověku.

Dokáže AI agent zvládnout úkoly, které chatbot neumí?

Agent může vybírat užitečné kroky pro proměnlivé požadavky mimo stávající postup. Skriptovaný chatbot také umí volat API, uchovávat stav a provádět vícekrokové úkoly. Schopnosti závisejí na integracích, oprávněních, pravidlech a důkazech, ne na názvu rozhraní. Žádost o vrácení stále vyžaduje samostatné oprávnění k zápisu.

A co latence?

Měřte čas do první užitečné odpovědi a ověřeného dokončení na reprezentativních úlohách, včetně pomalých a neúspěšných volání. Uvádějte rozdělení, například medián a 95. percentil, vůči svému požadavku. Další modelové a nástrojové kroky mohou zdržovat; označení samo neurčuje univerzální čas ani jeho přijatelnost.

Je „AI agent“ jen marketingové přejmenování „chatbota“?

Názvy se překrývají. Chatbot označuje interakční rozhraní, zatímco agentní řízení obvykle znamená, že model vybírá kroky či nástroje za běhu. Prohlédněte skutečný postup, oprávnění, ukončovací podmínky a důkazy výsledků. Samotný název produktu nezaručuje větší autonomii, přesnost ani obchodní přínos.