Jak stworzyć agenta AI do inwestowania? Poradnik krok po kroku

Twórcy internetowi coraz częściej przedstawiają agentów AI jako narzędzia, które pomogą nam inwestować na giełdzie. W tym artykule wyjaśnimy, jak zbudować własnego agenta oraz rozprawimy się z największymi mitami dotyczącymi wykorzystania sztucznej inteligencji na rynku.

Czym jest agent AI do inwestowania?

Agent AI to po prostu program wykorzystujący sztuczną inteligencję (dziś najczęściej są to modele językowe), który samodzielnie lub półautomatycznie wykonuje określone przez nas zadania.

W ten sposób przykładowym agentem może być taki, który np. samodzielnie dobiera tematy postów na social media, pisze je i publikuje w określonych godzinach. Następnie analizuje liczbę polubień i komentarze, modyfikując strategię publikacji.

W finansach takim prostym agentem może być system do analizowania newsów giełdowych, a bardziej skomplikowanym – ten, który samodzielnie podejmuje decyzje inwestycyjne, będąc podpiętym pod rachunek maklerski.

W tym drugim przypadku cały system może zawierać np. moduł posiadający dostęp do rocznych raportów spółek ściąganych z bazy danych SEC, ten analizujący najświeższe newsy czy taki, który bada sentyment inwestorów, analizując tweety czy posty na Reddicie.

Agent AI vs bot tradingowy

Nie należy jednak mylić takiego systemu z tradycyjnym botem tradingowym.

Różnica między nimi jest gigantyczna i tyczy się przede wszystkim przewidywalności.

Podczas gdy przeciętny bot tradingowy jest zbiorem napisanych przez nas instrukcji typu “jeśli X, zrób Y” (np. w języku C++ czy Pythonie), system oparty na LLM-ie nie jest całkowicie przewidywalny.

Bot jest deterministycznym kodem, który możemy dowolnie modyfikować, a LLM to model statystyczny, który jako całość jest dla nas czarną skrzynką i dodatkowo dostaje pewną autonomię.

Jakie zadania może wykonywać inwestycyjny agent AI?

Spektrum zadań, które może wykonywać taki agent, jest bardzo szerokie i obejmuje:

To, że agent w teorii mógłby coś robić, nie oznacza jednak, że zawsze powinniśmy mu na to pozwolić.

I ta kwestia wymaga dłuższego wyjaśnienia, dlatego zanim przejdziemy do omówienia przykładu takiego agenta, musimy poświęcić chwilę na dekonstrukcję największego mitu związanego z tym tematem.

Największy mit na temat AI w inwestowaniu

Dzisiaj wielu twórców internetowych promuje agentów AI jako rozwiązanie problemu tradingu i inwestowania, które zwalnia człowieka z pracy i konieczności posiadania elementarnej wiedzy.

Przekonują oni, że wystarczy podpiąć LLM pod rachunek u brokera, a on zrobi resztę za nas. Ich filmy przedstawiają agentów, którzy m.in.:

• „Ulepszają” strategie tradingowe w pętli.
• Sami szukają strategii.
• Samodzielnie liczą wskaźniki techniczne (np. RSI czy MACD) i wysyłają nam sygnały tradingowe na Telegramie.

W praktyce jest to przerost formy nad treścią i zaprzęganie drogich LLM-ów do budowy czegoś, co można zbudować klasycznym kodem znacznie taniej, osiągając ten sam efekt.

„Samoulepszający się agent” w tym przypadku pisze prostą strategię w Pythonie, którą następnie dostraja do szumu rynkowego, a ten liczący wskaźniki techniczne nie oferuje żadnej wartości dodanej, jedynie wprowadzając ryzyko poważnej pomyłki (ze względu na „halucynacje” modelu językowego).

Takie materiały mogą być tworzone dla pieniędzy, z pełną świadomością ich bezwartościowości, w modelu biznesowym znanym z farm treści.

