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

Function Calling a Tool Use označujú v jadre rovnakú schopnosť: Large Language Model na určitom mieste nevydáva súvislý text, ale štruktúrované, schéme zodpovedajúce volanie externe definovanej funkcie – vrátane príslušných argumentov. OpenAI zaviedlo pojem „Function Calling", Anthropic hovorí o „Tool Use". Technicky sú oba založené na JSON Schema a takmer identické. Rozdiely spočívajú v pomenovaní polí schémy a v niektorých mechanikách API – nie v základnom princípe.

Tento článok je súčasťou clustra okolo pilierovej témy „Základy LLM pre agentov" a prehlbuje to, čo sa naznačuje v sesterskom príspevku o základoch tool callingu. Všetky technické údaje sa vzťahujú na stav z roku 2026.

• Synonymum s nuansou: „Tool Use" je o niečo širší pojem, pretože nástroj môže byť u Anthropic aj serverová služba (webové vyhľadávanie, vykonávanie kódu) alebo MCP server. „Function Calling" znamená v užšom zmysle volanie čistej funkcie.
• Model nič nevykonáva: dodá iba volanie. Váš kód validuje argumenty, vykoná ich a vráti výsledok. Až potom LLM sformuluje odpoveď.
• Najdôležitejší implementačný rozdiel: OpenAI používa v schéme nástroja pole parameters, Anthropic input_schema. Oba pod tým stavajú na JSON Schema.

Ako LLM generuje štruktúrované volania nástrojov

Mechanizmus je v oboch ekosystémoch postavený identicky. Modelu odovzdáte zoznam definícií nástrojov dodatočne k samotnej používateľskej požiadavke. Každá definícia opisuje názov, popis (kedy sa nástroj má a kedy nemá použiť) a vstupnú schému s typovanými, sčasti povinnými parametrami.

Anthropic injektuje definície nástrojov do kontextu cez interný wrapper prompt API – približne podľa nasledujúceho vzoru:

