Budowanie rozszerzalnych agentów AI: Dogłębne spojrzenie na architekturę middleware

Wprowadzenie

FlowHunt wykorzystuje bibliotekę LangChain po stronie backendu, a w tym wpisie na blogu przyjrzę się architekturze middleware LangChain i temu, jak pozwala ona budować bardziej zaawansowanych agentów AI. Ewolucja agentów AI osiągnęła punkt zwrotny. Wraz ze wzrostem możliwości modeli językowych rośnie zapotrzebowanie na zaawansowane architektury agentów, które poradzą sobie ze złożonymi, wieloetapowymi procesami. LangChain 1.0 wprowadza zmianę paradygmatu w budowie agentów dzięki innowacyjnej architekturze middleware, która zasadniczo zmienia podejście do rozszerzalności i kompozycji agentów. Ten kompleksowy przewodnik omawia całkowicie przepisanych głębokich agentów na bazie LangChain 1.0, pokazując, jak middleware przekształca rozwój agentów z sztywnego, monolitycznego modelu w elastyczny, kompozytowalny system pozwalający programistom tworzyć potężnych agentów dopasowanych do własnych potrzeb.

Zrozumienie głębokich agentów: poza prostym wywoływaniem narzędzi

Zanim przejdziemy do architektury technicznej, warto zrozumieć, czym głębokie agenty różnią się od tradycyjnych systemów wywołujących narzędzia. U podstaw głębokie agenty to zaawansowane pętle wywołujące narzędzia, wzbogacone o konkretne wbudowane możliwości, które pozwalają im obsługiwać złożone, wieloetapowe procesy przy minimalnej interwencji człowieka. Podczas gdy proste agenty realizują zadania sekwencyjnie, wywołując narzędzia i przetwarzając wyniki, głębokie agenty wprowadzają warstwę inteligencji i struktury, która fundamentalnie zmienia ich podejście do rozwiązywania problemów.

Podstawę głębokich agentów stanowią cztery filary. Po pierwsze, możliwości planowania pozwalają agentom tworzyć i realizować uporządkowane listy zadań, rozbijając złożone procesy na wykonalne kroki przed przystąpieniem do działania. Ta faza planowania jest kluczowa — agent “przemyśli” cały przepływ pracy, zidentyfikuje zależności i zoptymalizuje kolejność czynności. Po drugie, dostęp do systemu plików umożliwia agentom trwałe przechowywanie danych i odciążenie kontekstu — mogą zapisywać informacje do plików, zamiast utrzymywać wszystko w historii rozmowy. Jest to szczególnie cenne przy zarządzaniu dużą ilością danych lub utrzymywaniu stanu między operacjami. Po trzecie, uruchamianie sub-agentów pozwala głównemu agentowi delegować zadania wyspecjalizowanym pod-agentom, tworząc strukturę hierarchiczną, która zwiększa efektywność i pozwala na ekspertyzę domenową. Wreszcie, szczegółowe systemowe podpowiedzi dostarczają wyczerpujących instrukcji obsługi narzędzi, zapewniając, że agent rozumie nie tylko jakie narzędzia są dostępne, ale także kiedy i jak ich używać najbardziej efektywnie.

Te możliwości okazały się nieocenione w systemach produkcyjnych, takich jak Manus i Cloud Code, gdzie agenci muszą poruszać się po złożonych workflow, zarządzać dużą ilością kontekstu i podejmować inteligentne decyzje dotyczące delegowania zadań. Celem paczki deep agents jest demokratyzacja dostępu do tej zaawansowanej architektury, tak by programiści mogli łatwo budować potężnych agentów bez konieczności wynajdowania koła na nowo czy poznawania wszystkich szczegółów implementacyjnych.

Ewolucja architektury agentów: od monolitu do modułów

Tradycyjne podejście do budowy agentów polegało na tworzeniu monolitycznych struktur, gdzie cała funkcjonalność — planowanie, zarządzanie narzędziami, obsługa stanu i inżynieria promptów — była ściśle powiązana w jednym kodzie. To podejście rodziło wiele problemów: rozszerzanie agentów wymagało modyfikacji logiki głównej, ponowne wykorzystanie komponentów było trudne, a testowanie pojedynczych funkcji niemal niemożliwe. Programiści musieli akceptować ograniczenia lub podejmować kosztowne refaktoryzacje w celu dodania nowych możliwości.

