Wyjaśnienie wywoływania narzędzi: jak modele proszą oprogramowanie o działanie i gdzie dochodzi do awarii.
Praktyczny przewodnik po wywoływaniu funkcji i używaniu narzędzi: pętla żądań, schematy, narzędzia do odczytu w porównaniu z narzędziami do działania, agenci, MCP, iniekcja promptów, śledzenie oraz częste błędy.
Źródła: Function Calling and Tool Use: How AI Agents Automate Workflows
Pierwotne chatboty były maszynami do odpowiadania na pytania. Osoba wpisywała coś, otrzymywała odpowiedź i na tym kończyła się wymiana informacji. Były przydatne, ale ograniczone. Model mógł opisać, jak zarezerwować lot, nie mogąc jednak sprawdzić dzisiejszych cen. Mógł wyjaśnić, co znajduje się na fakturze, ale nigdy nie mógł stworzyć jej w systemie rozliczeniowym. Mógł zaproponować godzinę spotkania, ale nadal nie miał możliwości sprawdzenia kalendarza kogokolwiek, nie mówiąc już o dodaniu wydarzenia do niego.
Wywoływanie funkcji usuwa tę barierę. Model językowy uzyskuje możliwość proszenia otaczającego go oprogramowania o pomoc, a reszta struktury rozwija się na bazie tej jednej umiejętności.
Model, który potrafi o coś prosić
Bez narzędzi model odpowiada na podstawie tego, co przyswoił podczas szkolenia. Z ich pomocą może stwierdzić, że pytanie wymaga pomocy z zewnątrz, i wskazać, które narzędzie powinno ją dostarczyć: usługa pogodowa, indeks wyszukiwania, zapytanie do bazy danych, kalkulator, kalendarz, proces płatności, wyszukiwanie w CRM, interpreter kodu lub jakaś wewnętrzna funkcja biznesowa. Zamiast zgadywać, model wysyła ustrukturyzowane żądanie, aplikacja je realizuje, a model kontynuuje pracę, mając do dyspozycji świeższe i dokładniejsze informacje. Wielcy dostawcy, takie jak OpenAI, Anthropic i Google, wraz z frameworkami takimi jak LangChain, opisują używanie narzędzi w ten sam ogólny sposób: modelowi oferuje się dobrze zdefiniowane narzędzia, on decyduje, kiedy je wywołać, przekazuje ustrukturyzowane argumenty i włącza uzyskane wyniki do swojej odpowiedzi lub działania.
Praktyczny obraz mentalny: model to mózg w rozmowie, a narzędzia to ręce, oczy, pamięć, kalkulator, szuflada na dokumenty oraz furgonetka dostawcza. Mózg określa, czego chce użytkownik. Narzędzia wykonują zadania, których generowanie surowego tekstu nie może wykonać w sposób bezpieczny lub niezawodny.
Wywoływanie funkcji versus wywoływanie narzędzi
Te dwa wyrażenia są używane zamiennie, przy czym drugie jest dokładniejsze, ponieważ koncepcja ta wykracza poza klasyczne funkcje programistyczne. Narzędzie może być tak proste jak get_weather(location). Może to równie dobrze być wyszukiwanie w bazie danych, sesja przeglądarki, odzyskiwanie dokumentów, kalkulator, polecenie w shellu, proces projektowy lub link do zewnętrznej usługi. W słowniku OpenAI narzędzie to możliwość udostępniona modelowi, a wywołanie narzędzia to specjalny rodzaj odpowiedzi modelu proszący o użycie jednego z nich.
Kluczowe jest to, że model zazwyczaj sam nic nie uruchamia. W typowym rozwiązaniu po stronie klienta zwraca ustrukturyzowaną prośbę, coś w rodzaju wywołania funkcji get_customer_profile z identyfikatorem klienta 12345. Aplikacja ją otrzymuje, sprawdza ją, wykonywa rzeczywistą funkcję, zbiera wynik i zwraca go modelowi, który następnie pisze swoją ostateczną odpowiedź. Dokumentowana sekwencja jest następująca: dostarczenie dostępnych narzędzi, otrzymanie wywołania narzędzia, uruchomienie kodu w własnej aplikacji, wysłanie wyniku oraz otrzymanie albo ostatecznej odpowiedzi, albo dalszych wywołań narzędzi.
Istnieją wyjątki. Niektórzy dostawcy hostują również narzędzia po stronie serwera, które działają na ich infrastrukturze. Anthropic wyraźnie rozdziela te dwa rodzaje narzędzi: narzędzia po stronie klienta są wykonywane przez twoją aplikację i przedstawiane jako ustrukturyzowane bloki używania narzędzi, natomiast narzędzia serwerowe, takie jak wyszukiwanie w internecie czy wykonywanie kodu, mogą działać po stronie Anthropic.
Różnica ta ma znaczenie. Stwierdzenie „model wywołał API” może oznaczać, że model wygenerował żądanie do wykonania przez twoje oprogramowanie, albo że platforma uruchomiła wbudowany narzędzie w imieniu modelu. W środowisku produkcyjnym zmienia to poziom bezpieczeństwa, logowanie, koszty, sposób obsługi danych, osoby upoważnione do decyzji oraz te, które są odpowiedzialne w przypadku wystąpienia problemów.
Pętla w pięciu krokach
Większość systemów wywołujących funkcje powtarza jeden cykl.
- Określ narzędzia. Każde narzędzie otrzymuje nazwę, opis oraz listę oczekiwanych danych wejściowych. Narzędzie do sprawdzania pogody może wymagać nazwy miasta i kraju. Narzędzie do zwrotu pieniędzy może potrzebować numeru zamówienia, powodu oraz maksymalnej kwoty. Narzędzie do planowania może wymagać informacji o uczestnikach, dacie, godzinie i temacie. Przykłady od OpenAI opisują parametry w stylu JSON Schema, z polami obowiązkowymi oraz ograniczeniami, takimi jak ustawienie additionalProperties na false, natomiast dokumentacja Google Gemini pokazuje deklaracje funkcji skonstruowane na podstawie nazw, opisów i struktur danych wejściowych.
- Użytkownik prosi o coś. Model czyta prośbę i ocenia, czy może na nią od razu odpowiedzieć. Zapytanie „Wyjaśnij, czym jest wywołanie funkcji” prawdopodobnie nie wymaga żadnego narzędzia. Zapytanie „Jaki jest status zamówienia 8472?” niemal na pewno takie narzędzie potrzebuje.
Cykl może zostać uruchomiony raz lub powtórzyć się wiele razy. Agent może przeszukiwać, porównywać wyniki, wywoływać inne narzędzia, zadawać dodatkowe pytania, aktualizować dane i na koniec podsumować to, co zrobił.
Język jako interfejs
Prawdziwą zaletą używania narzędzi jest to, że codzienny język staje się elastycznym interfejsem użytkownika dla oprogramowania.
Tradycyjnie każda funkcja wymaga własnych przycisków, formularzy, menu i procedur. Dzięki wywoływaniu funkcji użytkownik może bezpośrednio określić swój zamiar: znaleźć najnowszy rachunek od Acme, sprawdzić, czy wpłata nadeszła, a jeśli nie, napisać uprzejmy e-mail z przypomnieniem. Jedno zdanie kryje za sobą kilka narzędzi: wyszukiwanie w CRM, pobieranie rachunku, sprawdzanie stanu płatności, tworzenie projektu e-maila, a być może także prośbę o zatwierdzenie przed wysłaniem czegokolwiek.
Dobry projekt produktu nie jest rzeczą opcjonalną. Zmienia się jedynie to, gdzie zaczyna się interfejs. Zamiast zmuszać ludzi do nauki struktury oprogramowania, to oprogramowanie dostosowuje się do sposobu, w jaki ludzie już rozmawiają o swojej pracy.
To nakłada duży nacisk na opisy narzędzi. Niejasny opis sprawia, że model nie wie, jak używać narzędzia. Jasny opis wskazuje, kiedy go używać, co robi, co oznaczają poszczególne dane wejściowe oraz czego nie należy zakładać. Dokumentacja LangChain przedstawia narzędzia jako funkcje z dobrze określonymi danymi wejściowymi i wyjściowymi, zaznaczając, że wskazówki typowe i krótkie opisy pomagają modelowi prawidłowo nimi korzystać.
Dobre narzędzie to coś więcej niż funkcja – to umowa.
Cztery terminy, które się pokrywają
Ludzie mylą te pojęcia, chociaż należą one do różnych poziomów.
- Wywoływanie funkcji to mechanizm: model prosi o zorganizowane wywołanie funkcji lub narzędzia.
- Używanie narzędzi to szersza możliwość. Obejmuje ono wywoływanie funkcji, wbudowane narzędzia, wyszukiwanie w internecie, wyszukiwanie plików, wykonywanie kodu, sterowanie komputerem, serwery zdalne oraz wszelkie inne sposoby, za pomocą których model może łączyć się z zewnętrznymi systemami.
- Agent to system, który łączy różne formy używania narzędzi w kilku krokach w celu osiągnięcia celu. OpenAI opisuje agenty jako aplikacje, które planują działania, używają narzędzi, współpracują z specjalistami i śledzą postępy w zadaaniach wieloetapowych, a jego Agents SDK definiuje agenta jako LLM skonfigurowany z instrukcjami, narzędziami oraz opcjonalnymi elementami, takimi jak przekazywanie zadań, ograniczenia i zorganizowane wyniki.
Innymi słowy: wywoływanie funkcji to gniazdko, narzędzia to urządzenia podłączone do niego, pracownicy decydują, jak i kiedy je używać, a automatyzacja sprawia, że całość funkcjonuje jako część żywego systemu.
Dlaczego się tym przejmować?
Modele językowe doskonale radzą sobie z rozumieniem, łączeniem i przekazywaniem informacji. Są jednak słabymi zamiennikami kalkulatorów, baz danych czy systemów monitoringu w czasie rzeczywistym. Mogą pisać o pogodzie, ale nie mogą znać dzisiejszej prognozy, chyba że są połączone z danymi pogodowymi. Mogą omawiać faktury, ale nie mogą uzyskać dostępu do twojego systemu rozliczeniowego, jeśli ten nie jest podłączony. Mogą wyjaśniać kod, ale nie mogą stwierdzić, czy twoja usługa jest niedostępna, bez danych z monitoringu.
Narzędzia wypełniają te luki. Kalkulator zapewnia dokładne obliczenia. Narzędzia wyszukiwania dostarczają aktualnych faktów. Narzędzia do wyszukiwania informacji opierają odpowiedzi na dokumentach prywatnych. Narzędzia do zarządzania bazami danych odpowiadają na pytania dotyczące danych firmy. Narzędzia do zarządzania procesami biznesowymi tworzą zgłoszenia, wysyłają wiadomości, aktualizują zamówienia lub umawiają spotkania. Dokumentacja Gemini od Google sprowadza korzyści tych narzędzi do trzech: dodawanie wiedzy, rozszerzanie możliwości oraz działanie poprzez zewnętrzne systemy.
To jest moment, w którym doświadczenie przestaje przypominać rozmowę i zaczyna przypominać oprogramowanie. Model nie tylko wytwarza słowa; pomaga również koordynować prace.
Badania stojące za tą ideą
Agenty używające narzędzi nie pojawiły się znikąd. Kształtowanie tego obszaru przyczyniły się cztery wcześniejsze badania.
- MRKL Systems (2022) zaproponował modułową architekturę łączącą modele językowe z zewnętrznymi modułami wiedzy i rozumowania. Podstawowa myśl była prosta: nie proście jednego modelu, aby robił wszystko; przyporządkujcie każde zadanie specjalistycznemu komponentowi.
- ReAct (2022) badał, w jaki sposób modele mogą łączyć rozumowanie z działaniem. Zamiast myśleć wyłącznie lub działać wyłącznie, technika promptingu w stylu ReAct sprawia, że model najpierw rozumuje, następnie działa, obserwuje wynik i koryguje swój plan. Ten cykl poprawia wyniki w zadaniami związanych z odpowiadaniem na pytania i podejmowaniem decyzji, a także ułatwia zrozumienie zachowania modelu.
- Toolformer (2023) sprawdzał, czy model może nauczyć się samodzielnie używać narzędzi za pomocą prostych API. Nauczył się, kiedy narzędzie jest potrzebne, co wysłać oraz jak wykorzystać uzyskany wynik, przykładami były kalkulatory, silniki wyszukiwania, tłumacze i kalendarze.
- Gorilla (2023) skupił się na masowych wywołaniach API oraz praktycznych problemach: przy dostępności wielu narzędzi modele czasami wymyślają niepotrzebne wywołania lub podają błędne argumenty. Gorilla połączył proces szkolenia z mechanizmem wyszukiwania, dzięki czemu system mógł śledzić zmiany w dokumentacji API i popełniać mniej błędów.
Wszystko to sprowadza się do jednej idei: najlepsze systemy AI to nie izolowane modele. Są one częściami większych systemów połączonych z narzędziami, pamięcią, regułami, oprogramowaniem oraz nadzorem ludzkim.
Jak wygląda dobre narzędzie
Narzędzia o wysokiej jakości są precyzyjne, zrozumiałe i bezpieczne.
Narzędzia precyzyjne są łatwiejsze do wyboru przez modele oraz do kontrolowania przez programistów. Narzędzie o nazwie update_everything jest niejasne i niebezpieczne. create_refund_request jest jaśniejsze. approve_refund wymaga jeszcze większej ostrożności, ponieważ wpływa na rzeczywisty świat.
Zrozumiałe narzędzia mają proste nazwy i opisy. Model nie powinien zgadywać, czy funkcja fetch_record oznacza pobranie profilu klienta, pobranie pliku czy odzyskanie dokumentacji medycznej. Opis powinien określać jego przeznaczenie, sytuacje, w których jest potrzebny, znaczenie każdego argumentu oraz format wartości zwracanej.
Bezpieczne narzędzia mają wbudowane ograniczenia. Sprawdzają uprawnienia, walidują dane wejściowe i unikają przyznawania dostępu, którego nie jest potrzeba. Podają jasne komunikaty o błędach, prowadzą rejestrację działań i wymagają ludzkiej aprobaty przed wykonywaniem działań wrażliwych. Nigdy nie przyznają modelowi większych uprawnień, niż są wymagane do wykonania zadania.
OpenAI zaleca ścisłe schematy, aby argumenty docierały w sposób niezawodny, a jego Agents SDK skierowuje programistów ku zasadom bezpieczeństwa, ludzkiej weryfikacji, jasnym wynikom, zarządzaniu stanem oraz możliwościom monitorowania w miarę rozwoju procesów pracy. W praktyce najlepsze narzędzia są nudne: każde z nich dobrze wykonuje jedną funkcję i nie zaskakuje nikogo – ani programistów, ani modeli, ani użytkowników.
Schematy jako gramatyka
Schemat to gramatyka używania narzędzi. Gdy model wywołuje funkcję, musi dostarczyć argumenty w formie zrozumiałej dla aplikacji. Schemat określa, jakie pola istnieją, jakie są ich typy, które są obowiązkowe, a czasami także jakie wartości są dozwolone. Narzędzie do prognoz pogody może wymagać pola z lokalizacją w formie ciągu znaków oraz pola z jednostkami ograniczonymi do stopni Celsjusza lub Fahrenheita.
Ścisłe schematy eliminują niejednoznaczność i upraszczają weryfikację. Dokumentacja OpenAI wyjaśnia, że tryb ścisły zapewnia, iż wywołania są zgodne z deklarowanym schematem, wymagając między innymi ustawienia additionalProperties na false dla każdego pola oznaczonego jako wymagane oraz używania typów nullable do reprezentowania wartości opcjonalnych.
Schemat jednak nie czyni systemu bezpiecznym. Proszę o idealnie sformatowaną, ale nadal błędną treść. Wywołanie send_email skierowane na adres all_customers@example.com może w pełni spełniać wymogi schematu, a mimo to być okropnym pomysłem. Dlatego weryfikacja schematu musi iść w parze z regułami biznesowymi, autoryzacją, ograniczeniami szybkości, procedurami sprawdzania oraz monitorowaniem.
Czytanie versus działanie
Jedną z ważnych decyzji projektowych jest określenie, czy narzędzie będzie jedynie czytać, czy też będzie podejmować działania.
Narzędzia tylko do odczytu pozyskują informacje: wyszukiwanie dokumentów, sprawdzanie rekordów, kontrola zapasów, pobieranie danych pogodowych, obliczanie sum, analiza dzienników. Nadal mogą ujawniać dane wrażliwe i wymagają kontroli dostępu, ale zazwyczaj nic nie zmieniają.
Narzędzia działające służą do realizacji zadań. Wysyłają e-maile, składają zamówienia, anulują subskrypcje, wypłacają zwroty, aktualizują bazy danych, otwierają zgłoszenia, wdrażają kod lub planują spotkania. Błędy przy ich użyciu mają rzeczywiste konsekwencje.
Dobrze zaprojektowany agent traktuje te dwa rodzaje narzędzi inaczej. Narzędzia tylko do odczytu można używać swobodniej, choć nadal pod kontrolą uprawnień. Narzędzia działające wymagają zazwyczaj bardziej ścisłej kontroli: ekranów potwierdzenia, kroków zatwierdzania, ograniczeń transakcyjnych, dzienników audytowych, opcji cofania zmian oraz jasnych komunikatów dla użytkownika.
W tym momencie automatyzacja staje się kwestią zarządzania, a nie tylko techniczną. Problem nie polega na tym, czy model może wywołać funkcję, lecz na tym, pod jakimi warunkami jakikolwiek system powinien mieć możliwość wykonywania działań w imieniu osoby.
Od pojedynczych wywołań do agentów
Jedno wywołanie narzędzia może odpowiedzieć na proste pytanie. Agenci służą do realizacji bardziej złożonych i skomplikowanych zadań. Gdy ma się przygotować cotygodniowy podsumowanie sprzedaży i zaznaczyć konta wymagające uwagi, agent może musieć pobrać dane sprzedażowe, porównać je z danymi z poprzednich tygodni, zidentyfikować nietypowe wzorce, przeczytać notatki z CRM, napisać podsumowanie i wysłać je menedżerowi. To łańcuch decyzji, a nie pojedyncze wywołanie.
Ramy agentów zarządzają całym procesem. Przechowują stan, uruchamiają narzędzia, próbują ponownie kroki, które zawiodły, przekazują zadania między specjalistycznymi agentami, wytwarzają ustrukturyzowane wyniki, egzekwują zasady bezpieczeństwa i przechowują ślady działań. Dokumentacja SDK Agents firmy OpenAI opisuje dwa powszechne wzorce: wzorzec menedżera, w którym centralny agent wywołuje specjalistyczne agenty tak, jakby były to narzędzia, oraz mechanizmy przekazywania kontroli, w których jeden agent przenosi kontrolę na specjalistę.
Są potężne, to prawda, ale nie należy ich idealizować. Agent to nie mały pracownik działający wewnątrz twojego oprogramowania. To system probabilistyczny zbudowany z kodu, który wymaga określonych obowiązków, ograniczonych uprawnień, przypadków testowych, monitoringu, ścieżek eskalacji oraz planów na sytuacje awaryjne. Im większą swobodę ma agent, tym bardziej staranne musi być jego projektowanie.
Gdzie automatyzacja spotyka się z rzeczywistą pracą
Automatyzacja to etap, w którym używanie narzędzi przekształca się w operacje.
- Zespół wsparcia może wykorzystać pracownika do klasyfikacji zgłoszeń, pobierania odpowiednich dokumentów politycznych, opracowywania odpowiedzi oraz proponowania dalszych kroków.
- Zespół finansowy może rozrachowywać faktury, znajdować brakujące zamówienia i przygotowywać raporty o wyjątkach.
- Zespół inżynieryjny może badać nieudane testy, przeglądać logi, proponować naprawy oraz otwierać prośby o połączenie kodu.
- Zespół sprzedaży może uzupełniać informacje o potencjalnych klientach, przygotowywać notatki z rozmów i aktualizować system CRM.
Najskuteczniejsza automatyzacja nie zaczyna się od tego, co potrafi model – zaczyna się od istniejącego procesu pracy. Gdzie zaczyna się praca? Jakie informacje są potrzebne? Które decyzje są rutynowe, a które wrażliwe? Gdzie obecnie ludzie sprawdzają, zatwierdzają lub korygują? Które błędy byłyby irytujące, a które kosztowne?
Mając te odpowiedzi pod ręką, narzędzia pomagają sprawić, by proces przebiegał płynniej. Pracownik zbiera fakty, wypełnia formularze, opracowuje wiadomości, porównuje dane i składa rekomendacje, podczas gdy ludzie są zaangażowani tam, gdzie ważne są osąd, odpowiedzialność lub zaufanie.
Standaryzowane połączenia
Pierwotne integracje były projektowane indywidualnie. Każda aplikacja miała swój własny sposób prezentacji narzędzi, zasobów, poleceń i mechanizmów autoryzacji. To sprawdzało się w małych projektach, ale stawało się niepraktyczne, gdy organizacje łączyły coraz więcej modeli z coraz większą liczbą systemów.
Model Context Protocol (MCP) to jedna z prób standaryzacji tej warstwy. Jego specyfikacja opisuje, w jaki sposób aplikacje mogą dzielić się kontekstem, udostępniać narzędzia i funkcje oraz tworzyć elastyczne integracje poprzez układ hosta, klienta i serwera. Serwery MCP mogą oferować zasoby, polecenia i narzędzia. Protokół wymienia wiadomości w formacie JSON-RPC 2.0 i obejmuje negocjację możliwości, śledzenie postępów, anulowanie, rejestrację działań oraz raportowanie błędów.
Zalety są oczywiste: wspólna warstwa narzędzi umożliwia aplikacjom AI spójne łączenie się z źródłami danych i procesami pracy, dzięki czemu każda firma nie musi ponownie budować każdej integracji. Wadą jest natomiast nowe ryzyko. Serwer narzędzi oferujący potężne funkcje powinien być traktowany przez aplikację hostującą jako rzeczywista granica bezpieczeństwa, a nie jako kolejny plugin. Specyfikacja MCP podkreśla konieczność uzyskiwania zgody użytkownika, ochrony prywatności danych, bezpieczeństwa narzędzi oraz ostrożności przy dostępie do danych i wykonywaniu kodu.
Bезpieczeństwo jest najważniejsze
Agenty wykorzystujące narzędzia są cenne, ponieważ mogą podejmować działania, ale ta sama zdolność niesie ze sobą ryzyko.
Iniekcja promptu to najbardziej znana zagrożenie: wrogie instrukcje ukryte w danych wprowadzanych przez użytkownika lub w zewnętrznej treści, które zmuszają model do zachowań, których powinien unikać. OWASP zalicza ją do największych ryzyk dla aplikacji opartych na modelach językowych, a jej materiały z 2025 roku wskazują również na nadmierne uprawnienia, gdy system oparty na modelu językowym ma większą moc działania, niż jest to rozsądne, co może prowadzić do nieoczekiwanych, niejednoznacznych lub sfałszowanych wyników, a tym samym do szkodliwych działań.
Indirektna iniekcja najbardziej martwi osoby pracujące z agentami. Załóżmy, że agent czyta e-maile i może wysyłać odpowiedzi. Złośliwy nadawca mógłby ukryć w wiadomości instrukcję nakazującą mu zignorowanie własnych zasad i przekazanie kontaktów użytkownika. Użytkownik może nigdy nie zobaczyć tej instrukcji, ale model ją mimo to przetworzy. Jeśli system jest zbyt ufny i ma zbyt szerokie uprawnienia, wiadomość wyglądająca niewinnie może stać się źródłem rzeczywistych działań.
Zespoły ds. bezpieczeństwa zaczynają postrzegać modele językowe jako systemy, które można oszukać już samym sformułowaniem zapytania, a nie tylko dzięki błędom w kodzie. Brytyjskie Narodowe Centrum Bezpieczeństwa Cybernetycznego wskazuje, że iniekcja promptów różni się od iniekcji SQL tym, że modele językowe nie zachowują ścisłej granicy pomiędzy instrukcjami a danymi niezaufanymi.
Odpowiednią strategią jest wielowarstwowa ochrona:
- Ograniczaj uprawnienia narzędzi w maksymalnym stopniu.
- Trzymaj narzędzia do czytania oddzielnie od narzędzi do pisania.
- Wymagaj zatwierdzenia przed wykonywaniem działań wrażliwych.
- Traktuj wszystko, co zostanie pobraane – czy to strony internetowe, e-maile, dokumenty czy pola bazy danych – jako niezaufane.
- Sprawdzaj każdy argument narzędzia i oczyszczaj wyniki przed przekazaniem ich innym systemom.
- Używaj list dopuszczalnych wartości, rejestruj każde wezwanie narzędzia i obserwuj nieprawidłową aktywność.
- Testuj narzędzia przy użyciu przykładów adwersarialnych oraz twórz sposoby na cofnięcie działań, jeśli to możliwe.
Przekaż agencie tylko tyle uprawnień, ile faktycznie wymaga proces pracy.
Przeglądanie działań agenta
Oprogramowanie oparte na agencjach wymaga jeszcze bardziej rozbudowanych rekordów niż zwykłe oprogramowanie, ponieważ jedna sesja może obejmować rozumowanie modelu, wywołania narzędzi, przekazywanie zadań, sprawdzanie ograniczeń, próby ponowne oraz ostateczny wynik. Śledzenie pozwala programistom prześledzić całą ścieżkę od żądania do rezultatu. Zgodnie z dokumentacją dotyczącą śledzenia w SDK Agents firmy OpenAI, ślady mogą rejestrować generowanie treści przez modele językowe, wywołania narzędzi, przekazywanie zadań, ograniczenia oraz własne zdarzenia, co pomaga zespołom w debugowaniu, wizualizacji i monitorowaniu procesów pracy w fazie rozwoju i produkcji.
To ma znaczenie zarówno dla jakości, jak i bezpieczeństwa. Gdy agent podaje błędną odpowiedź, trzeba znaleźć przyczynę. Czy wybrał niewłaściwy narzędzie? Czy narzędzie zwróciło przestarzałe dane? Czy model błędnie odczytał opis? Czy zawiodła mechanizm ochronna? Czy użytkownik nie miał uprawnień? Czy agent zatrzymał się zbyt wcześnie? Bez żadnych śladów zespoły muszą zgadywać. Dzięki dobrej możliwości obserwacji budowa agentów staje się prawdziwą praktyką inżynieryjną.
Jak te systemy zazwyczaj zawodzą
Zawodności są przewidywalne. Po stronie modelu może on wybrać niewłaściwe narzędzie, gdy nazwy lub opisy są niejasne, wysłać niekompletne lub błędne argumenty, wezwać narzędzie wtedy, gdy powinien zadać pytanie wyjaśniające, lub pominąć wezwanie, gdy potrzebne są aktualne dane. Może też wywoływać narzędzia zbyt często, co zwiększa koszty i opóźnienia, utknąć w pętli powtarzających się wezwań bez postępów lub zaufać wynikom narzędzia bardziej, niż na to zasługuje.
Aplikacja również może zawieść. Może przyjmować argumenty dostarczone przez model bez weryfikacji, jednocześnie udostępniać zbyt wiele narzędzi, zwracać ogromne i chaotyczne wyniki, które mylą model, pochłaniać przydatne komunikaty o błędach, błędnie przypisywać wyniki do zapytań, które je wygenerowały, lub nie posiadać rejestrów audytowych, ograniczeń szybkości oraz mechanizmów zatwierdzania.
Drobne modyfikacje promptów rzadko rozwiązują te problemy. Rozwiązaniem jest lepszy projekt narzędzi, jaśniejsze schematy, bardziej restrykcyjne uprawnienia, lepsze zarządzanie stanem, intensywniejsze testowanie oraz lepszy monitoring.
Kiedy pominąć narzędzia
Wywoływanie funkcji nie zawsze jest konieczne. Jeśli zadanie wymaga jedynie wyjaśnienia, użycie narzędzia dodaje skomplikowań. Jeśli potrzebne informacje są już zawarte w instrukcji i się nie zmieniają, nie ma co ich pobierać. W przypadku działań o wysokim ryzyku, których nie można bezpiecznie zweryfikować ani odwrócić, pełna automatyzacja może okazać się złym wyborem. A jeśli wynik działania narzędzia jest niepewny, nieudokumentowany lub niesecure, podłączenie go do agenta pogłębia problemy.
Doświadczenie użytkownika również ma swoją cenę. Wywoływanie narzędzi powoduje opóźnienia, prośby o uprawnienia przerywają przepływ pracy, a złożone agenty mogą być trudne do przewidzenia. Czasami zwykła forma jest lepsza od procesu czatowego, szczególnie gdy użytkownicy wiedzą, czego chcą, i potrzebują szybkości, spójności lub zgodności z regulacjami.
Celem nie jest uczynienie wszystkiego zautomatyzowanym. Używaj narzędzia tylko wtedy, gdy język, kontekst i działanie rzeczywiście się ze sobą łączą.
Habity do skutecznego budowania
Zacznij od niewielkiej liczby jednoznacznych narzędzi i stopniowo rozszerzaj dostęp do modelu. Wybieraj specyficzne funkcje o prostych nazwach. Pisz opisy modelu nie tylko dla inżynierów. Tam, gdzie to możliwe, stosuj ścisłe schematy i zawsze waliduj dane we własnym kodzie. Zachowuj krótkie wyniki i przekazuj modelowi tylko to, czego faktycznie potrzebuje.
Ustal uprawnienia dla każdego narzędzia osobno. Pracownik obsługi klienta, który może sprawdzić status zamówienia, nie musi automatycznie wydawać zwrotów pieniędzy. Asystent planowania może potrzebować informacji o dostępności w kalendarzu, ale nie notatek o prywatnych wydarzeniach. Asystent programistyczny powinien móc czytać repozytorium na długo przed tym, jak będzie mógł wysyłać prośby o integrację.
Wymagaj, aby osoba odpowiedzialna za podjęcie decyzji zaaprobowała wszystko, co jest wrażliwe, kosztowne, publiczne, prawnie wiążące, finansowe lub trudne do cofnięcia, i ujmij prośbę w sposób konkretny, aby osoba sprawdzająca dokładnie wiedziała, co ma nastąpić.
Literatura pokrewna
- Wykorzystanie narzędzi produkcyjnych przez agenty: pochodzenie danych, próby ponowne i możliwość obserwacji — Agent banku nawiązał nieautoryzowane połączenie z płatną API i wymyślił numer telefonu. Dowiedz się o minimalnych zestawach narzędzi, pochodzeniu parametrów, trójkrotnych próbach ponownych oraz metrykach dla poszczególnych narzędzi.
- Zdjęcia pamięci agenta, umiejętności, proces degradacji danych i zakres pamięci dla poszczególnych gałęzi — Cztery ulepszenia warstwy pamięci opartej na wektorowym bazie danych do programowania agentów: przenośne zdjęcia pamięci z możliwością łączenia, aktywacja umiejętności, proces degradacji z kontrolą konfliktów oraz pamięć ograniczona do konkretnej gałęzi.