Mentionsy

To znaczy nie po prostu długie zdanie napisane, jak ktoś chce, tylko tak, jakbyśmy wołali na przykład funkcję.

W sensie jest to cecha API, czyli to jest warstwa, która leży gdzieś pomiędzy LLM-em, a pomiędzy tym klientem.

Czyli na przykład, jeżeli chcielibyśmy mieć dostęp do Google Drive'a, przykładowo, no to nie musimy implementować tego przez własne API, nie musimy się łączyć, nie musimy bibliotek ściągać, nic nie musimy, bo ktoś to już napisał.

Cały ten obiekt może być niczym innym jak payloadem zapytania API do np.

Możemy się o tym przekonać uruchamiając kolejny skrypt, w przypadku którego widzimy serię logów prowadzących nas do powstania nowego pliku, w którym zostały zapisane informacje na temat naszego zadania.

Widzimy w nim zapytanie http do API OpenAI, w przypadku którego po prostu przesyłamy treść wiadomości użytkownika oraz odbieramy odpowiedź.

Możemy jednak przełączyć tutaj tryb w auto i wówczas model będzie zachowywał się normalnie w normalnej konwersacji, ale jeżeli użytkownik napisze coś co wygląda jak prośba o dodanie zadania,

do zewnętrznego API.

Akt trzeci napisał taki komentarz.

co jest odpowiedzialne za przyjęcie tych danych wygenerowanych przez model oraz fizyczne połączenie już z API danej usługi i zwrócenie odpowiedzi.

My nie wiemy, kiedy on wywoła funkcję, my nie wiemy, czy on wywoła funkcję, nie wiemy z jakimi parametrami, bo to zależy trochę od LLM-a, ale jeśli ta funkcja zostanie delegowana, to wiemy, jak się zakończy, bo to jest funkcja napisana przez nas, w sensie raczej tam nie będzie jakichś magicznych sytuacji, że coś nie pójdzie zgodnie z planem, więc bardziej sterujemy, jak te funkcje wywoływać, naprowadzamy tego LLM-a tak, żeby trafił w to, co chcemy, używał wtedy, kiedy chcemy,

Zobaczmy teraz jak w praktyce wygląda działanie narzędzia, które pozwala w tym przypadku agentowi AI zarządzać linearem, uwzględniając przy tym dostęp do praktycznie dowolnej funkcji tego systemu, oczywiście o ile jest dostępna w API.

Przykładowo raz dziennie system może wysłać sam do siebie prośbę o to, aby zapoznać się z wpisami dostępnymi w Linearze, a następnie przygotować raport HTML na podstawie szablonu, który został zapisany w moim Obsidianie.

Najlepsze w tym jednak jest to, że jeżeli chciałbym wprowadzić zmiany do tego dziennego raportu, to mógłbym po prostu otworzyć mojego Obsidiana i zapisać tutaj dodatkowy punkt o na przykład kolejnej sekcji, która miałaby uwzględniać moje zdarzenia w kalendarzu.

Natomiast nie do końca, ponieważ jak projektujecie systemy, czy posługujecie się modelem językowym w kodzie aplikacji, to często dochodzi do sytuacji, w której właśnie ta logika, to co wcześniej mówiłem, że logika wykonania, logika, którą potrzebujemy do tego, żeby połączyć się z zewnętrznym API, musi być wykorzystana w wielu miejscach.

Niech model napisze sobie kodzik, niech ten kodzik wykona.

No właśnie, one są jeszcze na poziomie beta i zarówno pricing i techniki korzystania, wykorzystywania modeli, czy w ogóle podejścia do kształtowania takich narzędzi, one są w tej chwili jeszcze na relatywnie początkowym etapie.

Ale jeżeli bym go poprosił, na przykład dodaj mi wydarzenie do kalendarza, no to teraz on musi wiedzieć, jak się z tym połączyć, musi mieć jakiś klucz API być może, jakoś odpowiednio to zaprogramować.

Gdy nawet ogólnie spojrzymy na dostępną tutaj listę narzędzi, od razu widzimy, że jest ona znacznie krótsza niż lista akcji dostępna w API Lineara.

znacznie różnią się od tego, co oferuje API.

Powodem jest fakt, że API zostało stworzone z myślą o programistach, którzy dysponują dokumentacją, natomiast dostępne tutaj narzędzia muszą być zoptymalizowane pod kątem dużego modelu językowego oraz uwzględnienia faktu, że kontekst dokumentacji jest tutaj zwykle niedostępny.

