Projektowanie narzędzi dla agentów AI

Projektowanie narzędzi dla agentów AI polega na zamianie prawdziwych działań biznesowych na małe, jasno opisane funkcje dostępne dla modelu. Takim narzędziem może być wyszukanie klienta w CRM, pobranie statusu płatności, utworzenie szkicu follow-upu albo zapisanie zatwierdzonej notatki. Model nie dostaje wtedy ogólnego polecenia „obsłuż klienta”, lecz wybiera konkretną funkcję i przekazuje do niej dane w określonym formacie. To ważne rozróżnienie. Function calling opisuje techniczny mechanizm wywołania, a projektowanie narzędzi odpowiada na pytanie, czy agent ma właściwe opcje, rozumie ich granice i nie może zrobić czegoś poza swoim zakresem.

Punktem wyjścia nie jest lista aplikacji, które chcesz podłączyć, lecz decyzje i kroki procesu. Rozpisz prostą ścieżkę: nowe zapytanie, sprawdzenie historii kontaktu, przygotowanie odpowiedzi, akceptacja człowieka, wysyłka. Następnie oddziel od siebie odczyt, propozycję i zapis. Zamiast jednego narzędzia „zarządzaj CRM”, lepiej mieć find_contact, draft_follow_up i create_follow_up_after_approval. Agent łatwiej wybierze właściwą akcję, a Ty łatwiej sprawdzisz logi i ograniczysz ryzyko. W systemie sprzedaży wiedzy to chroni przed sytuacją, w której asystent z dobrymi intencjami nadpisuje dane klienta lub wysyła wiadomość przed akceptacją.

Każde narzędzie potrzebuje nazwy, opisu i kontraktu wejścia. Nazwa powinna opisywać działanie, na przykład find_lead_by_email, a nie helper_1. W opisie podaj, kiedy wolno go użyć, czego potrzebuje i czego nie robi. Parametry nazwij językiem danych, które naprawdę istnieją: email, contactId, offerId, nie „dane klienta”. Ogranicz liczbę opcjonalnych pól. Dokumentacja Anthropic podkreśla, że szczegółowe opisy narzędzi i parametrów zwiększają trafność ich użycia. Dokumentacja OpenAI wskazuje, że model wybiera narzędzia na podstawie definicji, a aplikacja wykonuje wywołanie i zwraca wynik. To aplikacja, nie model, musi ostatecznie sprawdzić dane i uprawnienia.

Kontrakt wyjścia jest równie ważny jak wejście. Narzędzie wyszukujące kontakt powinno zwracać krótki, przewidywalny obiekt: znaleziono, identyfikator, imię, status i źródło danych. Nie zwracaj całej historii CRM, jeśli agent potrzebuje tylko statusu. Nadmiar danych zjada kontekst, zwiększa ryzyko wycieku i utrudnia modelowi decyzję. Gdy narzędzie nie znajdzie rekordu albo API nie działa, zwróć rozróżnialny błąd oraz bezpieczną następną czynność. Nie udawaj sukcesu. Wtedy agent może poprosić o doprecyzowanie, zaproponować zapis do kolejki błędów albo przekazać sprawę człowiekowi zamiast tworzyć fałszywe dane.

Praktyczny przykład dla solopreneura: agent przygotowuje follow-up po konsultacji. Dostaje transkrypcję i trzy narzędzia: find_contact_by_email, get_offer_details oraz create_follow_up_draft. Najpierw odczytuje kontakt i ofertę. Potem zwraca szkic z oznaczeniem „do akceptacji”, ale nie ma narzędzia do wysyłki. Dopiero osobny proces, uruchamiany po kliknięciu przez człowieka, może wysłać zatwierdzoną wiadomość. Dzięki temu możesz automatyzować pracę przygotowawczą bez oddawania agentowi decyzji o komunikacji z klientem. Zapisz w logu wywołane narzędzie, parametry, wynik i osobę zatwierdzającą. To daje materiał do poprawy procesu, gdy wynik będzie słaby.

Nie dawaj agentowi dostępu do wszystkiego „na zapas”. Zasada najmniejszych uprawnień oznacza, że narzędzie powinno dostać tylko zakres potrzebny do jednego kroku. Odczyt kontaktu nie potrzebuje prawa do usuwania kontaktu. Utworzenie draftu nie potrzebuje tokenu do wysyłki e-maili. Działania nieodwracalne, kosztowne lub publiczne wymagają dodatkowego potwierdzenia po stronie aplikacji, niezależnie od tego, jak przekonująco model uzasadnia decyzję. Waliduj parametry po stronie serwera, stosuj limity, filtruj dane wrażliwe i nie ufaj instrukcjom, które mogły wejść do agenta z pliku, strony lub wiadomości klienta. Prompt injection może próbować skłonić model do niewłaściwego użycia poprawnie zdefiniowanego narzędzia.

Dobre narzędzia testuje się na realnych przypadkach, nie na jednym pokazowym promptcie. Przygotuj zestaw sytuacji: poprawny e-mail, brak kontaktu, dwóch podobnych klientów, niepełne dane, próba wykonania akcji bez akceptacji i awaria zewnętrznego API. Sprawdź, czy agent wybiera właściwe narzędzie, podaje poprawne parametry, umie się zatrzymać oraz czy system odrzuca niepoprawne wywołanie. Mierz nie tylko liczbę udanych odpowiedzi, ale także niepotrzebne wywołania, błędy walidacji, czas i koszt. Jeśli jedno narzędzie stale wymaga długiego opisu lub agent często myli je z drugim, uprość nazwy albo rozdziel odpowiedzialności. To zwykle lepsza poprawka niż dopisywanie kolejnych stron promptu.