Langfuse ve výrobní firmě od poptávky po kontrolu AI agentů

AI připravuje nabídky, přepisuje objednávky do systému a pomáhá dvěma lidem v IT vyvíjet aplikace, na které dříve nebyla kapacita. Firma zvládá více práce. Když ale agent slíbí nesprávný termín dodání, potřebuje vědět, odkud ho vzal. Právě tady získává Langfuse konkrétní hodnotu.

Část první pro obchod a vedení firmy

Firma už s AI umí pracovat

Představme si výrobce průmyslových komponentů, který část zboží vyrábí a část nakupuje k dalšímu prodeji. Má vlastní sklad, obchodníky, e-shop a malé IT: dva lidi na integrace, aplikace i provoz. Jde o modelovou firmu a navržené řešení, nikoli o zákaznickou případovou studii.

AI už používá napříč podnikem. Agent přečte poptávku z e-mailu, dohledá položky a připraví nabídku. Jiný převádí přijaté objednávky do návrhů zakázek. Obchod dostává podklady pro následné oslovení zákazníka. Marketing připravuje texty z produktových listů. Vývojáři denně používají AI při psaní kódu, testů a integrací.

To je dobrý výsledek: firma našla práci, kterou lze zjednodušit. S každou další automatizací ale přibývá míst, kde se může drobná nepřesnost proměnit ve skutečný závazek vůči zákazníkovi.

Jeden páteční termín a několik možných příčin

Zákazník poptává 200 kusů součástky. Agent připraví nabídku s dodáním v pátek. Obchodník při kontrole zjistí, že většina zásoby je rezervovaná pro jinou zakázku. Zboží sice fyzicky leží ve skladu, pro tuto objednávku však dostupné není.

Kde vznikla chyba? Agent mohl přehlédnout rezervace. Integrace mu mohla poslat pouze celkovou zásobu. Nová verze instrukcí mohla zaměnit předběžný odhad za potvrzený termín. A chyba mohla být i v kódu, který IT včera upravilo s pomocí AI.

Bez propojeného záznamu se hledá v e-mailech, aplikačních logách a historii změn. Účet za model potvrdí, že proběhlo volání. Poslední odpověď ukáže chybný slib. Co se stalo mezi tím, nemusí být dohledatelné.

Langfuse může při správném napojení spojit zadání, použité podklady, volání nástrojů, odpověď modelu a verzi aplikace do jednoho záznamu. Takovému záznamu se říká trace. Nejde o čtení myšlenek modelu: vidíme zaznamenané vstupy, výstupy a provedené kroky aplikace. [1]

V našem příběhu záznam ukáže, že nástroj vrátil 240 kusů skladem, ale údaj o 180 rezervovaných kusech v odpovědi úplně chyběl. Model dostal neúplný podklad. IT tak ví, že musí opravit rozhraní do skladu a kontrolu dostupnosti. Samotná věta „buď přesnější“ v zadání by příčinu neodstranila.

Co se změní v každodenní práci

Stejný princip pomáhá i mimo nabídky. Každý tým potřebuje vysvětlit jiný výsledek, ale společným základem je vazba mezi podkladem, akcí a hodnocením.

Tyto informace se musí do řešení doplnit. Langfuse sám neprohledá ERP ani nezjistí, že slíbený termín odporuje výrobnímu plánu. Přínos vzniká spojením jeho funkcí s tím, co firma považuje za správně dokončenou práci.

Přehled o kvalitě je důležitější než počet odpovědí

Vedoucí obchodu nepotřebuje sledovat každé volání modelu. Potřebuje vědět, kolik nabídek bylo použitelných, kde se vracejí opravy a zda nová verze opravdu pomohla.

Langfuse umožňuje připravit frontu případů k lidskému hodnocení. Obchodník u vybraných nabídek označí správnost ceny, termínu a položek; marketing posoudí věrnost produktovým podkladům. Takové hodnocení se připojí ke konkrétnímu běhu. Člověk, který zná obchodní realitu, tak dodává zpětnou vazbu přímo k práci agenta. [2]

