Kong AI Gateway: co umí a kdy ho použít pro AI agenty
Představte si Kong AI Gateway jako reverse proxy pro AI provoz. Agent neposílá požadavky přímo jednotlivým modelům a nástrojům, ale na interní endpointy Kongu. Gateway ověří volající aplikaci, uplatní limity a bezpečnostní pravidla, vybere cílovou službu a zapíše provozní metriky.
Kong není jazykový model ani framework pro tvorbu agentů. Agent stále plánuje kroky, udržuje stav a rozhoduje, kdy zavolat nástroj. Kong stojí v datové cestě těchto volání a řeší jejich provoz: autentizaci, směrování, přístupové údaje k poskytovatelům, limity, fallbacky a audit.
Krátká odpověď: Kong AI Gateway dává největší smysl tam, kde více aplikací nebo týmů používá několik modelů, MCP serverů a agentů a potřebuje nad nimi jednotná pravidla. Zvlášť přirozenou volbou je ve firmě, která už Kong používá pro běžná API.
Co je Kong a proč se o něm mluví u AI agentů
Klasická API gateway stojí před backendy: přijme HTTP požadavek, ověří klienta, najde odpovídající route a předá požadavek upstream službě. Kong AI Gateway tento model rozšiřuje o protokoly, formáty a metriky typické pro generativní AI.
V agentním systému se obvykle potkávají tři samostatné datové cesty:
- Agent → model: HTTP volání OpenAI, Anthropic, Gemini, Mistralu nebo vlastního modelu. Kong zde může sjednotit formát, skrýt klíče poskytovatelů a vybrat cílový model.
- Agent → nástroj: volání databáze, CRM, repozitáře či interního API, stále častěji přes Model Context Protocol (MCP).
- Agent → jiný agent: delegování úloh specializovaným agentům, například přes Agent2Agent Protocol (A2A).
Důležité rozlišení: nejde o jeden „magický“ endpoint. LLM, MCP a A2A provoz používají samostatné routes a pluginy. Když model vrátí tool_call, Kong nástroj automaticky nespustí. Výsledek zpracuje agentní runtime a ten následně odešle samostatné MCP volání, které může znovu projít přes Kong.
Právě možnost spravovat tyto cesty na jedné gateway je hlavní výhoda Kongu. Aplikační tým ponechá orchestrace v kódu agenta, zatímco platformní tým nastaví společná provozní pravidla v Kongu nebo v řídicí rovině Konnect.
Podrobnější rozdíl mezi cestou k modelům a cestou k nástrojům vysvětlujeme v článku LLM gateway a MCP gateway: dvě brány pro firemní AI. Tady se zaměříme přímo na Kong a jeho alternativy.
Co Kong AI Gateway konkrétně umí
1. Jednotný vstup k více modelům
Aplikace nemusí spravovat SDK, URL a API klíč každého poskytovatele zvlášť. Na vlastní Kong route může posílat například OpenAI kompatibilní požadavek. Plugin AI Proxy požadavek přeloží do formátu zvoleného poskytovatele a odpověď převede zpět. Skutečné klíče k modelům tak mohou zůstat v konfiguraci gateway místo v každé aplikaci.
AI Proxy Advanced přidává více cílů, load balancing, retry, circuit breaker a fallback. Gateway může volit model například metodou round-robin, podle latence, spotřeby nebo sémantické podobnosti promptu s popisem modelu. Při výpadku primárního cíle může požadavek předat jinému poskytovateli.
Kompatibilní HTTP formát ale neznamená stejné chování. Před nasazením fallbacku otestujte streamování přes SSE, strukturu tool_calls, structured output, důvody ukončení i chybové odpovědi. Retry po timeoutu navíc může vytvořit druhý placený požadavek, i když první upstream požadavek už běží.
Pro agenta je tato vrstva praktická ze dvou důvodů: kód není pevně svázaný s jedním poskytovatelem a pravidla pro výběr modelu nejsou zkopírovaná v každé aplikaci. Samotné rozhodnutí, zda je odpověď pro danou úlohu dostatečně kvalitní, však stále patří do testů a evaluací aplikace.
2. Limity, náklady a ochrana promptů
Klasické API limity počítají požadavky. U AI ale jeden požadavek může stát tisíckrát více než jiný. Kong proto umí pracovat také s tokeny a u vybraných funkcí s odhadovanými náklady. Politiky lze aplikovat centrálně podle klienta, aplikace nebo skupiny uživatelů.
Další pluginy řeší například:
- rate limiting podle požadavků, tokenů či nákladů;
- cache pro stejné nebo sémanticky podobné dotazy;
- povolená a zakázaná témata v promptech;
- úpravu systémových instrukcí a promptových šablon;
- logování latence, chyb, tokenů a dalších metrik.
Ne všechny pokročilé funkce jsou součástí bezplatné edice. Například AI Proxy Advanced a některé navazující pluginy patří do enterprise vrstvy. Při porovnávání řešení proto nestačí kontrolovat jen seznam funkcí — je potřeba ověřit také licenci a provozní náklady.
3. Brána pro MCP nástroje
Pro AI agenty je zásadní podpora Model Context Protocolu. Kong AI MCP Proxy umí stát před existujícím MCP serverem, ale také převést běžné REST API na MCP nástroje. Firma tak nemusí přepisovat každou interní službu jen proto, aby ji mohl používat agent.
Kong může několik sad nástrojů agregovat do jednoho MCP endpointu. Nad ním pak uplatní autentizaci, omezení provozu, audit a oprávnění pro konkrétní nástroje. Agent například uvidí nástroj pro čtení objednávek, ale ne nástroj pro jejich mazání.
To řeší častý problém rychle rostoucích agentních projektů: každý klient má vlastní seznam MCP serverů, vlastní klíče a jiná oprávnění. S gateway se klient připojuje na jedno místo a pravidla se spravují centrálně.
AI MCP Proxy vyžaduje podle aktuální dokumentace Kong Gateway 3.12 nebo novější. Při návrhu architektury je proto důležité kontrolovat konkrétní verzi gateway i verzi MCP protokolu, kterou používají upstream servery.
4. Řízení komunikace agent–agent
Vedle MCP Kong podporuje také provoz přes A2A. MCP standardizuje hlavně přístup k nástrojům a datům, zatímco A2A řeší komunikaci mezi samostatnými agenty. Brána zde může ověřovat identitu, omezovat přístup, měřit provoz a vytvářet auditní stopu stejně jako u běžných API.
Je to užitečné například tehdy, když obchodní agent deleguje kontrolu smlouvy právnímu agentovi a výpočet ceny cenovému agentovi. Bez centrální vrstvy vzniká další síť vzájemných spojení, tokenů a logů. Gateway ji dokáže sjednotit.
Jak vypadá požadavek přes Kong
Klient
↓
Agent runtime (plánování, stav, smyčka volání nástrojů)
├── HTTP / LLM route ──→ Kong + AI Proxy ──→ model
├── JSON-RPC / MCP ────→ Kong + MCP Proxy ─→ nástroj nebo API
└── JSON-RPC / A2A ────→ Kong + A2A Proxy ─→ jiný agent
Na gateway: autentizace · oprávnění · routing · limity · audit · metrikyU modelového volání proběhne typicky tato sekvence:
- Agent odešle
POSTna route definovanou v Kongu. Tělo může mít OpenAI kompatibilní formát, pokud je tak route nakonfigurovaná. - Kong ověří identitu aplikace, zkontroluje kvótu a aplikuje guardraily či další pluginy.
- AI Proxy vybere upstream model, doplní jeho přístupové údaje a případně přeloží formát požadavku.
- Odpověď nebo SSE stream projde zpět přes gateway, kde lze měřit latenci, tokeny a chyby.
- Vrátí-li model požadavek na nástroj, agentní runtime ho zpracuje a vytvoří nové MCP volání. Gateway sama agentní smyčku neřídí.
response = llm.chat(messages) # přes LLM route v Kongu
while response.tool_calls:
results = mcp.call(response.tool_calls) # samostatná MCP route
messages += [response, results]
response = llm.chat(messages)
return response.textPředstavme si agenta zákaznické podpory. Nejprve přes LLM route klasifikuje dotaz levnějším modelem. Potom přes MCP route načte stav objednávky; gateway ověří, zda identita agenta smí použít právě tento nástroj. Složitý případ může agent přes A2A route předat reklamačnímu agentovi.
Společné trace ID nevznikne automaticky. Agent musí mezi jednotlivými voláními propagovat trace context, například hlavičku traceparent, a gateway i aplikace musí exportovat telemetry do stejného systému. Bez toho uvidíte tři oddělené požadavky.
Praktické pravidlo je jednoduché: agent rozhoduje, co se má udělat; gateway rozhoduje, zda a kudy daný provoz projde. Obchodní logika zůstává v agentovi, ale provozní a bezpečnostní pravidla se nemusí implementovat znovu v každé aplikaci.
Co Kong neřeší
Slovo „AI Gateway“ může působit dojmem kompletní agentní platformy. Kong ale sám o sobě:
- nenavrhuje agentní smyčku ani nerozhoduje, jak agent plánuje;
- nenahrazuje LangGraph, CrewAI, Semantic Kernel ani vlastní orchestraci;
- neukládá automaticky dlouhodobou paměť a stav úloh;
- neřeší kvalitu odpovědí bez evaluačního procesu;
- nezaručuje bezpečnost nástroje jen proto, že jeho provoz prochází bránou;
- nenahrazuje lidské schválení rizikových akcí.
Gateway je kontrolní bod, ne mozek agenta. Pokud má agent příliš široká oprávnění, špatně navržený nástroj nebo nekonečnou smyčku, samotné nasazení Kongu problém neodstraní. Může však pomoci oprávnění omezit, provoz zastavit a incident zpětně dohledat.
Kong a podobná řešení: v čem se liší
Neexistuje jedna nejlepší AI gateway pro všechny. Produkty se liší hlavně tím, z jakého světa vyrostly.
LiteLLM: rychlý self-hosted vstup k modelům, MCP i A2A
LiteLLM začalo jako Python proxy sjednocující velké množství LLM poskytovatelů. Dnes nabízí také MCP Gateway a Agent Gateway pro A2A. Umí virtuální klíče, rozpočty, rate limity, routing a společný katalog modelů, MCP serverů i agentů.
Zvolte LiteLLM, když chcete rychle rozběhnout vlastní gateway, hlavním problémem je přístup k více modelům a nechcete zavádět plnohodnotnou enterprise API platformu. Počítejte ale s tím, že databázi, Redis, aktualizace a dostupnost self-hosted instalace budete provozovat sami.
Portkey: produkt zaměřený přímo na AI provoz
Portkey spojuje AI gateway, observabilitu, guardraily a správu promptů. Jeho MCP Gateway centralizuje autentizaci, oprávnění, injektování přístupových údajů a logování nástrojů. Modelová i MCP volání mohou být součástí stejného trace.
Zvolte Portkey, když chcete hotovější AI-native platformu s dashboardem a nechcete skládat většinu provozních funkcí z pluginů. Důkladně porovnejte managed a self-hosted variantu, licenční podmínky a požadavky na uložení dat.
Envoy AI Gateway: pro cloud-native a Kubernetes týmy
Envoy AI Gateway staví na Envoy Proxy a Kubernetes Gateway API. Nabízí integraci LLM poskytovatelů, OpenAI kompatibilní rozhraní, tokenové limity a fallbacky. Je přirozený pro platformní týmy, které už používají Envoy, Kubernetes nebo service mesh a chtějí AI provoz řídit stejnými deklarativními mechanismy.
Zvolte Envoy AI Gateway, když je pro vás klíčový výkon, otevřená cloud-native infrastruktura a hluboké napojení na Kubernetes. Pro malý tým bez platformních zkušeností může být jeho provoz zbytečně náročný.
Cloudflare AI Gateway: rychlá spravovaná vrstva na edgi
Cloudflare AI Gateway se zaměřuje na rychlé zapojení spravované služby: logy a analytiku, cache, rate limiting, retry, fallbacky, guardraily a limity výdajů. Hodí se zejména tam, kde už aplikace běží v ekosystému Cloudflare nebo tým nechce provozovat vlastní proxy.
Zvolte Cloudflare, když chcete co nejmenší provozní režii a hlavním tématem jsou modelová volání. Pokud potřebujete detailní správu interních MCP nástrojů nebo celé API portfolio, ověřte, zda aktuální rozsah produktu pokrývá vaše požadavky.
Tyk: API a MCP governance s jemnými oprávněními
Tyk rozšiřuje tradiční API management o MCP Gateway. Umí řídit přístup nejen k serveru jako celku, ale také k jednotlivým nástrojům, resources a prompts. Podporuje OAuth scopes, politiky, limity a filtrování JSON-RPC metod.
Zvolte Tyk, když potřebujete detailní governance MCP provozu a chcete ji spojit se správou běžných API. Stejně jako u Kongu je potřeba porovnat konkrétní edici a rozsah placených funkcí.
A co OpenRouter?
OpenRouter je velmi praktický jednotný vstup k velkému množství modelů a umí routing i fallbacky. Není ale přímou náhradou za plnohodnotnou gateway pro interní API, MCP nástroje a A2A komunikaci. Je vhodnější chápat ho jako hostovaný modelový router.
Jak vybrat správnou AI gateway
Začněte provozním problémem, ne názvem produktu:
- Už provozujete Kong: nejprve prověřte Kong AI Gateway. Využijete stávající know-how, politiky a observabilitu.
- Chcete rychlý self-hosted start: LiteLLM bývá jednodušší vstup, zvlášť pokud řešíte hlavně modely a rozpočty.
- Chcete hotovou AI operations platformu: porovnejte Portkey a další AI-native služby.
- Jste Kubernetes platformní tým: dává smysl Envoy AI Gateway.
- Chcete managed edge službu: prověřte Cloudflare AI Gateway.
- Potřebujete jemná MCP oprávnění v API managementu: srovnejte Kong a Tyk na konkrétním scénáři.
Při pilotu netestujte jen jednoduchý ne-streamovaný prompt. Ověřte alespoň:
- přidanou latenci a time to first token u streamované odpovědi;
- chování při timeoutu, výpadku a dosažení rate limitu poskytovatele;
- zda retry nebo fallback nevytváří duplicitní požadavky a náklady;
- kompatibilitu
tool_calls, structured output a chybových formátů mezi fallback modely; - přesnost měření tokenů, nákladů a identity volající aplikace;
- propagaci trace contextu a omezení přístupu ke konkrétnímu MCP nástroji.
Marketingový seznam funkcí neukáže, jak snadno se bude řešení provozovat ve vašem prostředí. Rozhodující je test na reálném request flow vašeho agenta.
Časté chyby při nasazení gateway
- Jeden univerzální klíč pro všechny agenty. Každá aplikace a tým potřebují vlastní identitu, limity a oprávnění.
- Logování citlivých promptů bez pravidel. Observabilita nesmí vytvořit nový sklad osobních údajů a tajemství.
- Fallback bez testu kvality. Jiný model může vrátit jiný formát nebo hůře volat nástroje, i když je API kompatibilní.
- Předpoklad, že „OpenAI kompatibilní“ znamená zaměnitelný. Zvlášť otestujte streamování, tool calls, structured output a mapování chyb.
- Automatický retry každého požadavku. Po timeoutu nemusíte vědět, zda upstream požadavek přijal. U MCP a A2A zápisů může opakování navíc zdvojit vedlejší efekt.
- Příliš mnoho nástrojů pro každého agenta. Nabízejte jen nejmenší potřebnou sadu; zlepšíte bezpečnost i výběr nástroje modelem.
- Záměna gateway za bezpečnostní kouzlo. Prompt injection se řeší také omezenými oprávněními, validací argumentů a potvrzením nevratných akcí.
- Závislost na proprietární funkci bez únikové cesty. Ověřte export konfigurace, podporované standardy a možnost změnit dodavatele.
Kdy tedy Kong dává smysl?
Kong AI Gateway je silná volba pro organizace, které mají více týmů, modelů a interních API a potřebují nad agentním provozem jednotnou governance. Jeho největší výhodou není jedna „AI funkce“, ale spojení modelového, MCP a A2A provozu s vyzrálými principy API managementu.
Pro malý prototyp může být Kong zbytečně robustní. Tam často stačí přímé API nebo LiteLLM. Jakmile ale agent získá přístup k firemním systémům, používá více poskytovatelů a jeho výpadek či chyba mají obchodní dopad, centrální gateway přestává být luxusem.
Chcete AI agenty nejen poskládat, ale také bezpečně provozovat?
V kurzu Programátor AI Agentů si prakticky projdete práci s modely, nástroji, MCP i bezpečností agentních aplikací. Pokud vás zajímá využití AI přímo ve vývojářském workflow, podívejte se také na kurz Vibe coding a AI ve vývoji.
Zdroje a další čtení
