Jak AI agenti skutečně implementují dovednosti: Kompletní srovnání napříč platformami

Úvod

Každý framework pro AI agenty čelí stejné základní otázce: jak zajistit, aby byl LLM dobrý v něčem konkrétním? Samotný model má široké obecné znalosti, ale když potřebujete, aby provedl revizi kódu, nasadil infrastrukturu nebo se pohyboval v Minecraftu — potřebuje specializované instrukce, přístup k nástrojům a doménový kontext.

Toto je problém vkládání dovedností. A každý významný framework ho řeší jinak.

Některé platformy nahrají vše do systémového promptu předem. Jiné používají líné načítání a odhalují schopnosti teprve tehdy, když je agent potřebuje. Několik dalších využívá vektorové databáze k vyhledání relevantních dovedností na základě sémantické podobnosti. Rozdíly nejsou akademické — přímo ovlivňují náklady na tokeny, spolehlivost agenta a počet dovedností, se kterými může agent realisticky pracovat.

Analyzovali jsme 11 hlavních platforem pro AI agenty, abychom přesně pochopili, kam se dovednosti v promptu umísťují, kdy se načítají, kolik stojí tokenů a jak přežijí zaplnění kontextového okna. Toto není povrchní srovnání funkcí. Prozkoumali jsme zdrojový kód, dokumentaci a architektonické diagramy, abychom zmapovali přesné mechanismy vkládání u každé platformy.

Hlavní srovnávací tabulka

Zde je kompletní přehled, než se ponoříme do detailů.

Mechanismy vkládání: Kde, kdy a jak

Persistence, náklady na tokeny a chování „vždy zapnuto"

Připraveni rozšířit své podnikání?

Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.

Požádat o demo Přihlásit se

Co „vkládání dovedností" skutečně znamená

Než se pustíme do srovnání, definujme problémový prostor. Kontextové okno AI agenta — celkový text, který LLM vidí při každém volání — má pevnou velikost. Každý token instrukce, historie konverzace, definice nástroje a načtených dat soutěží o místo v tomto okně.

„Dovednost" v kontextu agenta je jakýkoli strukturovaný balík odborných znalostí, který mění chování agenta. Může to být:

• Instrukce říkající agentovi, jak přistupovat ke specifické doméně (pokyny pro revizi kódu, kontrolní seznamy nasazení)
• Definice nástrojů poskytující agentovi volatelné funkce (API integrace, operace se soubory)
• Few-shot příklady ukazující agentovi, jak vypadá kvalitní výstup
• Vyhledané znalosti z vektorových databází nebo externích dokumentů

Mechanismus vkládání — kde a kdy tento obsah vstupuje do kontextu — určuje tři klíčové vlastnosti:

1. Efektivita tokenů: Kolik tokenů dovednost spotřebuje a platí se tato cena i tehdy, když dovednost není potřeba?
2. Spolehlivost: Bude agent dovednost konzistentně používat, když je relevantní, nebo může signál přehlédnout?
3. Škálovatelnost: Kolik dovedností může agent využívat, než přehlcení kontextu sníží výkon?

Každý framework dělá v těchto třech dimenzích jiné kompromisy. Pojďme se podívat na každý z nich.

Spektrum vkládání: Od „vždy zapnuto" po „na vyžádání"

Napříč všemi 11 platformami se přístupy k vkládání dovedností pohybují na spektru od „vše načteno předem" po „nic se nenačte, dokud to není explicitně potřeba."

Na jednom konci platformy jako CrewAI, SuperAGI a CAMEL-AI vkládají plný obsah každé aktivované dovednosti do každého volání LLM. Agent má vždy k dispozici svou kompletní odbornost. Jednoduché, spolehlivé, ale nákladné na tokeny.

Na druhém konci Claude Code, LangChain Deep Agents a OpenAI Responses API používají progresivní odhalování — agent vidí na začátku pouze názvy dovedností a krátké popisy a plný obsah se načítá na vyžádání. Efektivní, škálovatelné, ale vyžaduje to, aby agent rozpoznal, kdy dovednost potřebuje.

Uprostřed AutoGen Teachability a Voyager používají sémantické vyhledávání k vložení pouze nejrelevantnějších dovedností na každý tah, čímž vytvářejí dynamický, kontextově citlivý vzor vkládání.

A pak jsou tu unikátní přístupy: DSPy kompiluje optimalizované few-shot příklady offline a natrvalo je zabudovává do promptů modulů. MetaGPT kóduje dovednosti jako šablony akcí, které se aktivují pouze tehdy, když konkrétní role přejde ke konkrétní akci.

Pojďme se podrobně podívat na každý z nich.

Přihlaste se k odběru newsletteru

Získejte nejnovější tipy, trendy a nabídky zdarma.