Zachycená chyba se navíc může stát testovacím případem. Poptávka na rezervované zboží zůstane v sadě, na které se porovná každá další úprava. Langfuse podporuje datové sady a experimenty pro takové porovnávání. [3]

Pro malý tým je cenné právě toto opakované využití zkušenosti. Jednou vyřešený problém už nemusí zůstat jen v paměti vývojáře, který měl ten den službu.

Část druhá pro IT tým

Konkrétní architektura pro malý IT tým

Referenční varianta používá Google Cloud pro běh aplikací a Langfuse provozovaný u nás, nebo na vaší infrastruktuře. Model se volá přes firemní LLM bránu LiteLLM. Konkrétní služba a region modelu se schvalují samostatně: to, kde jsou uložené záznamy v Langfuse, neurčuje, kde model zpracuje požadavek.

Poptávku přijme aplikace, uloží její stav a vloží úkol do Cloud Tasks. Úkol zpracuje worker v Cloud Run. Google toto propojení dokumentuje včetně autentizace pomocí servisního účtu. [4] Worker může obsluhovat několik jasně oddělených postupů; každý agent nemusí být samostatná služba.

flowchart TD
    A["E-mail, e-shop a CRM"] --> B["Příjem požadavku a fronta Cloud Tasks"]
    B --> C["Worker agentů v Cloud Run"]
    C --> D["LLM brána LiteLLM"]
    D --> E["Schválené nasazení modelu"]
    C --> F["API firemních nástrojů"]
    F --> G["ERP, sklad a produktová data"]
    C --> H["Návrh a schválení v obchodní aplikaci"]
    H --> F
    C -. "záznamy běhů" .-> I["Langfuse"]
    F -. "záznamy operací" .-> I

Plné šipky ukazují volání a předání práce. Přerušované šipky představují telemetrii. Stav zakázky a schválení zůstává v obchodní aplikaci a její databázi; Langfuse není zdrojem pravdy o objednávkách.

Rozdělení odpovědností je konkrétní:

• Worker skládá kroky, hlídá čas a počet opakování a předává výjimky člověku.
• API nástrojů ověřuje oprávnění, pracuje s ERP a vynucuje pravidla pro zápis. Zvlášť nabízí čtení dostupnosti, vytvoření návrhu a potvrzení zakázky.
• LLM brána omezuje přístup k modelům a odděluje rozpočty zakázek, marketingu a vývoje. Rozpočty LiteLLM vyžadují PostgreSQL; při více instancích slouží Redis ke sdílení čítačů a dalšího stavu. Chování limitů při výpadku databáze či Redis je součástí konfigurace a provozního testu. [5]
• Langfuse zaznamenává průběh, spravuje verze promptů a propojuje výsledky s hodnocením.

Agent dostává pouze oprávnění potřebná pro svůj postup. Marketing nepotřebuje potvrzovat zakázky. Vývojový agent nemá produkční přihlašovací údaje do ERP. U brány se schvalují konkrétní nasazení modelů včetně náhradního směrování.

Začít jedním celým procesem

První implementace sleduje cestu od poptávky k návrhu nabídky. Je dost malá, aby ji dva lidé zvládli udržovat, a obsahuje všechny důležité vazby.

V Langfuse vznikne produkční projekt pro obchodní automatizaci a samostatný projekt pro vývoj a testy. Marketing s jiným okruhem oprávněných lidí může mít vlastní projekt. Samotný štítek prostředí není oddělením přístupů; Langfuse staví řízení práv na organizacích, projektech a rolích. Dostupnost jemnějších oprávnění závisí na variantě služby. [6]

Jeden pokus o zpracování má vlastní trace. Pseudonymní označení obchodního případu tvoří session_id, aby šly propojit další úpravy a navazující běhy. Do kontextu patří verze aplikace, identifikace nasazení modelu a účel automatizace. U konkrétních kroků se zaznamená verze ceníku, čas získání skladových dat a výsledek kontroly dostupnosti.

