Deep Agents

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek pierwszy z szesnastu. Budowanie coding agenta od podstaw to świetna zabawa przez około godzinę. Potem twój model dobija do context limitu, całkowicie zapomina o pierwotnym zadaniu i nadpisuje kluczowy plik śmieciami. Aby powstrzymać asystenta przed zniszczeniem własnego workspace'u, potrzebujesz wzorca znanego jako agent harness. Ludzie często spotykają się z tym wzorcem dzięki bibliotece o nazwie Deep Agents. Na początek krótkie wyjaśnienie. Deep Agents to nie LangChain ani LangGraph. To samodzielna biblioteka w Pythonie, która działa na wierzchu tych narzędzi, pakując je w gotowego do użycia coding asystenta. Jeśli próbujesz samodzielnie zbudować coding asystenta, zazwyczaj zaczynasz od prostego skryptu. Bierzesz prompt od użytkownika, wysyłasz go do dużego modelu językowego i printujesz zwrócony kod. To po prostu zwykły chat loop. Działa to świetnie, gdy chcesz odpowiedzieć na pojedyncze pytanie. Ale szybko zaczynasz chcieć, żeby model faktycznie zaimplementował feature'a w wielu plikach na twojej maszynie. I w tym momencie iluzja pryska. Uświadamiasz sobie, że musisz ręcznie napisać toole do czytania plików, przeszukiwania katalogów i bezpiecznego aplikowania diffów w kodzie. Potrzebujesz systemu do śledzenia kontekstu przez dziesiątki kroków bez przekraczania token limitu. Musisz zbudować persistent task list, żeby model faktycznie pamiętał, co przed chwilą zrobił i co musi zrobić w następnej kolejności. W efekcie spędzasz cały swój czas na pisaniu boilerplate'u systemu plików i state managementu, zamiast skupić się na zachowaniu agenta. I to jest dokładnie to, co rozwiązuje wzorzec agent harness. Harness to warstwa infrastruktury owijająca surowy model językowy. Zamienia kruchy, statelessowy chat loop w trwałego, długo działającego agenta. W Deep Agents ten harness zapewnia memory management, operacje na systemie plików i logikę planowania krok po kroku out of the box. Podajesz mu high-levelowy cel i wskazujesz lokalny katalog. Harness przejmuje powtarzalną robotę, zapewniając modelowi bezpieczne środowisko do planowania, edytowania i weryfikowania kodu. Oto kluczowa kwestia. Główną zaletą korzystania z niezależnego harnessu, takiego jak Deep Agents, jest to, że jest on całkowicie model-agnostic. Ściśle zintegrowane rozwiązania, takie jak Claude Agent SDK czy starsze ekosystemy, jak OpenAI Codex, są mocno zoptymalizowane, ale zamykają cię u jednego providera. Jeśli jutro wyjdzie tańszy lub mądrzejszy model, migracja twojego tightly coupled agenta będzie ogromnym bólem głowy. Ponieważ Deep Agents abstrahuje środowisko od reasoning engine'u, model językowy staje się całkowicie wymiennym komponentem. Harness zarządza listami zadań, czyta system plików i ogarnia error recovery. Ta logika pozostaje identyczna, niezależnie od tego, czy używasz Anthropic, OpenAI, czy lokalnego modelu open-weight. Harness to podwozie samochodu, a model językowy to tylko silnik. Prawdziwą wartością tego wzorca jest niezawodność. Agent jest tylko tak dobry, jak środowisko, w którym operuje, a bez harnessu, który zakotwiczy go w prawdziwym systemie plików i konkretnym planie, nawet najmądrzejszy model to tylko generator tekstu, który kręci się w kółko. Jeśli chcesz pomóc w utrzymaniu tego podcastu, możesz wyszukać DevStoriesEU na Patreonie. Każde wsparcie bardzo dużo daje i jest zawsze doceniane. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 2 z 16. Nie potrzebujesz ogromnego diagramu architektury ani setek linijek boilerplate'u, żeby model językowy mógł autonomicznie planować swoją pracę. Wystarczy jedno wywołanie funkcji, żeby uruchomić Core Loop. Entry pointem dla tego zachowania jest funkcja o nazwie create deep agent. To w tej funkcji definiujesz mózg swojej aplikacji. Zamiast importować osobne biblioteki klienckie i pisać własne wrappery, mówisz funkcji, którego modelu użyć, za pomocą prostego stringa rozdzielonego dwukropkiem. Przekazujesz providera, dwukropek i dokładną nazwę modelu. Możesz użyć anthropic dwukropek claude-sonnet-4-6, albo openai dwukropek gpt-5.4. Framework odczytuje tego stringa i ogarnia konkretną inicjalizację pod spodem. Agent potrzebuje sposobu na interakcję ze światem, co zapewniasz mu za pomocą tooli. Taki tool to po prostu standardowa funkcja w Pythonie, która wykonuje konkretną akcję. Powiedzmy, że budujesz agenta do researchu w internecie. Piszesz funkcję, która przyjmuje query, wywołuje API wyszukiwarki i zwraca tekst. Przekazujesz tę funkcję wyszukiwania bezpośrednio do wywołania create deep agent jako element listy. Twój agent jest gotowy. Żeby rozpocząć proces, wywołujesz metodę run na swoim nowym agencie i przekazujesz mu prompta, na przykład prosząc go o zrobienie researchu i syntezę najnowszych wiadomości o komputerach kwantowych. Teraz kontrolę przejmuje Core Loop. I tu jest kluczowa sprawa. Deweloperzy często zakładają, że muszą pisać skomplikowane system prompty, żeby wymusić na modelu podział zadań, albo budować customowe parsery do śledzenia jego postępów. Wcale nie musisz tego robić. Kiedy wywołujesz create deep agent, harness automatycznie wstrzykuje wbudowanego toola o nazwie write todos. Nigdy nie piszesz ani nie zarządzasz tym toolem samodzielnie. Jest on częścią core'owego silnika. Zanim agent w ogóle dotknie twojego toola do wyszukiwania, Core Loop wymusza na modelu użycie toola write todos. Agent analizuje twojego prompta i generuje ustrukturyzowaną listę kroków. Dopiero po sfinalizowaniu tego planu zaczyna się faza wykonania. Pętla iteruje po planie krok po kroku. Agent patrzy na swoje pierwsze zadanie, rozpoznaje, że potrzebuje informacji, i wywołuje twój tool do wyszukiwania w internecie. Czyta surowy tekst zwrócony przez wyszukiwarkę i aktualizuje swoją wewnętrzną pamięć. Następnie pętla sprawdza, czy główny cel został osiągnięty. Jeśli wyniki wyszukiwania były niekompletne, agent przechodzi do następnego elementu na swojej liście todo, być może formułując nowe query wyszukiwania, żeby znaleźć brakujące szczegóły. Ten cykl wybierania toola, obserwowania wyniku i sprawdzania planu toczy się autonomicznie. Kiedy pętla potwierdzi, że wszystkie niezbędne zadania są wykonane, przestaje wywoływać toole. Agent analizuje zebrane dane, generuje końcową, zsyntetyzowaną odpowiedź i zwraca ją do ciebie. Cechą charakterystyczną Core Loop jest to, że zamienia statyczny generator tekstu w aktywnego problem solvera, strukturalnie wymuszając na nim planowanie przed działaniem. To wszystko w tym odcinku. Dzięki za wysłuchanie i koduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 3 z 16. Przyznanie autonomicznemu agentowi bezpośredniego dostępu do twojego komputera to świetny sposób na przypadkowe usunięcie katalogu domowego. Jeśli agent zdecyduje się zreorganizować twoje pliki albo przetestować skrypt, musisz upewnić się, że jest zamknięty w bezpiecznym obszarze. Właśnie dlatego używamy Pluggable Filesystem. Kiedy dajesz Deep Agentowi narzędzia do odczytu lub edycji pliku, nie wpinają się one bezpośrednio w twój system operacyjny. Zamiast tego mapują się na backend. Backend to środowisko storage'owe, które dyktuje, gdzie i jak pliki faktycznie się znajdują. Domyślnym środowiskiem jest StateBackend. To efemeryczny dysk-widmo trzymany w całości w pamięci. Załóżmy, że prosisz agenta o napisanie szybkiego draftu maila albo zmanipulowanie jakichś danych tekstowych. Agent tworzy plik, odczytuje go i edytuje – a to wszystko wewnątrz StateBackend. Kiedy twój skrypt kończy działanie, ta pamięć jest czyszczona, a pliki znikają. To środowisko jest całkowicie odizolowane i w pełni bezpieczne. Ale co się dzieje, gdy chcesz, żeby agent wygenerował prawdziwy projekt w Pythonie na twoim lokalnym dysku? Sama pamięć już nie wystarczy. Podnosisz uprawnienia agenta, podpinając FilesystemBackend. To podpina narzędzia plikowe agenta do twojego fizycznego dysku twardego. Żeby zachować bezpieczeństwo, inicjalizujesz backend z parametrem virtual mode ustawionym na true. I tu jest kluczowa sprawa. Virtual mode tworzy ścisłą granicę ścieżki. Definiujesz katalog bazowy, a agent operuje w jego obrębie. Jeśli agent spróbuje odczytać wrażliwy plik systemowy spoza tego folderu, backend zablokuje request. Zamyka agenta w wyznaczonym workspace. Jednak jest tu pewne niebezpieczne nieporozumienie. Wielu developerów zakłada, że włączenie virtual mode tworzy całkowicie bezpieczny sandbox. Wcale tak nie jest. FilesystemBackend kontroluje tylko operacje na plikach. Jeśli chcesz też, żeby twój agent uruchamiał komendy w terminalu, musisz podpiąć trzeci typ backendu, czyli LocalShellBackend. LocalShellBackend daje agentowi nowe narzędzie o nazwie execute. Pozwala to agentowi na odpalanie komend shellowych na twojej maszynie hosta. Jeśli podepniesz LocalShellBackend, virtual mode twojego FilesystemBackend nie ochroni cię przed destrukcyjnymi komendami w terminalu. Agent mógłby wykonać skrypt usuwający dane w całym systemie, a shell by go odpalił, całkowicie omijając twoje restrykcje dotyczące ścieżek plików. Dostęp do plików i egzekucja w shellu to odrębne możliwości zmapowane na odrębne backendy. Jeśli twój agent musi tylko pisać kod, trzymaj się FilesystemBackend. Podpinaj LocalShellBackend tylko wtedy, gdy agent absolutnie musi skompilować lub odpalić ten kod lokalnie. Najbezpieczniejszy autonomiczny agent to nie ten z najmądrzejszymi promptami, ale ten zdeployowany z efemerycznym StateBackend, który fizycznie nie może dotknąć twojego systemu operacyjnego na hoście. To wszystko na dziś. Dzięki za wysłuchanie — idź zbudować coś fajnego.

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 4 z 16. Najczęstszym błędem w projektowaniu agentów jest pisanie ogromnego system promptu na cztery tysiące słów, który szczegółowo opisuje działanie każdego pojedynczego toola, i hardcodowanie w nim konkretnych danych sesji. W rezultacie kończysz z kruchym promptem, wyczerpanymi context windows i koszmarem przy obsłudze wielu użytkowników. Dynamiczne system prompty rozwiązują ten problem, składając w locie dokładne instrukcje, których potrzebuje model językowy. Pomyśl o context engineeringu w Deep Agents jak o dynamicznej linii montażowej. Zamiast pisać jeden statyczny blok tekstu, końcowy prompt wysyłany do modelu językowego jest konstruowany z trzech odrębnych warstw. Te warstwy to statyczny system prompt, tool prompty i runtime context. Łączą się one w samym momencie egzekucji, tworząc kompletny input context. Pierwsza warstwa to statyczny system prompt. To ten element, który piszesz ręcznie. Definiuje on personę agenta, jego podstawowe zasady i ostateczny cel. Jest celowo prosty. Możesz powiedzieć agentowi, że jest asystentem zapytań do bazy danych, ale nie mówisz mu, jak połączyć się z bazą, jakiego formatowania oczekuje tool, ani jakie jest session ID użytkownika. Utrzymujesz tę warstwę ściśle skupioną na wysokopoziomowej logice biznesowej. Druga warstwa składa się z tool promptów i to właśnie tutaj wkracza framework. Deep Agents automatycznie wstrzykuje niezbędne instrukcje użycia dla konkretnych tooli, które podpinasz do agenta. Jeśli dasz agentowi toola do odczytu pliku, framework dynamicznie doklei dokładny schemat dla tego toola. Razem ze schematami, wstrzykuje wbudowany planning prompt. Ten planning prompt instruuje model, jak efektywnie sekwencjonować dostępne toole, aby rozwiązać problem. Nigdy nie piszesz ręcznie instrukcji, jak model powinien sformatować tool calla, ani jak ma zaplanować kroki swojej egzekucji. Framework obsługuje te mechanizmy automatycznie. Kiedy dodajesz lub usuwasz toola z agenta, tool prompty pod spodem aktualizują się natychmiast, bez konieczności ruszania głównego system promptu. Teraz musimy wyjaśnić częste źródło nieporozumień między statycznym system promptem a runtime contextem. Statyczny prompt jest definiowany podczas inicjalizacji agenta. Runtime context jest natomiast wstrzykiwany dokładnie w momencie, gdy wywołujesz agenta do pracy. Wyobraź sobie scenariusz, w którym budujesz aplikację multi-tenant. Kiedy konkretny użytkownik zadaje pytanie, agent potrzebuje jego unikalnego connection ID do bazy danych, aby pobrać jego dane. Jeśli umieściłbyś ten identyfikator w statycznym system prompcie, musiałbyś odtwarzać całego agenta od zera dla każdego pojedynczego requestu użytkownika. Zamiast tego używasz runtime contextu. Oto kluczowa kwestia. Przekazujesz obiekt kontekstu przez feature o nazwie ToolRuntime, dokładnie na etapie wywołania. Przekazujesz frameworkowi słownik zawierający konkretne connection ID do bazy danych dla tej sesji. Framework bierze ten runtime context, łączy go z twoim statycznym promptem i automatycznie wygenerowanymi instrukcjami tooli, a następnie wpina go bezpośrednio w toole, które tego wymagają. Tool wykonuje się przy użyciu poprawnego, dynamicznie dostarczonego connection ID. Twój statyczny system prompt pozostaje całkowicie czysty od tymczasowych identyfikatorów, kluczy API czy tokenów sesji. W milisekundzie egzekucji, dynamiczna linia montażowa kończy swoją pracę. Deep Agents skleja twoje główne instrukcje, dynamicznie wygenerowane schematy tooli, planning prompty i konkretne dane wywołania w jeden spójny input context. Model otrzymuje kompletny, perfekcyjnie sformatowany zestaw instrukcji dostosowany do tego konkretnego użytkownika i tego konkretnego zadania. Najbardziej skalowalni agenci nie wiedzą nic o swoim środowisku aż do samego momentu, w którym zostaną poproszeni o działanie. To tyle w tym odcinku. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 5 z 16. Większość agentów AI crashuje lub failuje po cichu w momencie, gdy odczytają log systemowy albo zrzut danych, który przekracza ich maksymalny rozmiar promptu. Deep Agents zapobiega temu, traktując limity kontekstu tak, jak system operacyjny obsługuje pamięć wirtualną. Nazywa się to Context Compression and Offloading. Duże modele językowe mają sztywny limit tego, ile tekstu mogą przetwarzać w jednym czasie. Jeśli agent próbuje trzymać zbyt dużo danych w aktywnym prompcie, model rzuca błędem i się zatrzymuje. Deep Agents radzi sobie z tym token overflow, stale monitorując rozmiar danych konwersacji. Działa to dokładnie tak, jak komputer robiący paging RAM-u na dysk twardy, gdy pamięć się zapełnia. Aktywna przestrzeń robocza pozostaje lekka, podczas gdy większość danych jest bezpiecznie odkładana na bok. Ten mechanizm działa w dwóch odrębnych fazach. Pierwsza faza obsługuje nagłe, ogromne skoki danych z zewnętrznych toolsów. Framework monitoruje liczbę tokenów każdego pojedynczego tool inputu i tool resultu. Sztywny próg dla tej kontroli wynosi dwadzieścia tysięcy tokenów. Jeśli operacja przekroczy ten limit, system przechwytuje payload, zanim w ogóle dotrze on do modelu językowego. Wyobraź sobie agenta wykonującego zapytanie, które pobiera ogromny zrzut bazy danych ważący trzydzieści tysięcy tokenów. Standardowy agent próbuje wstawić cały ten payload bezpośrednio do historii konwersacji, co natychmiast powoduje token overflow. Deep Agents obiera inną drogę. Przechwytuje tę ogromną odpowiedź, robi offload całego tekstu do nowego pliku na backendowym filesystemie i zastępuje payload w konwersacji prostym, dziesięciolinijkowym podglądem. Agent odczytuje podgląd i otrzymuje ścieżkę do pliku wskazującą na pełne dane. Agent dokładnie wie, co znalazł, ale aktywny prompt pozostaje całkowicie niezaśmiecony. To załatwia sprawę nagłych skoków danych. Druga faza obsługuje powolne gromadzenie się danych w standardowej konwersacji. Kiedy agent wykonuje długi, wieloetapowy proces, ciągła historia zapytań i odpowiedzi powoli zżera dostępne tokeny. Deep Agents monitoruje całkowite zużycie context window w odniesieniu do limitów modelu. Gdy aktywny prompt osiągnie osiemdziesiąt pięć procent całkowitego dostępnego context window, automatycznie odpala się proces sumaryzacji w tle. System pobiera najstarszy blok wiadomości z bieżącej historii i wykorzystuje model językowy do wygenerowania zwięzłego, rzeczowego podsumowania tych zdarzeń. Następnie zastępuje ten starszy blok wiadomości w aktywnym prompcie nowo wygenerowanym podsumowaniem, natychmiast zbijając liczbę tokenów z powrotem do bezpiecznego poziomu roboczego. I tu jest kluczowa sprawa. Developerzy często zakładają, że sumaryzacja konwersacji bezpowrotnie niszczy oryginalną historię. To nieprawda. Zanim nastąpi jakakolwiek sumaryzacja, oryginalne wiadomości są zapisywane na filesystemie jako trwały, kanoniczny zapis. Surowe dane nie giną. Jeśli agent później stwierdzi, że potrzebuje bardzo konkretnego detalu z wcześniejszego kroku, który nie trafił do podsumowania, może użyć swoich search toolsów, aby odpytać ten filesystem i pobrać dokładny, oryginalny tekst. Łącząc natychmiastowy offload na filesystem dla ogromnych tool results z dynamiczną sumaryzacją dla długich historii, agent może działać w nieskończoność, nie dusząc się we własnym kontekście. Dzięki za wysłuchanie, udanego kodowania wszystkim!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 6 z 16. Jeśli twój główny agent AI czyta dziesięć stron internetowych, aby odpowiedzieć na jedno pytanie, w końcu zapomni, jaki był oryginalny prompt. Cały ten pośredni szum zagłusza instrukcje. Rozwiązaniem tego problemu jest Context Isolation z synchronicznymi subagentami. Pomyśl o tym jak o wzorcu clean architecture dla twoich modeli językowych. Gdy pojedynczy agent ma dostęp do dziesiątek toolsów i przechodzi przez długie iteracyjne pętle, jego context window szybko zapełnia się surowymi danymi, komunikatami o błędach i outputami z toolsów. To przeładowanie kontekstu pogarsza zdolność modelu do wnioskowania. Zamiast jednego wielkiego agenta, który próbuje robić wszystko, potrzebujesz supervisora. Główny agent działa jak menedżer. Deleguje tę brudną, pożerającą tokeny pracę specjalistom i otrzymuje tylko czysty, sformatowany raport końcowy. Ludzie często mylą subagentów z ciągłym, wieloagentowym chat roomem, w którym różne modele siedzą i przerzucają się pomysłami. Tutaj tak nie jest. Synchroniczni subagenci są ściśle efemeryczni. Są odpalani, by wykonać konkretne zadanie, działają całkowicie autonomicznie we własnej, odizolowanej przestrzeni pamięci aż do zakończenia pracy i zwracają pojedynczy, końcowy wynik do supervisora. Kiedy tylko przekażą ten wynik, znikają. Weźmy konkretny scenariusz. Twój główny agent ma za zadanie napisać briefing rynkowy i potrzebuje danych o najnowszych trendach gospodarczych. Zamiast bezpośrednio wywoływać web search tool pięć razy i zaśmiecać swój własny context window surowym tekstem ze stron, supervisor deleguje ten problem. Odpala subagenta researcher. Ten efemeryczny researcher wchodzi we własną, odizolowaną pętlę. Robi pięć wyszukiwań w Google, czyta zabałaganione wyniki, syntetyzuje wnioski i pisze jeden akapit podsumowania. Przekazuje tylko ten akapit z powrotem do supervisora. Supervisor dostaje dokładnie to, czego potrzebuje, a jego kontekst pozostaje nieskazitelny. Aby to skonfigurować, definiujesz swoich specjalistów za pomocą prostych słowników. Przekazujesz je do parametru subagents podczas budowania głównego agenta. Każdy słownik to specyfikacja subagenta, która wymaga czterech informacji. Po pierwsze, podajesz nazwę, na przykład researcher albo calculator. Po drugie, podajesz opis. To jest ta najważniejsza część. Supervisor czyta ten opis, żeby zdecydować, którego specjalistę zatrudnić do danego problemu. Po trzecie, przekazujesz toolsy, dając temu konkretnemu subagentowi wyizolowany dostęp do rzeczy takich jak web scraper czy database client. Na koniec podajesz system prompt, który steruje zachowaniem subagenta. Kiedy przekażesz tę listę konfiguracji do głównego agenta, automatycznie zyskuje on dostęp do wbudowanego toola o nazwie task. Supervisor nie musi wiedzieć, jak instancjonować subagentów. Gdy napotka problem pasujący do opisu specjalisty, po prostu wywołuje tool task. Przekazuje dwa argumenty: nazwę subagenta do użycia oraz instrukcję w plain text, co należy zrobić. Egzekucja supervisora zostaje wstrzymana. Subagent odpala się, pracuje ze swoimi toolsami i w końcu kończy działanie. Dla supervisora, tool task po prostu zwraca ostateczną odpowiedź tekstową, tak jakby to był standardowy function call. Nawet jeśli nie zdefiniujesz jawnie żadnych słowników, framework daje ci fallback. Wbudowany jest domyślny subagent ogólnego przeznaczenia. Główny agent może użyć tego domyślnego specjalisty, aby oddelegować skomplikowane kroki wnioskowania. Działa on jak czysta karta, dając modelowi świeży context window do przepracowania gęstej łamigłówki logicznej bez zaśmiecania pamięci supervisora. Oto kluczowy wniosek. Wymuszając ścisłe granice między odizolowanymi zadaniami, sprawiasz, że pośrednia praca w scratchpadzie nie obniża jakości wnioskowania w głównym flow twojej aplikacji. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 7 z 16. Pozwolenie autonomicznemu systemowi na ślepe wykonywanie zapytań SQL to doskonały sposób na przypadkowe usunięcie produkcyjnej bazy danych. Jeśli chcesz, żeby twój agent działał w prawdziwym świecie, potrzebujesz mechanizmu, który go przechwyci, zanim zrobi coś destrukcyjnego. I tu do gry wchodzą interwencje Human-in-the-Loop. Główna idea jest prosta. Pauzujesz agenta tuż przed wykonaniem wrażliwej operacji, prosisz człowieka o wskazówki, a następnie wznawiasz egzekucję na podstawie tego feedbacku. Zanim przejdziemy do mechaniki, musimy omówić jedną częstą pułapkę, której musisz unikać. LangGraph wymaga pamięci do pauzowania i wznawiania stanu. Jeśli spróbujesz skonfigurować interwencję Human-in-the-Loop bez ustawienia checkpointera, interwencja zakończy się błędem. System potrzebuje warstwy persystencji, takiej jak memory saver, żeby zamrozić execution graph i zapisać bieżące zmienne, podczas gdy czeka na odpowiedź człowieka. Zawsze najpierw podpinaj checkpointer. Nie wszystkie narzędzia wymagają weryfikacji przez człowieka. Sprawdzanie pogody czy czytanie pliku z logami jest generalnie bezpieczne. Usuwanie plików lub modyfikowanie rekordów w bazie danych wymaga ścisłej kontroli. Obsługujesz tę kategoryzację ryzyka za pomocą parametru konfiguracyjnego interrupt on. Kiedy inicjalizujesz swojego agenta albo definiujesz tool node, przekazujesz do tego parametru listę nazw narzędzi. Jeśli agent próbuje wywołać tool, którego nie ma na liście, uruchamia się on natychmiast. Jeśli próbuje wywołać tool, który jest na liście, egzekucja się pauzuje. Przejdźmy przez konkretny scenariusz. Masz agenta z toolem bazodanowym o nazwie execute. Dodajesz execute do swojej listy interrupt on. Agent decyduje, że musi wyczyścić trochę starych danych i próbuje uruchomić komendę drop na bazie danych. System przechwytuje to wywołanie i pauzuje execution graph. Kiedy uruchamiasz agenta, monitorujesz result object zwrócony przez framework. A dokładniej, sprawdzasz właściwość o nazwie interrupts. Jeśli lista interrupts zawiera dane, agent natrafił na bramkę bezpieczeństwa i czeka na twój input. W tym momencie operator, czyli człowiek, ocenia oczekującą akcję. Masz trzy dozwolone decyzje, które możesz przekazać z powrotem do agenta. Są to approve, reject albo edit. Jeśli wybierzesz approve, agent wykonuje tool z oryginalnymi argumentami. Jeśli wybierzesz reject, tool call kończy się kontrolowanym błędem, a agent otrzymuje komunikat o błędzie, który promptuje go do spróbowania innego podejścia. I tu robi się ciekawie. Decyzja edit pozwala ci zmodyfikować zamierzoną akcję agenta, zanim ona nastąpi. W naszym scenariuszu z bazą danych, agent próbuje wykonać niebezpieczną komendę drop. Możesz przechwycić to żądanie, przepisać argumenty toola tak, żeby zamiast tego uruchomić bezpieczne zapytanie select, i odesłać ten zmodyfikowany payload z powrotem do systemu. Żeby odpauzować agenta, wywołujesz go ponownie, ale tym razem przekazujesz command object za pomocą parametru resume. Wewnątrz tego parametru resume podajesz swój decision string wraz z wszelkimi zmodyfikowanymi argumentami. Checkpointer pobiera zamrożony stan, wstrzykuje twoją ludzką decyzję bezpośrednio do grafu, tak jakby agent od początku to tak zaplanował, i egzekucja trwa dalej. Najważniejszą rzeczą, o której musisz pamiętać, jest to, że interwencje Human-in-the-Loop dają ci coś więcej niż tylko przycisk awaryjnego zatrzymania. Możliwość edycji argumentów toola w locie pozwala ci bezpiecznie przeprowadzić agenta przez złożone workflowy bez konieczności zaczynania od nowa. Jeśli chcesz wesprzeć nasz podcast, wyszukaj DevStoriesEU na Patreonie. To wszystko w tym odcinku. Dzięki za słuchanie i koduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 8 z 16. Patrząc na agenta czytającego lokalny plik, możesz założyć, że ta funkcjonalność jest zahardcodowana głęboko w core execution loop. Wcale tak nie jest. Magia stojąca za systemem plików agenta opiera się w całości na komponowalnym middleware, które możesz samodzielnie rozszerzać. Dzisiaj omówimy rozszerzanie harnessu za pomocą middleware. Deep Agents to nie jest czarna skrzynka. Harness, który steruje execution pipeline, jest wysoce rozszerzalny. Kiedy wyposażasz agenta w system plików albo listę zadań, po prostu podpinasz gotowe middleware do tego harnessu. Middleware znajduje się dokładnie na granicy między decyzją agenta o wywołaniu toola a faktycznym wykonaniem tego toola. To jest interceptor. Daje ci absolutną kontrolę nad tym, co wchodzi, co wychodzi i co jest rejestrowane podczas tej wymiany. Aby napisać własne, customowe middleware, tworzysz funkcję interceptora i nakładasz specjalny dekorator o nazwie wrap tool call. Ten dekorator rejestruje twoją funkcję w harnessie. Kiedy agent uruchamia toola, harness wstrzymuje domyślny flow i przekazuje kontrolę do twojej opakowanej funkcji. Wewnątrz tego interceptora otrzymujesz surowe argumenty wejściowe wygenerowane przez agenta, referencję do wywoływanego toola oraz obecny graph state. Uruchamiasz oryginalnego toola ręcznie z poziomu swojej funkcji, przechwytujesz jego output, a następnie zwracasz ten output z powrotem do harnessu. Wyobraź sobie customowe middleware zbudowane do monitorowania zewnętrznego API. Chcesz przechwycić każdy tool call do API, zalogować dokładne argumenty użyte przez agenta i śledzić metryki użycia, żeby uniknąć rate limitów. Twoja funkcja wrap tool call przechwytuje request, zanim trafi on do sieci. Wyciąga payload, zapisuje go w logach aplikacji, a następnie wykonuje właściwy request do API. Kiedy request się zakończy, middleware otrzymuje dane z odpowiedzi. Teraz musi zarejestrować, że call został wykonany. Zwróć na to szczególną uwagę. Podczas śledzenia metryk użycia, developerzy często próbują używać standardowych class instance variables. Po prostu piszą coś w stylu: self dot api call count plus equals one. To fatalny błąd. Deep Agents rutynowo wykonują toole i subagenty równolegle. Jeśli wiele tooli zwróci wynik w tym samym momencie i spróbuje bezpośrednio zmutować tę samą właściwość instancji, spowodujesz race conditions. Twoje liczniki będą się wzajemnie nadpisywać, update'y zostaną zgubione, a twoje metryki będą całkowicie błędne. Aby bezpiecznie zarządzać danymi, musisz zamiast tego zaktualizować graph state. Graph state jest specjalnie zaprojektowany do obsługi równoległego wykonywania. Zamiast modyfikować zmienną lokalną, twoje middleware odczytuje bieżącą metrykę z graph state, oblicza nową wartość i zwraca zaktualizowany obiekt stanu razem z wynikiem toola. W tym momencie execution harness przejmuje kontrolę. Przetwarza wszystkie przychodzące update'y stanu z równoległych wykonań tooli i scala je czysto, bez kolizji. Dzięki kierowaniu wszystkich side effectów i śledzenia metryk przez graph state, twoje middleware pozostaje całkowicie thread-safe. Zrozumienie tego wzorca odblokowuje cały framework. Przestajesz traktować agenta jako zamknięty system, a zaczynasz postrzegać go jako transparentny pipeline, w którym każda akcja może być bezpiecznie przechwycona i zmierzona. To tyle w tym odcinku. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 9 z 16. Posiadanie asystenta AI do kodowania jest świetne, dopóki nie musisz mu po raz pięćdziesiąty przypominać, że twój projekt wymaga strict typing i zmiennych w snake case. Rozwiązaniem są konwencje projektu poprzez pliki pamięci. Ergonomia deweloperska wymaga, aby twoje narzędzia dostosowywały się do twojego codebase'u, a nie odwrotnie. Nie powinieneś wklejać style guide'a do każdego pojedynczego prompta. Deep Agents radzi sobie z tym, dając agentowi trwałą pamięć poprzez specjalny plik o nazwie AGENTS dot md. Ludzie czasami mylą pamięć ze skillami. Pamięć zapewnia twój uniwersalny baseline. Jest zawsze ładowana przy starcie, co czyni ją idealną do globalnych konwencji i reguł architektonicznych. Skille to funkcjonalne narzędzia, które agent ładuje dynamicznie tylko wtedy, gdy wymaga tego konkretne zadanie. Dzisiaj skupimy się wyłącznie na pamięci. Kiedy inicjalizujesz agenta i przekazujesz parametr memory, framework automatycznie wstrzykuje zawartość pliku AGENTS dot md bezpośrednio do contextu agenta, zanim ten zacznie jakąkolwiek pracę. Ta operacja opiera się na protokole memory-first, który narzuca trzy odrębne fazy dla agenta: Research, Response i Learning. W fazie Research, agent czyta plik pamięci, aby zrozumieć środowisko. W fazie Response, generuje kod lub odpowiada na prompt. Następnie przychodzi faza Learning. I tu jest kluczowa sprawa. Nie musisz ręcznie pisać pliku AGENTS dot md. Agent aktualizuje ten plik autonomicznie na podstawie twojego feedbacku. Weźmy konkretny scenariusz. Prosisz agenta o wygenerowanie nowego endpointu API. Pisze działający kod, ale formatuje zmienne w CamelCase. Odrzucasz pull request i odpisujesz, że ten projekt używa wyłącznie snake case. Agent poprawia kod, ale na tym nie poprzestaje. Wchodzi w fazę Learning, otwiera lokalny plik AGENTS dot md i dopisuje nową regułę wymagającą snake case dla wszystkich przyszłych zmiennych. Następnym razem, gdy poprosisz o endpoint, agent przeczyta ten plik pamięci podczas fazy Research i natywnie napisze kod w snake case od samego początku. Ten system trwałej pamięci działa w dwóch różnych scope'ach. Pierwszy to global scope. Ten plik znajduje się w twoim katalogu domowym, w folderze dot deepagents. Używasz go do swoich osobistych preferencji deweloperskich. Jeśli we wszystkich swoich projektach zawsze wolisz asynchronicznego Pythona od kodu synchronicznego, agent uczy się tego właśnie tutaj. Drugi to project scope. Ten plik znajduje się bezpośrednio w folderze twojego lokalnego repozytorium. To tutaj trafiają reguły specyficzne dla danego repozytorium. Kiedy agent startuje, ładuje oba pliki. Najpierw aplikuje twoje globalne preferencje, a następnie nakłada na nie konwencje specyficzne dla projektu. Ponieważ plik pamięci w project scope znajduje się w twoim repozytorium, commitujesz go do version control. Kiedy nowy deweloper dołącza do zespołu i uruchamia agenta, jego lokalna instancja natychmiast dziedziczy wszystkie decyzje stylistyczne, których agent już się nauczył. Każdy poprawiony błąd trwale poprawia zrozumienie twojego repozytorium przez agenta, zmieniając go z generycznego generatora kodu w wysoce kontekstowego maintainera. To wszystko na dzisiaj. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 10 z 16. Jeśli wrzucisz pięćdziesiąt różnych przewodników po API do swojego system promptu, twój agent nie stanie się mądrzejszy. Tylko się rozproszy i polegnie na podstawowych zadaniach. Potrzebujesz sposobu, żeby dać agentowi głęboką wiedzę bez zapychania context window. Progressive Disclosure with Skills rozwiązuje dokładnie ten problem. Skill w Deep Agents działa jak modułowy upgrade mózgu. Pozwala spakować złożoną logikę, taką jak reguły deployu na AWS czy customowe workflowy data science, do izolowanego directory. Żeby go zbudować, po prostu tworzysz nowy folder, nazywasz go tak jak swój skill i wrzucasz do niego plik o nazwie dokładnie skill dot md. Często błędnie zakłada się, że framework po prostu dokleja całą zawartość tego pliku do system promptu. Nic z tych rzeczy. Takie podejście cofnęłoby nas prosto do problemu przeładowanego context window, obniżając wydajność i podbijając koszty. Zamiast tego, framework opiera się na wzorcu zwanym progressive disclosure, który zachodzi w trzech krokach: Match, Read i Execute. Na samej górze pliku skill dot md piszesz blok frontmatter. Jest on sformatowany jako zwykły YAML i zawiera tylko nazwę oraz krótki opis. I to jest kluczowe. Framework ładuje tylko ten krótki opis do początkowego system promptu. Agent czyta opis i decyduje, czy pasuje on do obecnego requestu użytkownika. To jest faza Match. Jeśli agent uzna, że skill jest przydatny, nie zgaduje, co zrobić dalej. Aktywnie używa wewnętrznego toola, żeby pobrać resztę pliku skill dot md. To jest faza Read. Teraz agent ma pełne, szczegółowe instrukcje tymczasowo załadowane do swojej pamięci roboczej na tę konkretną turę. Na koniec przechodzi do fazy Execute, w której postępuje zgodnie z tymi szczegółowymi instrukcjami, żeby wykonać zadanie. Kiedy rozmowa schodzi na inny temat, ten ciężki payload jest zrzucany, a agent wraca do swojego stanu bazowego. Wyobraź sobie scenariusz, w którym chcesz zbudować skilla o nazwie langgraph-docs. Twój frontmatter w pliku skill dot md ma opis mówiący, że ten skill dostarcza instrukcje i wewnętrzne adresy URL do przeszukiwania dokumentacji LangGraph. Reszta pliku zawiera te właściwe wewnętrzne adresy URL i konkretną metodologię wyszukiwania. Kiedy użytkownik pyta, czym jest LangGraph, agent sprawdza swoje aktywne skille. Widzi krótki opis, orientuje się, że potrzebuje więcej informacji, żeby odpowiedzieć na pytanie, i wykonuje request o pełny dokument. Czyta adresy URL, wykonuje wyszukiwanie i formułuje dokładną odpowiedź. Bez progressive disclosure musiałbyś wklejać wszystkie te adresy URL do głównego promptu przy każdej pojedynczej konwersacji. Budując bibliotekę skilli, możesz natrafić na konflikty, w których dwa skille próbują definiować instrukcje dla podobnych zadań. Deep Agents rozwiązuje to za pomocą source precedence. Zasada jest prosta: ostatni wygrywa. Ten skill, który załaduje się jako ostatni, nadpisze sprzeczne instrukcje z tych wcześniejszych. To pozwala ci najpierw dodawać szerokie, generyczne skille, a potem nakładać na nie bardzo specyficzne overridy w dalszej części konfiguracji. Wykonanie całego twojego agentowego workflow zależy od tego, jak dobrze napiszesz ten frontmatter. Zadbaj o precyzję opisów i bardzo szczegółowe wnętrza swoich skilli, ponieważ agent przeczyta pełny plik tylko wtedy, gdy najpierw przekonasz go samym opisem. To wszystko w tym odcinku. Dzięki za wysłuchanie i koduj dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 11 z 16. Inteligentny asystent nie powinien pytać cię, jakiej bazy danych używasz za każdym razem, gdy zaczynasz nową konwersację. A jednak, out of the box, większość agentów cierpi na całkowitą amnezję w momencie zakończenia wątku. Aby to rozwiązać, potrzebujesz Long-term Memory Stores. Kiedy odpalasz agenta, generuje on pliki. Słuchacze często zakładają, że jeśli agent zapisze plik, to będzie on żył wiecznie. Tak nie jest. Domyślnie wszystko jest efemeryczne. Deep Agents używają StateBackend, który przechowuje pliki w state bieżącego wątku konwersacji. Kiedy ten wątek się kończy, te pliki znikają. Jeśli chcesz prawdziwej personalizacji, gdzie agent buduje dożywotnią bazę danych preferencji usera i wiedzy o projekcie, potrzebujesz innego podejścia. Potrzebujesz StoreBackend. Łączy się on bezpośrednio z persistent LangGraph Store, zapewniając bezpieczeństwo danych pomiędzy wieloma wątkami. Ale nie chcesz persistować każdego pojedynczego pliku tymczasowego, który tworzy twój agent. Potrzebujesz mechanizmu, który oddzieli efemeryczną pracę w scratchpadzie od trwałych memories. I tu wkracza CompositeBackend. Pomyśl o nim jak o routerze ruchu dla systemu plików twojego agenta. Konfigurujesz CompositeBackend z domyślnym fallbackiem, zazwyczaj efemerycznym StateBackend. Następnie jawnie rejestrujesz route dla swojego long-term storage. Mówisz routerowi, że każda ścieżka pliku zaczynająca się od prefiksu katalogu slash memories slash musi być obsługiwana przez StoreBackend. Zwróć uwagę na ten fragment. Ten persistence nie jest automatyczny. Musisz specyficznie zroutować ścieżkę slash memories slash do Store. Jeśli pominiesz ten krok routingu, agent po prostu zapisze pliki memory do efemerycznego state'u, i zostaną one usunięte, gdy wątek się skończy. Kiedy wprowadzisz persistent database, napotkasz nowy problem. Nie możesz pozwolić, aby jeden użytkownik czytał zapisane preferencje innego użytkownika. Aby temu zapobiec, StoreBackend używa namespace factories. Namespace factory to po prostu funkcja, która wstrzykuje warstwę izolacji na podstawie bieżącego contextu. Zamiast zapisywać plik globalnie, factory generuje prefix array, na przykład słowo users, po którym następuje unikalne user ID. Za każdym razem, gdy agent wchodzi w interakcję ze StoreBackend, baza danych automatycznie ogranicza scope operacji do tego konkretnego user namespace. Zobaczmy, jak to wygląda w praktyce. Zaczynasz konwersację numer jeden. Wspominasz, że budujesz aplikację w React. Agent to notuje i zapisuje podsumowanie do pliku o nazwie project notes dot txt, umieszczając go konkretnie w katalogu slash memories slash. CompositeBackend widzi ten prefiks katalogu, przechwytuje komendę zapisu i routuje ją do trwałego StoreBackend w twoim izolowanym user namespace. Jutro zaczynasz konwersację numer dwa. To całkowicie nowy wątek z zerowym bezpośrednim contextem. Zadajesz pytanie o frameworki do state managementu. Przed odpowiedzią, agent sprawdza swój katalog slash memories slash. CompositeBackend routuje request odczytu do persistent store. Agent czyta twoje project notes, widzi szczegóły Reacta i dostarcza bardzo trafną odpowiedź, dopasowaną do twojego konkretnego stacku. Context przenosi się idealnie, mimo że wątki są oddzielne. Cross-thread persistence wymaga celowego designu poprzez routowanie konkretnych katalogów do persistent store i chronienie ich za pomocą user-specific namespaces. Dzięki za spędzenie ze mną tych kilku minut. Do następnego razu, trzymaj się.

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 12 z 16. Pozwolenie AI na pisanie kodu robi wrażenie. Ale pozwolenie tej samej AI na ślepe odpalanie napisanego przed chwilą kodu bezpośrednio na twoim laptopie to fatalny pomysł. Żeby to rozwiązać, potrzebujesz bezpiecznego miejsca, w którym agent zweryfikuje swoją logikę bez narażania twojej maszyny hosta. I o tym właśnie dzisiaj porozmawiamy: o wykonywaniu kodu w sandboxach. Jeśli agent nie może wykonać kodu, nie jest w stanie sprawdzić, czy ten kod faktycznie działa. Opiera się wyłącznie na swoich danych treningowych, żeby zgadnąć, czy skrypt jest poprawny. Sandboxy dają agentowi bezpieczny plac zabaw do iteracji, popełniania błędów i ich naprawiania na podstawie rzeczywistego outputu z wykonania. Zanim przyjrzymy się mechanice, musimy wyjaśnić jedno powszechne nieporozumienie. Mógłbyś założyć, że sam agent musi zostać zdeployowany i uruchomiony wewnątrz sandboxa. Wcale tak nie jest. Deep Agents opierają się na patternie Sandbox as tool. Logika agenta, pamięć i prompty żyją bezpiecznie na twoim serwerze. Agent po prostu wypycha komendy shellowe i kod przez API do zdalnego, odizolowanego środowiska. Ta interakcja odbywa się przez execute tool. Kiedy agent decyduje, że musi odpalić skrypt, wywołuje execute tool i przekazuje wygenerowany blok kodu. To narzędzie przekazuje payload do backendu sandboxa. Providerzy tacy jak Modal, Daytona i Runloop dostarczają takie środowiska. Provisionują bezpieczny kontener, uruchamiają kod i zwracają standard output albo error logi z powrotem do agenta. Sandbox tworzy ścisłą granicę izolacji między przestrzenią wykonawczą a twoim systemem. Wyobraź sobie agenta, który ma za zadanie stworzyć małą paczkę w Pythonie i odpalić test suite przy użyciu pytest. Agent siedzi na twoim serwerze. Używa execute tool, żeby uderzyć do zdalnego, efemerycznego serwera. Najpierw wysyła komendę, żeby zainstalować wymagane biblioteki. Następnie zapisuje pliki Pythona w katalogu sandboxa. Na koniec wysyła komendę, żeby odpalić pytest. Sandbox wykonuje te kroki i zwraca output z terminala. Jeśli test nie przejdzie, agent odczytuje błąd z odpowiedzi API, aktualizuje kod i ponownie wywołuje execute tool. Agent może budować, testować i czyścić środowisko, podczas gdy twoja maszyna hosta pozostaje całkowicie nietknięta. Kiedy konfigurujesz backend sandboxa, musisz zdefiniować jego lifecycle. Są dwa główne podejścia. Pierwsze to thread-scoped. Tutaj sandbox jest przypięty do konkretnego threadu konwersacji. Kiedy konwersacja się zaczyna, podnosi się świeży sandbox. Kiedy sesja użytkownika się kończy, sandbox jest niszczony. To zapewnia czystą kartę dla każdej interakcji i jest idealne dla operacji single-task, gdzie dane nie muszą być persystowane. Drugie podejście to assistant-scoped. W tym modelu sandbox jest przypięty do samego agenta, niezależnie od aktywnej konwersacji. Każdy thread wchodzący w interakcję z tym agentem współdzieli dokładnie ten sam state sandboxa. Jeśli jeden thread zainstaluje konkretną wersję biblioteki albo pobierze duży dataset, te pliki pozostają dostępne dla następnego threadu. To właściwy wybór, kiedy twój agent działa jako persistent worker, wymagający stabilnego, ciągłego workspace'u. I tu jest kluczowy wniosek. Środowisko wykonawcze dyktuje możliwości agenta. Kontrolując lifecycle sandboxa i wymuszając ścisłe granice API, dajesz agentowi swobodę popełniania błędów bez narażania twojej infrastruktury. Prawdziwa siła agenta to nie tylko generowanie kodu, ale iterowanie po błędach, a zdalne sandboxy zapewniają jedyny bezpieczny sposób, żeby ta iteracja mogła dziać się automatycznie. To wszystko w tym odcinku. Dzięki za słuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 13 z 16. Wysyłasz złożone zapytanie, twój supervisor agent deleguje zadania do trzech równoległych subagentów, a twój user przez dwie bite minuty gapi się na zwykły spinner. To fatalny UX, i żeby to naprawić, musisz dokładnie pokazać, co dzieje się pod maską. Odpowiedzią jest Subgraph Streaming UX. Workflowy multi-agentowe są z natury asynchroniczne i powolne. Kiedy główny agent deleguje zadania, tworzy się black box. Jeśli po prostu czekasz na końcowy, połączony wynik, user zakłada, że aplikacja się zawiesiła. Musisz streamować aktywność subagenta bezpośrednio na frontend. Częstym błędem developerów jest zakładanie, że kiedy subagenci streamują tokeny, te tokeny są po prostu ślepo doklejane do output streamu głównego agenta. Gdyby tak było, równoległe outputy przeplatałyby się w niezrozumiały bełkot. Zamiast tego, framework radzi sobie z tym, izolując każdy pojedynczy event w jego własnym namespace'ie. Aby to zadziałało, używasz formatu streamingu w wersji drugiej i przekazujesz flagę ustawiającą subgraphs na true, kiedy wywołujesz swój stream. Kiedy to zrobisz, stream nie zwraca już surowych chunków tekstu. Zwraca dictionaries. Każde dictionary zawiera trzy konkretne klucze: type, ns i data. Type mówi ci, na jaki event patrzysz. Data przechowuje właściwy payload albo token tekstowy. A ns to skrót od namespace. I to jest najważniejsza część. Namespace to tuple definiujący dokładną ścieżkę node'a, który wygenerował event. Jeśli chunk pochodzi od głównego agenta, tuple namespace'u jest pusty. Jeśli pochodzi od subagenta, namespace zawiera ścieżkę. Wygląda to jak tuple zawierający słowo tools, po którym następuje unikalne ID subagenta. Powiedzmy, że budujesz frontendowy dashboard. User prosi system o zaplanowanie wakacji. Supervisor agent spawnuje trzech oddzielnych subagentów: jednego od lotów, jednego od hoteli i jednego od aktywności. W swoim kodzie na frontendzie, iterujesz w pętli po przychodzącym streamie. Sprawdzając klucz namespace w każdym chunku typu dictionary, wiesz dokładnie, który subagent wygenerował ten konkretny token. Możesz wtedy zroutować te dane do oddzielnych komponentów UI. Zamiast jednego zaciętego spinnera, twój user widzi trzy osobne paski ładowania albo okna tekstowe, wypełniające się outputem w czasie rzeczywistym, jedno obok drugiego. Czasami musisz streamować informacje, które nie są tylko tokenem modelu językowego. Może chcesz wypchnąć customowy update statusu, na przykład powiadomić UI, że wywoływane jest zewnętrzne API. Możesz to zrobić z wnętrza node'a, używając funkcji get stream writer. Pobierasz writera, przekazujesz mu swój customowy dictionary, a on wstrzykuje te dane bezpośrednio do głównego streamu pod obecnym namespace'em subagenta. Frontend odbiera to dokładnie tak samo jak każdy inny event i aktualizuje odpowiedni, konkretny pasek ładowania. Jeśli chcesz pomóc nam tworzyć ten podcast, możesz nas wesprzeć, wyszukując DevStoriesEU na platformie Patreon. Multi-agentowa transparentność to w gruncie rzeczy problem routingu; mapowanie tuple'i namespace'ów na niezależne komponenty UI to coś, co zamienia frustrujący black box w UX klasy premium. To wszystko w tym odcinku. Dzięki za wysłuchanie i twórz dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 14 z 16. Co by było, gdybyś mógł połączyć swojego lokalnego agenta w terminalu z firmową bazą danych bez pisania ani jednej linijki kodu w Pythonie? Właśnie dlatego omawiamy Deep Agents CLI i zewnętrzne narzędzia MCP. Deep Agents SDK oferuje wbudowane CLI w standardzie. Uruchamiasz proces i dostajesz prompt w terminalu, gdzie możesz czatować ze swoim agentem. Możesz zarządzać głównym mózgiem agenta bezpośrednio z tego promptu. Jeśli potrzebujesz lepszego silnika wnioskowania, po prostu wpisujesz slash model, a po nim identyfikator nowego modelu. CLI natychmiast podmienia dostawcę w locie, a ty kontynuujesz sesję. Ale agent w terminalu, który tylko czatuje, nie jest zbyt przydatny. Potrzebuje dostępu do twojej rzeczywistej pracy. Zazwyczaj danie agentowi dostępu do repozytorium na GitHubie lub lokalnej bazy danych wymaga napisania własnego wrappera w Pythonie do obsługi wywołań API. CLI całkowicie tego unika, wykorzystując Model Context Protocol, powszechnie znany jako MCP. Często pojawia się zamieszanie wokół tego, czym właściwie jest MCP. To nie jest biblioteka Pythona, którą importujesz do kodu swojego agenta. Serwer MCP to zupełnie oddzielny proces albo zdalny URL. Działa jako ustandaryzowany wrapper wokół zewnętrznego systemu. Kiedy CLI startuje, gada z tym oddzielnym procesem, pyta, jakie narzędzia on dostarcza, i dynamicznie je ładuje. Konfigurujesz to połączenie za pomocą prostego pliku tekstowego o nazwie dot mcp dot json. Ten plik to rdzeń integracji zero-code. Kiedy odpalasz Deep Agents CLI, wykonuje ono auto-discovery. Szuka tej konfiguracji json w twoim obecnym katalogu. Jeśli ją znajdzie, łączy się z serwerami wymienionymi w środku, rejestruje ich narzędzia i przekazuje je twojemu agentowi. Ten plik konfiguracyjny obsługuje dwa mechanizmy transportu. Pierwszy to standardowe wejście i wyjście, czyli stdio. To opcja dla serwerów lokalnych. CLI spawnuje serwer jako proces w tle na twojej maszynie i komunikuje się z nim przez standardowe strumienie terminala. Drugi typ transportu opiera się na HTTP i Server-Sent Events. Używasz tego, gdy twój serwer MCP jest hostowany zdalnie, na przykład siedzi w prywatnej sieci korporacyjnej. Ponieważ serwery stdio odpalają lokalne komendy, bezpieczeństwo to priorytet. CLI utrzymuje lokalny trust store dla serwerów na poziomie projektu. Kiedy CLI po raz pierwszy wykryje nową komendę lokalnego serwera w twoim pliku dot mcp dot json, zatrzymuje się i prosi o wyraźne pozwolenie. Kiedy je zatwierdzisz, hash tej komendy jest zapisywany w twoim trust store, a przyszłe uruchomienia łączą się automatycznie. Spójrzmy na konkretny scenariusz. Chcesz, żeby twój agent czytał pliki z twojego lokalnego dysku. Tworzysz plik dot mcp dot json. W środku definiujesz blok serwera i nazywasz go local-filesystem. Ustawiasz typ transportu na stdio. W command line każesz mu odpalić narzędzie node package manager, npx, wskazując na gotowy serwer społecznościowy o nazwie server-filesystem, razem ze ścieżką do katalogu, który chcesz wystawić. Zapisujesz plik i odpalasz Deep Agents CLI. I tu jest kluczowa sprawa. CLI automatycznie spawnuje tę komendę npx w tle. Serwer systemu plików bootuje się i rozgłasza, że ma narzędzia do czytania plików i listowania katalogów. CLI łapie ten broadcast i wyposaża twojego agenta. Możesz od razu wpisać w terminalu prośbę do agenta o przeczytanie twojego systemowego pliku logów. Agent rozumie, że ma to narzędzie, wywołuje proces w tle, pobiera zawartość pliku i odpowiada na twoje pytanie. Właśnie dałeś systemowi AI bezpieczny dostęp do swojego lokalnego dysku za pomocą kilku linijek tekstu konfiguracyjnego. Oddzielając logikę narzędzi od twojej aplikacji w Pythonie, MCP zamienia twój terminal z podstawowego interfejsu czatu w rozszerzalne centrum sterowania. To wszystko na dzisiaj. Do usłyszenia następnym razem!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 15 z 16. Po co zadowalać się uniwersalnym asystentem kodowania, skoro możesz wstrzyknąć własnego, mocno spersonalizowanego agenta LangGraph bezpośrednio do swojego edytora kodu? Protokół, który wyciąga twojego dedykowanego agenta z terminala i włącza go do twojego codziennego workflow, to Editor Integrations przez ACP. Zanim przejdziemy dalej, musimy wyjaśnić pewną kolizję skrótów. Prawdopodobnie słyszałeś o MCP, czyli Model Context Protocol. MCP łączy twojego agenta z zewnętrznymi toolsami, pozwalając mu przeszukiwać bazę danych lub czytać system plików. ACP, czyli Agent Client Protocol, to zupełnie coś innego. ACP łączy twojego agenta z zewnętrznymi IDE, takimi jak Zed czy VSCode. Jeden łączy agenta z zewnętrznymi danymi, a drugi z twoim workspace'em. ACP to ustandaryzowana warstwa komunikacji. Definiuje dokładnie, jak IDE wysyła zaznaczenia tekstu, struktury plików i prompty użytkownika do agenta AI. Określa również, jak ten agent odsyła wstawki kodu, diffy plików i odpowiedzi na czacie. Implementując ten protokół, twój customowy deep agent zachowuje się w edytorze dokładnie tak, jak gotowy asystent. Różnica polega na tym, że posiada wszystkie specyficzne struktury pamięci, customowe szablony promptów i wyspecjalizowane wewnętrzne toolsy, które w nim zbudowałeś. Aby wypełnić tę lukę, instalujesz paczkę deepagents-acp. Integracja wymaga bardzo krótkiego skryptu w Pythonie, który posłuży jako entry point. W tym skrypcie tworzysz instancję swojego wstępnie skonfigurowanego deep agenta. Następnie, zamiast odpalać serwer webowy czy pętlę w terminalu, opakowujesz swojego agenta w interfejs serwera ACP. Robisz to, wywołując dedykowaną funkcję run i przekazując obiekt AgentServerACP, który z kolei opakowuje logikę twojego agenta. I tu jest kluczowa sprawa. Konfigurując ten serwer, ustawiasz go tak, aby używał standardowego wejścia i wyjścia, powszechnie znanego jako tryb stdio. To bardzo ważne, bo oznacza, że nie masz żadnych portów sieciowych do zarządzania, żadnych reguł firewalla do omijania i żadnych web socketów do debugowania. Proces agenta po prostu nasłuchuje przychodzących stringów na standardowym wejściu i wypisuje swoje ustrukturyzowane odpowiedzi na standardowe wyjście. Następnie musisz podłączyć swój edytor do tego skryptu. Weźmy edytor Zed jako konkretny przykład. Wewnątrz Zed otwierasz swój plik JSON z ustawieniami użytkownika. Dodajesz blok konfiguracyjny, który instruuje edytor, żeby użył customowego agenta. Zamiast kierować Zed na zdalny endpoint REST API, wskazujesz mu bezpośrednio twój lokalny plik wykonywalny Pythona, podając ścieżkę do twojego nowego skryptu ACP jako główny argument. Kiedy odpalasz sesję, edytor uruchamia twój skrypt w Pythonie jako ukryty proces w tle. Za każdym razem, gdy prosisz o edycję inline albo zaznaczasz funkcję do refaktoryzacji, edytor wysyła ustrukturyzowaną wiadomość ACP przez standardowe wejście bezpośrednio do twojego działającego skryptu. Twój customowy agent przetwarza to żądanie, przechodzi przez swój wewnętrzny graf węzłów, odpytuje swoją pamięć i wypisuje sformatowaną odpowiedź ACP z powrotem na standardowe wyjście. Edytor przechwytuje ten output i wprowadza zmiany w kodzie natywnie w oknie twojej aplikacji. Najważniejszym wnioskiem z tego wszystkiego jest kontrola. Kierując swojego customowego agenta przez ACP po stdio, przestajesz polegać na generycznym asystencie i zaczynasz współpracować z bytem, który z natury rozumie specyficzne konwencje twojego codebase'u. To wszystko w tym odcinku. Dzięki za wysłuchanie i budujcie dalej!

