Jak zbudowałem własny system agentów AI (i czego mnie to nauczyło)

Zacząłem od irytacji. Płaciłem za kilka subskrypcji AI, otwierałem pięć zakładek naraz, kopiowałem tekst z jednego czatu do drugiego, a i tak co chwilę trafiałem w limit albo gubiłem wątek. Każde narzędzie było osobną wyspą. Żadne nie wiedziało, co robiłem wczoraj.

I za każdym razem, kiedy chciałem zrobić coś nieco bardziej złożonego niż “napisz mi e-mail”, musiałem ręcznie sklejać kawałki.

W pewnym momencie pomyślałem: a gdyby to wszystko działało u mnie, na moim komputerze, pod moją kontrolą? Nie jedna apka, tylko system. Coś, co pamięta, deleguje zadania, korzysta z różnych modeli zależnie od potrzeby i nie wysyła moich prywatnych plików nie wiadomo gdzie.

Tak powstał Fraktal — mój osobisty system agentów AI. Nie produkt, nie startup. Narzędzie, które zbudowałem dla siebie i które rozrosło się bardziej, niż planowałem. Ten tekst to szczery raport z budowy: co działa, co było ślepą uliczką i czego się przy okazji nauczyłem. Mapy, nie hype.

Dlaczego w ogóle samodzielnie, skoro są gotowce

Pierwsze, co usłyszysz od każdego rozsądnego inżyniera: nie wymyślaj koła na nowo. Na rynku są aktywnie rozwijane frameworki do budowy systemów wieloagentowych — LangGraph, CrewAI, AutoGen, OpenAI Agents SDK. Każdy z innym podejściem: jeden opiera orkiestrację na grafach stanu, drugi na hierarchii ról, trzeci na rozmowie agentów między sobą.

To użyteczne narzędzia, choć w 2026 roku większość z nich wciąż ewoluuje dość dynamicznie — i gdybym budował coś dla klienta korporacyjnego, i tak musiałbym liczyć się z tym, że interfejsy mogą się zmienić.

Ale ja nie budowałem dla korporacji. Budowałem dla siebie i miałem trzy twarde wymagania, których gotowce nie spełniały tak, jak chciałem:

Po pierwsze — wszystko lokalnie. Chciałem, żeby system działał na moim sprzęcie: zwykłym PC z kartą graficzną RTX 3060 i procesorem Ryzen 9. Nie w chmurze. Nie na cudzym serwerze. Część moich danych jest na tyle prywatna, że po prostu nie miały prawa opuścić tego komputera.

Po drugie — zero vendor lock-in. Nie chciałem być uzależniony od jednego dostawcy, jednego API, jednego cennika, który ktoś może z dnia na dzień podnieść albo wyłączyć. FOSS, otwarte komponenty, modele wymienne jak klocki.

Po trzecie — to miała być moja zabawa. Brzmi mało poważnie, ale to istotne. Najwięcej nauczyłem się właśnie dlatego, że budowałem to rękami, popełniając błędy, których w tutorialu nikt nie pokaże.

Gotowe frameworki dają ci gotową architekturę. Budując samemu, musisz zrozumieć każdą decyzję — i to jest jednocześnie ich największa zaleta i przekleństwo.

Jak to mniej więcej działa

Bez wchodzenia w bebechy — sercem systemu jest centralny dyrygent, którego nazwałem MarCePan. To on zarządza wszystkimi aplikacjami i wtyczkami, pilnuje, co jest uruchomione, i stanowi punkt, przez który przechodzą żądania. Można o nim myśleć jak o recepcji w dużym biurowcu: nie wykonuje pracy sam, ale wie, kto za co odpowiada i gdzie kogo wysłać.

Drugim filarem są Persony. To wyspecjalizowane AI — każda z własnym charakterem, własnym zakresem zadań i własną wiedzą podpiętą przez RAG (czyli mechanizm, który pozwala modelowi sięgać do konkretnych dokumentów, zamiast zgadywać z pamięci). Jedna persona zajmuje się szukaniem w kodzie, inna pisaniem treści, jeszcze inna kwestiami bezpieczeństwa. Zamiast jednego AI od wszystkiego mam zespół specjalistów.

Nad tym wszystkim siedzi nadrzędny orchestrator, który nazwałem MIA. Jego rola jest prosta do opisania i piekielnie trudna do dobrego zrobienia: dostaje zadanie, rozkłada je na części i deleguje każdą część do właściwej persony albo agenta. Jeśli zadania są niezależne, mogą iść równolegle. Jeśli jedno zależy od drugiego — ustawia je w kolejce.