Decyzja o tym musi być maksymalnie uproszczona, dlatego zamiast wystawiać wszystkie dostępne endpointy API,

Po prostu nie widzę powodu, aby ją dodawać ze względu na to, że w moim przypadku tworzenie zespołów występuje tylko i wyłącznie na etapie początkowej konfiguracji Lineara, a potem jest niepotrzebne.

No bo do zwykłego odnalezienia danego wpisu nie jest mi potrzebny komplet informacji na jego temat, a taki właśnie komplet zwykle otrzymujemy z API.

Niezbędne na takim etapie okazują się wyłącznie nazwy oraz identyfikatory, natomiast później model może wczytać dodatkowe informacje na temat tego wpisu.

Jednocześnie też mam nadzieję, że bardzo wyraźnie widać tą różnicę pomiędzy tym, co oferuje API, a co oferuje tak zoptymalizowany pod duże modele językowe interfejs.

Widać tutaj jak wiele różnych akcji oferuje API udostępniane przez Lineara oraz to jak przynajmniej część z tych akcji albo wyeliminowałem albo ze sobą połączyłem.

Są to w przypadku API dwie dodatkowe akcje, które agent musiałby podjąć.

Różnica pomiędzy API a własnymi narzędziami jest jeszcze bardziej widoczna w momencie gdy przejdziemy do definicji schematów czy też obiektów żądania.

W przypadku API będziemy mieć do dyspozycji wszystkie dostępne endpointy oraz akcje, a także wszystkie związane z nimi pola.

A w związku z tym, że powiedzieliśmy sobie, że przynajmniej z części akcji nie będziemy korzystać, to posiadanie ich na etapie obiektu żądania po prostu nie ma sensu i niepotrzebnie zwiększa złożoność.

Gdyby tego było mało, to w odpowiedzi ze strony API zwykle otrzymujemy generyczną informację, taką jak np.

Mianowicie, jeżeli spojrzymy sobie tutaj chociażby na format odpowiedzi API zawierający listę wyszukiwanych rekordów,

Zatem myślę, że na tym etapie przeszliśmy nie tyle co przez zestaw zasad, którymi kieruje się przy tworzeniu narzędzi,

Co prawda na pewnym etapie może okazać się, że duże modele językowe rozwiną się tak bardzo, że te wszystkie uproszczenia, które tutaj budujemy nie będą już potrzebne.

No i oczywiście, jeżeli już jesteś agentem piątym i chcesz czapeczkę, to napisz na kontakt małpa aidevs.pl albo aidevs małpa bravecourses i oczywiście taką czapeczkę dostaniesz.

Gdybyśmy natomiast zaprojektowali jakieś nawędzie, które nie jest takim 1 do 1 odbiciem API, tylko dalibyśmy mu na przykład prostą funkcję typu dodaj coś, to on by ją po prostu wywołał i wtedy jest szansa, że zakończyłoby się to na jednym kroku, dwóch krokach maksymalnie.

Dodatkowo, jeżeli albo jak ktoś myśli o łączeniu LLM z zewnętrznymi narzędziami, zwykle myśli o mapowaniu API.

Bo jest szansa, że można faktycznie przyoszczędzić, napisać to starym dobrym kodem.

No tak, tutaj jest kwestia formatu odpowiedzi z danego narzędzia, czyli właśnie po raz kolejny widzimy, jaka jest różnica w API.

W API zwraca nam na przykład status sukces albo identyfikator zmodyfikowanego czy utworzonego rekordu albo jakieś inne podstawowe informacje.

wymaga od agenta odpytywania API czy ta grafika została już wygenerowana.

będziemy przygotowywać API, będzie wsparcie dla multimodalności, będzie zarządzanie kontekstem, będzie pamięć długoterminowa.

Tak samo jeżeli wy chcielibyście go wdrożyć, to oczywiście w zależności od skali tam w dokumentacji jest zapisane, co ewentualnie można zmienić.

Natomiast taki serwer uwzględnia na przykład limity API,

Czyli jeżeli programujecie, potraficie, posługiwacie się API, to znowu są minimalne kompetencje, które potrzebujecie posiadać.