LangChain 1.0 rozwiązuje te problemy dzięki rewolucyjnemu konceptowi: middleware. Middleware to zmiana paradygmatu w architekturze agentów — wprowadza nakładaną warstwami abstrakcję, która pozwala programistom komponować funkcje agenta jak klocki. Zamiast zmieniać główną pętlę agenta, middleware przechwytuje i rozszerza konkretne punkty przepływu wykonania, umożliwiając czysty podział odpowiedzialności i maksymalną reużywalność. Ta innowacja architektoniczna przekształca rozwój agentów z monolitycznego podejścia “wszystko albo nic” w modułowy, kompozytowalny system, gdzie każdą funkcję można opracować, przetestować i wdrożyć niezależnie.

Piękno middleware polega na jego układalności. Programista może zdefiniować wiele komponentów middleware i stosować je w wybranej kolejności, a każda warstwa dodaje własne rozszerzenia stanu, narzędzia i modyfikacje promptów systemowych. Oznacza to, że jeden agent może korzystać z planowania, dostępu do systemu plików, uruchamiania sub-agentów i dowolnych niestandardowych rozszerzeń domenowych — wszystko to złożone razem. Kolejność stosowania middleware ma znaczenie, bo każda warstwa bazuje na poprzedniej, tworząc efekt kuli śnieżnej prowadzący do powstania wysoko kompetentnego agenta.

Jak middleware przekształca możliwości agentów

Aby zrozumieć middleware, warto przyjrzeć się, jak modyfikuje ono podstawową pętlę agenta ReAct (Reasoning + Acting). Wzorzec ReAct, który stał się standardem dla agentów wywołujących narzędzia, polega na tym, że model rozważa, jakie działania podjąć, wykonuje je przez narzędzie, obserwuje wynik i powtarza ten cykl do zakończenia zadania. Middleware nie zastępuje tej pętli — zamiast tego ulepsza ją w kluczowych miejscach.

Middleware działa na trzy główne sposoby. Po pierwsze, rozszerza schemat stanu, dodając nowe klucze i struktury danych, do których agent ma dostęp i które może modyfikować. Pozwala to każdemu komponentowi middleware utrzymywać własny stan bez kolizji z innymi. Po drugie, dodaje nowe narzędzia do zestawu agenta, dając modelowi dodatkowe możliwości osiągania celów. Po trzecie, modyfikuje żądanie do modelu, najczęściej przez dodanie niestandardowych instrukcji do promptu systemowego, wyjaśniających jak i kiedy korzystać z nowych narzędzi.

Takie trzytorowe podejście zapewnia, że rozszerzenia middleware są kompleksowe i dobrze zintegrowane. Samo dodanie narzędzia, bez rozszerzenia stanu czy instrukcji, byłoby nieskuteczne — model mógłby nie zrozumieć, jak użyć narzędzia lub kiedy jest ono odpowiednie. Dzięki połączeniu wszystkich trzech mechanizmów middleware tworzy spójne rozszerzenie, które model potrafi efektywnie wykorzystać.

Middleware planowania: strukturalna dekompozycja zadań

Middleware planowania doskonale pokazuje, jak architektura middleware umożliwia zaawansowane funkcje agentów. Rozszerza schemat stanu agenta o listę zadań — prostą, ale potężną strukturę danych pozwalającą utrzymać uporządkowany plan działania. Implementacja jest elegancka w swej prostocie: middleware dodaje jeden klucz do stanu, ale ten klucz odblokowuje ogromne możliwości.

Aby narzędzie planowania było skuteczne, middleware udostępnia narzędzie write-to-dos, które pozwala modelowi tworzyć, aktualizować i zarządzać listą zadań. Gdy agent napotyka złożone zadanie, może użyć tego narzędzia, by rozbić je na mniejsze, wykonalne kroki. Zamiast rozwiązywać wszystko naraz, agent tworzy plan, realizuje każdy krok i aktualizuje plan w trakcie pracy. Takie podejście ma wiele zalet: czyni rozumowanie agenta przejrzystym i audytowalnym, pozwala lepiej odzyskiwać się po błędach (jeżeli któryś krok się nie powiedzie, agent może dostosować pozostałe), i często prowadzi do sprawniejszej realizacji, bo agent przemyślał całość procesu.