Cześć, tu Alex z DEV STORIES DOT EU. Deep Agents, odcinek 16 z 16. Prosisz swojego agenta o potężny refaktor codebase'u, a interfejs czatu natychmiast się zawiesza. Utknąłeś, wpatrując się w kręcące się kółko przez dwadzieścia minut, nie mogąc o nic zapytać ani zmienić zdania. Aby to naprawić, potrzebujesz Background Workers z Async Subagents. Standardowe subagents są synchroniczne. Blokują main thread. Supervisor przekazuje task i po prostu czeka, aż się skończy. Async subagents całkowicie zmieniają tę dynamikę, działając jako nieblokujące Background Workers. Kiedy supervisor przypisuje pracę, nie czeka na wynik. Natychmiast otrzymuje job ID i zwraca kontrolę użytkownikowi. Interfejs użytkownika pozostaje responsywny, podczas gdy ciężka robota dzieje się gdzie indziej. Konfigurujesz te Background Workers używając specyfikacji Async SubAgent. Kiedy robisz deploy swojej aplikacji do LangSmith Deployments, te Async Subagents są hostowane niezależnie. Główny supervisor komunikuje się z nimi przez standardowe protokoły transportowe. Jeśli zrobisz deploy workera na dokładnie tym samym serwerze co supervisor, komunikują się ze sobą używając ASGI, co jest bardzo wydajne dla lokalnego routingu. Jeśli worker znajduje się na oddzielnym, zdalnym serwerze, supervisor łączy się z nim przez HTTP. Aby orkiestrować te zdalne workery, supervisor jest wyposażony w specjalny zestaw async tools. Wróćmy myślami do tego requestu o refaktor codebase'u. Użytkownik prosi o przepisanie kodu. Supervisor decyduje, że zajmie to dużo czasu i wywołuje start async task tool. Ten tool odpala coder subagent i przekazuje supervisorowi job ID. Supervisor odpowiada użytkownikowi, potwierdzając, że background job jest uruchomiony. Ponieważ main thread jest wolny, użytkownik może kontynuować konwersację. Kilka minut później użytkownik może zapytać, jak idzie refaktor. Supervisor wywołuje check async task tool, przekazując job ID, i pobiera aktualny status wykonania z workera. I tu jest kluczowa sprawa. Użytkownik nie jest odcięty od procesu, podczas gdy worker działa. Jeśli użytkownik nagle zda sobie sprawę, że potrzebuje, aby refaktor wymuszał strict type hinting, może po prostu powiedzieć o tym supervisorowi. Supervisor wywołuje wtedy update async task tool. To wypycha nowe instrukcje sterujące w locie bezpośrednio do działającego subagenta, bez konieczności restartowania joba od zera. Jeśli użytkownik uzna, że refaktor był całkowicie złym pomysłem, supervisor używa cancel async task tool, aby czysto zakończyć background process. Częstym powodem do nieporozumień jest to, jak supervisor zapamiętuje te joby podczas długiej sesji. Z czasem historie czatów są kompaktowane, aby oszczędzać context tokens. Gdyby job ID istniał tylko jako tekst w historii konwersacji, supervisor w końcu by go zapomniał i stracił z oczu workera. Aby temu zapobiec, metadane taska nigdy nie są przechowywane tylko w chat logu. Są one zapisywane w dedykowanym state channelu o nazwie async tasks. Ten state channel działa niezależnie od listy wiadomości, gwarantując, że aktywne job IDs przetrwają każdą kompresję konwersacji. Przejście z blocking calls na Background Workers zmienia twoją architekturę z prostego interfejsu czatu w równoległy silnik orkiestracji, zdolny do obsługi ogromnych workloadów. Jako że to już koniec naszej obecnej serii, zachęcam cię do przeczytania oficjalnej dokumentacji, spróbowania samodzielnego deployu async workera, lub odwiedzenia DEV STORIES DOT EU, aby zaproponować tematy na naszą kolejną serię. Dzięki za spędzenie ze mną tych kilku minut. Do następnego razu, trzymaj się.