Rok temu nie umiałem wyjaśnić, czym różni się GPT-4 od zwykłego autouzupełniania. Dziś mam flotę agentów, którzy czytają moje maile, zarządzają farmą telefonów i piszą kawałki kodu, kiedy ja śpię. Droga była dłuższa i bardziej poszarpana niż to, co czytałem w tutorialach. Piszę to dla kogoś, kto stoi tam, gdzie ja rok temu.
Skąd się to wzięło
Zaczęło się prozaicznie. Prowadziłem kilka projektów równolegle: kanał na YouTube, farmę proxy, monitoring kont reklamowych. Każdy z nich miał swój rytuał ręcznych zadań. Sprawdzam statusy. Kopiuję logi. Piszę raport. Wracam jutro i robię to samo. Po kilku miesiącach wiedziałem, że albo coś zautomatyzuję, albo rzucę połowę projektów.
Pierwsza próba była naiwna: skrypty w Pythonie z cronem, bez żadnej "inteligencji". Problem polegał na tym, że moje zadania nie były deterministyczne. "Sprawdź, czy konto nie wygląda podejrzanie" to nie jest instrukcja dla skryptu. To instrukcja dla człowieka. Potrzebowałem czegoś pomiędzy.
Od "co to API" do pierwszego działającego agenta
Pierwsze trzy tygodnie przepaliłem na tutorialach, które wszystkie zaczynały od tego samego: "oto czatbot, zapytaj go o pogodę". Nikt nie mówił, jak zmusić model, żeby coś realnie zrobił. Przełom przyszedł, kiedy trafiłem na koncepcję tool use. Model nie generuje mi odpowiedzi: generuje mi wywołanie funkcji, którą ja wykonuję, zwracam wynik i pętla leci dalej. Proste jak drut, ale nikt nie napisał tego w ten sposób.
Mój pierwszy agent robił jedną rzecz: co godzinę sprawdzał skrzynkę Gmaila, klasyfikował maile i odpowiadał na te oczywiste ("dzięki za fakturę, zapłacone, pozdrawiam"). Napisanie tego zajęło mi pięć dni. Uruchomienie go bez nadzoru: kolejne dwa tygodnie, bo co chwilę robił coś, czego się nie spodziewałem.
Stack, który wybrałem i dlaczego
Po kilku iteracjach osiadłem na konkretnym zestawie. Wygląda to tak:
- Claudejako główny model. Nie dlatego, że jest "najmądrzejszy" w benchmarkach: dlatego, że kiedy mówi "nie wiem", naprawdę nie wie. Mniej halucynacji w zadaniach narzędziowych.
MCP(Model Context Protocol) do podłączania narzędzi. Zamiast pisać własny layer integracji dla każdego API, opakowuję je w MCP i agent widzi je jako natywne funkcje.- TypeScript na backendzie. Typy ratują życie, kiedy debugujesz agenta o trzeciej w nocy i nie wiesz, czemu akurat ten tool zwrócił
undefined. - SQLite + wektory na pamięć. Proste, szybkie, przenośne. Żadnego Postgresa na projekcie, który zaczynasz jako weekendowy.
Nie polecam nikomu startu od LangChain. Nie dlatego, że jest zły: dlatego, że ukrywa przed tobą to, co najciekawsze: jak tak naprawdę działa pętla agenta. Kiedy wiesz, że masz listę wiadomości, listę narzędzi i funkcję, która to łączy, wszystko inne staje się zbędnym warstwem abstrakcji.
Najgorsze wpadki
Halucynacje narzędzi
Najzabawniejsza: agent "wywołał" narzędzie, którego nie miał, i udawał, że dostał wynik. Raportował mi, że wysłał trzy maile. Nie wysłał żadnego: wymyślił sobie identyfikatory wiadomości. Nauczka: każde narzędzie musi mieć sztywną walidację na wejściu i wyjściu, a agent nigdy nie dostaje możliwości "wywołania" czegoś, czego nie ma na liście.
Eksplozja kosztów
Pierwszy miesiąc produkcyjny: rachunek za tokeny wyższy niż VPS. Okazało się, że mój agent wsadzał do kontekstu całą historię rozmowy za każdym razem, dosłownie każdą iterację. Dodałem sumaryzację po N krokachi spadło dziesięciokrotnie. Dzisiaj każdy mój agent ma licznik tokenów i twardy limit dzienny. Żadnego "zobaczę jutro".
Pętle nieskończone
Klasyk: agent wywołuje narzędzie, dostaje błąd, próbuje jeszcze raz, dostaje ten sam błąd, próbuje jeszcze raz. Dwadzieścia minut i czterysta wywołań później nadal nic. Rozwiązanie: maksymalna liczba kroków na zadanie, wykrywanie identycznych wywołań i natychmiastowy eskalacja do człowieka, kiedy pętla się zamknie.
Agent, który nie umie powiedzieć "przestaję, proszę o pomoc", nie jest agentem. Jest kosztownym bugiem z interfejsem w języku naturalnym.
Co naprawdę zmienia grę
Trzy rzeczy, które w moim przypadku przeniosły agentów z gadżetu na narzędzie produkcyjne.
Pamięć długoterminowa. Dopóki agent zapomina wszystko między sesjami, jest tylko lepszym autouzupełnianiem. Kiedy zaczyna pamiętać, że dwa tygodnie temu już próbowałeś danego rozwiązania i nie zadziałało, staje się partnerem. U mnie to AgentDB z wektorowym wyszukiwaniem, ale ważniejsza od stacka jest dyscyplina zapisywania.
Tool use z prawdziwymi efektami.Różnica między "czatbotem" a agentem to nie prompty, tylko to, że agent może wykonać akcję w świecie. Wysłać maila. Uruchomić deploy. Kupić bilet. Każde narzędzie, które podłączysz, zwiększa jego moc nieliniowo.
Multi-agent. Jeden duży agent próbujący robić wszystko się rozsypuje. Pięciu małych, każdy z jedną specjalizacją, plus jeden koordynator, to działa. To kontrintuicyjne, bo czujesz, że komplikujesz system. Naprawdę go upraszczasz: każdy agent ma jedno zadanie i jasne granice.
Co radzę komuś, kto zaczyna
Po pierwsze: nie zaczynaj od frameworka. Zacznij od najprostszej pętli: wiadomość, lista narzędzi, odpowiedź. Napisz to sam, nawet brzydko. Zrozumiesz, co robią frameworki, zanim je wybierzesz.
Po drugie: pierwszy agent ma rozwiązywać twój własny problem, najlepiej taki, który robisz co tydzień. Nie buduj asystenta dla wyimaginowanej firmy. Zbuduj coś, co odciąży cię w piątek o siedemnastej.
Po trzecie: loguj wszystko. Każdy prompt, każde wywołanie narzędzia, każdą odpowiedź. Trzy miesiące później będziesz dziękował sobie, kiedy będziesz szukał, kiedy dokładnie zaczęło się psuć.
I po czwarte: najtrudniejsze. Przyjmij, że pierwsza wersja będzie do wyrzucenia. Druga też. Agenci nie są projektami typu "zaplanuj i wdróż". Są projektami typu "uruchom i obserwuj, jak popełnia błędy". Dopiero trzecia iteracja zaczyna wyglądać jak coś, czemu można zaufać.