Co istotne, middleware planowania nie tylko dodaje narzędzie — modyfikuje też prompt systemowy o szczegółowe instrukcje korzystania z write-to-dos. Wyjaśniają one, kiedy planowanie jest właściwe, jak skonstruować dobry plan i jak go aktualizować w miarę postępów. Ta modyfikacja promptu jest kluczowa, bo ukierunkowuje zachowanie modelu, zapewniając strategiczne wykorzystanie narzędzia planowania.

Middleware systemu plików: odciążanie kontekstu i trwałość danych

Podczas gdy middleware planowania skupia się na dekompozycji zadań, middleware systemu plików rozwiązuje inny, równie ważny problem: zarządzanie kontekstem i utrzymanie stanu między operacjami. Middleware systemu plików rozszerza stan agenta o słownik plików, tworząc wirtualny system plików, z którego agent może odczytywać i do którego może zapisywać dane.

W odróżnieniu od middleware planowania, które udostępnia jedno narzędzie, middleware systemu plików daje wiele narzędzi do różnych operacji na plikach. Agent może wylistować pliki, by zobaczyć, co ma do dyspozycji, odczytać plik, by wczytać informację do kontekstu, zapisać nowy plik, by przechować dane, czy edytować istniejący plik, by zaktualizować zawartość. To podejście odzwierciedla rzeczywistość — interakcje z systemem plików są różnorodne i wymagają różnych operacji.

Middleware systemu plików jest szczególnie cenne przy zarządzaniu dużą ilością danych lub utrzymywaniu stanu przez wiele operacji. Zamiast trzymać wszystko w historii rozmowy (co zużywa tokeny i może przekroczyć limity kontekstu), agent może zapisywać dane do plików i pobierać je w razie potrzeby. Przykładowo, agent prowadzący projekt badawczy może zapisywać wnioski do plików, porządkować je tematycznie i potem pobierać odpowiednie pliki podczas syntezy wniosków. Takie podejście znacznie zwiększa efektywność i pozwala agentom pracować na znacznie większych zbiorach danych, niż gdyby wszystko musiało mieścić się w oknie kontekstu.

Podobnie jak middleware planowania, middleware systemu plików zawiera niestandardowe prompty systemowe wyjaśniające efektywne korzystanie z narzędzi plikowych. Podpowiedzi te instruują, kiedy zapisywać dane do plików, jak organizować pliki dla łatwiejszego odnalezienia i najlepsze praktyki zarządzania wirtualnym systemem plików.

Middleware sub-agentów: delegowanie i specjalizacja

Middleware sub-agentów to najbardziej zaawansowany element architektury deep agents. Umożliwia głównemu agentowi uruchamianie wyspecjalizowanych sub-agentów do odizolowanych zadań, tworząc hierarchiczną strukturę zwiększającą efektywność i pozwalającą na ekspertyzę domenową. Implementacja jest bardziej złożona niż middleware planowania czy systemu plików, bo musi obsłużyć wiele scenariuszy i konfiguracji.

U podstaw middleware sub-agentów leży narzędzie task, dzięki któremu główny agent może delegować pracę sub-agentom. Gdy główny agent uznaje, że zadanie powinien wykonać sub-agent, wywołuje narzędzie task, określa, który sub-agent ma się tym zająć i przekazuje stosowne informacje. Sub-agent realizuje zadanie i zwraca głównemu agentowi kompletną odpowiedź. Ten model delegacji ma wiele zalet: izoluje kontekst (sub-agent widzi tylko informacje istotne dla swojego zadania), pozwala na specjalizację (różni sub-agenci mogą mieć różne narzędzia i prompty), a także często skutkuje czystszą, bardziej efektywną realizacją.

Middleware sub-agentów obsługuje dwa główne scenariusze tworzenia sub-agentów. Pierwszy to izolacja kontekstu — ogólny sub-agent otrzymuje te same narzędzia co główny agent, ale realizuje wąsko zdefiniowane zadanie. Po jego zakończeniu zwraca czystą, kompletną odpowiedź, bez pośrednich wywołań narzędzi czy kontekstu, które zaśmiecałyby historię głównego agenta. Takie podejście oszczędza tokeny i czas przez unikanie niepotrzebnego gromadzenia kontekstu. Drugi scenariusz to specjalizacja domenowa — sub-agent tworzony jest z dedykowanym promptem i konkretnym zestawem narzędzi dopasowanych do zadania lub domeny. Przykładowo, agent badawczy może mieć sub-agenta do przeglądu literatury z dostępem do baz akademickich, a inny sub-agent specjalizuje się w analizie danych z dostępem do narzędzi statystycznych.