W ten sposób łatwo dać się oszukać, myśląc, że LLM jest tu nową technologią, która pozwala nam robić zupełnie nowe rzeczy (pokonać rynek), podczas gdy często jest to nowa technologia, dzięki której osoby niepotrafiące programować mogą wdrażać stare i w większości nieskuteczne strategie giełdowe. 

Innymi słowy – LLM demokratyzuje programowanie. Nie zarabianie na rynku.  

Obok błędów samych twórców modę na agentów AI na giełdzie napędzają antropomorfizacja modeli językowych (“skoro pisze jak człowiek, to pewnie i myśli jak człowiek, więc zarobi dla mnie pieniądze”) i zatarcie granic między trzema pojęciami: AI, uczeniem maszynowym i LLM-ami.

LLM jest częścią świata Machine Learningu i modelem, który nie został stworzony do pracy z danymi z giełdy oraz działa, generując działa, generując tekst token po tokenie na podstawie rozkładu prawdopodobieństwa kolejnych elementów wypowiedzi.

Taki model jest dla nas nieprzewidywalny: nie da się prześledzić jego „rozumowania” tak, jak czyta się kod, ani przewidzieć, jak zareaguje na dane, których wcześniej mu nie pokazaliśmy. Drobna zmiana w danych wejściowych może dać zupełnie inną odpowiedź, a w tradingu i inwestowaniu to gigantyczna wada.

Kolejny problem wiąże się z danymi, na których model został wytrenowany.

Zbiór treningowy może obejmować ogromne ilości tekstu, w tym m.in. treści dotyczące analizy fundamentalnej czy technicznej, a LLM, generując dla nas strategie, siłą rzeczy będzie opierał się na tej właśnie wiedzy.

Jeśli większość poradników inwestowania lub tradingu, które znajdują się w internecie, nie ma żadnej praktycznej wartości, AI doprowadzi tę “bezwartościowość” do perfekcji i będzie idealnie wprowadzać w życie coś, co nie ma sensu.

Overfitting

Problemem jest też sama giełda, która jest systemem zaszumionym i pełnym przypadkowych wahań.

Przy tym same algorytmy są podatne na wyciąganie ze zbioru danych treningowych “wzorców”, które w rzeczywistości są przypadkowymi ruchami. Algorytmy te dopasowują się do szumu w zbiorze, osiągając rekordowe zyski, jednak rozpadają się na świeżych danych, których nigdy wcześniej nie widziały (co nazywa się “overfittingiem”). 

Właśnie dlatego “samoulepszający się agent” z filmów na YouTube to zły pomysł.

Coś takiego nie ulepsza strategii, tylko – jak już mówiliśmy – dostraja parametry tak, aby strategia osiągała jak najlepsze wyniki na danych historycznych.

Budujemy w ten sposób system, który na pamięć uczy się rozwiązań zadań na teście. Gdy dostanie całkiem nowy test – po prostu go obleje.

Architektura agenta AI – jak to może działać?

Stąd prosty wniosek – jeśli jesteś traderem lub inwestorem i chcesz przetwarzać dane liczbowe, nie tekst, LLM prawdopodobnie nie jest Ci do niczego potrzebny. 

Spróbujemy więc wykorzystać możliwości językowe modelu Gemini od Google’a, budując prostego agenta AI do celów demonstracyjnych, który skorzysta z najłatwiej dostępnych, darmowych danych.

Model będzie pełnił tu funkcję researchera uzupełniającego podstawowe informacje, które wcześniej zgromadzimy klasycznie – za pomocą skryptów w Pythonie.

Nie chcemy, by zmyślał wyniki finansowe i tworzył na ich podstawie wprowadzające w błąd zestawienia. Lepiej będzie więc uczynić cały proces jak najbardziej mechanicznym, aby ograniczyć kompetencje modelu językowego do interpretacji materiałów prasowych dotyczących spółek i tworzenia własnej narracji.

