Inżynieria agentów AI, które budują i wdrażają software: architektura Jobbit

Większość „agentów AI" zatrzymuje się na rozmowie. Odpowiadają, a potem to człowiek wykonuje pracę. Naprawdę ciekawym — i autentycznie trudnym — problemem inżynierskim jest budowa agentów, które wykonują pracę: piszą aplikację full-stack, uruchamiają ją, naprawiają własne błędy i wdrażają na produkcję. To właśnie problem, nad którym codziennie pracuje zespół inżynierski Jobbit oraz jego dział badawczo-rozwojowy, Jobbit Labs (jobbitlabs.com).

Ten wpis to inżynierskie zanurzenie w schematy stojące za agentami AI, które budują i wdrażają oprogramowanie — architekturę, tryby awarii i wnioski. Jest celowo praktyczny i niezależny od dostawcy: czy budujesz na LLM-ach, orkiestracji multi-agent, wywoływaniu narzędzi (tool calling) czy RAG-u, te zasady się przenoszą.

Chatboty odpowiadają; agenci działają

Skok od chatbota do agenta to skok od generowania tekstu do podejmowania działań w świecie. Agent musi zaplanować wieloetapowe zadanie, wywołać narzędzia, odczytać wyniki i zdecydować, co dalej — a potem powtarzać to aż do osiągnięcia celu. Ta pętla, często nazywana pętlą agentową (agentic loop, czyli rozumuj–działaj), jest sercem systemu.

Wyzwanie inżynierskie polega na tym, że każdy krok może się nie udać. Model może zmyślić funkcję, która nie istnieje, napisać kod, który się nie kompiluje, błędnie odczytać wynik narzędzia albo po cichu zboczyć z zadania. Błędny chatbot tworzy złe zdanie; błędny agent tworzy zepsuty deploy. Prawdziwą pracą inżynierską jest niezawodność, a nie surowa moc.

Architektura: planista, wykonawca, narzędzia

