Co ujawnia 10-minutowy proces tworzenia agenta o prawdziwej architekturze
Narzędzia do tworzenia agentów w ciągu dziesięciu minut, takie jak TrueForge, ukrywają decyzje architektoniczne, z którymi muszą się zmierzyć Deep Agents lub LangGraph: umiejętności, narzędzia MCP, stan oraz ścieżki awarii.
Źródła: I Built an Agent in 10 Minutes. Then I Understood Why Building One Takes So Long.
To, co ujawniło się podczas pracy z LangGraph, Deep Agents i TrueForge na temat abstrakcji, kontroli oraz tego, jak faktycznie zachowują się agenci.
Podczas tworzenia DEVIN znaczna część wysiłków została poświęcona pracom, które w ogóle nie są widoczne, gdy ktoś po prostu korzysta z agenta AI.
Łączenie elementów Deep Agents.
Konfigurowanie Daytona jako środowiska sandbox.
Używanie Ingest do obsługi transmisji strumieniowej i wykonywania zadań w tle.
Zapewnienie współpracy wszystkich tych elementów.
Postępy były powolne.
Jednak w trakcie tej ciężkiej pracy pojawił się jaśniejszy obraz tego, co faktycznie składa się na system agentów.
Nie tylko sam model.
Wszystko, co go otacza.
Czas wykonywania.
Narzędzia.
Środowisko sandbox.
Szyna orkiestracji.
Sposób, w jaki agenci ze sobą komunikują się i przekazują sobie zadania.
Następnie pojawił się hackathon, a wraz z nim TrueForge.
Prawie od razu stało się oczywiste, jak dużą część infrastruktury, którą starannie budowano ręcznie, można zamiast tego przekazać platformie.
Zbudowanie działającego agenta nie zajęło więcej niż około dziesięciu minut: podłączenie odpowiednich MCP-ów, dodanie niezbędnych narzędzi, stworzenie pliku SKILL.md opisującego zachowanie, a następnie jego prosty uruchomienie.
Po całym tym czasie spędzonym na budowaniu infrastruktury od zera, wydawało się to niemal zbyt proste.
I szczerze mówiąc, było to imponujące.
To właśnie powinno dawać takie wrażenie przy dobrej abstrakcji.
Jednak kompromis ukryty za tą łatwością nie był jeszcze oczywisty.
Agent w 10 minut
Pierwszą reakcją była czysta podziw dla tego, jak bezproblemowy był ten proces.
TrueForge zajął się otaczającą infrastrukturą, pozostawiając główne zadanie opisania tego, co agent powinien faktycznie robić, definicji umiejętności.
To jest naprawdę silna abstrakcja.
Dodawane MCP-y były widoczne.
Narzędzia były widoczne.
Plik SKILL.md był widoczny.
Wszystko wydawało się czytelne i łatwe do zrozumienia.
Dlatego utrwalił się nawyk korzystania z niego.
Dopiero przy dalszym używaniu pojawił się subtelniejszy problem, którego nie zauważono podczas samego hackathonu.
Kwestią nie było to, co można było sprawdzić.
Kwestią było gdzie znajduje się rzeczywista architektura.
Sama umiejętność nie jest architekturą
Agent główny czyta plik z umiejętnościami i wykorzystuje go do decydowania, w jaki sposób zastosować przysługujące mu możliwości, w tym jak i kiedy uruchomić podagenty.
To oznacza, że jeden plik SKILL.md może w tajemnicy określić znaczną część struktury behawioralnej agenta.
Załóżmy, że chcemy stworzyć coś takiego:
Root Agent
/ \
/ \
Researcher Coder
/ \
/ \
Searcher Tester
Po prostu powiedzenie agentowi głównemu coś w stylu: „Oto twoje narzędzia, utwórz potrzebne podagenty i sam rozwiąż problem” nie jest tym samym co projektowanie systemu.
Najważniejsze jest bezpośrednie zdefiniowanie architektury:
- kterzy agenci istnieją
- za co jest odpowiedzialny każdy z nich
- które narzędzia trafiają do którego agenta
- jaki kontekst otrzymuje każdy agent
- kiedy powinna nastąpić delegacja
- jaki jest plan odzyskiwania po awarii
To właśnie ta różnica zaczęła rzucać się w oczy.
Pracując z podejściem Deep Agents, architekturę buduje się celowo.
Pracując z TrueForge, strona infrastruktury jest znacznie prostsza, ale architektura behawioralna zależy od tego, czy główny agent interpretuje umiejętność w sposób zamierzony.
To zależność łączy zachowanie całego systemu znacznie mocniej z podstawowym modelem.
Bardziej zaawansowany model może odczytywać umiejętność dokładnie w sposób, w jaki miała być odczytywana.
Słabszy model może obrać zupełnie inny tor działania przy tych samych instrukcjach.
Ta sama plik z umiejętnością.
Te same narzędzia.
Różne zachowanie wynikowe.
Architektura na papierze się nie zmieniła.
Zmieniła się tylko interpretacja tej architektury przez model.
To właśnie ta luka sprawiła, że trudno było w pełni zaufać temu podejściu.
Praaca nad AEGIS pogłębiła to zaniepokojenie
Podczas tworzenia AEGIS zespół napotkał prosty, ale pouczający problem.
Agent miał badać przypadki zatoru pętli wydarzeń w Node.js.
Musiał analizować kod, odtwarzać problem, mierzyć zachowanie w czasie rzeczywistym, zdiagnozować przyczynę, zaproponować rozwiązanie i potwierdzić, że naprawa rzeczywiście zadziałała.
Na początku etap weryfikacji polegał głównie na podaniu modelowi instrukcji, mniej więcej w takim tonie:
Wykonaj eksperyment, porównaj uzyskane wskaźniki i ocenij, czy naprawa rzeczywiście rozwiązała problem.
Jednak pozostawienie decyzji o tym, czy własna poprawka zadziałała, modelowi LLM wcale nie stanowi prawdziwej weryfikacji.
Zatem deterministyczna część tej logiki została przeniesiona do kodu zamiast do tekstu instrukcji.
Model przeprowadza rozumowanie.
System dokonuje pomiaru.
Weryfikator wykonuje wywołanie.
To doświadczenie doprowadziło do powstania zasady, która obecnie znajduje szerokie zastosowanie w projektowaniu agentów:
Jeśli coś nie może być zaobserwowane, nie można go prawidłowo przetestować. Jeśli nie można go przetestować, nie można go ocenić. A jeśli nie można go ocenić, nie można go wiarygodnie udoskonalić.
Dlatego właśnie architektura ma znaczenie.
Nie dlatego, że diagram z większą liczbą pudełek i strzałek jest z natury lepszy.
Ponieważ potrzebna jest jasna informacja o tym, co spowodowało zachowanie, które próbujemy poprawić.
"To działa" kontra ">Rozumiem, dlaczego to działa"
Dwa różne agenty mogą oba technicznie odnieść sukces.
Oba mogą ukończyć przydzielone zadanie.
Oba mogą świetnie wyglądać podczas demonstracji na żywo.
Prawdziwa próba następuje, gdy coś idzie nie tak.
W przypadku jednego typu agenta można prześledzić dokładną ścieżkę wykonywania:
Root Agent
↓
Researcher
↓
Search Tool
↓
Result
↓
Root Agent
↓
Coder
↓
Sandbox
Każdy punkt decyzyjny można przeanalizować i zakwestionować:
Dlaczego doszło do tego konkretnego kroku?
W przypadku innego typu agenta istnieje tylko opis umiejętności określający zamierzony wynik, podczas gdy model sam znajduje odpowiednią ścieżkę.
Gdy to działa, wydaje się to niezwykle proste.
Gdy zawodzi, pytanie dotyczące debugowania staje się znacznie trudniejsze do odpowiedzi:
Czy awaria była spowodowana modelem, instrukcjami, logiką delegacji, dostarczonym kontekstem czy architekturą, którą model sam wymyślił?
To drugi scenariusz to o wiele trudniejszy problem do rozwikłania.
I to właśnie nauczyło TrueForge
Zanim poświęcimy czas na pracę z tą platformą, naturalnym założeniem jest, że trudna część budowy agentów leży wyłącznie w warstwie infrastruktury.
Praca z nią zmienia to spojrzenie. Okazuje się, że infrastruktura stanowi tylko połowę wyzwania.
Infrastrukturę można abstrahować.
Zachowanie opiera się abstrakcji.
Platforma może dostarczyć środowisko sandbox.
Może dostarczyć MCP.
Może dostarczyć funkcje transmisji strumieniowej.
Może dostarczyć cały środowisko wykonawcze.
Mimo to, jeśli budujesz agenta, którego działania są rzeczywiście istotne, nadal musisz samodzielnie odpowiedzieć na niektóre pytania:
Która komponenta podejmuje jakie decyzje?
Komu jest dozwolone robić co?
Gdzie dokładnie ma miejsce delegowanie?
Jaka masz widoczność na ten proces?
Czego możesz faktycznie zmierzyć lub ocenić?
Które narzędzia są dostępne, by naprawić problemy, gdy się pojawią?
To są elementy, których nikt nie powinien przekazywać innej osobie bez dwojnego namysłu.
Ile czasu zajmuje zrozumienie, dlaczego coś się nie udało?
Zbudowanie agenta w dziesięć minut to naprawdę imponujący wynik.
Jednak ważniejsze od tej szybkości staje się inne pytanie:
Ile czasu zajmuje zrozumienie, dlaczego coś się nie udało?
Środowiska produkcyjne nie nagradzają udanego pierwszego demo.
Karzą za dziesiątą nieudaną próbę.
Narzędzie, które zwraca coś nieoczekiwanego.
Słabszy model bazowy.
Agent, który przekazuje zadania wtedy, gdy nie powinien.
Agent, który nie przekazuje zadań wtedy, gdy powinien.
Agent, który ogłasza „Gotowe”,
mimo że w rzeczywistości nic nie zostało zrobione.
Dokładnie w tym miejscu architektura sprawdza się najskuteczniej.
Czego faktycznie się nauczyliśmy
Refleksjonując nad projektem DEVIN, prawdziwym wnioskiem nie było opanowanie Deep Agents, Daytona czy Ingest jako samodzielnych narzędzi.
Rzeczą kluczową było zrozumienie sposobu, w jaki komponenty systemu agentów łączą się ze sobą.
Następnie TrueForge pokazało, jak szybko te same komponenty można ukryć przed wzrokiem.
A ich użycie ujawniło drugą stronę tej wygody:
Infrastruktura może zniknąć z procesu pracy, bez tego, by zachowanie również zniknęło.
Ktoś nadal musi kontrolować to zachowanie.
Ktoś nadal musi to zobaczyć w praktyce.
Ktoś nadal musi ocenić, czy to działa.
A ktoś nadal musi zdecydować, co zostanie zmienione w przypadku awarii.
To jest odpowiedzialność, którą warto mieć pod kontrolą, a nie zlecać innym.
Którędy zmierza architektura agentów
To doświadczenie przekształca również sposób rozumienia szerszych aspektów rozwoju systemów agentowych.
Dziedzina ta przechodziła przez różne etapy:
modeli → narzędzi → MCP → agentów → zaawansowanych agentów
A na każdym etapie infrastruktura niezbędna do ich działania staje się coraz prostsza w uzyskaniu.
Zgodnie z tą perspektywą najważniejszą warstwą w przyszłości jest infrastruktura otaczająca model.
Nie chodzi tu tylko o surowe możliwości modelu, ale także o system dostarczający mu:
kontekst, narzędzia, wykonywanie, uprawnienia, orkiestracja, pamięć, obserwowalność, ocena i kontrola.
W miarę doskonalenia się modeli sama jakość surowego modelu przestanie być decydującym czynnikiem.
Zapytanie inżynieryjne, które warto postawić, będzie coraz częściej brzmiało:
Jakie środowisko zostało stworzone wokół modelu i jak duży wpływ mamy na jego zachowanie?
To jest chyba najważniejsza lekcja wynikająca z budowy DEVIN oraz późniejszego stworzenia agenta w dziesięć minut.
Im łatwiej jest stworzyć agenta, tym ważniejsze staje się zrozumienie wszystkiego, co go otacza.
Literatura pokrewna
- Co LangChain faktycznie automatyzuje po stworzeniu pętli agenta — Wyjaśnia, w jaki sposób LangChain, LangGraph oraz podobne SDK-y otaczają tę samą podstawową pętlę agenta zbudowaną od zera, oraz kiedy korzystanie z frameworka jest pomocne, a kiedy szkodliwe.
- Wybór frameworku agenta AI dla Python w 2026 roku: praktyczne porównanie — Porównuje pięć frameworków agentów AI w Pythonie pod kątem sposobu radzenia sobie z błędami i złożonością, pomagając czytelnikom dobrać odpowiedni narzędzie do swojego procesu pracy.