Czyli wykorzystujemy LLM tylko tam, gdzie klasyczny kod nie ma zastosowania. 

Zaczniemy od filtrów fundamentalnych:

• Revenue Acceleration – wskaźnik pokazuje zmianę tempa wzrostu przychodów. Dodatnia wartość oznacza, że przychody rosną coraz szybciej, a ujemna – że dynamika wzrostu słabnie.
• Margin Expansion – wskaźnik pokazujący, czy marża zysku netto (zysk netto / przychody) rośnie – co oznacza, że z każdego dolara, który firma otrzymuje za produkt lub usługę, zachowuje ona dla siebie coraz większą część zysku.

Obok nich skorzystamy także z filtrów technicznych:

• ADR% – to Average Daily Range, pokazuje średni dzienny zakres wahań ceny wyrażony procentowo. W projekcie jest liczony na podstawie danych z ostatnich [liczba] sesji według wzoru [wzór wykorzystany w kodzie].
• Relative strength – wskaźnik porównuje zachowanie akcji spółki do indeksu S&P 500 na przestrzeni ostatniego kwartału. W ten sposób, jeśli szeroki rynek spada o 4%, a nasza spółka o zaledwie 0,5%, jest ona relatywnie silna względem rynku.
• 30-day return – zwrot, który spółka osiągnęła na giełdzie w ostatnim miesiącu.

W makroskali program będzie działał w prosty sposób:

Jak stworzyć agenta AI krok po kroku?

Teoretycznie nie musimy pisać takiego programu samodzielnie, ponieważ narzędzia do kodowania – takie jak Claude Code – są wystarczająco rozwinięte, aby zrobić to za nas.

W praktyce najlepiej będzie, jeśli sami umiemy programować w jakimkolwiek stopniu – tak, abyśmy w razie czego umieli samodzielnie modyfikować i debugować kod lub po prostu wydawać Claude’owi bardziej precyzyjne polecenia.

Bez tego praca w tych nieco bardziej skomplikowanych momentach będzie przypominać próby napisania spójnej powieści po chińsku, bez zrozumienia słowa w tym języku.

Przy czym w przypadku dużych projektów sam proces poprawy błędów z chatbotem paradoksalnie może być trudniejszy niż samodzielne nauczenie się danego zagadnienia z tutorialu.

Krok 1. Tworzenie bazy danych

Pierwszym krokiem będzie zbudowanie skryptu, który utworzy świeżą bazę danych z kolumnami zawierającymi:

• Ticker
• Revenue acceleration
• Margin expansion
• ADR
• 30-day return
• Relative strength

Kiedy zostanie wykonany, w folderze z naszym projektem pojawi się nowa, pusta baza danych o nazwie stocks.db, która w kolejnych krokach zostanie wypełniona wartościami wskaźników.

W architekturze agentów często korzysta się z techniki RAG (Retrieval Augmented Generation), która łączy LLM z systemem wyszukiwania informacji, dzięki któremu model może poszerzyć swoją wiedzę o zebrane przez nas dane.

Przy tak małym projekcie i tak niewielkiej liczbie informacji będzie ona jednak zbędna.

Krok 2. Pobranie tickerów z Wikipedii

Stworzona wcześniej baza potrzebuje tickerów interesujących nas spółek. Musimy więc ściągnąć je z tabeli dostępnej na Wikipedii.

W tym przypadku skorzystamy z listy wszystkich firm wchodzących w skład indeksu S&P SmallCap 600, obejmującego 600 spółek o małej kapitalizacji.

Do jej pobrania użyjemy bibliotek requests do wysyłania zapytań HTTP oraz BeautifulSoup – do tzw. scrapingu (czyli ekstrakcji danych ze stron internetowych).

Sam link do strony indeksu S&P umieścimy w pliku ze zmiennymi środowiskowymi – .env. Dzięki temu będziemy mogli szybko zmienić interesujący nas indeks np. na Nasdaq-100, podmieniając ten link.

