Function Calling vs. Tool Use: Vysvetlenie pojmov a implementácie

Function Calling a Tool Use označujú v jadre tú istú schopnosť: veľký jazykový model na určitom mieste nevydá súvislý text, ale štruktúrované volanie externe definovanej funkcie, ktoré zodpovedá schéme, vrátane príslušných argumentov. OpenAI zaviedla pojem „Function Calling“, Anthropic hovorí o „Tool Use“. Technicky sú oba založené na JSON Schema a takmer zhodné. Rozdiely sú v pomenovaní polí schémy a v niektorých mechanikách API, nie v základnom princípe.

Tento článok patrí do klastra okolo piliera „Základy LLM pre AI agentov“ a rozvíja to, čo načrtáva sesterský článok o základoch tool callingu. Všetky technické údaje zodpovedajú stavu v roku 2026.

• Synonymum s nuansou: „Tool Use“ je o niečo širší pojem, pretože nástrojom môže byť pri Anthropic aj služba na strane servera (webové vyhľadávanie, vykonávanie kódu) alebo MCP server. „Function Calling“ v užšom zmysle označuje volanie čistej funkcie.
• Model nič nevykonáva: dodá iba volanie. Tvoj kód validuje argumenty, vykoná funkciu a vráti výsledok. Až potom LLM sformuluje odpoveď.
• Najviditeľnejší rozdiel v implementácii: OpenAI používa v schéme nástroja pole parameters, Anthropic input_schema. Oba pritom vychádzajú z JSON Schema.

Ako LLM vytvára štruktúrované volania nástrojov

Mechanizmus je v oboch ekosystémoch postavený rovnako. Okrem samotnej požiadavky používateľa odovzdáš modelu zoznam definícií nástrojov. Každá definícia obsahuje názov, popis (kedy nástroj použiť a kedy nie) a vstupnú schému s typovanými, čiastočne povinnými parametrami.

API spoločnosti Anthropic zostaví z definícií nástrojov, konfigurácie nástrojov a tvojho system promptu vlastný prompt pre Tool Use. Podľa dokumentácie Anthropic sa riadi približne týmto vzorom:

```
In this environment you have access to a set of tools you can use to answer the user's question.
{{ FORMATTING INSTRUCTIONS }}
String and scalar parameters should be specified as is, while lists and objects should use JSON format.
Here are the functions available in JSONSchema format:
{{ TOOL DEFINITIONS IN JSON SCHEMA }}
{{ USER SYSTEM PROMPT }}
{{ TOOL CONFIGURATION }}
```

Z toho vyplýva často prehliadaný ekonomický dôsledok: každý nástroj ako schéma trvalo spotrebúva tokeny (typicky rádovo okolo 100–300 na nástroj, podľa zložitosti schémy), pretože model číta definície v každom inferenčnom kroku. Katalóg s desiatimi nástrojmi tak vychádza zhruba na 1 000–3 000 tokenov na volanie. Pri 100 000 volaniach mesačne je to 100–300 miliónov tokenov čistej záťaže schémami, ekonomicky únosnej iba vďaka Prompt Caching.

V koncepte 12-Factor Agents od Dexa Horthyho preto platí zásada: nástroje sú len štruktúrované výstupy. To, čo LLM vytvára, je JSON zodpovedajúci schéme; to, čo sa vykonáva, je deterministický kód, ktorý sám vlastníš a kontroluješ.

Definícia schémy: spoločný jazyk JSON Schema

Obaja poskytovatelia stavajú pod kapotou na JSON Schema ako lingua franca. Nástroje typu code-first ako Pydantic (Python) alebo Zod (TypeScript) generujú túto schému automaticky z typových definícií.

Spoľahlivá definícia nástroja stojí na svojom popise, na úrovni nástroja aj poľa. Parameter recipient_email s popisom „e-mailová adresa príjemcu podľa RFC 5321; musí zodpovedať existujúcemu záznamu zákazníka“ je výrazne spoľahlivejší ako to isté pole bez popisu. Osvedčené pravidlo z praxe: popis by nemal hovoriť len to, čo nástroj robí, ale predovšetkým kedy ho volať a ako zostaviť argumenty. Popis je trvalé zmluvné rozhranie medzi modelom a API. Pri novších modeloch, ktoré po nástrojoch siahajú skôr zdržanlivo, je merateľne účinnejší ako samotný popis funkcie.

Tip pre región DACH: názvy nástrojov a parametrov drž v angličtine (interoperabilita s knižnicami, logmi, OpenAPI), popisy však píš v jazyku, v ktorom agent pracuje. Katalógy so zmiešanými jazykmi s frontier modelmi fungujú, sú však zdrojom nekonzistentností, ktorému sa dá vyhnúť.

