--- title: "Function Calling vs. Tool Use: Vysvetlenie pojmov a implementácie" description: "Function Calling a Tool Use označujú rovnakú základnú funkciu: LLM nevydáva súvislý text, ale štruktúrované, schéme zodpovedajúce volanie externe definovanej funkcie. OpenAI zaviedlo „Function Calling\", Anthropic používa „Tool Use\", technicky sú oba založené na JSON Schema a takmer identické, s rozdielmi v názvoch polí a mechanike API." locale: "sk" canonical: "https://blckalpaca.at/sk/vedomosti/ai-agenti/zaklady-llm-pre-ai-agentov/function-calling-vs-tool-use" category: "AI agenti" topic: "Základy LLM pre AI Agentov" updated: "2026-07-29T08:59:32.237Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Function Calling vs. Tool Use: Vysvetlenie pojmov a implementácie Function Calling a Tool Use označujú rovnakú základnú funkciu: LLM nevydáva súvislý text, ale štruktúrované, schéme zodpovedajúce volanie externe definovanej funkcie. OpenAI zaviedlo „Function Calling", Anthropic používa „Tool Use", technicky sú oba založené na JSON Schema a takmer identické, s rozdielmi v názvoch polí a mechanike API. ## Klucove body - Function Calling (OpenAI) a Tool Use (Anthropic) sú do veľkej miery synonymá, oba umožňujú LLM generovať štruktúrovaný JSON namiesto súvislého textu, ktorý následne vykoná deterministický kód. - Hlavným implementačným rozdielom je pomenovanie polí: OpenAI používa 'parameters' v schéme nástroja, Anthropic 'input_schema'. Oba pod tým stavajú na JSON Schema. - LLM nevykonáva nič samo: dodá volanie nástroja, váš kód ho vykoná a vráti výsledok. U Anthropic stop_reason 'tool_use' signalizuje, že volanie čaká na spracovanie. - Paralelné volania nástrojov sú štandardom a dajú sa vypnúť (Anthropic: disable_parallel_tool_use). Chyby patria späť do modelu ako štruktúrovaný tool_result s is_error, nie ako výnimka. - Výber nástrojov sa neškáluje ľubovoľne: málo jasne ohraničených nástrojov je robustnejších ako mnoho prekrývajúcich sa. Definície nástrojov sú zároveň prompt budget aj cieľ cache. - Pravidlo z praxe: vstupy nástrojov vždy čítať pomocou JSON parsera, nikdy cez porovnávanie reťazcov, escaping sa môže medzi verziami modelov líšiť. 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](/sk/slovnik/openai) zaviedlo pojem „Function Calling", Anthropic hovorí o „Tool Use". Technicky sú obe založené na [JSON Schema](/sk/vedomosti/seo-geo/technicke-seo/trukturovane-data-ako-vrstva-porozumenia-ai) a takmer identické. Rozdiely spočívajú v pomenovaní polí schémy a v niektorých mechanikách [API](/sk/slovnik/api), nie v základnom princípe. Tento článok je súčasťou klastra okolo piliera „[Základy LLM pre agentov](/sk/sluzby/integracia-ai-agenta)" 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](/sk/slovnik/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](/sk/slovnik/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](/sk/slovnik/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](/sk/slovnik/system-prompt) }} {{ TOOL CONFIGURATION }} \`\`\` Z toho vyplýva často prehliadaný [ekonomický dôsledok](/sk/vedomosti/ai-agenti/prompt-engineering-pre-agentov/system-prompts-design-patterns): 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](/sk/vedomosti/ai-agenti/prehlad-architektur-ai-agentov/react-pattern-erklaert) 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](/sk/vedomosti/ai-agenti/zaklady-llm-pre-ai-agentov/strukturierte-outputs-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](/sk/slovnik/ai) SDK), aby zapuzdrili rozdiely v názvoch polí. | Aspekt | OpenAI (Function Calling) | Anthropic (Tool Use) | | --- | --- | --- | | Pojem | Function Calling | Tool Use | | Pole schémy pre parametre | `parameters` | `input_schema` | | Štandard schémy | JSON Schema | JSON Schema | | Signál pre volanie nástroja | Tool-Call v odpovedi (`finish_reason`) | `stop_reason: "tool_use"` | | Riadenie výberu | `tool_choice`: auto / required / none / pomenovaný | `tool_choice`: auto / any / tool / none | | Paralelné volania | Štandardne aktívne | Štandardne aktívne | | Vypnutie paralelnosti | cez `tool_choice`-možnosti | `disable_parallel_tool_use: true` v `tool_choice` | | Vrátenie výsledku | Tool-Result správa s odkazom na volanie | `tool_result`-blok s príslušným `tool_use_id` | | Signalizácia chyby | štruktúrovaná chyba v Result | `tool_result` s `is_error: true` | | Serverové nástroje | okrem iného Code Interpreter, webové vyhľadávanie | Vykonávanie kódu, webové vyhľadávanie/-fetch, Computer Use | | Striktné vynucovanie schémy | Structured Outputs / `strict: true` | `strict: true` resp. `output_config.format` | 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](/sk/slovnik/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](/sk/blog/implementacia-agenta-aws-ai-strategicky-ramec-pre-uspech-podnikovej-sfery) 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](https://www.nist.gov/itl/ai-risk-management-framework) (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](/sk/slovnik/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. ## FAQ ### Je Function Calling to isté ako Tool Use? V jadre áno. Oba pojmy opisujú rovnaký mechanizmus: LLM generuje štruktúrované, schéme zodpovedajúce volanie vami definovanej funkcie namiesto súvislého textu. 'Function Calling' je označenie OpenAI, 'Tool Use' označenie Anthropic. Nuansa: 'Tool Use' je o niečo širší pojem, pretože nástroj môže byť u Anthropic aj serverová služba (napríklad webové vyhľadávanie alebo vykonávanie kódu) alebo MCP server, nielen funkcia na strane klienta. V praxi sa tieto pojmy používajú synonymne. ### Aký je najdôležitejší technický rozdiel medzi OpenAI a Anthropic? Pomenovanie polí v schéme nástroja. OpenAI definuje parametre pod kľúčom 'parameters', Anthropic pod 'input_schema'. Oba pod tým používajú JSON Schema, takže samotný objekt parametrov je takmer identický. Ďalšie rozdiely sa týkajú signalizácie (Anthropic: stop_reason 'tool_use') a formátu návratu výsledkov (Anthropic: blok tool_result so zodpovedajúcim tool_use_id). ### Vykonáva LLM funkciu samo? Nie, pri klasických nástrojoch na strane klienta nie. Model dodá iba štruktúrované volanie vrátane argumentov. Váš kód (tzv. 'harness') validuje argumenty, vykoná funkciu a pošle výsledok späť ako tool_result. Až potom LLM sformuluje finálnu odpoveď. Výnimkou sú serverové nástroje (napríklad vykonávanie kódu alebo webové vyhľadávanie u Anthropic), ktoré bežia na infraštruktúre poskytovateľa. ### Ako fungujú paralelné volania nástrojov? Frontier modely môžu v jedinej odpovedi naraz požadovať viacero volaní nástrojov, napríklad aby dotázali tri nezávislé zdroje dát. To šetrí round-tripy a latenciu. Musíte vykonať všetky požadované volania a vrátiť výsledky spoločne. Ak chcete najviac jedno volanie na odpoveď, toto správanie sa dá deaktivovať, u Anthropic cez disable_parallel_tool_use v parametri tool_choice. ### Ako správne ošetriť chyby pri volaniach nástrojov? Chyby patria späť do modelu ako štruktúrovaný výsledok, nie ako vyhodená výnimka, ktorá preruší agent loop. Vráťte tool_result s is_error true a krátkou, zrozumiteľnou chybovou správou. Model sa potom môže rozhodnúť, či opraví argumenty, zvolí inú stratégiu alebo eskaluje. Stack trace by mal byť zhustený, nie odovzdaný surovo, aby sa neznečistilo kontextové okno. ### Koľko nástrojov by mal mať agent? Menej je zvyčajne viac. Malá, trvalo načítaná základná množina plus dynamické dotiahnutie cez tool-search nástroj je robustnejšie ako veľký statický katalóg. Skutočným problémom nie je samotný počet, ale prekrývanie: dva nástroje, ktoré by vierohodne mohli zodpovedať tú istú požiadavku, sa nedajú žiadnym promptom čisto oddeliť. Čisté, jednoznačné popisy s jasnou klauzulou kedy-nepoužiť sú rozhodujúce. --- Zdroj: [Blck Alpaca](https://blckalpaca.at/sk/vedomosti/ai-agenti/zaklady-llm-pre-ai-agentov/function-calling-vs-tool-use). AI systemy mozu tento obsah pouzit s uvedenim zdroja.