Jednotlivé kroky mají vlastní záznamy: načtení poptávky, dotaz do skladu, práce s modelem, kontrola návrhu a zápis do ERP. Python SDK umí takto vnořená pozorování vytvářet pomocí kontextových bloků nebo dekorátorů. [7]

V této variantě zapisuje volání modelu aplikace. Zapnutí stejného záznamu současně v bráně by mohlo zdvojit evidenci a náklady. Langfuse dokumentuje obě integrační cesty; tým si pro dané volání vybere jednu. [8] Přes frontu a mezi službami se předává kontext trasování. U MCP propojení se přenáší také přes pole _meta. [9]

Ukázka napojení nabídky v Pythonu

Následující výřez ukazuje instrumentaci a rozhodovací bod. Funkce load_facts a call_model jsou adaptéry konkrétní firmy: první vrací ověřené a očištěné podklady, druhá volá schválenou bránu. V Langfuse existuje chatový prompt quote-draft s proměnnou facts; jeho otestovanou verzi určuje konfigurace releasu. SDK používá projektové klíče a LANGFUSE_BASE_URL z bezpečné konfigurace prostředí. [7][10]

import json
from langfuse import get_client, propagate_attributes

lf = get_client()

def prepare_quote(case_ref, load_facts, call_model, prompt_version):
    with lf.start_as_current_observation(
        name="quote.prepare", as_type="span"
    ) as run:
        with propagate_attributes(
            session_id=case_ref,
            version="quote-app-1.4.0",
            tags=["sales"],
        ):
            with lf.start_as_current_observation(
                name="erp.availability", as_type="tool"
            ) as tool:
                facts = load_facts()
                tool.update(output=facts)

            if facts["status"] != "ok" or not facts["can_promise"]:
                result = {"status": "needs_review"}
            else:
                prompt = lf.get_prompt(
                    "quote-draft", type="chat", version=prompt_version
                )
                messages = prompt.compile(
                    facts=json.dumps(facts, ensure_ascii=False)
                )
                with lf.start_as_current_observation(
                    name="quote.compose", as_type="generation",
                    prompt=prompt, input=messages,
                ) as generation:
                    reply = call_model(messages)
                    generation.update(
                        output=reply["text"], model=reply["model"],
                        usage_details=reply["usage"],
                    )
                result = {"status": "draft", "text": reply["text"]}

            run.update(output={"status": result["status"]})
            return result

Rozhodnutí can_promise počítá firemní služba podle volné zásoby, rezervací a platných termínů. Tento údaj nesmí dodávat zákaznický text ani odhadovat jazykový model. V našem případu 240 kusů skladem a 180 rezervovaných znamená jen 60 volných kusů: poptávka na 200 skončí u člověka.

Vrácený návrh ještě prochází kontrolou položek, ceny a termínu. Ukázka nic neposílá zákazníkovi ani nepotvrzuje v ERP. Zápisy řeší navazující aplikační krok.

Adaptér vrací skutečně použitý model a spotřebu v podporovaném formátu. Při vlastním mapování tokenů se kategorie nesmějí překrývat; jinak může vzniknout dvojí započtení. Pro interní názvy modelů se nastaví odpovídající ceny. [11] Obslužná funkce workeru po ukončení záznamu volá lf.flush(), aby se dokončil export před koncem krátkého běhu. [7]

Oprava se ověřuje na obchodních situacích

Vedle unit testů vznikne v Langfuse úvodní sada například 40 případů. Je to navržený rozsah pilotu, nikoli hranice zaručující spolehlivost. Sada pokrývá běžné objednávky i situace, na kterých může firma prodělat.

Část výsledků se kontroluje kódem: správná položka, cena podle pravidel, existence jediného návrhu v testovacím ERP. Hodnocení věrnosti textu může doplnit další model a lidská kontrola. Výsledek modelového hodnotitele se nejprve porovná s posouzením obchodníka. [2][3]