Middleware pozwala definiować sub-agentów na dwa sposoby. Sub-agenci wywołujący narzędzia powstają od podstaw z niestandardowym promptem i określoną listą narzędzi. Mogą mieć zupełnie inne narzędzia niż główny agent — to prawdziwa specjalizacja. Programista może również wskazać inny model dla każdego sub-agenta, co pozwala użyć różnych modeli do różnych zadań. Niestandardowi sub-agenci dają jeszcze więcej elastyczności, pozwalając przekazać gotowe grafy LangGraph jako sub-agentów. To szczególnie cenne dla programistów, którzy już zbudowali zaawansowane workflow agentów i chcą udostępnić je głównemu agentowi jako sub-agentów.

Co ważne, sub-agenci także otrzymują middleware, dzięki czemu korzystają z planowania, dostępu do plików i innych rozszerzeń. To oznacza, że sub-agenci nie są ograniczeni do prostych wywołań narzędzi — mogą być równie zaawansowani jak główny agent, z własnym planowaniem, systemem plików, a nawet własnymi sub-agentami.

Zarządzanie kontekstem i middleware podsumowania

Wraz z wydłużaniem się rozmów i wzrostem złożoności zadań, okno kontekstu staje się kluczowym ograniczeniem. Middleware podsumowania rozwiązuje ten problem przez automatyczne zarządzanie kontekstem, gdy ten robi się zbyt duży. Middleware monitoruje historię rozmowy i, gdy liczba tokenów zbliża się do limitu, automatycznie kompresuje historię — podsumowuje starsze wiadomości, zachowując najnowsze.

Middleware podsumowania jest niezbędny dla agentów produkcyjnych, którzy muszą utrzymywać kontekst przez długie rozmowy. Bez niego agent w końcu przekroczyłby limity kontekstu i stracił dostęp do ważnych informacji historycznych. Dzięki podsumowaniu, agent zachowuje świadomość wcześniejszych interakcji, pozostając w ramach limitu tokenów. Middleware inteligentnie równoważy potrzebę zachowania najnowszego kontekstu (zwykle najbardziej istotnego) z kompresją starszego (który można skrócić bez utraty kluczowych danych).

Takie podejście do zarządzania kontekstem odzwierciedla szerszą zasadę projektowania agentów: kontekst to cenny zasób, którym trzeba rozsądnie zarządzać. Każdy token wydany na kontekst to token, którego nie można użyć na rozumowanie lub wynik narzędzia. Automatyczne podsumowanie, gdy jest to konieczne, pozwala agentom działać efektywnie nawet w długotrwałych scenariuszach.

Human-in-the-Loop: middleware dla aplikacji krytycznych

W aplikacjach krytycznych, gdzie agenci muszą wywoływać wrażliwe narzędzia (np. wysyłać e-maile, eskalować zgłoszenia, wykonywać transakcje finansowe), middleware human-in-the-loop zapewnia niezbędne zabezpieczenia. Middleware pozwala programiście określić, które narzędzia mają być przerywane przed wykonaniem, umożliwiając człowiekowi przegląd i akceptację (lub modyfikację) wywołań narzędzi przed ich realizacją.

Middleware human-in-the-loop przyjmuje konfigurację narzędzi, określającą, które narzędzia mają być przerywane i jakie działania człowiek może podjąć na danym wywołaniu. Przykładowo, przed wysłaniem wrażliwego e-maila middleware można skonfigurować tak, by człowiek mógł zatwierdzić akcję, edytować parametry lub przekazać agentowi wskazówki, co powinien zrobić inaczej. Tworzy to workflow, w którym agent zajmuje się rozumowaniem i planowaniem, a człowiek zachowuje kontrolę nad krytycznymi działaniami.