E-mailová adresa

Přihlásit se

Claude Code: Třívrstvé progresivní odhalování

Claude Code implementuje jednu z nejsofistikovanějších architektur vkládání dovedností, využívající třívrstvý systém progresivního odhalování, který vyvažuje povědomí s efektivitou tokenů.

Vrstva 1: Vždy v kontextu

Při startu relace se název a popis každé dostupné dovednosti vloží do zprávy system-reminder — bloku metadat, který model vždy vidí. To stojí přibližně 250 znaků na dovednost a spotřebovává asi 1 % rozpočtu kontextového okna pro všechny popisy dovedností dohromady (přibližně 8K znaků jako záložní rozpočet, přepsatelný přes proměnnou prostředí SLASH_COMMAND_TOOL_CHAR_BUDGET).

Obdobně se odložené nástroje — nástroje, jejichž plná JSON schémata ještě nebyla načtena — zobrazují jako seznam pouze názvů v blocích system-reminder. Od verze Claude Code v2.1.69 jsou dokonce vestavěné systémové nástroje jako Bash, Read, Edit, Write, Glob a Grep odloženy za ToolSearch, čímž se kontext systémových nástrojů snižuje z přibližně 14–16K tokenů na zhruba 968 tokenů.

Agent vidí dostatek informací, aby věděl, co je k dispozici, aniž by platil náklady na tokeny za plné definice.

Vrstva 2: Při aktivaci

Když uživatel zadá příkaz lomítkem (např. /commit) nebo model automaticky přiřadí dovednost na základě jejího popisu, plné tělo SKILL.md se načte jako zpráva v konverzaci přes nástroj Skill. Toto tělo obsahuje kompletní instrukce — někdy tisíce tokenů podrobného vedení.

Klíčový detail: Nejprve proběhne preprocessing shellu (jakékoli direktivy !command v souboru dovednosti se spustí a jejich výstup nahradí direktivu) a po načtení zůstává tělo dovednosti v konverzaci po zbytek relace.

Vrstva 3: Na vyžádání

Další zdroje — referenční dokumenty, skripty, soubory s aktivy — se načtou pouze tehdy, když se model explicitně rozhodne použít nástroj Read k jejich přístupu. Nikdy se nenačítají automaticky.

Chování při kompakci kontextu

Když se konverzace blíží limitu kontextu a spustí se kompakce, Claude Code znovu připojí naposledy vyvolané dovednosti s rozpočtem 5K tokenů na dovednost a kombinovaným maximem 25K. Naposledy vyvolané dovednosti mají prioritu. Starší dovednosti mohou být zcela vypuštěny.

Tato třívrstvá architektura znamená, že agent s 20+ dostupnými dovednostmi platí minimální počáteční náklady, ale může přistoupit k plné odbornosti kterékoli z nich v rámci jednoho tahu.

CrewAI: Plné vkládání do každého promptu úkolu

CrewAI volí opačný přístup oproti progresivnímu odhalování. Když je dovednost aktivována pro agenta, její plný obsah se vkládá do každého promptu úkolu, který agent vykonává.

Jak to funguje

Dovednosti v CrewAI jsou samostatné adresáře, každý se souborem SKILL.md obsahujícím YAML frontmatter (název, popis, licence, kompatibilita, povolené nástroje) a markdownové tělo. Systém dovedností rozlišuje mezi dovednostmi a nástroji: dovednosti vkládají instrukce a kontext, které formují způsob myšlení agenta, zatímco nástroje poskytují volatelné funkce pro akce.

Během inicializace agenta Agent.set_skills() volá discover_skills() k prohledání adresářů dovedností na úrovni metadat, poté activate_skill() k načtení plných těl dovedností. Při spuštění úkolu _finalize_task_prompt() volá format_skill_context() pro každou aktivovanou dovednost a připojí veškerý formátovaný obsah dovedností k promptu úkolu.

LLM obdrží: [systémová zpráva] + [prompt úkolu + VŠECHNA těla dovedností]

Dopady na tokeny

CrewAI stanovuje měkké varování při 50 000 znacích na dovednost, ale žádný pevný limit. Dokumentace doporučuje udržovat dovednosti zaměřené a stručné, protože velké injekce do promptu oslabují pozornost modelu — reálný problém vzhledem k výzkumu degradace kontextu.

Kompromis je přímočarý: agent má vždy k dispozici plnou odbornost (vysoká spolehlivost), ale náklady na tokeny rostou lineárně s počtem dovedností na úkol (nízká efektivita). Pro agenty s 1–2 zaměřenými dovednostmi to funguje dobře. Pro agenty vyžadující širokou sadu schopností se to rychle prodraží.

Žádná persistence mezi úkoly