Testy běží nad uloženými podklady a sandboxem, kde nemohou založit skutečnou zakázku ani odeslat nabídku. Stejnou sadu dostane dosavadní i kandidátní verze kódu, promptu a modelu. CI nasazení zastaví při selhání kritického pravidla; Langfuse pro experimenty v CI/CD takové vyhodnocení podporuje. Úspěch v této sadě dokládá výsledek konkrétních testů, ne bezchybnost celého provozu. [12]

AI vývojář dostane konkrétní závadu a ověřitelný výsledek

Tady se propojí automatizace obchodu s vývojem pomocí AI. Langfuse dnes nabízí agentům přístup přes skill a CLI, MCP server nebo veřejné API. Agent tak může hledat chybové běhy, porovnávat verze a pracovat s testovacími daty. [13]

V našem návrhu dostane vývojový agent očištěný záznam chybné nabídky a zadání: zjistit, proč chyběly rezervace, upravit adaptér a přidat regresní test. Připraví změnu v repozitáři. CI porovná výsledky a vývojář schválí nasazení. Produkční prompty ani ERP agent při diagnostice měnit nemůže.

Toto omezení je potřeba skutečně nastavit. Dokumentace Langfuse MCP uvádí, že ve výchozím stavu jsou dostupné čtecí i zapisovací nástroje. Přístup se proto omezí povolenými nástroji a odpovídajícím oprávněním; samotná instrukce „jen se dívej“ přístupová práva nenahrazuje. [13]

Tím vzniká opakovatelný postup: provoz odhalí případ, Langfuse dodá souvislosti, AI pomůže s opravou a test ověří její účinek. Běžné testy aplikace, kontrola závislostí a revize změny zůstávají součástí vývoje.

Co se hlídá za běhu

Pro obchod mají smysl čtyři přehledy: podíl návrhů schválených bez opravy, podíl předání člověku, čas od poptávky k použitelnému návrhu a náklady modelů na použitelný návrh. Poslední ukazatel zahrnuje i spotřebu neúspěšných pokusů. Čas lidí a provoz infrastruktury se připočítávají zvlášť.

Výsledek schválení posílá obchodní aplikace do Langfuse jako hodnocení. Bez tohoto napojení by přehled ukazoval především technický konec běhu, nikoli obchodní úspěch. Předání člověku přitom není automaticky chyba: u nepotvrzené dostupnosti je správným výsledkem.

Langfuse umožňuje nad zaznamenanými metrikami a skóre nastavovat upozornění, například na růst nákladů nebo zhoršení kvality; v aktuální dokumentaci jsou dostupná v cloudu a u vlastního nasazení od verze 4. [14] Upozornění však není synchronní zákaz další operace. Okamžité limity počtu kroků a opakování vynucuje worker, rozpočty brána a oprávnění API nástrojů. Langfuse jejich účinnost pomáhá zpětně posoudit. [15]

Potvrzení nabídky a zápis zakázky proto probíhají mimo samotné generování textu. Schválení se váže na přesnou verzi nabídky; změna ceny nebo termínu vyžaduje nové schválení. Zápis má idempotentní identifikátor, aby opakování úkolu nevytvořilo druhou objednávku. Pokud není jasné, zda ERP první zápis dokončilo, aplikace nejprve ověří jeho výsledek.

Přehled nesmí vytvořit další neřízenou kopii firemních dat

Záznamy mohou obsahovat nákupní ceny, zákaznické zprávy i interní dokumenty. Do produkčního napojení proto patří výběr potřebných údajů, maskování před exportem, přístupová práva a doba uchování. Langfuse podporuje maskování vstupů, výstupů a metadat; u dalších exporterů a logů se ochrana řeší samostatně. [16]

Stejné pravidlo platí pro AI vývojáře i automatického hodnotitele. Pokud dostanou obsah záznamu, vzniká další cesta, kterou firemní data odcházejí do modelu.

