Function Calling vs. Tool Use: definicje i implementacje

Function Calling i Tool Use oznaczają w gruncie rzeczy tę samą zdolność: duży model językowy w określonym miejscu nie zwraca swobodnego tekstu, lecz ustrukturyzowane, zgodne ze schematem wywołanie zewnętrznie zdefiniowanej funkcji wraz z odpowiednimi argumentami. 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, a nie samej zasady działania.

Ten artykuł należy do klastra wokół artykułu filarowego „Podstawy LLM dla agentów” i rozwija to, co zasygnalizowano w powiązanym artykule o podstawach tool callingu. 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. „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 dla Tool Use. Według dokumentacji Anthropic 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.

W ujęciu 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. 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. 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 SDK), żeby ukryć różnice w nazwach pól.

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 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, 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.

```
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 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 (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-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 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.