Každý úkol dostane čerstvé vložení. Nedochází k akumulaci obsahu dovedností mezi úkoly — což je ve skutečnosti výhoda, ne chyba. Znamená to, že každý úkol začíná s čistým kontextem a vyhýbá se problémům se zastaráváním, které může persistence založená na relacích způsobit.

LangChain Deep Agents: Načítání řízené agentem přes SkillsMiddleware

LangChain Deep Agents implementuje sofistikovaný systém dovedností založený na middleware, kde agent sám rozhoduje, kdy načíst plný obsah dovednosti — skutečný model progresivního odhalování, kde aktivaci řídí agent.

Tři úrovně

Úroveň 1 (Index): SkillsMiddleware parsuje všechny SKILL.md frontmatter při startu a vkládá lehký index do systémového promptu. Tento index obsahuje pouze názvy a popisy a stojí přibližně 278 tokenů na dovednost oproti 3 302 tokenům za plný obsah.

Úroveň 2 (Plný obsah): Když agent určí, že je dovednost relevantní, zavolá read_file() na cestu k SKILL.md dovednosti. Toto je běžné volání nástroje — framework tělo nevkládá; agent se vědomě rozhodne ho načíst. Plný obsah vstoupí do historie konverzace jako výsledek nástroje.

Úroveň 3 (Hluboký ponor): Podpůrné materiály, referenční dokumenty a skripty jsou přístupné pouze tehdy, když je agent explicitně přečte.

Efektivita tokenů v praxi

S 12 dovednostmi progresivní odhalování snižuje kontext z přibližně 30 000 tokenů (vše načteno) na zhruba 600 tokenů (pouze index), s rozšířením na 2 000–5 000 když se načtou relevantní dovednosti pro konkrétní úkol. To je potenciální snížení spotřeby tokenů souvisejících s dovednostmi o 83–98 %.

Více zdrojů dovedností lze vrstvit a při kolizi názvů vyhrává poslední zdroj. Soubory nad 10 MB jsou automaticky přeskakovány.

Klíčový rozdíl oproti Claude Code

Zatímco Claude Code používá vyhrazený nástroj Skill ke spuštění načítání, Deep Agents využívá stávající nástroj agenta read_file. To znamená, že mechanismus načítání je transparentní — agent čte soubory dovedností stejným způsobem jako jakýkoli jiný soubor. Nevýhodou je, že neexistuje speciální chování při kompakci: obsah dovedností, který vstoupí do historie konverzace, podléhá standardnímu ořezávání zpráv LangChain bez prioritního zacházení.

OpenAI Responses API a Agents SDK: Odložené načítání spravované platformou

OpenAI implementuje vkládání dovedností prostřednictvím dvou odlišných, ale filozoficky sladěných mechanismů: typu nástroje tool_search v Responses API a ToolSearchTool v Agents SDK.

Responses API: tool_search

Typ nástroje tool_search (dostupný na GPT-5.4+) umožňuje vývojářům odložit rozsáhlé povrchy nástrojů do doby běhu. K dispozici jsou tři strategie odložení:

• Odložení jednotlivých funkcí: @function_tool(defer_loading=True) — model vidí název funkce a popis, ale schéma parametrů je odloženo. Šetří tokeny na úrovni parametrů.
• Odložení jmenného prostoru: tool_namespace(name=..., description=..., tools=[...]) — seskupuje funkce pod jeden jmenný prostor. Model vidí pouze název a popis jmenného prostoru, čímž výrazně šetří tokeny.
• Odložení MCP serveru: HostedMCPTool(tool_config={..., "defer_loading": True}) — odkládá celé povrchy nástrojů MCP serveru.

Když model určí, že potřebuje konkrétní nástroj, vydá volání tool_search. API vrátí 3–5 relevantních definic nástrojů, vložených na konec kontextového okna pro zachování cachování promptu.

Agents SDK: ToolSearchTool

Agents SDK poskytuje programový ekvivalent. Jmenné prostory nástrojů se zaregistrují, ale nenačtou:

crm_tools = tool_namespace(
    name="crm",
    description="CRM management tools",
    tools=[...]
)
agent = Agent(tools=[*crm_tools, ToolSearchTool()])

Za běhu agent vidí pouze názvy jmenných prostorů. Zavolá ToolSearchTool("crm") k objevení a načtení plných schémat, poté může volat jednotlivé nástroje v rámci daného jmenného prostoru.

Žádná persistence mezi požadavky

Každý API požadavek je nezávislý. Objevené nástroje se neuchovávají mezi voláními. Toto je nejbezstavovější přístup v našem srovnání — čistý, předvídatelný, ale vyžadující znovuobjevení při každém požadavku, pokud se nástroje změní.

AutoGen Teachability: Sémantické vyhledávání na každý tah

