J.A.R.V.I.S PROJECT

01ETAP

Lokalny mózg

Jednym z głównych założeń od początku było uruchomienie możliwie dużej części systemu lokalnie.

Najprostszym rozwiązaniem byłoby podpięcie mocnego modelu przez API i wysyłanie każdego zadania do chmury. Tyle że przy kilku agentach pracujących regularnie oznacza to kolejne koszty i uzależnienie całego systemu od zewnętrznych usług.

Dlatego pierwszym mózgiem JARVIS-a został Qwen uruchomiony lokalnie przez Ollamę. Pierwsza architektura była banalnie prosta. I wtedy szybko pojawiło się pierwsze pytanie:

Co z tego, że AI potrafi mi odpowiedzieć, skoro nie potrafi niczego zrobić?

02ETAP

JARVIS dostaje ręce

Zacząłem więc podpinać narzędzia. Dostęp do plików, katalogów, aplikacji, procesów, terminala czy przeglądarki sprawił, że model przestał być wyłącznie chatbotem. Mógł dostać zadanie i wykonać konkretną operację na komputerze.

Jednocześnie nie chciałem dawać modelowi pełnej kontroli bez żadnych ograniczeń. Powstał więc Policy Engine i system zatwierdzania bardziej ryzykownych operacji.

To był moment, w którym JARVIS zaczął faktycznie przypominać agenta, a nie interfejs do modelu językowego.

03ETAP

Pamięć

Kolejnym problemem okazała się pamięć. Jeżeli powiedziałem:

> Wejdź do tego katalogu.

a chwilę później:

> Skopiuj stamtąd zdjęcia.

agent powinien wiedzieć, czym jest „stamtąd”. Do tego potrzebował pamiętać wcześniejsze działania, aktualne zadanie i jego stan. Dlatego pojawiło się SQLite, Context Resolver i system przechowywania zadań.

Od tego momentu celem przestało być wykonanie pojedynczej komendy. JARVIS miał dostać cel, zapamiętać go i realizować kolejne kroki prowadzące do jego osiągnięcia.

04ETAP

Pierwszy agent biznesowy: Lead Hunter

Potrzebowałem czegoś, na czym będę mógł sprawdzić, czy cała ta architektura ma praktyczny sens. Tak powstał Lead Hunter. Pomysł jest prosty: zamiast ręcznie szukać potencjalnych klientów, agent ma zrobić większość tej pracy za mnie.

Pierwsza wersja dostała możliwość wykonywania audytu SEO. Następnie podpiąłem przez API Google PageSpeed, dzięki czemu agent może sprawdzać wydajność znalezionej strony i wykrywać konkretne problemy. Do systemu została również podłączona Meta przez API, żeby JARVIS mógł w przyszłości korzystać z kolejnych źródeł danych i automatyzacji związanych z ekosystemem Meta.

To jednak nadal wymagało podania konkretnej strony. A przecież nie o to chodziło. Docelowo chciałem powiedzieć tylko:

> Znajdź 10 firm z tej branży, których strony mają problemy.

05ETAPeksperyment

Agent szukający klientów na Facebooku

W międzyczasie pojawił się drugi pomysł. Skoro potencjalni klienci sami publikują na grupach facebookowych, że szukają strony internetowej, specjalisty SEO, reklamy czy innej usługi, dlaczego agent nie miałby ich wyszukiwać?

Zacząłem więc eksperymentować z agentem, którego zadaniem miało być przeglądanie grup i wyszukiwanie postów będących potencjalnymi leadami.

I tutaj pojawiła się ściana. Facebook bardzo mocno ogranicza automatyczny dostęp do części danych i działań. Samo podłączenie Meta API nie oznacza, że agent może swobodnie przeszukiwać wszystkie grupy, posty i profile tak, jak robi to człowiek. Próby obejścia tego przeglądarką prowadzą z kolei do następnego problemu: zabezpieczeń przed automatyzacją.

Ten agent nadal jest więc eksperymentem, a nie ukończonym elementem systemu. I była to jedna z ważniejszych lekcji podczas budowy JARVIS-a:

Czasami ograniczeniem agenta nie jest AI. Ograniczeniem jest środowisko, do którego próbujesz dać mu dostęp.

06ETAPtrwają prace

Przeglądarka okazała się trudniejsza niż AI

Podobny problem pojawił się przy Lead Hunterze. JARVIS potrafi już wykonać audyt SEO. Potrafi wysłać stronę do Google PageSpeed. Problem zaczyna się krok wcześniej: sam znajdź te strony.

Przy większej liczbie automatycznych wyszukiwań pojawiają się blokady, CAPTCHA i reCAPTCHA. I nagle cały workflow potrafi zatrzymać się już na pierwszym kroku:

1. Znajdź firmyCAPTCHA
2. Znajdź strony
3. SEO
4. PageSpeed

Obecnie eksperymentuję więc z Playwrightem i wyszukiwaniem przez przeglądarkę. To właśnie nad tym pracuję obecnie.

08ETAPtu jestem dziś

JARVIS jako orkiestrator

Dzisiaj coraz mniej patrzę na JARVIS-a jak na jeden model AI. Model jest tylko jednym z elementów.

JARVIS ma być orkiestratorem, który rozumie cel, dobiera odpowiednie możliwości systemu, korzysta z lokalnego lub chmurowego modelu i pilnuje wykonania zadania.

Po drodze: Context Resolver, Task Manager i Planner, dwa mózgi — Qwen lokalnie i model w chmurze, gdy jest potrzebny — warstwa możliwości z przeglądarką, Lead Hunterem i Meta API, a na końcu zatwierdzenie, wykonanie, weryfikacja i zapis w pamięci.

I właśnie w tym miejscu projekt znajduje się dzisiaj.