```
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 stojí ako schéma trvalo tokeny (rádovo typicky okolo 100–300 na nástroj, podľa zložitosti schémy), pretože model číta definície v každom inference turne. Katalóg s desiatimi nástrojmi tak hrubo leží okolo 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émy – ekonomicky zvládnuteľné len cez prompt caching.

V rámci 12-Factor-Agents od Dexa Horthyho preto platí zásada: Nástroje sú len štruktúrované výstupy. To, čo LLM produkuje, je JSON zodpovedajúci schéme; to, čo sa vykonáva, je deterministický kód, ktorý sami vlastníte a kontrolujete.

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

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

Spoľahlivá definícia nástroja žije zo svojho popisu – na úrovni nástroja aj na úrovni poľa. Parameter recipient_email s popisom „e-mailová adresa príjemcu zodpovedajúca RFC-5321; musí zodpovedať existujúcemu zákazníckemu záznamu" je výrazne spoľahlivejší ako to isté pole bez popisu. Ako spoľahlivé pravidlo z praxe platí: popis by nemal hovoriť len čo nástroj robí, ale predovšetkým kedy sa má zavolať a ako sa majú konštruovať argumenty. Je trvalou zmluvou o rozhraní medzi modelom a API – a na novších modeloch, ktoré sú pri siahaní po nástrojoch skôr zdržanlivé, merateľne účinnejší ako čistý popis funkcie.

Poznámka špecifická pre DACH: názvy nástrojov a identifikátory parametrov držať v angličtine (interoperabilita s knižnicami, logmi, OpenAPI), popisy však písať v runtime jazyku agenta. Jazykovo zmiešané katalógy fungujú s frontier modelmi, sú však zbytočným zdrojom nekonzistencií.

Implementačné rozdiely: OpenAI vs. Anthropic

Nasledujúca tabuľka zhŕňa prakticky relevantné rozdiely (stav 2026). Dôležité: spoločné prevažuje. V produkcii mnohé tímy používajú abstrakčnú vrstvu (napríklad LiteLLM alebo Vercel AI SDK), aby zapuzdrili rozdiely v názvoch polí.

U Anthropic sú pre tool_choice k dispozícii štyri režimy: {"type": "auto"} (rozhoduje model, default), {"type": "any"} (musí sa použiť aspoň jeden nástroj), {"type": "tool", "name": "..."} (vynúti sa konkrétny nástroj) a {"type": "none"} (žiadne nástroje). Každá z týchto hodnôt môže navyše niesť disable_parallel_tool_use: true, aby sa vynútilo najviac jedno volanie na odpoveď.

Paralelné volania nástrojov a agent loop

Frontier modely môžu v jedinej odpovedi naraz požadovať viacero volaní nástrojov – napríklad „načítať profil", „nahrať posledné objednávky" a „skontrolovať stav skladu" paralelne. To citeľne znižuje round-tripy a latenciu. Váš harness musí spracovať všetky požadované volania a vrátiť výsledky spoločne v jedinej nadväzujúcej správe.

Manuálny agent loop u Anthropic prebieha podľa tohto vzoru: zavolať API, skontrolovať odpoveď – kým sa stop_reason rovná tool_use, vykonajú sa bloky tool_use, k histórii správ sa pripojí kompletná odpoveď modelu, ako aj bloky tool_result (vždy so zodpovedajúcim tool_use_id), a spustí sa ďalšie volanie API. Loop končí, keď sa stop_reason rovná end_turn. Oficiálne SDK alternatívne ponúkajú automatický „Tool Runner", ktorý tento loop zapuzdruje; manuálny loop sa používa pre jemnú granularitu, napríklad schvaľovacie brány alebo vlastné logovanie.

Ošetrenie chýb: robustne namiesto krehko

Druhou najčastejšou príčinou nestabilných produkčných agentov – po nejednoznačných definíciách nástrojov – je zlé ošetrenie chýb. Tri princípy platia naprieč odvetviami:

• Chyby vracať ako štruktúrovaný tool-result, nie vyhadzovať ako výnimku, ktorá preruší loop. Zhustené { "error": "code", "message": "...", "retry_after_seconds": 30 } umožní modelu rozhodnúť, či opraví argumenty, zvolí inú stratégiu alebo eskaluje. U Anthropic navyše nastavíte is_error: true v bloku tool_result.
• Kontext chyby držať kompaktný. Žiadne surové stack trace nelievať do kontextového okna – to znečisťuje kontext a zhoršuje nasledujúce odpovede. Zhusťujte.
• Obmedziť počet opakovaní. Tri pokusy sú typické. Diferencujte podľa typu chyby: chybu nástroja (500/timeout) skúšať znova s backoffom, chybu validácie (400) s upravenými argumentmi, chybu oprávnení (403) bez opakovania eskalovať na človeka, rate limity (429) s backoffom a prípadne zmenou modelu.

Húževnatým anti-patternom je tiché potláčanie chýb, pri ktorom volania nástrojov zlyhajú, ale agent beží ďalej, akoby bolo všetko v poriadku. Chyby vždy explicitne vracajte modelu.

Druhé, praktické pravidlo: vstupy nástrojov vždy čítať pomocou JSON parsera, nikdy cez porovnávanie reťazcov na serializovanom vstupe. Modely aktuálnej generácie (napríklad Opus 4.6, 4.7 a 4.8, ako aj Sonnet 4.6, stav 2026) môžu JSON escaping medzi verziami spracovávať rozdielne – napríklad Unicode alebo slash escaping. Kto surovo porovnáva reťazce, vyrobí si ťažko dohľadateľný bug.

Konkrétny príklad v pseudokóde

Nasledujúci príklad v pseudokóde ukazuje definíciu nástroja a manuálny loop v zápise Anthropic. Rozdiel oproti OpenAI spočíva v podstate v tom, že input_schema by sa tam volalo parameters.

```
tool = {
"name": "fetch_recent_orders",
"description": "Lädt die letzten Bestellungen eines Kunden. "
"Nutzen, wenn der Nutzer nach Bestellhistorie, Status "
"oder Lieferungen fragt. NICHT nutzen für reine "
"Produktsuche – dafür search_products verwenden. "
"Returns: Liste von {id, total, status, items}.",
"input_schema": {
"type": "object",
"properties": {
"user_id": {"type": "string", "description": "Interne Kunden-ID"},
"limit": {"type": "integer", "description": "Max. Anzahl (Default 10)"}
},
"required": ["user_id"]
}
}

