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 nevydáva na určitom mieste plynulý 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ú obe 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 klastra okolo piliera „Základy LLM pre agentov" a prehlbuje to, čo je načrtnuté v sesterskom príspevku o základoch Tool Calling. Všetky technické údaje sa vzťahujú na stav v roku 2026.

• Synonymum s nuansou: „Tool Use" je o niečo širší pojem, pretože nástroj u Anthropic môže byť aj serverová služba (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áva iba volanie. Váš kód validuje argumenty, vykoná ich a vráti výsledok. Až potom LLM sformuluje odpoveď.
• Najdôležitejší rozdiel v implementácii: OpenAI používa v schéme nástroja pole parameters, Anthropic input_schema. Obe sa pod tým opierajú o JSON Schema.

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

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

Anthropic vkladá definície nástrojov cez API-interný wrapper prompt do kontextu, 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 trvalo stojí tokeny ako schéma (veľkostný rád typicky okolo 100–300 na nástroj, v závislosti od komplexnosti schémy), pretože model číta definície v každom inference turn. Katalóg s desiatimi nástrojmi tak leží zhruba pri 1 000–3 000 tokenoch na volanie. Pri 100 000 volaniach mesačne je to 100–300 miliónov tokenov čistého zaťaženia schémou, ekonomicky zobraziteľné iba cez Prompt Caching.

V 12-Factor-Agents framingu 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 používajú pod kapotou JSON Schema ako 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 poľa. Parameter recipient_email s popisom „RFC-5321-konformná e-mailová adresa príjemcu; musí zodpovedať existujúcemu zákazníckemu záznamu" je výrazne spoľahlivejší ako to isté pole bez popisu. Ako spoľahlivé praktické pravidlo platí: Popis by nemal hovoriť len o tom, čo nástroj robí, ale predovšetkým kedy má byť volaný a ako majú byť konštruované argumenty. Je to trvalá zmluvná rozhranie medzi modelom a API, a na mladších modeloch, ktoré sú pri používaní nástrojov skôr zdržanlivé, merateľne účinnejšie ako čistý popis funkcie.

DACH-špecifický tip: Názvy nástrojov a označenia parametrov držať v angličtine (interoperabilita s knižnicami, logy, OpenAPI), ale popisy písať v runtime jazyku agenta. Viacjazyčné katalógy fungujú s frontier modelmi, ale sú zbytočným zdrojom nekonzistencií.

Rozdiely v implementácii: OpenAI vs. Anthropic

Nasledujúca tabuľka zhŕňa prakticky relevantné rozdiely (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), aby zapuzdrili rozdiely v názvoch polí.

U Anthropic sú pre tool_choice k dispozícii štyri režimy: {"type": "auto"} (model rozhoduje, default), {"type": "any"} (musí byť použitý aspoň jeden nástroj), {"type": "tool", "name": "..."} (konkrétny nástroj je vynútený) a {"type": "none"} (žiadne nástroje). Každá z týchto hodnôt môže dodatočne niesť disable_parallel_tool_use: true na vynútenie maximálne jedného volania na odpoveď.

Paralelné Tool-Calls a Agent-Loop

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

Manuálny agent loop u Anthropic beží podľa tohto vzoru: Zavolať API, skontrolovať odpoveď, pokiaľ je stop_reason rovný tool_use, vykonajú sa bloky tool_use, kompletná odpoveď modelu aj tool_result-bloky (každý s príslušným tool_use_id) sa pripoja k histórii správ a spustí sa ďalšie API volanie. Loop sa končí, keď je stop_reason rovný end_turn. Oficiálne SDK ponúkajú alternatívne 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.

Spracovanie chýb: robustné namiesto krehkého

Druhá najčastejšia príčina nestabilných produkčných agentov, po nejednoznačných definíciách nástrojov, je zlé spracovanie chýb. Tri princípy platia naprieč odvetviami:

