Co tak naprawdę automatyzuje LangChain po stworzeniu cyklu agenta
Wyjaśnia, w jaki sposób LangChain, LangGraph oraz podobne SDK-y otaczają ten sam podstawowy cykl agenta stworzony od zera, oraz kiedy korzystanie z frameworka jest pomocne, a kiedy szkodliwe.
Do tego momentu stworzyłeś już całego agenta z surowców — pętlę, pamięć, narzędzia, podagenty, elementy łączące — używając wyłącznie prostego Anthropic SDK. Nie widać tu żadnego frameworku.
To dokładnie ten moment, by porozmawiać o frameworkach, ponieważ teraz dzieje się coś przydatnego: skoro sam zbudowałeś cały mechanizm, żaden framework już nigdy nie będzie dla ciebie tajemniczy.
Nazwy, które ciągle słyszysz
LangChain. LangGraph. LlamaIndex. CrewAI. AutoGen. The OpenAI Agents SDK.
Każdy z nich ma własną terminologię oraz swój sposób pakowania tego, co wydaje się być tą samą podstawową zadaniami. Jeśli jesteś nowicjuszem w tym obszarze, ogromna liczba opcji może wydawać się przytłaczająca.
Istnieje jedno spostrzeżenie, które rozwiewa tę confuzję:
Każdy z tych frameworków otacza tę samą pętlę, którą już zbudowałeś wcześniej w tej serii.
To właśnie jest cała tajemnica. Żaden z nich nie zawiera ukrytej magii. W gruncie rzeczy wszystkie realizują tę samą sekwencję: wysyłanie wiadomości, sprawdzanie przyczyny zatrzymania, wykonywanie narzędzi oraz wprowadzanie powrotnie uzyskanych wyników. To identyczny cykl, który już doskonale znasz.
Wyobraź to sobie jak gotowanie. Gdy już nauczysz się przygotowywać danie z surowych składników, znasz każdy krok, możesz próbować i dostosowywać się w trakcie, a jeśli coś nie smakuje, dokładnie wiesz, co należy zmienić. Framework jest bardziej podobny do zestawu na gotowanie – warzywa są już pokrojone, sos jest przygotowany z góry, a ty po prostu składasz wszystko w ciągu kilku minut. To szybsze, oczywiście. Ale jeśli sos okaże się nieprawidłowy, nie masz sposobu, by to naprawić, ponieważ nigdy go sam nie przygotowałeś i nie wiesz, co się w nim znajduje.
To jest oferta, jaką oferuje każda ramka: oddajesz część kontroli w zamian za większą szybkość.
Zobaczenie tego na własne oczy
Rozważmy ten sam agent zaimplementowany dwa razy — raz ręcznie, a raz za pomocą ramki.
Oto mniej więcej jak wygląda twój agent przy użyciu surowego SDK, wersji, którą teraz w pełni rozumiesz:
messages = [{"role": "user", "content": user_message}]
while True:
# call the API — this runs again every time the model asks for a tool
response = client.messages.create(
model="claude-sonnet-4-6",
tools=tools,
messages=messages,
) # if the model is done, stop
if response.stop_reason == "end_turn":
break # otherwise it asked for a tool: run it, append the result, loop again
messages.append(response_as_message)
messages.append(tool_result_message)
To jest dokładnie pętla wprowadzona wcześniej w serii. Wywołanie API znajduje się wewnątrz pętli while, ponieważ jest wykonywane wielokrotnie — raz dla początkowej odpowiedzi, a potem ponownie po powrocie każdego wyniku narzędzia — aż model da sygnał, że skończył.
Porównaj to teraz z mniej więcej takim samym agentem stworzonym w LangChain:
from langchain.agents import create_agent
agent = create_agent(model="claude-sonnet-4-6", tools=tools)
result = agent.invoke({"messages": [user_message]})
Pięć linii zamiast trzydziestu. Na pierwszy rzut oka wygląda to jak oczywisty ulepszenie.
Zauważ jednak, co zniknęło. Pętla zniknęła. Sprawdzanie wartości stop_reason zniknęło. Ręczna obsługa wiadomości zniknęła. Żadna z tych logik nie zniknęła naprawdę — nadal działają, po prostu są ukryte wewnątrz funkcji create_agent, gdzie już ich nie można zobaczyć.
Gdy wszystko przebiega gładko, oszczędzasz czas. Gdy coś się psuje, utkniesz przy debugowaniu procesu, którego nie możesz przeanalizować.
To napięcie stanowi właściwie całą istotę frameworków. Wszystko inne to jedynie dodatkowe szczegóły.
To, co faktycznie robisz, a to, co robi framework
Oto ta część, która często zaskakuje ludzi. Gdy już używasz frameworka, nigdy nie patrzysz bezpośrednio na stop_reason. Nigdy nie sprawdzasz bloku tool_use. Nigdy ręcznie nie dodajesz wartości tool_result. W ogóle nigdy nie piszesz pętli.
Zamiast tego twoja praca sprowadza się do trzech kroków:
- Napisz funkcje swojego narzędzia dokładnie tak, jak robiłbyś to z surowym SDK.
- Zarejestruj te funkcje u agenta za pomocą czegoś w rodzaju
create_agent(tools=[...]). - Zawołaj
agent.invoke(...)tylko raz.
To cały proces. Połącz narzędzia i uruchom wywołanie tylko raz.
Za tym jednym wywołaniem framework w tle uruchamia cały wcześniej stworzony pętlę: wysyła komunikaty, sprawdza powód zatrzymania, zauważa, że model potrzebuje narzędzia, wywołuje twoją funkcję, dodaje wynik, ponownie wchodzi w pętlę i powtarza ten cykl, aż model w końcu zwróci end_turn. Dopiero wtedy przekazuje ci gotową odpowiedź.
Zatem framework nie tylko ukrywa samą pętlę — ukrywa także cały mechanizm, który sprawia, że wywołania narzędzi w ogóle działają. Osoba ucząca się agentów, zaczynając od frameworka, nawet nie wiedziałaby o istnieniu takiego powodu zatrzymania jak end_turn, ani o tym, że wywołania narzędzi są realizowane poprzez powtarzane iteracje. Dla niej to po prostu wyglądałoby tak, jakby „zarejestrowała narzędzie i zostało ono użyte automatycznie”.
To w porządku, dopóki wywołanie narzędzia nie zaczyna zachowywać się nienormalnie. W tym momencie zostajesz sam przed czarną skrzynką, ponieważ nigdy nie widziałeś działających pod spodem mechanizmów. Ty natomiast zbudowałeś ten mechanizm własnymi rękami. Dokładnie wiesz, co się w nim dzieje.
LangChain, LangGraph — jaka jest różnica?
Często będziesz spotykać oba te nazwy, więc oto krótka wersja.
LangChain to sam framework. Zapewnia definicje narzędzi, połączenia z modelami oraz funkcję create_agent — ten sam skrót umożliwiający ukrycie pętli, o którym mówiono wcześniej.
LangGraph to warstwa wykonawcza niższego poziomu, na której opiera się LangChain. Używa się go wtedy, gdy potrzebna jest większa kontrola — np. wstrzymanie działania agenta, aby człowiek mógł zatwierdzić dany krok, koordynacja logiki rozgałęzień pomiędzy kilkoma agentami lub przechowywanie stanu, aby uszkodzony serwer mógł kontynuować pracę dokładnie od tego miejsca.
Prosty model mentalny: LangChain to szybki, wysokiego poziomu punkt wejścia. LangGraph to narzędzie, do którego się ucieka, gdy ten punkt wejścia nie wystarcza. Od końca 2025 roku LangChain został przeprojektowany w oparciu o LangGraph, więc nie są to już konkurencyjne narzędzia — stanowią dwie warstwy jednego systemu, jedną prostą, a drugą potężną.
Jeśli dopiero zaczynasz, prawdopodobnie jeszcze żadnego z nich nie potrzebujesz. Surowe SDK, które już znasz, może pomóc ci zaskakująco daleko.
Kiedy framework jest przydatny
Frameworki same w sobie nie są pułapką. W niektórych sytuacjach użycie takiego narzędzia jest rzeczywiście właściwym rozwiązaniem.
Potrzebujesz gotowych integracji. Załóżmy, że twój agent musi pobierać dane z magazynu wektorowego Pinecone oraz pliki z Google Drive. Napisanie obu połączeń samodzielnie przy użyciu surowego SDK jest możliwe, ale żmudne. LangChain dostarcza je już przygotowane — wystarczy je importować i podłączyć. To prawdziwa oszczędność czasu.
Budujesz prototyp pod terminem. Twój menedżer chce gotowej demonstracji jutro rano. W takiej sytuacji szczegóły techniczne nie są jeszcze ważne — potrzebujesz szybko czegoś funkcjonalnego. Pięciolinijowa konfiguracja może pomóc ci osiągnąć cel jeszcze dziś wieczorem.
Potrzebna jest orkiestracja naprawdę złożona pod względem budowy. Wyobraź sobie agenta, który w trakcie wykonywania zadania się zatrzymuje, czeka, aż ktoś kliknie „zatwierdź”, zanim uwolni płatność, a następnie kontynuuje dokładnie tam, gdzie przerwał – nawet po ponownym uruchomieniu serwera. Niektóre frameworki oferują takie zachowanie od razu po instalacji. Odtworzenie go od zera wymaga znacznych wysiłków inżynierskich.
Kiedy framework szkodzi
Diagnozowanie błędów staje się trudne. Wyobraź sobie, że twój agent czasami zwraca pustą odpowiedź, a ty nie potrafisz ustalić dlaczego. W kodzie, który sam napisałeś, dodałbyś instrukcję wydruku, prześledził pętlę i znalazł problem w ciągu kilku minut. W ramach frameworka ten sam błąd znajduje się gdzieś w funkcji create_agent – kodzie, który nie należy do ciebie. W końcu musisz przeglądać źródła frameworka na GitHubie, tylko po to, by zrozumieć, co robi twój własny agent.
Abstrakcja zaczyna przeciekać. Frameworki są optymalizowane pod typowe przypadki użycia. Załóżmy, że potrzebujesz wyników narzędzia w niestandardowym formacie lub polityki ponownych prób dostosowanej do Twojej specyficznej konfiguracji. Framework nigdy tego nie przewidział. Teraz musisz stosować nietypowe rozwiązania, by zmusić go do wykonywania czegoś, co trzydzieści linii Twojego własnego kodu mogłoby załatwić bezpośrednio.
Ostatecznie uczysz się narzędzia zamiast samego koncepcji. Rozpoczynanie pracy od frameworka uczy Cię „jak działa LangChain”, a nie tego, jak faktycznie funkcjonują agenci. Następnie API LangChain ulega zmianom – co zresztą dzieje się wielokrotnie – a Twoja wiedza staje się przestarzała błyskawicznie. Pętla omówiona wcześniej w tej serii nie uległa zmianie od chwili pierwszego stworzenia agentów i tak też pozostanie.
Zasada, której warto przestrzegać
Zacznij od surowego SDK. Zbuduj pętlę ręcznie. W ten sposób dokładnie wiesz, co robi twój agent, i możesz prześledzić każdą linię kodu, gdy coś się zepsuje. Dla większości agentów to rzeczywiście wszystko, czego kiedykolwiek będziesz potrzebował.
Wdroż framework tylko wtedy, gdy lepiej rozwiązuje jakiś konkretny problem niż ty sam — gotową integrację, stan, który przetrwa awarię, kroki zatwierdzania przez człowieka. Używaj go celowo, z tego dokładnego powodu, a nie jako standardu.
Nie sięgaj po framework tylko po to, by pominąć naukę budowy pętli. To jest prawdziwa pułapka. Pominąwszy ten krok, skończysz z „czarną skrzynką” opartą na ideach, których tak naprawdę nigdy nie przyswoiłeś.
Najpierw zrozum pętlę. Dopiero potem framework staje się narzędziem, które wybierasz celowo — a nie podpórką, na którą polegasz, ponieważ nigdy nie opanowałeś podstaw.
Dlaczego ta seria buduje wszystko od zera
To właśnie jest powód, dla którego do teraz odkładano użycie frameworków.
Gdyby ta seria zaczynała się od instrukcji „zainstaluj LangChain, wywołaj create_agent”, mielibyśmy działającego agenta, ale bez rzeczywistego zrozumienia jego funkcjonowania. Nie wiedzielibyśmy, czym jest blok tool_use, dlaczego wyniki z równoległych wywołań narzędzi są łączone w jedną wiadomość, ani dlaczego logika autoryzacji znajduje się w hooku.
Ponieważ ta podstawa już należy do ciebie, słownictwo dowolnego frameworka można natychmiast przetłumaczyć. To, co nazywa „agentem”, to w rzeczywistości ten sam mechanizm działający w tle. To, co określa jako „pamięć”, to nic innego jak lista komunikatów, którą już znasz. To, co oznacza jako „narzędzia”, bezpośrednio odpowiada blokom tool_use, którymi zarządzasz ręcznie. A to, co promuje jako „middleware”, to po prostu inna nazwa dla hakenów, które sam stworzyłeś.
To właśnie jest pożądana pozycja. Nie „Znam LangChain” – ale „Rozumiem, jak działają agenci, a LangChain to tylko jeden ze sposobów na to wyrażenie”.
Frameworki będą się dalej rozwijać. Co kilka miesięcy pojawiają się nowe. Mechanizm działający w tle pozostaje niezmienny. Buduj swoją wiedzę na tej części, która się nie zmienia.
Literatura pokrewna
- Chatbot vs AI Agent: Co Właściwie Rozdziela Je Poza LLM — Dowiedz się, dlaczego rzeczywista różnica między chatbotami a agentami AI leży w architekturze otaczającego systemu — narzędziach, planowaniu i działaniach — a nie w samym LLM.
- Zrozumienie Agentów AI: Cele, Narzędzia, Pamięć i Petla Agenta — Przystępne dla początkujących wyjaśnienie, w jaki sposób agenci AI różnią się od chatbotów, obejmujące podstawowe komponenty, pętlę decyzyjną, poziomy autonomii oraz praktyczne zastosowania w rzeczywistym świecie.