Plik .env przyda się także później – przy połączeniu z modelem Gemini przez API.

Krok 3. Ekstrakcja danych fundamentalnych i technicznych

Dwa poprzednie kroki pozwoliły nam postawić bazę oraz pobrać z Wikipedii tickery, które zostaną w niej zapisane.

Pora na pobranie potrzebnych wskaźników fundamentalnych i technicznych, które ją wypełnią.

Skorzystamy tu z biblioteki yfinance, która pozwala na ściąganie danych spółek z bazy serwisu Yahoo Finance.

Trzeba zaznaczyć, że jest to źródło bardzo ograniczone, oferujące tylko kilka ostatnich odczytów interesujących nas wskaźników (co wyklucza rzetelną analizę fundamentalną), jednak jest darmowe, proste w obsłudze i wystarczy do zobrazowania przykładu (w systemach tego typu korzysta się z płatnych API, takich jak Financial Modeling Prep, albo pisze się własne skrypty do pobierania danych z API SEC).

Pierwszy plik, który tworzymy, czyli get_fundamentals.py, zawiera klasę z dwiema metodami (funkcjami): jedna liczy przyspieszenie przychodów, a druga – zwiększenie/zmniejszenie marży firmy.

Metody te pobierają dane historyczne, obliczają tempo zmian (lub marżę), a następnie wyznaczają wskaźnik „przyspieszenia” czy „ekspansji” jako średnią wyciągniętą z dwóch ostatnich zmian (w przypadku yfinance – są to zmiany rok do roku).

Drugi plik, get_technicals.py, robi coś podobnego, pracując jednak z surową ceną, z której wylicza ADR czy wynik osiągnięty przez spółkę w ostatnich 30 dniach.

Krok 4. Zapisywanie wskaźników do bazy danych

Na tym etapie mamy już pliki tworzące bazę danych, a także te pobierające dane fundamentalne oraz techniczne. Kolejny plik, save_to_db.py, importuje potrzebne funkcje z tych plików, a następnie kolejno je wywołuje, zapełniając potrzebnymi danymi puste wiersze w już istniejącej bazie.

Krok 5. Tworzenie rankingu

Kolejny plik, czyli rank_stocks.py, zostanie uruchomiony już przy gotowej bazie danych, zapełnionej tickerami i wskaźnikami dla każdego z nich.

Jego zadaniem jest stworzenie krótkiego rankingu spółek. Skrypt przeczesze bazę, szeregując spółki według wyników – od najlepszych do najgorszych, następnie przypisując każdej z nich jeden wynik („score”) według ważności każdego ze wskaźników.

W tym przypadku największą wagę ma ADR, co oznacza, że faworyzujemy bardziej zmienne spółki. Wagi te zostały dobrane arbitralnie, do celów demonstracyjnych (uwaga: dostrajanie takich wag do danych historycznych to prosta droga do wspomnianego wcześniej overfittingu).

Krok 6. Połączenie z modelem Gemini i pętla „kontroli jakości”

LLM wchodzi do gry dopiero na tym etapie.

W pliku ze zmiennymi środowiskowymi .env umieszczamy klucz API pod zmienną „GEMINI_API_KEY”, który pozwoli nam połączyć się z modelem Gemini od Google’a (klucz API możemy uzyskać w Google AI Studio).

Kolejnym krokiem jest stworzenie dwóch plików tekstowych: pliku prompt.txt zawierającego główny prompt (polecenie, które automatycznie wyślemy do naszego modelu) dla analityka oraz pliku prompt_control.txt z instrukcjami dla „kontrolera jakości”.

Następnie w pliku gemini_client.py tworzymy klienta, który odczyta klucz API z pliku .env oraz prompt, a następnie połączy się z modelem językowym, wysyłając do niego zapytanie, które przekaże do niego instrukcje wraz ze stworzonym wcześniej rankingiem spółek.

