AI může připravit odpověď během několika sekund. Firemní požadavek ale často čeká na doplnění, schválení nebo zápis do dalšího systému. Praktické srovnání ukazuje, kdy pro takový proces stačí LangChain a kdy dává smysl řídit jeho stav a větvení pomocí LangGraphu.
Rozdíl není jen technický. Ovlivňuje, zda firma dokáže zjistit, v jakém kroku se požadavek nachází, kdo má rozhodnout a co se stane po chybě. Zároveň neplatí, že složitější nástroj automaticky vytvoří lepší řešení. Mnoho úloh zvládne jednoduchá integrace nebo běžná automatizace bez AI.
Odpověď AI ještě není dokončený firemní proces
Jednorázová úloha má jasný začátek a konec. Systém dostane otázku, načte podklady a vrátí návrh. Pokud jde například o shrnutí servisního protokolu pro interní potřebu, může být takový průběh dostačující.
Provozní požadavek obvykle pokračuje dál. Může chybět číslo zakázky, souhlas vedoucího nebo potvrzení zákazníka. Odpověď se nemá jen vygenerovat, ale také správně přiřadit, zkontrolovat, uložit a někdy odeslat. Mezi jednotlivými kroky mohou uplynout hodiny nebo dny.
Dobrá vstupní otázka proto není „Který AI framework je nejlepší?“, ale „Jaký stav musí proces udržet, než bude požadavek skutečně uzavřen?“ Teprve z odpovědi vyplyne, jakou technickou vrstvu firma potřebuje.
Modelový proces: změna rozsahu servisní zakázky
Následující příklad je záměrně fiktivní. Zákazník pošle e-mail, že při plánované návštěvě technika potřebuje prověřit ještě další zařízení. Firma nechce zprávu jen shrnout. Potřebuje rozhodnout, zda jde o součást původní objednávky, změnu rozsahu, nebo nový požadavek.
Přijetí a přiřazení: systém rozpozná zákazníka, objekt a pravděpodobnou zakázku.
Načtení kontextu: získá objednaný rozsah, termín, přiřazeného technika a dostupné dokumenty.
Kontrola úplnosti: ověří, zda má dost podkladů. Pokud ne, připraví doplňující otázku místo domýšlení údajů.
Návrh dalšího kroku: připraví návrh odpovědi a doporučí, zda požadavek připojit k zakázce, předat k nacenění, nebo založit samostatně.
Schválení: odpovědný člověk návrh schválí, upraví, nebo vrátí s poznámkou.
Provedení: systém po schválení aktualizuje evidenci a připraví nebo odešle odpověď podle nastaveného oprávnění.
Doklad o výsledku: uloží, co bylo provedeno, kým a s jakým výsledkem.
AI je v tomto toku užitečná pro práci s neuspořádaným textem a výběr nástrojů. Pevná pravidla mají dál hlídat oprávnění, povinná pole, povolené přechody stavů a zápisy s dopadem na klienta nebo peníze. Právě spojení flexibilního úsudku a deterministických kontrol odlišuje provozní workflow od obyčejného chatu.
Co v tomto procesu řeší LangChain
LangChain je podle aktuální dokumentace framework pro vytváření agentů. Nabízí jednotné rozhraní pro modely, nástroje a agentní smyčku, doplněné o middleware. Prakticky to znamená, že vývojový tým může definovat, jaké zdroje smí agent číst, jaké funkce smí volat a jak má vypadat jeho výstup.
LangChain dává smysl jako výchozí vrstva, když má úloha jeden souvislý běh a agent potřebuje například:
načíst údaje z CRM nebo dokumentové evidence,
vybrat z několika bezpečných nástrojů,
vrátit strukturovaný návrh,
uplatnit validační pravidla nebo jednoduchý schvalovací zásah,
zaznamenat průběh pro následnou kontrolu.
Důležitá současná souvislost: LangChain a LangGraph nejsou dvě vzájemně se vylučující alternativy. Agenti vytvoření přes LangChain běží nad LangGraphem. V praxi se tedy rozhoduje spíše mezi použitím hotové vyšší abstrakce a přímým návrhem vlastního grafu s přesně řízeným stavem.
Kdy je potřeba řídit stav přímo v LangGraphu
LangGraph je nízkoúrovňový orchestrační framework a runtime pro dlouhé stavové procesy a agenty. Proces modeluje jako kroky a přechody nad společným stavem. To je užitečné ve chvíli, kdy nestačí vědět, jakou odpověď model vrátil, ale je nutné uchovat i to, co už bylo ověřeno, na koho se čeká a která akce už proběhla.
Přímé použití LangGraphu dává větší smysl, když proces:
má více větví podle typu požadavku nebo míry rizika,
se musí bezpečně zastavit před odesláním, zápisem nebo jinou citlivou akcí,
čeká na člověka či externí systém déle než jeden běh aplikace,
potřebuje pokračovat z posledního potvrzeného kroku po výpadku,
kombinuje volnější rozhodnutí modelu s pevnými pravidly,
musí zpětně ukázat cestu, kterou konkrétní požadavek prošel.
Dokumentace LangGraphu pro tento účel popisuje ukládání kontrolních bodů, perzistenci a přerušení. Přerušení umožní proces pozastavit, předložit člověku chystanou akci a po jeho rozhodnutí navázat na uložený stav. To je vhodné například před odesláním závazné odpovědi, změnou termínu nebo zápisem částky.
Obnova ale neznamená, že je automaticky bezpečné zopakovat každý krok. Volání externího systému může po přerušení proběhnout znovu. Zápisy a odesílání proto musí být navržené idempotentně: stejný požadavek se nemá založit dvakrát a stejný e-mail se nemá odeslat podruhé. LangGraph poskytuje mechanismus pro uchování a obnovu běhu, ale správnost vedlejších účinků zůstává součástí návrhu aplikace.
LangChain, LangGraph, nebo automatizace bez AI?
| Provozní situace | Rozumný výchozí přístup | Proč |
|---|---|---|
| Jednoduché přepsání údajů mezi systémy podle pevných pravidel | Běžná automatizace bez AI | Výsledek je předvídatelný a není potřeba úsudek jazykového modelu. |
| Načtení podkladů a příprava jednoho strukturovaného návrhu | LangChain nebo srovnatelná vyšší agentní vrstva | Rychlý start, standardní práce s modely a nástroji. |
| Citlivá akce, před níž stačí jednoduché schválení člověkem | LangChain agent se schvalovací politikou | Vyšší vrstva už umí lidský zásah a využívá LangGraph pod povrchem. |
| Proces na několik hodin či dní s větvením a návratem | Vlastní workflow v LangGraphu | Je potřeba explicitní stav, kontrolní body a přesné přechody. |
| Zápisy do více systémů, u nichž hrozí duplicitní provedení | LangGraph spolu s idempotentními integračními kroky | Orchestrace pomůže obnovit běh, integrace musí zabránit dvojím akcím. |
Tato tabulka není univerzální technický verdikt. Stejný nástroj lze použít pro různé úlohy a konkrétní volbu ovlivní také existující systémy, zkušenost týmu, provozní náklady a požadavky na ochranu dat. Je to rozhodovací pomůcka pro první návrh.
Pilot má ověřit proces, ne popularitu frameworku
První pilot by měl být menší než cílová představa. Vhodný je jeden typ požadavku, omezený počet nástrojů a jasně určený schvalovatel. Před vývojem je užitečné zmapovat skutečný proces: vstupy, stavy, rozhodnutí, oprávnění a doklad o dokončení.
Minimální kontrolní seznam pro pilot:
Rozsah: jaký požadavek agent přijímá a kdy ho musí předat člověku.
Zdroj pravdy: ze kterého systému se berou platné údaje o klientovi, zakázce a termínu.
Oprávnění: co smí systém jen číst, co může připravit a co může provést až po schválení.
Stav: jak se pozná, že proces čeká na doplnění, schválení, externí systém nebo opravu chyby.
Opakovatelnost: jak se zabrání duplicitnímu e-mailu, úkolu, objednávce nebo zápisu.
Audit: zda lze dohledat vstup, navrženou akci, lidské rozhodnutí a skutečný výsledek.
Měření: kolik požadavků projde správně, kolik vyžaduje opravu a kde proces nejčastěji stojí.
Generativní model může vytvořit přesvědčivě znějící, ale chybný obsah. NIST tento jev uvádí mezi riziky generativní AI. Lidské schválení proto nemá být dekorativní tlačítko. Schvalovatel musí vidět podklady, navrženou změnu i její očekávaný dopad.
Pokud firma teprve hledá první vhodný případ, pomůže začít od článku AI ve firmě prakticky. Pro posouzení konkrétního toku dat, schvalování a integrací dává smysl navázat praktickým AI zaškolením a návrhem pilotu.
Smyslem není složitější graf, ale dokončená a dohledatelná práce
LangChain je vhodný výchozí bod pro rychlé sestavení agenta z modelu, nástrojů a pravidel. LangGraph přináší přímou kontrolu nad stavem a průběhem tam, kde proces čeká, větví se, obnovuje po chybě nebo vyžaduje několik schvalovacích bodů. V aktuálním ekosystému se tyto vrstvy doplňují.
Nejlepší rozhodnutí proto nevychází z názvu knihovny. Vychází z toho, zda je každý požadavek přiřazený, kontrolovaný, bezpečně provedený a zpětně dohledatelný. Pokud takovou jistotu poskytne jednoduchá automatizace, není důvod stavět vlastní graf. Pokud se práce ztrácí mezi čekáním, schvalováním a opakovanými zápisy, explicitní orchestrace už může mít skutečnou provozní hodnotu.