To jest dokładnie ten sam wzorzec, który w świecie frameworków nazywa się orchestrator-workers: jeden koordynator i zespół wykonawców. Doszedłem do niego niezależnie, zanim porządnie poczytałem, jak robią to inni — i kiedy zobaczyłem, że duże frameworki idą tą samą drogą, poczułem dziwną mieszankę satysfakcji i rozczarowania.

Satysfakcji, że trafiłem w sprawdzony wzorzec. Rozczarowania, że nie wymyśliłem niczego rewolucyjnego. Ale to jest właśnie dobra wiadomość: dobre rozwiązania są zbieżne. Jeśli dochodzisz do tego samego co ludzie z dużo większymi zasobami, prawdopodobnie idziesz w dobrą stronę.

Więcej o samej koncepcji wyspecjalizowanych AI piszę w tekście Persony i agenci AI, a o tym, jak jeden koordynator rozdziela zadania — w artykule o orkiestracji wielu agentów.

Decyzja, która zaoszczędziła mi najwięcej: free-first

Najlepsza decyzja architektoniczna, jaką podjąłem, nie dotyczyła wcale architektury. Dotyczyła pieniędzy.

Na początku robiłem to, co większość — wszystko leciało przez jeden, najmocniejszy płatny model. Działało świetnie i kosztowało absurdalnie dużo. Szybko zobaczyłem, że ogromna część zadań w systemie to drobnica: sklasyfikuj to, streść tamto, rozpoznaj, do której persony skierować zapytanie, wyciągnij dane z tekstu. Do tego nie potrzeba najdroższego modelu na świecie. To jak wzywać profesora, żeby policzył ci resztę w sklepie.

Wprowadziłem więc zasadę, którą nazywam free-first. Najpierw próbujemy darmowych, szybkich modeli — Groq, Cerebras, Mistral. Dopiero gdy zadanie naprawdę tego wymaga, sięgamy po mocniejszy, płatny model. A dla rzeczy prywatnych w ogóle nie wychodzimy z komputera — wszystko idzie przez lokalnie uruchomiony model na Ollama.

Efekt? Koszty spadły drastycznie. Nie podam ci dokładnej liczby, bo zależy od tygodnia i od tego, czym akurat się bawię, ale różnica między “wszystko przez najdroższy model” a “mądry routing po modelach” to różnica między rachunkiem, na który krzywię się co miesiąc, a rachunkiem, którego prawie nie zauważam.

Delegacja prostych zadań do tańszych modeli to najbardziej niedoceniana dźwignia w całej tej zabawie. Rozwijam ten temat osobno, bo zasługuje na to — w tekście o ekonomii tokenów w firmie. A o samym podziale na to, co lokalnie, a co w chmurze — w artykule lokalne vs. chmurowe AI.

Co nie działało (czyli właściwa część artykułu)

Łatwo napisać tekst, w którym wszystko poszło gładko. To by była ściema. Najwięcej nauczyłem się z rzeczy, które się wywaliły.

Przekombinowałem architekturę. To mój pierwszy i największy grzech. Kiedy budujesz sam, nikt cię nie hamuje. Dokładałem warstwę po warstwie: a może jeszcze taki pośrednik, a może jeszcze osobny mechanizm na ten przypadek brzegowy, a może abstrakcja na wszelki wypadek. W pewnym momencie sam nie ogarniałem, co przez co przechodzi.

Twarda lekcja: najprostsze rozwiązanie, które działa, prawie zawsze wygrywa. Każda warstwa, którą dokładasz, to kolejne miejsce, w którym coś może paść i które potem musisz utrzymywać. W świecie frameworków mówi się, że większość projektów z 2025 roku została porzucona albo wchłonięta przez nowsze wersje — i teraz rozumiem dlaczego. Złożoność to dług, który spłacasz codziennie.

Procesy biły się o zasoby. Mam jeden komputer i jedną kartę graficzną. A na niej chce działać generowanie obrazów, lokalne modele językowe, czasem coś jeszcze. Przez długi czas po prostu pozwalałem im startować, kiedy chciały — i regularnie kończyło się to tym, że dwa ciężkie procesy próbowały naraz wcisnąć się do tej samej pamięci karty i jeden z nich padał.

Musiałem dobudować mechanizm, który pilnuje, kto ma pierwszeństwo i czy w ogóle jest miejsce, zanim cokolwiek odpalę. Banalne w opisie, upierdliwe w praktyce. Na cudzym serwerze w chmurze ten problem znika — płacisz za to po prostu inną walutą.