Middleware ten doskonale pokazuje, jak architektura middleware pozwala programistom dodać zaawansowane mechanizmy governance i bezpieczeństwa bez ingerencji w logikę główną agenta. Różne aplikacje potrzebują różnego poziomu nadzoru człowieka, a podejście middleware pozwala każdej z nich skonfigurować właściwy poziom interakcji.

Budowanie rozszerzalnych agentów z własnym middleware

LangChain 1.0 dostarcza kilka gotowych komponentów middleware, ale prawdziwą siłą tej architektury jest jej rozszerzalność. Programista może tworzyć własne middleware przez rozszerzenie bazowej klasy middleware agenta, co pozwala dodać nowe klucze stanu, narzędzia i modyfikacje promptów systemowych dopasowane do konkretnego zastosowania.

Tworzenie własnego middleware przebiega według tego samego schematu co wbudowane: rozszerz stan o nowe klucze, dodaj narzędzia operujące na tym stanie i zmodyfikuj prompt systemowy o instrukcje użycia tych narzędzi. Ta spójność ułatwia opracowanie nowych komponentów, które płynnie współdziałają z istniejącymi.

Przykładowo, programista budujący agenta do obsługi klienta może napisać własne middleware dodające narzędzie bazy klientów do wyszukiwania danych, narzędzie zarządzania zgłoszeniami do zakładania i aktualizacji ticketów oraz narzędzie bazy wiedzy do pobierania dokumentacji. Takie middleware rozszerzy możliwości agenta w sposób specyficzny dla obsługi klienta, a jednocześnie skorzysta z planowania, systemu plików i sub-agentów z wbudowanego middleware.

Możliwość tworzenia własnych middleware sprawia, że programista nigdy nie jest ograniczony do gotowych funkcji. Jeśli agent potrzebuje specjalnego narzędzia lub mechanizmu zarządzania stanem, można go zaimplementować jako middleware i płynnie zintegrować z resztą architektury.

FlowHunt i uproszczony rozwój agentów

LangChain 1.0 stanowi fundament architektoniczny dla budowy zaawansowanych agentów, ale platformy takie jak FlowHunt wynoszą rozwój agentów na wyższy poziom, oferując interfejs no-code do budowania, wdrażania i zarządzania agentami AI. Komponent AI Agent w FlowHunt wykorzystuje zasady architektury middleware, umożliwiając tworzenie potężnych agentów bez kodowania.

Podejście FlowHunt do budowy agentów doskonale wpisuje się w filozofię middleware: kompozytowalność, rozszerzalność i łatwość użycia. Zamiast zagłębiać się w szczegóły implementacji middleware, FlowHunt udostępnia wizualny interfejs, gdzie programista komponuje możliwości agenta przez łączenie komponentów. Platforma obsługuje orkiestrację middleware w tle, pozwalając skupić się na definiowaniu co agent ma robić, a nie jak to zaimplementować.

Agenci FlowHunt mogą mieć skonfigurowane planowanie, dostęp do systemu plików, sub-agentów i narzędzia niestandardowe — wszystko przez intuicyjny interfejs graficzny. To demokratyzuje rozwój agentów, czyniąc go dostępnym dla programistów bez głębokiej znajomości LangChain czy architektury agentów. Dodatkowo FlowHunt oferuje funkcje takie jak szczegółowe logi agenta, śledzenie historii i kontrola kosztów, pomagające lepiej zrozumieć zachowanie agenta i zoptymalizować jego wydajność.

Praktyczna implementacja: tworzenie głębokiego agenta

Zrozumienie teorii architektury middleware jest cenne, ale to praktyczna implementacja ujawnia jej prawdziwą moc. Tworzenie głębokiego agenta w LangChain 1.0 polega na użyciu funkcji create_deep_agent, która udostępnia gotowy interfejs do budowy agentów ze wszystkimi omawianymi wcześniej możliwościami.

Funkcja create_deep_agent przyjmuje kilka kluczowych parametrów. Programista przekazuje narzędzia, do których agent ma mieć dostęp, własne instrukcje definiujące zachowanie i cele agenta oraz sub-agentów, którym główny agent może delegować zadania. Następnie funkcja korzysta z budowniczego agenta, by złożyć agenta przez sekwencyjne zastosowanie odpowiednich middleware.