Dzięki temu model rozumie, że ma zrobić krótki research na temat spółek (prompt) oraz wie, których spółek ten research ma dotyczyć (ranking).

Domyślnie LLM nie ma dostępu do internetu, dlatego musimy też zezwolić mu na korzystanie z wyszukiwarki, dopisując do konfiguracji zmienną „tools”, która zawrze narzędzie wyszukiwania Google.

W pliku znajdą się także: funkcja wywołująca agenta odczytującego prompt_control.txt, który zajmie się sprawdzaniem zgodności informacji z raportu ze źródłami, funkcja koordynująca działanie obu agentów w pętli oraz ta, która generuje gotowy raport w formacie HTML i zapisuje go w folderze naszego projektu.

Krok 7. Uruchomienie całego programu

Ostatnim elementem będzie plik run.py, który uruchamia cały łańcuch skryptów – od utworzenia bazy aż po wygenerowanie gotowego raportu.

Jak widać na pierwszym fragmencie schematu powyżej, uruchomienie pliku run.py skutkuje inicjalizacją bazy danych. Następnie skrypt sprawdza, czy baza zawiera dane dla tickerów. Opisujemy pierwsze uruchomienie, więc przyjmujemy, że baza ich nie zawiera. 

Na kolejnym fragmencie widzimy, że przy pierwszym uruchomieniu program przechodzi do pobrania listy spółek z Wikipedii i zapisania ich wszystkich w bazie stocks.db, po czym pobiera dane fundamentalne dla zgromadzonych tickerów i także umieszcza je w bazie.

Kolejny krok to odczytanie danych z bazy przez funkcję rank_stocks(), która tworzy na ich podstawie ranking 5 najwyżej sklasyfikowanych spółek. Ranking ten zostaje przesłany do zasilanych LLM-em agentów AI.

Pierwszy z nich, czyli _generate_draft(), odbiera ranking i robi research dla spółek, korzystając z narzędzia Google Search. Jego wstępny raport odbiera agent _evaluate_draft(), który odczytuje umieszczone w nim źródła i sprawdza, czy przedstawione informacje są z nimi zgodne.

Jeśli któraś z informacji przedstawionych w raporcie nie pokrywa się z materiałami źródłowymi, agent wydaje werdykt negatywny, generuje sugestie poprawek i odsyła draft do poprawy.

Jeśli raport jest zgodny ze źródłami, generujemy gotowy plik w formacie HTML.

Jak widać, to, co jest w tym wszystkim najważniejsze (i co jest praktyką wykorzystywaną w realnych projektach), to jasny podział odpowiedzialności. LLM pojawia się dopiero tam, gdzie klasyczny kod nie wystarcza. 

Przykład użycia

Po uruchomieniu pliku run.py cały program się rozpoczyna, generując w linii komend logi w czasie wykonywania kolejnych kroków.

Cały proces trwa dobre kilka minut. Po jego zakończeniu system obwieszcza sukces, a w folderze, w którym znajduje się nasz projekt, widzimy nowy plik o nazwie raport.html. 

Gdy go otworzymy, zobaczymy zestawienie wraz z krótkim researchem dla każdej ze spółek z rankingu. 

Jak widać powyżej, bot zgodnie z instrukcjami przesłał nam linki źródłowe, dzięki czemu możemy samodzielnie przeczytać artykuły, pogłębiając research.

Koszty, ograniczenia i dodatkowe ryzyka

Ten podstawowy szkic można rozbudować o dodatkowe funkcje, jak rozbicie researchu na mniejsze etapy i stworzenie osobnych agentów do zbierania danych i pisania raportu czy dodanie skryptów pobierających z internetu newsy finansowe, które prześlemy agentom.

