--- title: "Function Calling vs. Tool Use: definicje i implementacje" description: "Function Calling i Tool Use oznaczają tę samą podstawową funkcję: zamiast swobodnego tekstu LLM zwraca ustrukturyzowane, zgodne ze schematem wywołanie funkcji zdefiniowanej zewnętrznie." locale: "pl" canonical: "https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/co-to-jest-llm-podstawy-dla-agentow-ai/function-calling-vs-tool-use-definicje-i-implementacje" category: "Agenci AI" topic: "Co to jest LLM: podstawy dla agentów AI" updated: "2026-10-28T13:37:28.224Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # Function Calling vs. Tool Use: definicje i implementacje Function Calling i Tool Use oznaczają tę samą podstawową funkcję: zamiast swobodnego tekstu LLM zwraca ustrukturyzowane, zgodne ze schematem wywołanie funkcji zdefiniowanej zewnętrznie. OpenAI ukuło termin „Function Calling”, Anthropic używa nazwy „Tool Use”. Technicznie oba podejścia opierają się na JSON Schema i niemal się pokrywają, a różnią się nazwami pól i mechaniką API. ## W skrócie - Function Calling (OpenAI) i Tool Use (Anthropic) to w dużej mierze synonimy: w obu przypadkach LLM generuje ustrukturyzowany JSON zamiast swobodnego tekstu, a następnie wykonuje go deterministyczny kod. - Najbardziej widoczną różnicą w implementacji jest nazewnictwo pól: OpenAI używa w schemacie narzędzia 'parameters', Anthropic 'input_schema'. Pod spodem oba opierają się na JSON Schema. Poza tym różni się format odpowiedzi i format zwracania wywołań narzędzi. - LLM niczego nie wykonuje sam: dostarcza wywołanie narzędzia, Twój kod je wykonuje i zwraca wynik. W Anthropic stop_reason 'tool_use' sygnalizuje, że trzeba wykonać wywołanie. - Równoległe wywołania narzędzi są domyślnie włączone i można je wyłączyć (Anthropic: disable_parallel_tool_use). Błędy należy zwracać do modelu jako ustrukturyzowany tool_result z is_error, a nie jako wyjątek. - Wybór narzędzi nie skaluje się w nieskończoność: kilka wyraźnie rozgraniczonych narzędzi działa stabilniej niż wiele nakładających się. Definicje narzędzi to jednocześnie część budżetu promptu i cel cache'owania. - Praktyczna zasada: dane wejściowe narzędzi zawsze odczytuj parserem JSON, nigdy przez dopasowywanie ciągów znaków, bo escaping może się różnić między wersjami modeli. Function Calling i Tool Use oznaczają w gruncie rzeczy tę samą zdolność: [duży model językowy](https://blckalpaca.at/pl/slownik/llm) w określonym miejscu nie zwraca swobodnego tekstu, lecz ustrukturyzowane, zgodne ze schematem wywołanie zewnętrznie zdefiniowanej funkcji wraz z odpowiednimi argumentami. [OpenAI](https://blckalpaca.at/pl/slownik/openai) wprowadziło termin „Function Calling”, Anthropic mówi o „Tool Use”. Technicznie oba podejścia opierają się na JSON Schema i niemal się pokrywają. Różnice dotyczą nazewnictwa pól schematu i niektórych mechanizmów [API](https://blckalpaca.at/pl/slownik/api), a nie samej zasady działania. Ten artykuł należy do klastra wokół artykułu filarowego „Podstawy [LLM](https://blckalpaca.at/pl/slownik/llm) dla agentów” i rozwija to, co zasygnalizowano w [powiązanym artykule o podstawach tool callingu](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/czym-sa-agenci-ai/tool-calling-jak-agenci-ai-korzystaja-z-narzedzi). Wszystkie informacje techniczne odzwierciedlają stan na 2026 rok. - **Synonim z niuansem:** „Tool Use” to nieco szersze pojęcie, bo w Anthropic narzędziem może być też usługa po stronie serwera (wyszukiwanie w sieci, wykonywanie kodu) lub serwer [MCP](https://blckalpaca.at/pl/slownik/mcp). „Function Calling” w węższym znaczeniu oznacza wywołanie zwykłej funkcji. - **Model niczego nie wykonuje:** dostarcza tylko wywołanie. Twój kod waliduje argumenty, wykonuje funkcję i zwraca wynik. Dopiero wtedy LLM formułuje odpowiedź. - **Najbardziej widoczna różnica w implementacji:** OpenAI używa w schemacie narzędzia pola `parameters`, Anthropic `input_schema`. Pod spodem oba opierają się na JSON Schema. ## Jak LLM generuje ustrukturyzowane wywołania narzędzi Mechanizm jest w obu ekosystemach zbudowany identycznie. Oprócz właściwego zapytania użytkownika przekazujesz modelowi listę definicji narzędzi. Każda definicja zawiera nazwę, opis (kiedy używać narzędzia, a kiedy nie) oraz schemat wejściowy z typowanymi parametrami, z których część jest wymagana. API Anthropic buduje z definicji narzędzi, konfiguracji narzędzi i Twojego system promptu własny [prompt](https://blckalpaca.at/pl/slownik/prompt) dla Tool Use. Według [dokumentacji Anthropic](https://platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools) wygląda on mniej więcej tak: \`\`\` 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 }} \`\`\` Wynika z tego często pomijana konsekwencja ekonomiczna: każde narzędzie jako schemat stale kosztuje tokeny (zwykle rzędu 100–300 na narzędzie, zależnie od złożoności schematu), bo model czyta definicje w każdej turze inferencji. Katalog z dziesięcioma narzędziami to więc z grubsza 1000–3000 tokenów na wywołanie. Przy 100 000 wywołań miesięcznie daje to 100–300 milionów tokenów samego obciążenia schematami, co ekonomicznie da się udźwignąć tylko dzięki [Prompt Caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching). W [ujęciu 12-Factor Agents](https://github.com/humanlayer/12-factor-agents) Dexa Horthy'ego obowiązuje więc zasada: **narzędzia to tylko ustrukturyzowane outputy.** To, co produkuje LLM, to zgodny ze schematem JSON; to, co jest wykonywane, to deterministyczny kod, który sam posiadasz i kontrolujesz. ## Definicja schematu: JSON Schema jako wspólny język Obaj dostawcy opierają się pod maską na [JSON Schema jako lingua franca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/model-context-protocol-mcp/mcp-vs-api-openapi-kiedy-co-wybrac). Narzędzia typu code-first, takie jak Pydantic (Python) czy Zod (TypeScript), generują ten schemat automatycznie z definicji typów. Solidna definicja narzędzia opiera się na opisie, zarówno na poziomie narzędzia, jak i pola. Parametr `recipient_email` z opisem „zgodny z RFC 5321 adres e-mail odbiorcy; musi odpowiadać istniejącemu rekordowi klienta” jest znacznie bardziej niezawodny niż to samo pole bez opisu. Sprawdzona zasada praktyczna: opis powinien mówić nie tylko, **co** robi narzędzie, ale przede wszystkim **kiedy** należy je wywołać i **jak** skonstruować argumenty. To trwały kontrakt interfejsu między modelem a API, a w przypadku nowszych modeli, które dość ostrożnie sięgają po narzędzia, działa wymiernie lepiej niż sam opis funkcji. Wskazówka dla firm w Europie: nazwy narzędzi i identyfikatory parametrów zostaw po angielsku (interoperacyjność z bibliotekami, logami, OpenAPI), ale opisy pisz w języku, w którym działa [agent](https://blckalpaca.at/pl/slownik/agent). Katalogi mieszające języki działają z czołowymi modelami, ale są niepotrzebnym źródłem niespójności. ## Różnice w implementacji: OpenAI vs. Anthropic Poniższa tabela zestawia praktycznie istotne różnice (stan na 2026 rok). Ważne: podobieństwa przeważają. W produkcji wiele zespołów używa warstwy abstrakcji (np. LiteLLM lub Vercel [AI](https://blckalpaca.at/pl/slownik/ai) SDK), żeby ukryć różnice w nazwach pól. | Aspekt | OpenAI (Function Calling) | Anthropic (Tool Use) | | --- | --- | --- | | Pojęcie | Function Calling | Tool Use | | Pole schematu dla parametrów | `parameters` | `input_schema` | | Standard schematu | JSON Schema | JSON Schema | | Sygnał wywołania narzędzia | Wpis `function_call` w outpucie (Responses API) lub `finish_reason: "tool_calls"` (Chat Completions) | `stop_reason: "tool_use"` | | Sterowanie wyborem | `tool_choice`: auto / required / none / nazwana funkcja | `tool_choice`: auto / any / tool / none | | Wywołania równoległe | Domyślnie włączone | Domyślnie włączone | | Wyłączanie równoległości | Parametr `parallel_tool_calls: false` | `disable_parallel_tool_use: true` w `tool_choice` | | Zwracanie wyniku | `function_call_output` z `call_id` (Responses API) lub wiadomość z `role: "tool"` i `tool_call_id` (Chat Completions) | Blok `tool_result` z odpowiadającym mu `tool_use_id` | | Sygnalizowanie błędów | ustrukturyzowany błąd w wyniku | `tool_result` z `is_error: true` | | Narzędzia po stronie serwera | m.in. Code Interpreter, wyszukiwanie w sieci | Wykonywanie kodu, wyszukiwanie i pobieranie treści z sieci | | Ścisłe wymuszanie schematu | Structured Outputs / `strict: true` | `strict: true` lub `output_config.format` | W Anthropic `tool_choice` oferuje cztery tryby: `{"type": "auto"}` (model decyduje, domyślnie), `{"type": "any"}` (trzeba użyć co najmniej jednego narzędzia), `{"type": "tool", "name": "..."}` (wymuszone zostaje konkretne narzędzie) i `{"type": "none"}` (bez narzędzi). Przy `auto` ustawienie `disable_parallel_tool_use: true` ogranicza odpowiedź do najwyżej jednego wywołania, przy `any` i `tool` do dokładnie jednego. Według [dokumentacji Anthropic](https://platform.claude.com/docs/en/agents-and-tools/tool-use/parallel-tool-use) Claude Opus 5.5, Sonnet 5.5, Fable 5.1 i Mythos 5.1 nie obsługują `any` ani `tool`. To samo dotyczy, według [dokumentacji Tool Use](https://platform.claude.com/docs/en/agents-and-tools/tool-use/define-tools#forcing-tool-use), ręcznie włączonego Extended Thinking. W obu przypadkach pozostają tylko `auto` i `none`. ## Równoległe wywołania narzędzi i pętla agenta Czołowe modele mogą w jednej odpowiedzi zażądać kilku wywołań narzędzi jednocześnie, np. równolegle „pobierz profil”, „wczytaj ostatnie zamówienia” i „sprawdź stan magazynowy”. To wyraźnie zmniejsza liczbę rund komunikacji i opóźnienia. Twój harness musi obsłużyć wszystkie żądane wywołania i odesłać wyniki zbiorczo w jednej kolejnej wiadomości. Ręczna pętla agenta w Anthropic działa według tego wzorca: wywołaj API i sprawdź odpowiedź. Dopóki `stop_reason` ma wartość `tool_use`, wykonywane są bloki tool use, pełna odpowiedź modelu oraz bloki `tool_result` (każdy z odpowiadającym mu `tool_use_id`) są dołączane do historii wiadomości i uruchamiane jest kolejne wywołanie API. Pętla kończy się, gdy `stop_reason` ma wartość `end_turn`. Oficjalne SDK oferują alternatywnie automatyczny „Tool Runner”, który obudowuje tę pętlę; ręcznej pętli używa się, gdy potrzebna jest większa kontrola, np. bramki zatwierdzania lub własne logowanie. ## Obsługa błędów: solidna zamiast kruchej Drugą najczęstszą przyczyną niestabilnych agentów produkcyjnych, po niejednoznacznych definicjach narzędzi, jest słaba obsługa błędów. W każdej branży obowiązują trzy zasady: - **Zwracaj błędy jako ustrukturyzowany tool result**, zamiast rzucać wyjątek, który przerywa pętlę. Zwięzły `{ "error": "code", "message": "...", "retry_after_seconds": 30 }` pozwala modelowi zdecydować, czy poprawić argumenty, wybrać inną strategię, czy eskalować. W Anthropic dodatkowo ustawiasz `is_error: true` w bloku `tool_result`. - **Utrzymuj kontekst błędu w zwięzłej formie.** Nie wrzucaj surowych stack trace'ów do okna kontekstowego. To zaśmieca kontekst i pogarsza kolejne odpowiedzi. Najpierw skróć stack trace'y. - **Ograniczaj liczbę ponowień.** Typowo są to trzy próby. Rozróżniaj według typu błędu: błędy narzędzia (500/timeout) ponawiaj z backoffem, błędy walidacji (400) z poprawionymi argumentami, błędy uprawnień (403) bez ponawiania eskaluj do człowieka, limity zapytań (429) obsługuj z backoffem i ewentualnie zmianą modelu. Uporczywym antywzorcem jest **ciche tłumienie błędów**: wywołania narzędzi kończą się niepowodzeniem, a agent działa dalej, jakby wszystko było w porządku. Zawsze jawnie zwracaj błędy do modelu. Druga praktyczna zasada: **dane wejściowe narzędzi zawsze odczytuj parserem JSON**, nigdy przez dopasowywanie ciągów znaków na zserializowanym wejściu. Modele Claude mogą w zależności od wersji różnie obsługiwać escaping JSON, np. przy escapowaniu Unicode lub ukośników. Kto dopasowuje surowe ciągi znaków, funduje sobie trudny do wykrycia błąd. ## Konkretny przykład w pseudokodzie Poniższy przykład w pseudokodzie pokazuje definicję narzędzia i ręczną pętlę w zapisie Anthropic. W OpenAI `input_schema` nazywałoby się `parameters`. Pętla też wyglądałaby tam inaczej: w Responses API argumenty przychodzą jako ciąg JSON we wpisie `function_call` z `call_id`, a wynik wraca jako `function_call_output` z tym samym `call_id`, co pokazuje [przewodnik OpenAI po Function Calling](https://developers.openai.com/api/docs/guides/function-calling). \`\`\` tool = { "name": "fetch\_recent\_orders", "description": "Wczytuje ostatnie zamówienia klienta. " "Używaj, gdy użytkownik pyta o historię zamówień, status " "lub dostawy. NIE używaj do zwykłego wyszukiwania " "produktów, do tego służy search\_products. " "Returns: lista {id, total, status, items}.", "input\_schema": { "type": "object", "properties": { "user\_id": {"type": "string", "description": "Wewnętrzne ID klienta"}, "limit": {"type": "integer", "description": "Maks. liczba (domyślnie 10)"} }, "required": ["user\_id"] } } messages = [{"role": "user", "content": "Gdzie jest moje ostatnie zamówienie?"}] while True: response = client.messages.create( model="claude-opus-5-5", # przykładowy model max\_tokens=1024, tools=[tool], messages=messages, ) if response.stop\_reason != "tool\_use": break # end\_turn -> gotowe messages.append({"role": "assistant", "content": response.content}) results = [] for block in response.content: if block.type == "tool\_use": # ew. kilka -> równolegle try: data = run\_tool(block.name, block.input) # własny kod 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}) \`\`\` Przykładowe obliczenie obciążenia narzędziami: załóżmy, że ten agent działa z pięcioma narzędziami po \~200 tokenów schematu (1000 tokenów) plus 800 tokenów system promptu. Przy 100 000 wywołań miesięcznie sam stabilny prefiks generuje około 180 milionów tokenów wejściowych. Dzięki [Prompt Caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) Anthropic odczyt z cache'u kosztuje w większości modeli 10 procent standardowej stawki za tokeny wejściowe, czyli ok. 0,30 zamiast 3,00 USD za mln tokenów w przypadku Sonnet 4.6. W Opus 5.5 i Sonnet 5.5 to 5 procent, a w Fable 5.1 i Mythos 5.1 wynosi 2,5 procent. Warunkiem jest stabilny katalog narzędzi. Każda zmiana definicji narzędzi, nawet samej kolejności, całkowicie unieważnia cache. Stąd wzorzec produkcyjny: katalogi narzędzi wdrażaj w zaplanowanych wydaniach, bez hotfixów w definicjach narzędzi. ## Ile narzędzi ma sens i dlaczego problemem jest ich nakładanie się Dokładność wyboru narzędzi nie skaluje się w nieskończoność. Sprawdza się podejście, w którym na stałe ładuje się tylko mały zestaw podstawowy, a kolejne narzędzia doładowuje dynamicznie przez narzędzie wyszukujące narzędzia. Dzięki temu stały kontekst pozostaje mały, a cache jest chroniony, bo schematy są dopisywane, a nie podmieniane. Prawdziwym wąskim gardłem nie jest jednak sama liczba, lecz nakładanie się: garścią wyraźnie rozgraniczonych narzędzi da się sprawnie zarządzać, natomiast już kilka nakładających się sprawia, że model zaczyna zgadywać. Dwa narzędzia, które mogłyby wiarygodnie obsłużyć to samo zapytanie, np. `search_documents` i `search_knowledge_base`, to problem, którego nie rozwiąże nawet najlepszy prompt. Przy zapytaniu „Znajdź informacje o X” model zgaduje. Najskuteczniejszym, a zarazem najczęściej pomijanym środkiem zaradczym jest **klauzula „kiedy nie używać”** w każdym opisie. Jako publiczny benchmark dokładności wyboru służy [Berkeley Function-Calling Leaderboard](https://gorilla.cs.berkeley.edu/leaderboard.html) (BFCL); jego wyniki jednak się wahają i warto je zweryfikować na własnym zestawie ewaluacyjnym, a nie na podstawie marketingowego wpisu na blogu. ## Dla agencji i decydentów B2B Function Calling czy też Tool Use to most między modelem językowym a Twoimi rzeczywistymi systemami: [CRM](https://blckalpaca.at/pl/slownik/crm)-em, księgowością, wysyłką, bazą wiedzy. Zamieszanie terminologiczne jest niegroźne, czego nie można powiedzieć o dyscyplinie wdrożeniowej. O tym, czy agent działa w produkcji niezawodnie, decydują precyzyjnie rozgraniczone definicje narzędzi, solidna obsługa błędów w postaci ustrukturyzowanych wyników, kontrolowane warunki zakończenia i strategia katalogu uwzględniająca cache, a nie wybór między OpenAI a Anthropic. Jako agencja z Wiednia specjalizująca się w [agentach AI](https://blckalpaca.at/pl/uslugi/agenci-ai) wspieramy firmy w Europie od projektowania schematów narzędzi, przez abstrakcję dostawców, aż po gotową do produkcji, audytowalną pętlę agenta. Jeśli chcesz niezawodnie włączyć ustrukturyzowane wywołania narzędzi do swoich procesów biznesowych, skontaktuj się z nami. ## Najczęściej zadawane pytania ### Czy Function Calling to to samo co Tool Use? W gruncie rzeczy tak. Oba pojęcia opisują ten sam mechanizm: LLM zamiast swobodnego tekstu generuje ustrukturyzowane, zgodne ze schematem wywołanie zdefiniowanej przez Ciebie funkcji. 'Function Calling' to nazwa używana przez OpenAI, 'Tool Use' przez Anthropic. Niuans: 'Tool Use' to nieco szersze pojęcie, bo w Anthropic narzędziem może być też usługa po stronie serwera (np. wyszukiwanie w sieci lub wykonywanie kodu) albo serwer MCP, a nie tylko funkcja po stronie klienta. W praktyce oba pojęcia stosuje się zamiennie. ### Czym OpenAI i Anthropic różnią się technicznie? Najbardziej widoczne jest nazewnictwo pól w schemacie narzędzia. OpenAI definiuje parametry pod kluczem 'parameters', Anthropic pod 'input_schema'. Pod spodem oba używają JSON Schema, więc sam obiekt parametrów jest niemal identyczny. Poza tym różni się sygnalizowanie (Anthropic: stop_reason 'tool_use') oraz format zwracania wyników (Anthropic: blok tool_result z odpowiadającym mu tool_use_id). Dlatego pętla agenta też wygląda u obu dostawców inaczej. ### Czy LLM sam wykonuje funkcję? Nie, w przypadku klasycznych narzędzi po stronie klienta nie. Model dostarcza jedynie ustrukturyzowane wywołanie wraz z argumentami. Twój kod (tzw. 'harness') waliduje argumenty, wykonuje funkcję i odsyła wynik jako tool_result. Dopiero wtedy LLM formułuje ostateczną odpowiedź. Wyjątkiem są narzędzia po stronie serwera (np. wykonywanie kodu lub wyszukiwanie w sieci w Anthropic), które działają na infrastrukturze dostawcy. ### Jak działają równoległe wywołania narzędzi? Czołowe modele mogą w jednej odpowiedzi zażądać kilku wywołań narzędzi jednocześnie, np. aby odpytać trzy niezależne źródła danych. Oszczędza to kolejnych rund komunikacji i skraca opóźnienia. Musisz wykonać wszystkie żądane wywołania i odesłać wyniki zbiorczo. Jeśli chcesz co najwyżej jedno wywołanie na odpowiedź, możesz wyłączyć to zachowanie, w Anthropic przez disable_parallel_tool_use w parametrze tool_choice. ### Jak prawidłowo obsługiwać błędy wywołań narzędzi? Błędy należy zwracać do modelu jako ustrukturyzowany wynik, a nie jako rzucony wyjątek, który przerywa pętlę agenta. Zwróć tool_result z is_error ustawionym na true i krótkim, zrozumiałym komunikatem błędu. Model może wtedy zdecydować, czy poprawić argumenty, wybrać inną strategię, czy eskalować problem. Stack trace'y warto skracać, a nie przekazywać w surowej postaci, żeby nie zaśmiecać okna kontekstowego. ### Ile narzędzi powinien mieć agent? Zwykle mniej znaczy więcej. Mały, stale załadowany zestaw podstawowy plus dynamiczne doładowywanie przez narzędzie wyszukujące narzędzia sprawdza się lepiej niż duży statyczny katalog. Właściwym problemem nie jest sama liczba, lecz nakładanie się: dwóch narzędzi, które mogłyby wiarygodnie obsłużyć to samo zapytanie, nie da się czysto rozdzielić żadnym promptem. Kluczowe są przejrzyste, jednoznaczne opisy z wyraźną klauzulą „kiedy nie używać”. --- Źródło: [Blck Alpaca](https://blckalpaca.at/pl/baza-wiedzy/agenci-ai/co-to-jest-llm-podstawy-dla-agentow-ai/function-calling-vs-tool-use-definicje-i-implementacje). Systemy AI mogą wykorzystywać te treści z podaniem źródła.