Kontekst AI się psuł przy długich zadaniach. To była najbardziej podstępna pułapka, bo nie objawia się błędem. Przy długich, wieloetapowych zadaniach model stopniowo gubi wątek — zaczyna od konkretnej instrukcji, a po kilkunastu krokach robi coś subtelnie obok. Nic nie krzyczy “błąd”, po prostu wynik jest cichcem coraz gorszy.

Rozwiązaniem okazało się tniecie zadań na małe, samodzielne etapy i zapisywanie wyników na dysk po każdym kroku, zamiast trzymania wszystkiego w jednej, coraz dłuższej rozmowie. Pisałem o tym mechanizmie szerzej w tekście o psuciu się odpowiedzi AI wraz z kontekstem — to zjawisko, które dopadnie każdego, kto wyjdzie poza krótkie czaty.

Ufałem, że “wydaje się, że działa”. Mój ulubiony błąd, bo najbardziej ludzki. Agent kończy zadanie, raportuje sukces, kod się kompiluje — i ruszam dalej. A potem okazuje się, że “kompiluje się” to nie to samo co “działa”.

Nauczyłem się twardej zasady: żadnego ogłaszania sukcesu bez fizycznego dowodu. Nie “import przeszedł”, tylko: uruchom, zrób zrzut ekranu, sprawdź logi, kliknij. AI potrafi z absolutną pewnością siebie zameldować, że wszystko gra, podczas gdy nic nie gra. To ta sama choroba, co halucynacje w czatach — tyle że tutaj kosztuje cię godziny szukania, gdzie naprawdę leży problem.

Czego mnie to wszystko nauczyło

Po miesiącach dłubania zostało mi kilka wniosków, które wykraczają poza sam Fraktal.

System jest tyle wart, ile jego najsłabsze ogniwo — czyli zwykle koordynacja. Pojedyncze persony działają świetnie. Sztuką nie jest mądry agent. Sztuką jest mądry podział pracy między agentów i pilnowanie, żeby informacja nie gubiła się po drodze. Większość mojego czasu poszła nie na “inteligencję”, tylko na hydraulikę: kto komu co przekazuje, kto czeka na kogo, gdzie zapisać wynik.

Lokalnie da się więcej, niż myślałem — ale nie wszystko. Na zwykłym, dobrym PC można uruchomić zaskakująco dużo. Lokalne modele świetnie radzą sobie z prostymi, prywatnymi zadaniami. Ale do naprawdę złożonego rozumowania wciąż sięgam po mocne modele z chmury. Sztuka polega na tym, żeby wiedzieć, co komu zlecić — i tu wracamy do free-first oraz podziału lokalne/chmura.

Budowa własnego systemu to najlepszy kurs AI, jaki istnieje. Nauczyłem się więcej o tym, jak naprawdę działają te narzędzia, budując ten system przez tydzień, niż przez miesiące czytania. Każdy błąd czegoś mnie nauczył. Każda ślepa uliczka pokazała, dlaczego ludzie robią to tak, a nie inaczej.

I najważniejsze: nie potrzebujesz tego wszystkiego. Mówię to szczerze, choć sam to zbudowałem. Większość ludzi nie potrzebuje własnego systemu agentów. Potrzebuje dwóch–trzech dobrze dobranych narzędzi i nawyku ich sensownego używania. Ja zbudowałem Fraktala, bo lubię rozumieć rzeczy od środka i bo mam specyficzne potrzeby związane z prywatnością. Jeśli Ty ich nie masz — gotowe narzędzia w zupełności wystarczą.

Na koniec

Fraktal nadal się zmienia. Co tydzień coś poprawiam, coś wyrzucam, coś upraszczam — bo upraszczanie okazało się najtrudniejszą i najważniejszą umiejętnością w całej tej historii. Nie jest to system “skończony” i pewnie nigdy nie będzie. I dobrze.

Jeśli wyciągnąłbym z tego jedno zdanie dla kogoś, kto myśli o budowie czegoś podobnego: zacznij od najprostszej wersji, która działa, weryfikuj wszystko własnymi rękami i nie ufaj słowu “wydaje się”. Reszta to detale, których nauczysz się po drodze — tak jak ja.

A jeśli chcesz pogadać o tym, jak poukładać AI w swoim własnym procesie — niekoniecznie budując cały system od zera — właśnie tym się zajmuję. Napisz do mnie, chętnie pogadam.