Zła wiadomość jest jednak taka, że przy dużej liczbie zapytań wysyłanych do API największych modeli językowych (jak Claude Opus 4.8) koszty korzystania z czegoś takiego mogą okazać się spore.

Dlatego projekt korzysta z tańszej alternatywy od Google’a, czyli Gemini 3.5 Flash, który na jeden utworzony raport potrzebował ok. 23,37 tys. tokenów wejściowych (input) i 32,77 tys. tokenów wyjściowych (output), kosztując kosztując w sumie około 0,33 USD, czyli około 1,25 zł według kursu z 22 lipca 2026 roku. 

Na pierwszy rzut oka to niewiele, jednak musimy pamiętać, że przedstawiony projekt jest ekstremalnie prosty, a rozbudowanie go np. o bardziej złożony research czy weryfikację treści to dodatkowe zapytania i kolejne koszty.

Jeśli planujemy stworzenie bardziej rozbudowanego projektu, który np. będzie monitorował rynek całą dobę, wysyłając nam powiadomienia, dojdą do tego koszty hostingu na serwerze VPS.

Największym z ograniczeń są jednak dane. 

Tutaj wykorzystano darmowe źródło w postaci Yahoo Finance, jednak korzysta się z niego tylko w szkicach MVP, podmieniając później na płatne alternatywy – takie jak wspomniany wcześniej Financial Modeling Prep.

Z kolei gdybyśmy chcieli rozbudować projekt o realną analizę sentymentu, domyślnym wyborem byłaby platforma X (niegdyś Twitter), której koszty API w przypadku hobbystycznych projektów od dawna są zaporowe. Inny popularny wybór, czyli Reddit, posiada mocno ograniczone API, które nie pozwoli nam np. na stworzenie pełnoprawnego wskaźnika sentymentu opartego na historycznych wpisach. 

Wartościowe dane z giełd niestety nie są darmowe i w przypadku domowej eksperymentacji cały ten biznes może okazać się po prostu nieopłacalny.

Kolejnym z ograniczeń, tym razem niezwiązanym z finansami, jest tzw. inżynieria cech (“Feature Engineering”). 

Przedstawiony kod dla uproszczenia zakładał, że każdy z wykorzystanych wskaźników dodawał do obrazu coś nowego. W realnym projekcie nie dobieramy tych wskaźników “na oko”, ale wybieramy grupę potencjalnych cech i mierzymy ich korelacje ze sobą, co pozwala odfiltrować i odrzucić te, które korelują z innymi w wysokim stopniu, nie dając nam nowych informacji.

Ostatnim problemem jest wymienione na początku tekstu nadmierne zaufanie do modeli językowych.

Model zawsze powinien udostępniać źródła, na których się opierał, tak, abyśmy mogli się upewnić, że nie zmyślił przytoczonych danych. Nade wszystko jednak nie powinien generować strategii, które bez zastanowienia wdrożymy, czy samodzielnie handlować na realnym koncie. 

To wciąż tylko model statystyczny o specyficznym zakresie przeznaczenia, do którego giełda przeważnie w ogóle nie należy.

Co gorsza, ten model z każdym kolejnym zapytaniem działa jak upiększające rzeczywistość lustro. Jeśli stanie przed nim ktoś, kto wie, co robi, model poszerzy jego istniejące już możliwości. Jeśli jednak stanie tam ktoś, kto po raz pierwszy styka się z tematem giełdy, ten sam model może zracjonalizować najbardziej absurdalne pomysły, opakowując je w zdania, które brzmią mądrze. 

A więc czy w ogóle warto próbować budować takie systemy?

Jeśli ciekawi nas automatyzacja i chcemy, jak powyżej, szybciej znaleźć listę instrumentów do głębszej analizy, odpowiedź brzmi: “jak najbardziej”. Ale jeśli liczymy na to, że model językowy wygeneruje dla nas gotową, działającą strategię lub rozbije bank, kupując akcje za pośrednictwem brokera, po prostu szkoda naszego czasu.