Schopnost AutoGen Teachability volí zásadně odlišný přístup od všech ostatních frameworků v tomto srovnání. Místo vkládání statického obsahu dovedností dynamicky vyhledává relevantní „poznámky" z vektorové databáze ChromaDB při každém jednotlivém tahu.

Smyčka vyhledávání na každý tah

Teachability registruje hook na process_last_received_message, který zachytí každou příchozí uživatelskou zprávu předtím, než ji agent zpracuje:

1. TextAnalyzerAgent extrahuje klíčové koncepty z příchozí zprávy
2. Tyto koncepty se použijí k dotazu na ChromaDB (ve výchozím nastavení pomocí Sentence Transformer embeddingů)
3. Vyhledá se top-K nejrelevantnějších poznámek (konfigurovatelné přes max_num_retrievals, výchozí hodnota 10)
4. Vyhledané poznámky se připojí k textu zprávy, než ji agent uvidí

Klíčové je, že upravená zpráva se nepropaguje do uložené historie konverzace — ukládá se pouze původní zpráva. Tím se zabrání hromadění obsahu poznámek napříč tahy.

Učící smyčka

Po odpovědi LLM druhý hook analyzuje odpověď na nové poznatky:

1. TextAnalyzerAgent identifikuje nové znalosti v odpovědi
2. Nové poznámky se extrahují jako páry klíč-hodnota (vstupní text → výstupní text)
3. Tyto poznámky se uloží do ChromaDB, dostupné pro budoucí tahy a relace

Tím vzniká skutečná učící smyčka, kde agent postupem času akumuluje odborné znalosti.

Persistence mezi relacemi

AutoGen Teachability je jednou z pouhých tří platforem v našem srovnání (spolu s Voyager a DSPy), které uchovávají dovednosti mezi relacemi. Databáze ChromaDB žije na disku, což znamená, že agent se může v pondělí naučit z interakcí a tyto znalosti aplikovat v pátek.

Parametr recall_threshold (výchozí hodnota 1.5) řídí, jak podobná musí být zpráva uložené poznámce pro vyhledání, a reset_db může vymazat celou paměť, když je to potřeba.

Efektivita tokenů

Protože se na každý tah vkládají pouze relevantní poznámky (typicky 3–5), náklady na tokeny jsou přirozeně omezené bez ohledu na to, jak velká je databáze poznámek. Agent s 10 000 uloženými poznámkami stále platí pouze za hrstku nejrelevantnějších pro aktuální tah.

Semantic Kernel: Schémata pluginů jako vždy přítomné definice nástrojů

Microsoftí Semantic Kernel volí přímočarý přístup: pluginy jsou kolekce objektů KernelFunction zaregistrovaných v Kernelu a jejich schémata jsou vystavena LLM jako definice nástrojů pro volání funkcí.

Dvě cesty vkládání

Volání funkcí: Když je nastaveno ToolCallBehavior.AutoInvokeKernelFunctions, všechny zaregistrované funkce se odesílají LLM jako dostupné nástroje v každém API požadavku. LLM rozhodne, které zavolá; Semantic Kernel řeší vyvolání a směrování výsledků.

Šablony promptů: Syntaxe šablon Semantic Kernel ({{plugin.function}}, Handlebars nebo Liquid) umožňuje volat funkce inline během vykreslování promptu. Výsledky se vkládají přímo do textu promptu, než dorazí k LLM — forma dychtivého vyhodnocení namísto líného volání nástrojů.

Žádné progresivní odhalování

Schéma každého zaregistrovaného pluginu je zahrnuto v každém API volání. Neexistuje vestavěné odložené načítání, seskupování jmenných prostorů ani aktivace na vyžádání. Dokumentace explicitně doporučuje importovat pouze pluginy potřebné pro konkrétní scénář, aby se snížila spotřeba tokenů a chybná volání.

To dělá Semantic Kernel jednou z nejpředvídatelnějších platforem — vždy přesně víte, k čemu má agent přístup — ale omezuje to škálovatelnost. Agent s 50 zaregistrovanými funkcemi platí plné náklady na schémata při každém jednotlivém volání.

Persistence

Registrace pluginů je per-instance-Kernelu a v paměti. Neexistuje vestavěný mechanismus pro persistence dovedností mezi relacemi.

MetaGPT: Šablony akcí v rámci SOP založených na rolích

MetaGPT kóduje dovednosti nikoli jako samostatné balíčky, ale jako šablony akcí vložené do standardních operačních postupů (SOP), které řídí chování rolí.

Architektura rolí a akcí

Každá Role v MetaGPT má prefix persony vkládaný do promptů a sadu tříd Action. Každá akce obsahuje LLM proxy vyvolávaný přes aask(), který používá šablony promptů v přirozeném jazyce ke strukturování volání LLM.