Solidna platforma agentowa oddziela planowanie od wykonania. Warstwa planowania rozkłada cel („zbuduj aplikację do rezerwacji z płatnościami") na konkretne kroki; warstwa wykonawcza realizuje każdy krok za pomocą narzędzi. Trzymanie tych obszarów osobno czyni system łatwym do debugowania: plan można analizować niezależnie od tego, jak przebiegł każdy krok.

Użycie narzędzi (tool use) to miejsce, w którym agent dostaje ręce. Narzędzia to dobrze zdefiniowane funkcje, które model może wywołać — odczytaj plik, napisz kod, uruchom build, odpytaj bazę danych, wdróż. Dyscypliną inżynierską jest tu projektowanie interfejsów: każde narzędzie potrzebuje ścisłego, jednoznacznego schematu, walidowanych danych wejściowych i ustrukturyzowanych wyników, które model potrafi niezawodnie sparsować. Luźne interfejsy narzędzi to jedno z głównych źródeł awarii agentów; ścisłe to najtańsza dostępna inwestycja w niezawodność.

W złożonych zadaniach pojedynczy agent często ustępuje miejsca orkiestracji multi-agent — wyspecjalizowanym agentom, którzy planują, piszą kod, recenzują i weryfikują, koordynowanym przez orkiestratora. Dekompozycja daje skupienie (każdy agent ma wąskie zadanie i wąski kontekst) oraz równoległość (niezależne podzadania działają jednocześnie). Kosztem jest narzut koordynacji, więc warstwa orkiestracji musi być deterministyczna tam, gdzie może, i odporna tam, gdzie nie może.

Bezpieczne uruchamianie i wdrażanie prawdziwego kodu

Agent, który pisze oprogramowanie, musi to oprogramowanie uruchomić — a uruchamianie kodu wygenerowanego przez model jest przede wszystkim problemem bezpieczeństwa. Odpowiedzią jest wykonywanie kodu w sandboxie: niezaufany kod działa w izolowanym środowisku z ograniczonymi zasobami, bez dostępu do sekretów i ze ścisłymi granicami sieciowymi. Sandbox to coś, co pozwala agentowi iterować — kompiluj, testuj, czytaj błąd, naprawiaj — bez narażania platformy ani innych użytkowników.

Wdrożenie to krok, który zamienia wygenerowaną aplikację w produkt. Prawdziwy builder aplikacji AI zarządza całą drogą od kodu do działającego URL-a: build, udostępnienie hostingu, podłączenie domeny, terminacja TLS. Dobra inżynieria oznacza tu, że wdrożenia są powtarzalne i odwracalne — te same dane wejściowe dają ten sam wynik, a zły deploy można wycofać. Idempotentność i czysty rollback nie są efektowne, ale to one sprawiają, że autonomiczne wdrażanie staje się godne zaufania.

Kontekst, pamięć i pobieranie informacji

LLM-y mają skończony kontekst, a prawdziwe projekty się w nim nie mieszczą. Dlatego poważny system agentowy mocno inwestuje w inżynierię kontekstu (context engineering): decydowanie o tym, co model widzi na każdym kroku. Wpychanie wszystkiego do promptu jest zarazem kosztowne i przeciwskuteczne — zbyt wiele nieistotnego kontekstu degraduje rozumowanie.

To tu RAG (retrieval-augmented generation) i bazy wektorowe zarabiają na swoje miejsce. Zamiast zrzucać cały codebase do kontekstu, system pobiera tych kilka plików, symboli lub dokumentów istotnych dla bieżącego kroku. W połączeniu z ustrukturyzowaną pamięcią — zapisem decyzji, ewoluującą specyfikacją i tym, co już zostało wypróbowane — pobieranie utrzymuje agenta osadzonego w realiach przez całe długie zadanie, bez przepełniania okna kontekstu. Dobre pobieranie często bardziej podnosi jakość niż większy model.

Niezawodność: ewaluacje, weryfikacja i bariery ochronne

Jeśli jest jedna idea, która odróżnia produkcyjną inżynierię agentów od demówek, to ta: nie wdrożysz tego, czego nie potrafisz zmierzyć. Systemy agentowe są stochastyczne, więc niezawodność buduje się poprzez ewaluacje (evals) — automatyczne zestawy testów, które oceniają agenta na reprezentatywnych zadaniach i wyłapują regresje, zanim zrobią to użytkownicy. Zmiana, która „wydaje się lepsza", ale obniża wyniki ewaluacji, to zmiana, której nie wdrażasz.

Na ewaluacjach opierają się działające w czasie wykonania bariery ochronne (guardrails) i weryfikacja. Najskuteczniejszym wzorcem jest adwersarialne samosprawdzanie: gdy agent wyprodukuje wynik — fragment kodu, plan, poprawkę — osobny przebieg weryfikacyjny próbuje go obalić. Czy kod się kompiluje? Czy testy przechodzą? Czy wynik pasuje do schematu? Traktowanie weryfikacji jako odrębnego, sceptycznego kroku wyłapuje sporą część awarii, które pojedynczy, pewny siebie przebieg by przeoczył. Resztę załatwiają ponowienia z backoffem, bezpieczniki (circuit breakers) i eskalacja do człowieka.

Obserwowalność, którą da się debugować

Gdy autonomiczny system podejmuje dziesiątki decyzji na zadanie, musisz je widzieć. Obserwowalność (observability) — ustrukturyzowane śledzenie każdego promptu, wywołania narzędzia i wyniku — nie podlega negocjacjom. Gdy agent zawodzi, to ślad (trace) pozwala znaleźć dokładny krok, w którym zboczył, odtworzyć go i naprawić źródłową przyczynę. Zespoły inżynierskie, które traktują ślady agentów jako pełnoprawną telemetrię, debugują w minuty; te, które tego nie robią, debugują w dni.

Edge i elastyczna skala

Obciążenia agentowe są skokowe i wrażliwe na opóźnienia, co czyni edge computing naturalnym dopasowaniem. Działanie blisko użytkowników — na platformach takich jak Cloudflare Workers i edge'owych magazynach danych — skraca czas obiegu i skaluje się elastycznie wraz z popytem. Jobbit Labs opiera się na tym podejściu edge-first w częściach swojej infrastruktury danych i produktu: globalnie rozproszonej, autoskalującej się i rozliczanej za faktyczne zużycie, tak by moc obliczeniowa podążała za obciążeniem, zamiast stać bezczynnie.

Warstwa human-in-the-loop

Ostatni element architektury to ten, którego brakuje większości platform agentowych: ścieżka human-in-the-loop (człowiek w pętli). AI obsługuje wolumen i tempo, ale niektóre decyzje — logika wrażliwa na bezpieczeństwo, sformułowania prawne, osąd projektowy — należą do człowieka. Inżynieria tego oznacza budowanie czystych punktów przekazania, w których zweryfikowany ekspert może wkroczyć, a escrow chroni transakcję. Agent i sieć ludzi nie są konkurującymi warstwami; są wbudowanym zabezpieczeniem, które sprawia, że na całym systemie można polegać.

Wnioski dla inżynierów budujących agentów

Jeśli budujesz systemy agentowe, kilka zasad zwraca się wielokrotnie.

Projektuj ścisłe interfejsy narzędzi. Większość awarii agentów wywodzi się z niejednoznacznych narzędzi. Surowe schematy i walidowane wejście/wyjście to najtańsza niezawodność, jaką kiedykolwiek kupisz.

Weryfikuj adwersarialnie. Nie ufaj pewnemu siebie pierwszemu przebiegowi. Dodaj osobny krok, którego zadaniem jest obalenie wyniku.

Mierz ewaluacjami. Zbuduj zaplecze ewaluacyjne, zanim wyskalujesz agenta. Nie poprawisz tego, czego nie umiesz ocenić.

Inżynieruj kontekst, nie zrzucaj go. Pobieraj to, co istotne; pamiętaj to, co ważne. Większe prompty to nie lepsze prompty.

Wszystko, co niezaufane, trzymaj w sandboxie. Jeśli agent uruchamia kod, izolacja jest warunkiem wstępnym, a nie dodatkiem.

Zachowaj ścieżkę dla człowieka. Najbezpieczniejszy system autonomiczny to taki, który wie, kiedy zapytać człowieka.

Najczęściej zadawane pytania

Czym agent AI różni się od chatbota?

Chatbot generuje tekst; agent AI planuje i podejmuje działania — wywołuje narzędzia, uruchamia kod i iteruje w stronę celu. Trudność inżynierska leży w niezawodności na przestrzeni wielu kroków, gdzie pojedynczy błąd może zepsuć cały wynik.

Jak bezpiecznie uruchamiać kod wygenerowany przez AI?

Za pomocą wykonywania kodu w sandboxie: niezaufany kod działa w izolowanym środowisku z ograniczonymi zasobami, bez dostępu do sekretów i z ograniczoną siecią, dzięki czemu agent może kompilować, testować i naprawiać bez ryzyka dla platformy.

Dlaczego ewaluacje są tak ważne dla systemów agentowych?

Ponieważ agenci są stochastyczni, potrzebujesz automatycznych ewaluacji (evals), by mierzyć jakość na reprezentatywnych zadaniach i wyłapywać regresje przed wdrożeniem. Bez nich „ulepszenia" to zgadywanka.

Czym zajmuje się Jobbit Labs?

Jobbit Labs (jobbitlabs.com) to dział badawczo-rozwojowy i danych stojący za Jobbit, skupiony na cięższej, intensywnej danymi inżynierii klasy enterprise — badaniach, platformach danych i agentowych fundamentach, na których zbudowany jest produkt.

Ciekawi Cię inżynieria stojąca za agentami, które wdrażają oprogramowanie? Odwiedź jobbit.uk i jobbitlabs.com.