Innymi słowy, dążymy do tego, że na przykład wiele agentów ma zarówno swoje workspace, gdzie są w stanie na przykład zapisywać notatki, jakieś informacje z danej sesji, ale są w stanie również współdzielić te informacje między sobą.

to co pokazałem w kontekście raportu wysyłanego rozdzielnie, to po pierwsze ja mogę sobie wejść do Obsidiana, czyli zwykłego pliku tekstowego i zapisać nowe notatki i wiem, że od jutra to zostanie zaaplikowane.

I raczej jesteśmy jeszcze na etapie, w którym rzeczywiście ten czas i złożoność realizacji zadań w przypadku agentów rzeczywiście został pochnięty do przodu.

Także widzicie, są różne podejścia do różnych problemów i weszliśmy w taki, ja bym powiedział, trochę nowy obszar projektowania systemów, wykorzystując duże modele językowe, gdzie rzeczywiście jesteśmy już znacznie dalej poza tymi zwykłymi apikolami, czy prowadzeniem, czy budowaniem chatbotów, tylko rzeczywiście ta logika, o której mówię, ona też w ogóle...

Teraz ja to mogę sobie przeredagować, ja mogę tam coś zmienić, dodać, usunąć albo napisać totalnie od nowa.

Teraz widzą, że te narzędzia mają pewne możliwości i teraz twierdzą, że ich programiści dokładnie te same możliwości zaimplementują teraz na poziomie API.

Albo drag and dropem wrzuca jakiś tam plik i ten plik jest tam parsowany, pisze się fragment kodu Pythona, no to LLM napisze ten fragment kodu Pythona, a potem go wykona w sandboxie, nie?

Przykładowo w poprzedniej edycji mieliśmy sytuację napisania agenta, który chodzi po stronie internetowej i zbiera informacje.

Natomiast jak zaczniecie korzystać z tego MCP w codzienności, to zobaczycie, że część akcji jest niedostępna, część akcji jest źle zaimplementowana, a na przykład po części API zaczyna zwracać błędy, bo na przykład w wyniku podjęcia zbyt dużej liczby interakcji jest limit API.

No tak, z perspektywy osoby, która pierwszy raz spotyka się z API, z JSON-em, czy nie wiem, z bazami danych albo z czymkolwiek, to rzeczywiście to jest czarna magia, nie?

No mamy taką zasadę, że mamy dwa tygodnie testowe, to znaczy w momencie jak się ktoś z Was zapisze, zapłaci tam za wstęp, to od momentu, nie zapłaty, ale od momentu startu szkolenia macie dwa tygodnie na to, żeby podjąć decyzję, czy idziecie z nami dalej, czy też nie.

Natomiast same frameworki mają też to do siebie, że być może napiszę w ogóle o tym newsletter, bo to jest w ogóle fajny temat, jeżeli chodzi o frameworki.

Natomiast w skrócie narzucanie warstwy abstrakcji na koncepcję budowania agentów na tym etapie, gdy tak mało osób w ogóle

wie jak do tego podejść i w jakich sytuacjach agenci mogą być stosowani, po prostu nie ma sensu i jeszcze na etapie prototypu, na etapie jakiejś weryfikacji być może to ma sens.

Bardzo się cieszę, że Null Undefined napisałeś, że przekonało cię, że to jest podejście, gdzie będziemy robić produkcję, to jest coś ważnego.

Też dlatego, że nie muszę przeskakiwać, żonglować kluczami API.

Czyli nie poruszamy się po tych najmocniejszych modelach, tylko poruszamy się na etapie optymalizacji.

po stronie kodu, po stronie sprawdzania samej logiki zapisanej w kodzie, ale stosuję też zestawy danych, które są wykorzystywane po to, żeby sprawdzić, jak na przykład dany model posługuje się konkretnym narzędziem, czyli izoluję sobie problem i na przykład mam zestaw danych do narzędzia do zarządzania kalendarzem.

Mateusz napisał, ostatnie zadania rozkminiałem na porodowce z telefonu, więc żona była obok.

Jak już jesteście agentem piątym w kolejnej edycji, napiszcie do północy, dostaniecie też tapeczkę.

I większość API, z którymi mieliśmy do czynienia, ma ten problem, że w momencie wysyłania serii zapytań część z nich zaczyna być nienaturalnie długa w odpowiedzi.

Przypominam, że dzisiaj jeszcze do końca dnia, jeżeli już jesteście z nami agentem piątym, napiszcie.