messages = [{"role": "user", "content": "Wo ist meine letzte Bestellung?"}]

while True:
response = client.messages.create(
model="claude-opus-4-8", # Stand 2026
max_tokens=1024,
tools=[tool],
messages=messages,
)
if response.stop_reason != "tool_use":
break # end_turn -> fertig

messages.append({"role": "assistant", "content": response.content})
results = []
for block in response.content:
if block.type == "tool_use": # ggf. mehrere -> parallel
try:
data = run_tool(block.name, block.input) # eigener Code
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ástrojov: predpokladajme, že tento agent beží s piatimi nástrojmi à ~200 tokenov schémy (1 000 tokenov) plus 800 tokenov systémového promptu. Pri 100 000 volaniach za mesiac pripadne len na stabilný prefix okolo 180 miliónov vstupných tokenov. Cez prompt caching od Anthropic stojí jedno cache-read len asi 10 percent štandardnej vstupnej sadzby (stav 2026: napr. okolo 0,30 namiesto 3,00 amerických dolárov za milión tokenov pri Sonnet 4.6) – za predpokladu, že katalóg nástrojov zostane stabilný. Každá zmena definícií nástrojov, čo i len poradia, invaliduje cache úplne. Z toho vyplýva produkčný pattern: katalógy nástrojov vyvádzať v plánovaných releasoch, žiadne hotfixy na tool-defs.

Koľko nástrojov – a pasca prekrývania

Presnosť výberu nástrojov sa neškáluje ľubovoľne. Osvedčilo sa trvalo načítať len malú základnú množinu a ďalšie nástroje dotiahnuť dynamicky cez tool-search nástroj – to drží fixný kontext malým a šetrí cache, pretože schémy sa pripájajú namiesto vymieňania. Skutočným úzkym miestom však nie je samotný počet, ale prekrývanie: už hŕstka jasne ohraničených nástrojov sa dá čisto manažovať, zatiaľ čo niekoľko prekrývajúcich sa spoľahlivo privedie model k hádaniu.

Dva nástroje, ktoré by vierohodne mohli zodpovedať tú istú požiadavku – napríklad search_documents a search_knowledge_base –, sú ten problém, ktorý nevyrieši žiadny, ani ten najlepší prompt. Pri „Nájdi informácie k X" model háda. Najúčinnejším, väčšinou zabudnutým protiopatrením je klauzula kedy-nepoužiť v každom popise. Ako verejná benchmark referencia pre presnosť výberu slúži Berkeley Function-Calling Leaderboard (BFCL); jeho hodnoty však kolíšu a mali by sa rebenchmarkovať voči vlastnej eval sade, nie voči marketingovému blogovému príspevku.

Pre agentúry a B2B rozhodovateľov

Function Calling, respektíve Tool Use, je mostom medzi jazykovým modelom a vašimi reálnymi systémami – CRM, účtovníctvo, expedícia, znalostná databáza. Pojmový zmätok je neškodný; implementačná disciplína nie. To, či agent v produkcii beží spoľahlivo, sa rozhoduje pri čisto ohraničených definíciách nástrojov, robustnom ošetrení chýb ako štruktúrovaných výsledkov, kontrolovaných podmienkach ukončenia a stratégii katalógu vedomej si cache – nie pri voľbe medzi OpenAI a Anthropic.

Ako viedenská agentúra so zameraním na AI agentov sprevádzame podniky v regióne DACH od dizajnu schémy nástrojov cez abstrakciu poskytovateľa až po produkčne zrelý, auditovateľný agent loop. Ak chcete spoľahlivo zapojiť štruktúrované volania nástrojov do svojich obchodných procesov, ozvite sa nám.