Lilith Lilith.
⌕
CS EN PL
Začít

← Průvodci · Průvodce

Koog a AI agenti v Kotlinu — co to je a k čemu to je

Koog je framework od JetBrains pro stavbu AI agentů v Kotlinu a Javě. Neřeší magii promptů, ale praktickou architekturu: strategie, nástroje, paměť, tracing, dlouhý kontext a provoz v JVM aplikacích.

#agents #mcp #tool-use #infrastructure #open-source #workflow #kotlin

Krátká verze: Koog je pokus JetBrains udělat pro AI agenty v Kotlin/JVM světě to, co dobrý webový framework dělá pro web: dát opakovatelnou strukturu místo hromady slepených requestů na model. Agent pak není „prompt s nožičkama“, ale řízený systém: strategie, nástroje, stav, paměť, logy a testy.

Co je AI agent

AI agent je systém, ve kterém jazykový model nejen odpovídá, ale rozhoduje další kroky. Může zavolat nástroj, přečíst data, upravit soubor, zeptat se uživatele, zkontrolovat výsledek a pokračovat, dokud není úloha hotová.

Rozdíl oproti obyčejnému chatbotu je jednoduchý:

  • chatbot říká, co by se mělo udělat,
  • agent má nástroje a může něco skutečně udělat,
  • dobrý agent má hranice, logiku, stav a kontrolu,
  • špatný agent je LLM vypuštěný do aplikace jako démon v obchodě s porcelánem.

Příklad: uživatel řekne „připrav mi finanční report“. Chatbot napíše obecné rady. Agent může načíst data, zavolat interní API, vyrobit návrh reportu, poslat ho do compliance kontroly, opravit chyby a uložit výsledek.

Co je Koog

Koog je open-source framework od JetBrains pro stavbu AI agentů v Kotlinu a Javě. Je určený hlavně pro JVM/Kotlin týmy, které chtějí agentní systémy integrovat do existujících backendů, Android aplikací, multiplatformních projektů nebo interních nástrojů.

Koog řeší věci, které se v agentních prototypech často lepí ručně:

  • napojení na různé LLM providery,
  • definici nástrojů, které může agent používat,
  • strategie/workflow jako graf kroků,
  • dlouhou historii a kompresi kontextu,
  • persistenci stavu agenta,
  • memory a knowledge retrieval,
  • streaming a paralelní volání nástrojů,
  • tracing a observabilitu,
  • MCP a další integrační protokoly.

Od verze Koog 1.0 JetBrains slibuje stabilnější core API a jasnější oddělení stabilních a beta modulů. To je nudné, ale přesně ten druh nudy, který chceš v produkci.

K čemu je to dobré

Koog dává smysl tam, kde máš aplikaci v Kotlinu/JVM a nechceš agentní vrstvu odnést do úplně jiného technologického světa. Typické případy:

1. Interní firemní agenti

Agent, který pracuje s interními systémy: hledá v dokumentaci, připravuje reporty, kontroluje ticket, vyplňuje rutinní workflow nebo pomáhá supportu. Koog mu dá nástroje a strategii, ale zůstane uvnitř JVM stacku.

2. Produktové AI funkce

Například AI asistent v IDE, bankovní aplikaci, CRM nebo administraci. Důležité není jen „odpovědět hezky“, ale bezpečně volat interní funkce, držet stav, logovat kroky a nedat modelu víc oprávnění, než potřebuje.

3. Multiplatformní Kotlin aplikace

Koog cílí i na Kotlin Multiplatform: JVM, JS, WasmJS, Android a iOS. To je zajímavé pro týmy, které chtějí část agentní logiky sdílet napříč backendem a klienty.

4. Agentní workflow místo jedné velké výzvy

Největší hodnota není v tom, že zavoláš model. Největší hodnota je v tom, že úlohu rozdělíš: nejdřív sběr dat, potom návrh, potom kontrola, potom oprava, potom finální výstup. Každý krok může mít jiné nástroje, jiný model a jiná pravidla.

Úzký koridor pro model

Nejdůležitější myšlenka z přednášky Vadima Briliantova je podle mě tahle: LLM nemá dostat celý vesmír nástrojů. Má dostat úzký koridor.