To właśnie budowniczy agenta jest miejscem, gdzie dzieje się magia. Rozpoczyna od wyboru modelu (domyślnie Claude Sonnet 3.5, ale można wskazać dowolny obsługiwany), następnie stosuje middleware w określonej kolejności. Najpierw middleware planowania — rozszerza stan o listę zadań i dodaje narzędzie write-to-dos. Następnie middleware systemu plików — wprowadza narzędzia plikowe i stan. Potem middleware sub-agentów — pozwala delegować zadania. Na końcu middleware podsumowania — obsługuje zarządzanie kontekstem.

Ta sekwencyjna aplikacja middleware jest kluczowa: każda warstwa buduje się na poprzedniej, tworząc efekt synergii. Prompt systemowy jest rozszerzany o instrukcje z każdego middleware w kolejności, dzięki czemu model otrzymuje wyczerpujące wskazówki jak korzystać ze wszystkich funkcji. Schemat stanu rośnie z każdą warstwą, pozwalając agentowi utrzymywać wiele typów stanu. Zestaw narzędzi poszerza się z każdym middleware, dając modelowi więcej możliwości realizacji celów.

Programista może dostosować ten proces, wybierając które middleware zastosować. Jeśli agent nie potrzebuje dostępu do systemu plików — pomija się to middleware. Jeśli nie potrzebuje sub-agentów — można je pominąć. Dzięki temu agenci są skonfigurowani dokładnie z tymi możliwościami, których potrzebują, bez zbędnych narzutów.

Zaawansowane wzorce: orkiestracja wieloagentowa

Wraz ze wzrostem zaawansowania aplikacji agentowych, programiści często potrzebują orkiestracji kilku agentów pracujących razem nad złożonymi celami. Architektura middleware umożliwia eleganckie rozwiązania dla orkiestracji wieloagentowej właśnie przez system sub-agentów.

Jednym z potężnych wzorców jest hierarchiczne delegowanie, gdzie główny agent rozbija złożone zadanie na sub-zadania i deleguje każde z nich wyspecjalizowanemu sub-agentowi. Przykładowo, agent badawczy może zlecić przegląd literatury jednemu sub-agentowi, analizę danych drugiemu, a syntezę wniosków trzeciemu. Każdy sub-agent jest zoptymalizowany pod swoje zadanie, z własnym promptem i narzędziami. Główny agent koordynuje całość workflow, dbając o prawidłową kolejność i integrację wyników sub-agentów.

Inny wzorzec to wykonywanie równoległe, gdzie kilka sub-agentów pracuje jednocześnie nad różnymi aspektami problemu. Choć obecna implementacja przetwarza sub-agentów sekwencyjnie, architektura wspiera wzorce równoległe, gdzie kilku sub-agentów jest uruchamianych, a ich wyniki agregowane. Jest to szczególnie wartościowe przy zadaniach możliwych do rozbicia na niezależne części.

Trzeci wzorzec to iteracyjna poprawa, gdzie główny agent uruchamia sub-agentów do wygenerowania początkowych rozwiązań, a następnie wykorzystuje ich wyniki do udoskonalenia podejścia i uruchamia kolejne sub-agenty do głębszej analizy. Taki wzorzec sprawdza się w złożonych problemach, gdzie kolejne iteracje analizy i poprawy prowadzą do lepszych rozwiązań.

Te wzorce pokazują, jak architektura middleware umożliwia budowę zaawansowanych systemów wieloagentowych bez konieczności tworzenia skomplikowanej orkiestracji od zera. Middleware sub-agentów obsługuje mechanikę delegacji i komunikacji, pozwalając programiście skupić się na projektowaniu workflow i możliwości każdego agenta.

Efektywność tokenowa i optymalizacja kosztów

Jedną z najbardziej praktycznych zalet architektury głębokich agentów jest jej wpływ na efektywność tokenową i optymalizację kosztów. Dzięki połączeniu planowania, dostępu do systemu plików i delegacji do sub-agentów, głębokie agenty mogą realizować złożone zadania zużywając znacznie mniej tokenów niż prostsze rozwiązania.

Planowanie zmniejsza zużycie tokenów, bo pozwala agentom przemyśleć workflow przed wykonaniem, unikając zbędnego błądzenia i powtarzania. Zamiast próbować różnych podejść i uczyć się na błędach, agent planuje efektywną ścieżkę do celu z wyprzedzeniem. **Dostęp do systemu plików zmniejsza zużycie