Když se spustí Role._act(), podporuje tři režimy reakce:

• "react": LLM dynamicky vybírá akce ve smyčkách přemýšlení-akce
• "by_order": Akce se vykonávají sekvenčně v předem určeném pořadí
• "plan_and_act": Agent nejprve plánuje, poté vykonává akce podle plánu

Úzké okno vkládání

V každém okamžiku je aktivní pouze šablona promptu aktuální akce. Agent nevidí šablony pro jiné akce — vidí pouze prefix své role plus kontext konkrétní akce. Toto je nejužší okno vkládání ze všech frameworků, které jsme zkoumali.

Funkce parsování kontextu v rámci tříd akcí extrahují relevantní informace ze vstupů, takže každá akce obdrží kurátorskou podmnožinu dostupného kontextu místo plné historie konverzace.

Persistence jednoho tahu

Šablona se vykresluje čerstvě pro každé spuštění akce. Nedochází k akumulaci ani persistence mezi relacemi. To udržuje každou akci zaměřenou, ale znamená to, že agent nemůže stavět na dříve načteném obsahu dovedností v rámci jednoho workflow.

Voyager: Vyhledávání dovedností na základě embeddingů pro celoživotní učení

Voyager, agent pro průzkum Minecraftu od NVIDIA a Caltech, implementuje jednu z nejelegantnějších architektur vkládání dovedností: rostoucí knihovnu ověřených programů vyhledávaných podle podobnosti embeddingů.

Knihovna dovedností

Když Voyager napíše kód, který projde samoverifikací (vygenerovaný Mineflayer JavaScript skutečně funguje ve hře), kód a jeho dokumentační řetězec se uloží do vektorové databáze. Embedding dokumentačního řetězce se stane klíčem pro vyhledávání.

Vyhledávání na úkol

Při každém novém úkolu navrženém automatickým kurikulem:

1. Popis úkolu a zpětná vazba prostředí se převedou na embedding
2. Kosinová podobnost se prohledá proti všem uloženým embeddingům dovedností
3. Vyhledá se top-5 nejrelevantnějších dovedností
4. Vyhledaný kód dovedností se zahrne do promptu akčního agenta jako few-shot příklady

Prompt vypadá takto:

You are a Minecraft bot. Here are some relevant skills you've learned:

// Skill: mineWoodLog
async function mineWoodLog(bot) { ... }

// Skill: craftPlanks
async function craftPlanks(bot) { ... }

Now write code to: build a wooden pickaxe

Vygenerovaný kód může volat vyhledané dovednosti jménem, což umožňuje kompoziční budování dovedností — složité chování konstruované z jednodušších, ověřených primitiv.

Celoživotní persistence

Knihovna dovedností je jádrovým mechanismem „celoživotního učení". Roste po celou dobu životnosti agenta a nové dovednosti staví na starých. Na rozdíl od většiny frameworků, kde dovednosti vytvářejí lidé, dovednosti Voyageru jsou generovány, ověřovány a ukládány samotným agentem.

Náklady na tokeny jsou přirozeně omezené: bez ohledu na to, zda knihovna obsahuje 50 nebo 5 000 dovedností, každý úkol platí pouze za 5 nejrelevantnějších vyhledaných výsledků.

DSPy: Zkompilované few-shot příklady jako zmrazené dovednosti

DSPy volí radikálně odlišný přístup od všech ostatních frameworků. Místo vkládání dovedností za běhu DSPy kompiluje optimální few-shot ukázky offline a natrvalo je zabudovává do promptů modulů.

Proces kompilace

Kompilaci řeší dva hlavní optimalizátory:

BootstrapFewShot: Používá učitelský modul ke generování tras přes program. Trasy, které projdou uživatelem definovanou metrikou, se uchovávají jako ukázky. Každý modul dspy.Predict v rámci programu získá svou vlastní kurátorskou sadu ukázek.

MIPROv2 (Multi-prompt Instruction Proposal Optimizer v2): Třífázový proces:

1. Bootstrap: Generování kandidátních sad ukázek
2. Navrhování: Generování kandidátních textů instrukcí, které berou v úvahu jak distribuci dat, tak ukázky
3. Hledání: Bayesovská optimalizace nad kombinovaným prostorem instrukcí × ukázek napříč všemi moduly

Parametry jako max_bootstrapped_demos (generované příklady) a max_labeled_demos (z trénovacích dat) řídí, kolik příkladů skončí v promptu každého modulu.

Fixní po kompilaci

Po zkompilování se ukázky uloží v atributu demos každého modulu Predict a formátují se do promptu při každém volání LLM. Za běhu se nemění — „dovednost" je zmrazená.