Pro dva lidi v IT by vlastní provoz Langfuse byl další odpovědností navíc. Zahrnuje aplikaci Web, Worker, PostgreSQL, ClickHouse, Redis či Valkey a objektové úložiště; Docker Compose na jedné VM označuje dokumentace za variantu pro lokální použití a testování bez vysoké dostupnosti, škálování a záloh. [17] Proto Langfuse provozujeme my: na naší platformě, nebo na vaší infrastruktuře, včetně aktualizací, záloh a dohledu. Záznamy tak zůstávají v prostředí, které firma zná, a její IT se o další systém starat nemusí.

Ani Langfuse nemá být jediným místem, kde se eviduje schválení nebo zápis objednávky. Export telemetrie může mít zpoždění a aplikace potřebuje sledovat i jeho výpadky. Pokud používá prompty z Langfuse, připraví cache a otestovanou záložní verzi pro studený start při nedostupnosti služby; samotná cache nepokrývá situaci, kdy ještě není naplněná. [18]

Vraťme se k pátečnímu termínu. Po opravě už další podobná poptávka dostane jiný průběh: rezervace jsou součástí podkladu, nedostatečná dostupnost vede k předání obchodníkovi a test hlídá, aby se původní chyba nevrátila. Firma navíc ví, která verze opravu přinesla a jak se chová na dalších zakázkách.

Malý IT tým získává z AI větší kapacitu. Langfuse mu pomáhá udržet souvislost mezi rychlostí vývoje a skutečným výsledkem ve firmě: od konkrétního příslibu zákazníkovi až ke kroku, který ho způsobil.

Zdroje

1. Langfuse — Observability & Application Tracing. Zaznamenávání volání, podkladů a souvisejících kroků.
2. Langfuse — Annotation Queues. Lidské hodnocení, opravené výstupy a kalibrace modelových hodnotitelů.
3. Langfuse — Datasets. Testovací případy, očekávané výsledky a využití produkčních záznamů.
4. Google Cloud — Executing asynchronous tasks. Propojení Cloud Tasks a Cloud Run.
5. LiteLLM — Budgets, Rate Limits a Production Best Practices. Databázové závislosti, sdílení stavu a chování při výpadcích.
6. Langfuse — Access Control. Organizace, projekty, role a projektové API klíče.
7. Langfuse — Instrumentation. Python SDK, vnořená pozorování a předávání kontextu.
8. Langfuse — LiteLLM Proxy Integration. Varianty integrace na straně brány a klientské aplikace.
9. Langfuse — MCP Tracing. Propojení trasování klienta a serveru.
10. Langfuse — Get Started with Prompt Management a Link Prompts to Traces. Načtení promptu a přiřazení jeho verze ke generování.
11. Langfuse — Model Usage & Cost Tracking. Cenové definice, skutečná spotřeba a nepřekrývající se kategorie tokenů.
12. Langfuse — Experiments in CI/CD. Porovnávání verzí a zastavení postupu při regresi.
13. Langfuse — Agentic access a MCP Server. Přístup vývojových agentů a výchozí dostupnost čtecích i zapisovacích nástrojů.
14. Langfuse — Alerts. Upozornění nad metrikami, skóre a chybějícími daty; dostupnost podle varianty a verze.
15. Langfuse — Security & Guardrails. Rozdíl mezi ochranami za běhu a následným vyhodnocením v Langfuse.
16. Langfuse — Masking. Omezení citlivých údajů před exportem telemetrie.
17. Langfuse — Self-hosting. Součásti vlastního nasazení a omezení základní varianty Docker Compose.
18. Langfuse — Caching of Prompts. Cache, přednačtení a záložní prompty.

Příklad firmy, skladové počty, návrh architektury a rozsah pilotní testovací sady jsou ilustrativní. Nejde o výsledky měření konkrétního zákazníka. Funkce produktů jsou popsány podle dokumentace ověřené 26. října 2026.