Když modelu dáš všechny funkce aplikace a řekneš „vyřeš problém“, bude improvizovat. Někdy se trefí, někdy se zacyklí, někdy zavolá zbytečné nástroje, někdy utratí hromadu tokenů. To je pekelně drahá loterie.

Lepší design:

  1. Urči fáze úlohy.
  2. V každé fázi povol jen relevantní nástroje.
  3. Dej modelu jasný cíl pro danou fázi.
  4. Po důležitých krocích proveď kontrolu.
  5. Ulož trace, aby šlo zjistit, proč agent něco udělal.

Koog tyhle „koridory“ modeluje jako strategie a grafy. To je zdravější než jeden obří prompt, který se tváří jako architektura.

Jak vypadá agent v Koog mentalitě

Zjednodušeně:

  1. Model — OpenAI, Anthropic, Google, Ollama, OpenRouter nebo jiný provider.
  2. Nástroje — funkce aplikace, API, databáze, soubory, MCP tools.
  3. Strategie — pravidla, v jakém pořadí a za jakých podmínek se kroky dějí.
  4. Stav a historie — co se už stalo, co je důležité, co lze zahodit.
  5. Observabilita — logy/traces, aby agent nebyl černá skříňka.
  6. Evaluace/testy — ověření, že nová verze nerozbila staré workflow.

Tohle je podstatné: agent není model. Model je jen motor. Agent je celý stroj kolem něj.

Praktický příklad: report

Představ si agenta, který má připravit kvartální report.

Špatně:

„Tady máš přístup do databáze, Slacku, dokumentů a tabulek. Udělej report.“

Lépe:

  1. Sběr dat — agent smí jen číst data a vytvořit seznam faktů.
  2. Analýza — agent smí pracovat jen s nasbíranými fakty a najít trendy.
  3. Návrh reportu — agent smí psát dokument, ale nesmí tahat další data.
  4. Kontrola — jiný krok ověří čísla, compliance a chybějící zdroje.
  5. Oprava — pokud kontrola selže, agent se vrátí do konkrétní fáze.
  6. Publikace — až po splnění podmínek se výstup uloží nebo pošle dál.

Tohle je přesně rozdíl mezi „AI magie“ a inženýrstvím.

Co Koog není

Koog není náhrada za dobrý návrh produktu. Neudělá z rozbitého workflow dobrého agenta. Nevyřeší bezpečnost jen tím, že existuje. A neznamená, že každý use-case má být agent.

Koog také není důkaz, že Kotlin je najednou nejlepší jazyk pro veškeré AI. Python má pořád obrovský ML ekosystém. Koog je spíš odpověď na otázku: co když už naše aplikace, týmy a provoz žijí v Kotlin/JVM světě a chceme agentní vrstvu stavět tam?

Nejčastější pasti

  • Příliš mnoho nástrojů: Model dostane plný přístup a začne bloudit.
  • Žádná trace: Když agent selže, nikdo neví proč.
  • Žádné evaly: Každá změna promptu je náboženský experiment.
  • Dlouhý kontext bez komprese: Model platí za historii, kterou už neumí dobře použít.
  • Agent místo workflow: Některé věci mají být normální deterministický kód, ne LLM smyčka.
  • Bezpečnost jako dodatek: Tool permissions, sandboxing a schvalování musí být v návrhu od začátku.

Kdy bych po Koog sáhla

Sáhla bych po něm, pokud:

  • tým píše Kotlin/Javu a nechce další Python runtime,
  • agent potřebuje volat existující JVM aplikační logiku,
  • úloha má víc kroků a potřebuje stav,
  • záleží na tracingu, testování a provozu,
  • chceš postupně přecházet od asistenta k autonomnějším workflow.

Nesáhla bych po něm jako první volbě pro čistý ML research prototyp, kde stejně žiješ v Pythonu, notebookách a modelech. Tam by to byla zbytečná okružní jízda peklem.

Co si pamatovat

Koog je zajímavý ne proto, že „Kotlin má taky AI framework“. Zajímavý je tím, že bere agenty jako software engineering problém: strategie, nástroje, stav, observabilita, paměť, testování a produkční kompatibilita.

Jestli si z toho máš odnést jednu věc: dobrý agent není svobodný génius. Je to model vedený úzkým koridorem, s dobrými nástroji a stopou, kterou můžeš později vyšetřit.

Zdroje