To znamená, že dovednosti DSPy jsou nejpředvídatelnější v našem srovnání: náklady na tokeny jsou známy po kompilaci, neexistuje variance mezi tahy a agent vždy vidí stejné ukázky. Nevýhodou je nepružnost — pro změnu dovedností musíte překompilovat.

Persistence

Zkompilované programy se serializují do JSON včetně všech ukázek. Jsou plně persistentní a načitatelné mezi relacemi, což dělá DSPy jedním z nejodolnějších mechanismů ukládání dovedností.

SuperAGI: Registrace na bázi toolkitů předem

SuperAGI používá tradiční vzor toolkitů, kde se všechny nástroje registrují při inicializaci agenta.

Každý toolkit rozšiřuje BaseToolkit s:

• atributy name a description
• metodou get_tools() vracející seznam instancí BaseTool
• get_env_keys() pro požadované proměnné prostředí

Toolkity se instalují z GitHub repozitářů přes správce nástrojů SuperAGI. Při inicializaci agenta BaseToolkit.get_tools() vrátí všechny nástroje a jejich kompletní schémata jsou vystavena LLM jako definice pro volání funkcí.

Neexistuje odložené načítání, žádné progresivní odhalování a žádné filtrování na tah. Schéma každého zaregistrovaného nástroje je přítomno v každém volání. Toto je nejjednodušší model vkládání a funguje dobře pro agenty se zaměřenými, malými sadami nástrojů, ale neškáluje se na agenty potřebující desítky schopností.

CAMEL-AI: Registrace nástrojů v ChatAgent

CAMEL-AI následuje podobný vzor registrace předem. Nástroje z různých toolkitů (např. MathToolkit, SearchToolkit) se předávají jako seznam do ChatAgent(tools=[...]) při inicializaci.

Framework zdůrazňuje, že vlastní funkce potřebují jasné názvy argumentů a komplexní docstringy, aby model mohl pochopit použití — schéma nástroje je jediný obsah „dovednosti", který model vidí. Neexistuje samostatný mechanismus vkládání instrukcí.

Nedávné přírůstky zahrnují podporu MCP (Model Context Protocol) přes MCPToolkit, umožňující ChatAgent připojit se k MCP serverům a registrovat externí nástroje. To rozšiřuje dostupný povrch nástrojů, ale nemění model vkládání — všechny objevené MCP nástroje jsou stále registrovány předem.

Srovnání napříč platformami

Kdy se dovednosti vkládají

Modely persistence

Přežití kompakce kontextu

Vzor progresivního odhalování

Nejvýznamnějším architektonickým trendem napříč těmito platformami je přijetí progresivního odhalování — konceptu převzatého z UI designu, kde se informace odhalují postupně na základě potřeby.

Proč na progresivním odhalování záleží

Naivní přístup k vkládání dovedností — načtení všeho předem — vytváří dva problémy:

1. Plýtvání tokeny: Většina dovedností není relevantní pro většinu tahů. Načtení 20 plných těl dovedností, když jsou na tah potřeba pouze 1–2, plýtvá 90%+ tokenů souvisejících s dovednostmi.
2. Rozptýlení pozornosti: Výzkum degradace kontextu ukazuje, že LLM fungují hůře, když jejich kontext obsahuje velké množství irelevantních informací. Více dovedností v kontextu může ve skutečnosti snížit kvalitu aplikace dovedností.

Progresivní odhalování řeší oba problémy udržováním lehkého indexu dostupných dovedností při načítání plného obsahu pouze tehdy, když je potřeba.

Varianty implementace

Claude Code používá vyhrazený systém: metadata dovedností ve zprávách system-reminder, nástroj Skill pro aktivaci a ToolSearch pro odložená schémata nástrojů. Framework řídí vkládání automaticky s kompakcí založenou na prioritách.

LangChain Deep Agents používá stávající schopnost agenta číst soubory: SkillsMiddleware vloží index a agent načte plný obsah přes read_file(). Toto je transparentnější, ale nabízí méně optimalizací na úrovni frameworku.

OpenAI Responses API používá seskupování na bázi jmenných prostorů s vyhledáváním spravovaným platformou: jmenné prostory nástrojů poskytují popisy na vysoké úrovni a tool_search vrací relevantní schémata. Logiku vyhledávání řídí zcela platforma.

Úspora tokenů v praxi

Čísla jsou přesvědčivá. S 12 dovednostmi:

• Vkládání „vždy zapnuto" (styl CrewAI/SuperAGI): ~30 000 tokenů
• Pouze index progresivního odhalování: ~600 tokenů
• Index + 2 aktivované dovednosti: ~2 000–5 000 tokenů

To je snížení spotřeby tokenů souvisejících s dovednostmi o 83–98 % na tah. Během dlouhé relace se stovkami tahů se úspory dramaticky násobí.