Rozdiely v implementácii: OpenAI vs. Anthropic

Nasledujúca tabuľka zhŕňa rozdiely, na ktorých v praxi záleží (stav 2026). Dôležité: spoločné znaky prevažujú. V produkcii mnohé tímy používajú abstrakčnú vrstvu (napríklad LiteLLM alebo Vercel AI SDK), ktorá rozdiely v názvoch polí zapuzdrí.

Pri Anthropic sú pre tool_choice k dispozícii štyri režimy: {"type": "auto"} (rozhoduje model, predvolený režim), {"type": "any"} (model musí použiť aspoň jeden nástroj), {"type": "tool", "name": "..."} (vynúti sa konkrétny nástroj) a {"type": "none"} (žiadne nástroje). Pri auto obmedzí disable_parallel_tool_use: true odpoveď na najviac jedno volanie, pri any a tool na presne jedno. Podľa dokumentácie Anthropic modely Claude Opus 5.5, Sonnet 5.5, Fable 5.1 a Mythos 5.1 režimy any a tool nepodporujú. To isté platí podľa dokumentácie k Tool Use pri ručne zapnutom Extended Thinking. V oboch prípadoch zostávajú iba auto a none.

Paralelné volania nástrojov a agentová slučka

Frontier modely môžu v jedinej odpovedi naraz vyžiadať viacero volaní nástrojov, napríklad paralelne „načítať profil“, „načítať posledné objednávky“ a „skontrolovať stav skladu“. To citeľne znižuje počet round-tripov aj latenciu. Tvoj harness musí spracovať všetky vyžiadané volania a výsledky vrátiť spolu v jednej nasledujúcej správe.

Manuálna agentová slučka pri Anthropic beží podľa tohto vzoru: zavolať API a skontrolovať odpoveď. Kým sa stop_reason rovná tool_use, vykonajú sa bloky Tool Use, celá odpoveď modelu a bloky tool_result (každý s príslušným tool_use_id) sa pripoja k histórii správ a spustí sa ďalšie volanie API. Slučka skončí, keď sa stop_reason rovná end_turn. Oficiálne SDK ponúkajú ako alternatívu automatický „Tool Runner“, ktorý túto slučku zapuzdruje; manuálna slučka sa používa na jemnejšie riadenie, napríklad schvaľovacie brány alebo vlastné logovanie.

Spracovanie chýb: robustné namiesto krehkého

Druhou najčastejšou príčinou nestabilných agentov v produkcii, hneď po nejednoznačných definíciách nástrojov, je zlé spracovanie chýb. Naprieč odvetviami platia tri princípy:

• Chyby vracaj ako štruktúrovaný výsledok nástroja, nevyhadzuj ich ako výnimku, ktorá preruší slučku. Zhustená odpoveď { "error": "code", "message": "...", "retry_after_seconds": 30 } nechá model rozhodnúť, či opraví argumenty, zvolí inú stratégiu alebo eskaluje. Pri Anthropic navyše nastavíš is_error: true v bloku tool_result.
• Kontext chyby drž kompaktný. Nesyp do kontextového okna surové stack trace. Znečisťuje to kontext a zhoršuje nasledujúce odpovede. Stack trace najprv zhusti.
• Obmedz počet opakovaní. Typické sú tri pokusy. Rozlišuj podľa typu chyby: chyby nástroja (500/timeout) skús znova s backoffom, validačné chyby (400) s upravenými argumentmi, chyby oprávnení (403) bez opakovania eskaluj na človeka, pri rate limitoch (429) použi backoff a prípadne zmeň model.

Pretrvávajúcim anti-patternom je tiché potláčanie chýb: volania nástrojov zlyhajú, ale agent beží ďalej, akoby bolo všetko v poriadku. Chyby vždy explicitne vráť modelu.

Druhé praktické pravidlo: vstupy nástrojov vždy čítaj JSON parserom, nikdy porovnávaním reťazcov v serializovanom vstupe. Modely Claude môžu JSON escaping podľa verzie spracovať rôzne, napríklad pri escapovaní Unicode alebo lomiek. Kto porovnáva surové reťazce, zabuduje si ťažko odhaliteľný bug.

Konkrétny príklad v pseudokóde

Nasledujúci príklad v pseudokóde ukazuje definíciu nástroja a manuálnu slučku v zápise Anthropic. Pri OpenAI by sa pole input_schema nazývalo parameters. Inak by tam vyzerala aj slučka: v Responses API prichádzajú argumenty ako reťazec JSON v položke function_call s call_id a výsledok sa vracia ako function_call_output s rovnakým call_id, ako ukazuje príručka OpenAI k Function Calling.