• Chyby vrátiť ako štruktúrovaný Tool-Result, nie hodiť ako výnimku, ktorá preruší loop. Zhustené { "error": "code", "message": "...", "retry_after_seconds": 30 } nechá model rozhodnúť, či opraví argumenty, zvolí inú stratégiu alebo eskaluje. U Anthropic navyše nastavíte is_error: true v tool_result-bloku.
• Kontext chyby držať kompaktný. Žiadne surové stack-trace do kontextového okna, to znečisťuje kontext a zhoršuje následné odpovede. Zhusťujte.
• Opakovania obmedziť. Tri pokusy sú typické. Rozlišujte podľa typu chyby: Chyby nástroja (500/Timeout) skúsiť znova s backoffom, validačné chyby (400) s upravenými argumentmi, chyby oprávnení (403) bez opakovania eskalovať na človeka, rate-limity (429) s backoffom a prípadne zmenou modelu.

Tvrdošijný anti-pattern je tiché potlačenie chyby, pri ktorom volania nástrojov zlyhajú, ale agent beží ďalej, akoby bolo všetko v poriadku. Chyby vždy explicitne vráťte modelu.

Druhé, praktické pravidlo: Tool-Inputs vždy čítať s JSON parserom, nikdy cez string-matching na serializovanom vstupe. Modely súčasnej 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ť odlišne, napríklad Unicode- alebo Slash-escaping. Kto matchuje surovo stringy, buduje si ťažko nájditeľný bug.

Konkrétny pseudokód príklad

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

```
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 dodávky. NEPOUŽÍVAŤ pre čisté "
"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 (Default 10)"}
},
"required": ["user_id"]
}
}

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

while True:
response = client.messages.create(
model="claude-opus-4-8", # Stav 2026
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 zaťaženia nástrojmi: Predpokladajme, že tento agent beží s piatimi nástrojmi à ~200 tokenov schémy (1 000 tokenov) plus 800 tokenov system prompt. Pri 100 000 volaniach mesačne pripadá len na stabilný prefix okolo 180 miliónov input tokenov. Cez Anthropic Prompt Caching stojí cache-read len asi 10 percent štandardnej input sadzby (stav 2026: napr. okolo 0,30 namiesto 3,00 US dolárov na mil. tokenov pri Sonnet 4.6), za predpokladu, že katalóg nástrojov zostane stabilný. Každá zmena definícií nástrojov, aj len poradia, invaliduje cache úplne. Z toho vyplýva produkčný pattern: Katalógy nástrojov nasadzovať v plánovaných releaseoch, žiadne hotfixy na tool-defs.

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

Presnosť výberu nástroja neškaluje ľubovoľne. Osvedčilo sa načítavať trvalo len malú jadrovú množinu a ďalšie nástroje dynamicky donačítavať cez tool-search nástroj, to udržuje fixný kontext malý a šetrí cache, pretože schémy sa pripájajú namiesto výmeny. Skutočným úzkym miestom však nie je čistý počet, ale prekrývanie: Už hŕstka jasne oddelených nástrojov sa dá čisto riadiť, zatiaľ čo niekoľko prekrývajúcich sa spoľahlivo privedie model k hádaniu.

Dva nástroje, ktoré by mohli plauzibilne 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ádá. Najúčinnejšie, najčastejšie zabudnuté protiopatrenie je klauzula kedy-nepoužívať v každom popise. Ako verejná benchmark referencia pre presnosť výberu slúži Berkeley Function-Calling Leaderboard (BFCL); jej hodnoty však kolíšu a mali by byť rebenchmarknuté proti vlastnému eval setu, nie proti marketingovému blogpostu.

Pre agentúry a B2B rozhodovateľov

Function Calling respektíve Tool Use je most medzi jazykovým modelom a vašimi reálnymi systémami. CRM, účtovníctvo, expedícia, databáza znalostí. Pojmový zmätok je neškodný; implementačná disciplína nie je. Či agent v produkcii beží spoľahlivo, rozhoduje sa na čisto oddelených definíciách nástrojov, robustnom spracovaní chýb ako štruktúrovaných results, kontrolovaných termination podmienkach a cache-vedomej katalógovej stratégii, nie na voľbe medzi OpenAI a Anthropic.

Ako viedenská agentúra so zameraním na AI agentov sprevádzame DACH podniky od návrhu tool-schémy cez abstrakciu poskytovateľov až po produkčne pripravený, auditovateľný agent loop. Ak chcete spoľahlivo zapojiť štruktúrované volania nástrojov do svojich obchodných procesov, kontaktujte nás.