Architektonické vzory a kompromisy

Při pohledu napříč všemi 11 platformami se vynořují čtyři odlišné architektonické vzory:

Vzor 1: Vkládání „vždy zapnuto"

Používají: CrewAI, SuperAGI, CAMEL-AI, Semantic Kernel

Jak to funguje: Plný obsah dovedností nebo schémata nástrojů jsou přítomny v každém volání LLM.

Výhody:

• Maximální spolehlivost — agent má vždy k dispozici plnou odbornost
• Nejjednodušší implementace — není potřeba logika aktivace
• Předvídatelné náklady na tokeny — stejné každý tah

Nevýhody:

• Náklady na tokeny rostou lineárně s počtem dovedností
• Rozptýlení pozornosti s mnoha dovednostmi
• Neškáluje se nad ~5–10 dovedností na agenta

Nejlepší pro: Zaměřené agenty s 1–3 klíčovými dovednostmi, které jsou vždy relevantní.

Vzor 2: Progresivní odhalování

Používají: Claude Code, LangChain Deep Agents, OpenAI Responses API/Agents SDK

Jak to funguje: Lehká metadata vždy přítomna; plný obsah načítán na vyžádání.

Výhody:

• Škáluje se na desítky nebo stovky dostupných dovedností
• Minimální náklady na tokeny, když dovednosti nejsou potřeba
• Zachovává cache promptu, když se plná schémata připojují na konec

Nevýhody:

• Agent může přehlédnout signál k aktivaci relevantní dovednosti
• Další latence z aktivačního kroku
• Složitější implementace frameworku

Nejlepší pro: Univerzální agenty, kteří potřebují přístup k mnoha schopnostem, ale na úkol používají jen několik.

Vzor 3: Sémantické vyhledávání

Používají: AutoGen Teachability, Voyager

Jak to funguje: Dotazy na vektorovou databázi vyhledají relevantní dovednosti/znalosti na základě sémantické podobnosti s aktuálním kontextem.

Výhody:

• Přirozeně omezené náklady na tokeny bez ohledu na velikost knihovny
• Relevance obsahu se zlepšuje s růstem knihovny
• Učení a akumulace mezi relacemi
• Není potřeba explicitní aktivace — relevance se počítá automaticky

Nevýhody:

• Kvalita vyhledávání závisí na kvalitě modelu embeddingů
• Riziko vyhledání zastaralých nebo jemně nesprávných informací
• Vyžaduje infrastrukturu vektorové databáze
• Méně předvídatelné — různé tahy načítají různý obsah

Nejlepší pro: Agenty, kteří se učí ze zkušeností a potřebují postupně akumulovat doménové znalosti.

Vzor 4: Zkompilované/statické vkládání

Používají: DSPy, MetaGPT

Jak to funguje: Dovednosti jsou zkompilovány do fixního obsahu promptu (DSPy) nebo aktivovány přes rigidní šablony akcí (MetaGPT).

Výhody:

• Nejpředvídatelnější chování — stejný obsah pokaždé
• Optimalizace může probíhat offline (kompilace DSPy)
• Žádná režie za běhu pro výběr dovedností
• Prokázaně efektivní pro dobře definované, opakovatelné úkoly

Nevýhody:

• Nepružné — změna dovedností vyžaduje rekompilaci (DSPy) nebo změny kódu (MetaGPT)
• Nedokáže se přizpůsobit novým situacím mimo zkompilované příklady
• Samotný proces kompilace DSPy vyžaduje mnoho volání LLM

Nejlepší pro: Produkční pipeline s dobře definovanými úkoly, kde spolehlivost převáží nad flexibilitou.

Praktické důsledky pro tvůrce agentů

Výběr správného vzoru

Správná architektura vkládání dovedností závisí na profilu vašeho agenta:

Pokud má váš agent úzkou, dobře definovanou roli (např. bot pro revizi kódu, agent zákaznické podpory pro jeden produkt), vkládání „vždy zapnuto" (vzor CrewAI/SuperAGI) je nejjednodušší a nejspolehlivější. Náklady na tokeny pro 2–3 vždy přítomné dovednosti jsou zvládnutelné a vyhnete se složitosti logiky aktivace.

Pokud váš agent potřebuje široké schopnosti, ale na interakci používá jen několik (např. vývojářský asistent, univerzální automatizační agent), progresivní odhalování (vzor Claude Code/Deep Agents) je jasný vítěz. Úspora 83–98 % tokenů ve velkém měřítku je příliš významná na to, aby se ignorovala.

Pokud se váš agent potřebuje učit a zlepšovat z interakcí (např. osobní asistent, doménový expert akumulující znalosti), sémantické vyhledávání (vzor AutoGen Teachability) poskytuje učící smyčku, kterou ostatní vzory postrádají. Jen se ujistěte, že máte kontrolu kvality nad tím, co vstupuje do znalostní báze.

