Tool calling: jak agent AI wywołuje narzędzia zewnętrzne

Bez tool calling model językowy potrafi tylko jedno: tworzyć tekst na podstawie tekstu. Nie może ani sprawdzić aktualnej bazy danych, ani wysłać wiadomości, ani wyzwolić działania w zewnętrznym oprogramowaniu. Tool calling to most łączący model z systemem zewnętrznym. To on zmienia model, który tylko rozmawia, w agenta AI zdolnego do działania, podstawowy element każdego autonomicznego agenta.

Definicja szczegółowa

Tool calling, nazywane też function calling, oznacza zdolność modelu językowego do odpowiadania na zapytanie nie wyłącznie tekstem, lecz ustrukturyzowanym żądaniem wykonania konkretnej funkcji, z argumentami wypełnionymi według wcześniej zdefiniowanego schematu. Dokumentacja Anthropic opisuje tę zasadę tak: model określa, czy powinien wywołać narzędzie, na podstawie zapytania i opisu narzędzia, a następnie zwraca ustrukturyzowane wywołanie, które aplikacja wykonuje (po stronie klienta) lub które wykonuje sam dostawca (po stronie serwera, w przypadku niektórych wbudowanych narzędzi). Dokumentacja OpenAI, która spopularyzowała termin function calling w 2023 roku, opisuje identyczny mechanizm: model odpowiada wywołaniem funkcji czytelnym dla maszyny, a nie swobodnym tekstem, a wykonanie pozostaje po stronie aplikacji.

Obaj referencyjni dostawcy zgadzają się co do definicji: funkcja jest opisana nazwą, opisem w języku naturalnym oraz schematem JSON wymieniającym oczekiwane parametry. Model opiera się wyłącznie na tych trzech elementach, aby zdecydować, czy wywołać narzędzie i jak wypełnić jego argumenty. Między obydwoma podejściami nie ma znaczących różnic w tej podstawowej zasadzie; różnice dotyczą szczegółów implementacji (formatów wywołań równoległych, narzędzi dostarczanych natywnie przez dostawcę, obsługi błędów).

Tool calling to element, który odróżnia zwykły chatbot od systemu zdolnego działać na rzeczywistym świecie: sprawdzać bazę danych, szukać w sieci, zapisywać w pliku, wysyłać wiadomość, wyzwalać płatność. To też podstawowy element umożliwiający protokół MCP, pomyślany, by standaryzować sposób opisywania i udostępniania narzędzi modelowi.

Jak to działa

Przebieg wywołania narzędzia zawsze przebiega według tego samego, wieloetapowego schematu. Najpierw aplikacja definiuje listę narzędzi dostępnych dla modelu, każde z nazwą, opisem i schematem argumentów. Następnie model otrzymuje zapytanie użytkownika wraz z tą listą narzędzi i decyduje, w zależności od kontekstu, czy odpowiedzieć bezpośrednio tekstem, czy zażądać wykonania narzędzia.

Jeśli zdecyduje się wywołać narzędzie, model zwraca ustrukturyzowaną odpowiedź zawierającą nazwę narzędzia i wartości jego argumentów, nie wykonując przy tym niczego samodzielnie. To aplikacja otrzymuje to żądanie, faktycznie wykonuje działanie (wywołuje API, odczytuje bazę, zapisuje plik), a następnie zwraca wynik modelowi w formie, którą ten może odczytać. Model kontynuuje wtedy odpowiedź, opierając się na tym wyniku, i może wykonać kolejne wywołania narzędzi, jeśli zadanie tego wymaga.

Ten podział ma znaczenie dla bezpieczeństwa: model nigdy sam nie uruchamia kodu, jedynie proponuje wywołanie. To aplikacja zachowuje kontrolę nad tym, co faktycznie się wykonuje, i może odmówić wywołania, jeśli warunki nie są spełnione.

Konkretny przykład z Atako

W Atako tool calling jest sednem działania agenta. Każda podłączona integracja (Slack, Notion, GitHub, HubSpot i około czterdziestu innych) udostępnia zestaw konkretnych działań, jak post_message w Slack czy create_issue w GitHub, które agent może wywołać, gdy uzna, że zadanie tego wymaga.

W Atako jednak wywołanie narzędzia nigdy nie wykonuje się bezpośrednio. Najpierw przechodzi przez kontrolę uprawnień: platforma sprawdza, czy istnieje „grant” dla tego agenta i tego konkretnego połączenia, czy żądane działanie faktycznie znajduje się na liście działań dozwolonych w tym grancie, oraz czy przyznany zakres (tylko odczyt lub odczyt i zapis) obejmuje dane działanie. Jeśli którykolwiek z tych warunków nie jest spełniony, wywołanie zostaje odrzucone, a odmowa zarejestrowana. Ta ścieżka decyzyjna, agent proponujący wywołanie, a następnie platforma weryfikująca przed wykonaniem, to dokładnie logika bezpieczeństwa, którą umożliwia tool calling: model proponuje, infrastruktura decyduje.

Częste błędy

Częstym błędem jest przekonanie, że to model sam wykonuje wywoływane narzędzie. Tak nigdy nie jest: model tworzy ustrukturyzowane żądanie, a to zawsze aplikacja lub platforma faktycznie wykonuje działanie i może w dowolnym momencie odmówić.

Drugi błąd: myślenie, że danie modelowi dostępu do narzędzia równa się pełnemu i nieograniczonemu dostępowi do tej usługi. Dobrze zaprojektowany system tool calling precyzyjnie ogranicza dostępne działania, z uprawnieniami dla każdego działania i zakresu, zamiast ogólnego dostępu „wszystko albo nic”.

Trzeci błąd: niedocenianie znaczenia opisu narzędzia. Model dysponuje jedynie nazwą, opisem i schematem argumentów, aby zdecydować, kiedy i jak wywołać narzędzie. Niejasny lub dwuznaczny opis prowadzi do źle dobranych wywołań lub błędnych argumentów, nawet przy wydajnym modelu.

Wreszcie niektórzy mylą tool calling z MCP. Tool calling to podstawowy mechanizm, obecny od 2023 roku u dużych dostawców modeli. MCP to nowszy protokół, który standaryzuje sposób opisywania i łączenia narzędzi z modelem, aby uniknąć budowania od nowa innej integracji dla każdego narzędzia i każdego dostawcy.