```
tool = {
"name": "fetch_recent_orders",
"description": "Načíta posledné objednávky zákazníka. "
"Použiť, keď sa používateľ pýta na históriu objednávok, stav "
"alebo doručenie. NEPOUŽÍVAŤ na samotné "
"vyhľadávanie produktov, na to použiť search_products. "
"Returns: zoznam {id, total, status, items}.",
"input_schema": {
"type": "object",
"properties": {
"user_id": {"type": "string", "description": "Interné ID zákazníka"},
"limit": {"type": "integer", "description": "Max. počet (predvolene 10)"}
},
"required": ["user_id"]
}
}

messages = [{"role": "user", "content": "Kde je moja posledná objednávka?"}]

while True:
response = client.messages.create(
model="claude-opus-5-5", # vzorový model
max_tokens=1024,
tools=[tool],
messages=messages,
)
if response.stop_reason != "tool_use":
break # end_turn -> hotovo

messages.append({"role": "assistant", "content": response.content})
results = []
for block in response.content:
if block.type == "tool_use": # príp. viacero -> paralelne
try:
data = run_tool(block.name, block.input) # vlastný kód
results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": to_json(data),
})
except ToolError as e:
results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": str(e),
"is_error": True,
})
messages.append({"role": "user", "content": results})
```

Príklad výpočtu záťaže nástrojmi: predpokladajme, že tento agent beží s piatimi nástrojmi, z ktorých každý má približne 200 tokenov schémy (spolu 1 000 tokenov), plus 800 tokenov system promptu. Pri 100 000 volaniach mesačne pripadne len na stabilný prefix okolo 180 miliónov vstupných tokenov. S funkciou Prompt Caching spoločnosti Anthropic stojí čítanie z cache pri väčšine modelov 10 percent štandardnej sadzby za vstup, napríklad 0,30 namiesto 3,00 USD za milión tokenov pri Sonnet 4.6. Pri Opus 5.5 a Sonnet 5.5 je to 5 percent, pri Fable 5.1 a Mythos 5.1 2,5 percenta. Predpokladom je stabilný katalóg nástrojov. Každá zmena definícií nástrojov, aj len ich poradia, cache úplne zneplatní. Z toho vyplýva produkčný postup: katalógy nástrojov nasadzovať v plánovaných vydaniach, žiadne hotfixy definícií nástrojov.

Koľko nástrojov má zmysel a prečo je problémom prekrývanie

Presnosť výberu nástroja sa neškáluje ľubovoľne. Osvedčilo sa trvalo načítavať len malú základnú množinu a ďalšie nástroje dopĺňať dynamicky cez nástroj na vyhľadávanie nástrojov (tool search). Fixný kontext tak zostáva malý a cache sa šetrí, pretože schémy sa pripájajú, a nie vymieňajú. Skutočným úzkym miestom však nie je samotný počet, ale prekrývanie: aj hŕstku jasne ohraničených nástrojov zvládneš bez problémov, zatiaľ čo už niekoľko prekrývajúcich sa nástrojov model spoľahlivo privedie k hádaniu.

Dva nástroje, ktoré by rovnako dobre mohli odpovedať na tú istú požiadavku, napríklad search_documents a search_knowledge_base, sú problém, ktorý nevyrieši ani ten najlepší prompt. Pri „Nájdi informácie o X“ model háda. Najúčinnejším a najčastejšie zabúdaným protiopatrením je klauzula „kedy nepoužiť“ v každom popise. Ako verejná benchmarková referencia pre presnosť výberu slúži Berkeley Function-Calling Leaderboard (BFCL); jeho hodnoty však kolíšu, preto ich treba overiť na vlastnej sade evaluácií, nie podľa marketingového blogového príspevku.

Pre agentúry a B2B rozhodovateľov

Function Calling, resp. Tool Use, je most medzi jazykovým modelom a tvojimi reálnymi systémami: CRM, účtovníctvo, expedícia, znalostná báza. Pojmový zmätok je neškodný; pri disciplíne v implementácii to neplatí. O tom, či agent v produkcii beží spoľahlivo, rozhodujú jasne ohraničené definície nástrojov, robustné spracovanie chýb formou štruktúrovaných výsledkov, kontrolované podmienky ukončenia a katalógová stratégia, ktorá počíta s cache, nie voľba medzi OpenAI a Anthropic.

Ako viedenská agentúra so zameraním na AI agentov sprevádzame firmy v regióne DACH od návrhu schém nástrojov cez abstrakciu poskytovateľov až po produkčne pripravenú a auditovateľnú agentovú slučku. Ak chceš štruktúrované volania nástrojov spoľahlivo zapojiť do svojich obchodných procesov, ozvi sa nám.