Pokud váš agent provozuje dobře definované pipeline (např. zpracování dat, generování reportů, standardizované workflow), zkompilované vkládání (vzor DSPy) vám dá nejpředvídatelnější, optimalizované chování.

Hybridní přístup

Pro produkční týmy agentů, kde agenti potřebují fungovat hned po vybalení, doporučujeme hybridní přístup:

Klíčové dovednosti (1–2 na agenta, definující jejich primární doménovou odbornost): vždy vloženy do systémového promptu, ve stylu CrewAI. Jsou to nezbytné schopnosti, které agent potřebuje při každém tahu.

Rozšířené dovednosti (další schopnosti, které agent může potřebovat): pouze metadata v systémovém promptu, načítané přes mechanismus vyhledávání/načtení, když jsou potřeba, ve stylu Deep Agents. Rozšiřují sadu schopností agenta bez placení nákladů na tokeny, když nejsou relevantní.

Naučené znalosti (akumulovaná doménová odbornost): uloženy ve vektorové databázi a sémanticky vyhledávány na každý tah, ve stylu AutoGen. To umožňuje agentovi se zlepšovat v čase bez ručního vytváření dovedností.

Tato vrstvená architektura se přirozeně mapuje na to, jak se buduje systémový prompt: datum → persona → systémové instrukce → klíčové dovednosti → index dovedností → kontext role/týmu. Klíčové dovednosti a index přidávají předvídatelné, zvládnutelné náklady na tokeny, zatímco plná těla dovedností se objeví pouze tehdy, když jsou potřeba.

Osvědčené postupy pro rozpočet tokenů napříč frameworky

Bez ohledu na to, který vzor vkládání používáte, tyto strategie správy tokenů platí univerzálně:

Řazení přátelské ke cache

Neměnný kontext (systémové instrukce, schémata nástrojů) umisťujte na začátek promptu. U poskytovatelů podporujících cachování promptu stojí cachované tokeny o 75 % méně. Claude Code i OpenAI vkládají objevená schémata nástrojů na konec kontextu specificky pro zachování cache hitů na statickém prefixu.

Přesun do externích zdrojů

Shrnujte odpovědi nástrojů místo uchovávání plných výsledků v kontextu. Kompletní data ukládejte do externích referencí, které může agent číst na vyžádání. Toto je obzvlášť důležité pro agenty, kteří provádějí mnoho volání nástrojů za relaci.

Redukce

Kompaktujte historii konverzace prostřednictvím sumarizace. Z dlouhých výměn extrahujte klíčová fakta do zhuštěných reprezentací. Každý framework s persistencí založenou na relacích těží z agresivní správy historie.

Vyhledávání namísto předběžného načítání

Dynamicky načítejte relevantní informace za běhu místo načítání všeho předem. To platí pro dovednosti, znalostní báze a dokonce i historii konverzace. Studie ukazují, že to může snížit velikost promptů až o 70 %.

Izolace

Používejte subagenty pro specifické úkoly, aby kontext každého agenta zůstal zaměřený. Místo toho, abyste jednomu agentovi dali 20 dovedností, vytvořte tým 5 agentů se 4 dovednostmi každý. Každý agent si udržuje štíhlé kontextové okno a tým kolektivně pokrývá celou sadu schopností.

Závěr

Způsob, jakým frameworky pro AI agenty vkládají dovednosti do kontextu, je jedním z nejzásadnějších architektonických rozhodnutí v návrhu agentů — přesto se o něm na této úrovni detailu diskutuje jen zřídka.

Oblast jasně konverguje k progresivnímu odhalování jako preferovanému vzoru pro univerzální agenty, přičemž Claude Code, LangChain Deep Agents a OpenAI nezávisle dospěli k podobným tříúrovňovým architekturám. Mezitím specializované vzory jako sémantické vyhledávání (AutoGen, Voyager) a zkompilované vkládání (DSPy) slouží důležitým nikám, které samotné progresivní odhalování neřeší.

Pro praktiky budující systémy agentů dnes je klíčovým poznatkem, že vkládání dovedností není problém jednoho řešení pro všechny. Správný přístup závisí na roli vašeho agenta, počtu dovedností, které potřebuje, zda se potřebuje učit v čase, a vaší toleranci ke kompromisům mezi náklady na tokeny a spolehlivostí.

Nejrobustnější produkční systémy budou pravděpodobně kombinovat více vzorů — „vždy zapnuto" pro klíčové schopnosti, progresivní odhalování pro rozšířené dovednosti a sémantické vyhledávání pro akumulované znalosti — a vytvářet agenty, kteří jsou efektivní i odborní.