Pętle kontra grafy: dwa sposoby projektowania agentów AI
Inżynieria pętli a inżynieria grafu dla agentów AI: jak działa każda z tych architektur, kiedy wybrać jedną zamiast drugiej oraz lista kontrolna przed wdrożeniem w produkcję.
Źródła: Loop Engineering vs. Graph Engineering: The Architecture Shift Quietly Reshaping AI Agents
Dwa modne terminy, jedno pytanie dotyczące architektury
Każdy, kto śledzi agenty AI, które przeszukują internet, używają narzędzi, piszą kod lub samodzielnie uruchamiają procesy, prawdopodobnie ostatnio spotkał dwa takie terminy: inżynieria pętli i inżynieria grafów. Brzmią jak elementy marketingu, ale odnoszą się do rzeczywistej decyzji strukturalnej.
Rozważmy agenta, który zużywa 40 000 tokenów oraz sześć minut czasu rzeczywistego na rozwiązanie pytania, które powinno zostać rozstrzygnięte w trzech krokach. Nie ma nic nie tak z modelem ani z zadanym promptem – problem leży w projekcie, ponieważ agent nie potrafi stwierdzić, że już coś próbował. Po prostu powtarza sekwencję myślenie, działanie, obserwacja, bez żadnego zapisu tego, jak wygląda jego własny proces.
Tego typu problemy przenoszą projektowanie agentów poza kategorię promptowania do architektury oprogramowania. Gdy spojrzymy na to w ten sposób, niemal każdy wdrożony system agentów opiera się na jednym z dwóch wzorców: pętlach i grafach. W dalszej części omówimy, czym są one, jak są budowane, gdzie napotykają problemy oraz dlaczego przejście z jednego wzorca na drugi zmienia sposób, w jaki inżynierowie podchodzą do tych systemów, poza zwykłą zamianą narzędzi.
Co tak naprawdę robi agent
W danym momencie agent wykonuje jedną z trzech czynności: myśli (wywołanie modelu językowego), działa (wywołanie narzędzia) lub decyduje, co nastąpi dalej. Inżynieria agentów polega głównie na połączeniu tych trzech elementów ze sobą.
W pierwszych latach istnienia agentów LLM prawie wszyscy konfigurowali je w ten sam sposób, jako pętlę. Był to oczywisty wybór. Agenty w stylu ReAct funkcjonowały w ten sposób od samego początku, a tak też opisuje Anthropic najprostszego agenta: model używający narzędzi samodzielnie w ramach pętli.
Później agenty otrzymywały dłuższe i bardziej skomplikowane zadania: kilka specjalistycznych podagentów, próby ponowne, zatwierdzenia przez ludzi oraz złożone reguły biznesowe. Jedna pętla zaczęła nie radzić sobie z tym obciążeniem. Zespoły chciały analizować strukturę procesu, zamiast polegać na tym, że pętla ostatecznie doprowadzi do rozwiązania, a ta potrzeba doprowadziła do powstania inżynierii grafów, która przedstawia proces za pomocą węzłów i krawędzi, nie pozostawiając go w sferze powtarzających się iteracji.
Żaden z tych modeli nie jest błędny. Rozwiązują one różne problemy, więc każdy zasługuje na dokładną analizę.
Analogia z kuchni
Wyobraź sobie, że uczysz kogoś gotować. Inżynieria pętli polega na powtarzaniu jednej instrukcji: spróbuj zupy, dodaj sól, jeśli jest to konieczne, spróbuj ponownie i kontynuuj, aż będzie dobrze. To jeden cykl składający się z działania, sprawdzenia i ewentualnego powtórzenia. Proste, przewidywalne i łatwe do zrozumienia.
Inżynieria grafów przypomina pełny przepis z odgałęzieniami. Pokrój warzywa, podczas gdy ktoś inny zagotuje wodę. Gdy obie rzeczy będą gotowe, połącz je. Jeśli osoba smakująca chce więcej przypraw, odesłaj garnek z powrotem do etapu doprawiania, w przeciwnym razie podawaj danie. Tutaj nie ma jednej linii kroków – istnieje kilka ścieżek, niektóre kroki wykonywane są jednocześnie, inne zależą od decyzji, a tylko niektóre powracają w obrocie, gdy coś jest nie tak.
Co oznacza inżynieria pętli
Pętla to najprostszy i podstawowy sposób na stworzenie agenta. Działa w jednym ciągłym cyklu:
- Przyjmij dane wejściowe, czyli pytanie lub cel użytkownika.
- Rozważ, co robić dalej – to jest krok rozumowania modelu.
- Działaj, co zazwyczaj oznacza wywołanie narzędzia, uruchomienie kodu lub poszukiwanie informacji.
- Obserwuj, jaki efekt przyniosła ta akcja.
- Wróć do kroku 2 i kontynuuj, aż agent uzna, że cel został osiągnięty.
Ludzie często nazywają to cyklem myślenia, działania i obserwacji, a wiele z pierwszych agentów zostało zbudowanych na jego podstawie. W ramach ćwiczeń inżynieria pętli traktuje agenta jako pojedynczy, powtarzający się cykl: model rozumuje, wybiera akcję, ją wykonuje, analizuje wynik i zapisuje go z powrotem do swojego kontekstu, a następnie zaczyna od nowa, dopóki nie stwierdzi, że zadanie zostało zakończone lub osiągnięto limit.
Kilka punktów wyjaśnia jego popularność:
- Laymanowskim przykładem jest dobrze znany wzorzec ReAct (rozumowanie połączone z działaniem) zaproponowany przez Yao i jego współpracowników, w którym ślady rozumowania są łączone z działaniami, a model nie musi najpierw dokończyć całego procesu myślenia.
- Większość frameworki dla agentów definiuje „agenta” w ten sam sposób – jako jeden pętla sterująca z wspólnym oknem kontekstowym oraz interfejsem do wywoływania narzędzi.
- Jego napisanie zajmuje zaledwie kilka linijek kodu. Stanem jest dotychczasowa rozmowa, a istnieje tylko jedno warunek zakończenia. Asystent do kodowania, który edytuje pliki, lub agent badawczy, który szuka odpowiedzi, aż będzie zadowolony, nie wymagają niczego bardziej skomplikowanego.
- Wskazówki firmy Anthropic mówią o tym jasno: zacznij od najprostszego rozwiązania, które działa, i dodawaj strukturę tylko wtedy, gdy tego wymaga zadanie.
Problem polega na tym, że wszystko, co pętla musi rozważyć – w tym to, co już próbowała, co się nie udało oraz jaki był cel – musi znajdować się w jednym stale rosnącym oknie kontekstowym. Proces nie ma oddzielnego pamięci. Zachowuje jedynie transkrypcję.
Jak składa się pętla
Przepływ działa od początku do końca w ten sposób.
Kroki realizacji:
- Zadanie użytkownika uruchamia pętlę z określonym celem.
- W kroku rozważań model czyta instrukcje systemu, historię rozmowy oraz najnowsze obserwacje, a następnie decyduje, co nastąpi dalej.
- Sprawdzenie „czy zadanie jest zakończone?” nie stanowi odrębnego systemu. Sam model decyduje, na podstawie swojego kontekstu, czy zadanie zostało ukończone.
- Jeśli zadanie nie jest zakończone, model wybiera narzędzie i je uruchamia.
- Rezultat lub błąd narzędzia jest zwracany jako obserwacja.
- To spostrzeżenie jest dodawane do kontekstu, a cykl rozpoczyna się na nowo po każdym przetworzeniu, posiadając nieco dłuższą historię.
- Gdy model oceni wykonaną pracę, pętla się kończy i zwraca ostateczną odpowiedź.
Kompaktowa wersja w Pythonie pokazuje, jak mało kodu jest w tym potrzebne.
def run_agent(task: str, tools: list, max_iterations: int = 10) -> str:
context = [{"role": "user", "content": task}]
for step in range(max_iterations):
response = llm.generate(context, tools=tools)
if response.is_final_answer:
return response.content
tool_result = execute_tool(response.tool_call)
context.append({"role": "assistant", "content": response.content})
context.append({"role": "tool", "content": tool_result})
return "Stopped: max iterations reached"
Co oznacza inżynieria grafów
Inżynieria grafów wyraźnie przedstawia proces agenta. Jest to zbiór węzłów, z których każdy stanowi jednostkę pracy, taką jak wywołanie LLM, wywołanie narzędzia lub fragment logiki biznesowej, połączonych krawędziami, które mogą być stałe lub warunkowe. Wszystkie węzły czytają i zapisują dane do jednego wspólnego, typowanego obiektu stanu. Krótko mówiąc, przepływ pracy staje się mapą połączonych kroków z ścieżkami między nimi, zastępując pojedynczy cykl powtarzalny.
Węzeł może być jednym z następujących:
- agentem, specjalistyczną sztuczną inteligencją pełniącą określoną funkcję, taką jak badania, pisanie lub analiza
- wywołaniem narzędzia, na przykład wyszukiwaniem w internecie, obliczeniem lub zapytaniem do bazy danych
- punktem decyzyjnym, który wybiera następną ścieżkę
- punktem łączenia, który łączy wyniki z kilku ścieżek
Wiele ścieżek może być wykonywanych równolegle, a inne są warunkowe i są realizowane tylko wtedy, gdy test się powiedzie. Pętle nadal są możliwe, ale pojawiają się tylko tam, gdzie są potrzebne, jako kontrolowane rozwiązanie, które powraca do poprzednich kroków, a nie bezrefleksyjnie powtarza wszystko od nowa.
Dlaczego grafy są atrakcyjne
- Równoległość. Niezależne zadania mogą być wykonywane jednocześnie i nie muszą czekać w kolejce.
- Rozgałęzianie. Przepływ pracy może zmierzać w różnych kierunkach w zależności od sytuacji, zamiast powtarzać te same kroki.
- Specjalizacja. Każdy węzeł może być samodzielnym, wyspecjalizowanym elementem o jednym kluczowym zadaniu, co jest bliższe sposobowi, w jaki zespół ludzi dzieli prace.
- Celowe ponawiania. Gdy np. kontrola jakości się nie powiedzie, tylko ten konkretny krok wysyła pracę do ponownego wykonania, a wszystko inne pozostaje nietknięte.
- Widoczność. Ponieważ proces pracy jest przedstawiony jako mapa, łatwiej jest zobaczyć, gdzie doszło do błędu i który ścieżka została wybrana.
LangGraph to framework oparty na tej koncepcji, który modeluje procesy pracy jako stanowe, cykliczne grafy skierowane. Graf może nadal zawierać pętle, ponieważ węzeł może mieć krawędź prowadzącą z powrotem do wcześniejszego węzła, dzięki czemu możliwe są ponowne próby i iteracje. Zmienia się to tym, że pętla staje się jedną z wielu krawędzi na mapie, którą można oglądać, i przestaje stanowić całą architekturę.
To dobrze pokrywa się z rozróżnieniem, jakie Anthropic czyni pomiędzy przepływami pracy – w których modele językowe i narzędzia podążają za z góry zdefiniowanymi ścieżkami kodu kontrolowanymi przez programistów – a agentami, w których model dynamicznie kieruje własnym procesem. Graf może przedstawić obie te koncepcje w jednej strukturze: ze stałymi ścieżkami, gdzie ważna jest przewidywalność, oraz gałęziami kierowanymi przez model, gdzie przydatna jest elastyczność, a różnica jest widoczna na diagramie.
Jak składa się graf
Weźmy ten sam rodzaj problemu – agenta, który musi przeprowadzić badania, napisać kod i przejrzeć swój własny wynik, a następnie przekształcić to w graf.
Krok po kroku:
- START to punkt wejścia do grafu.
- Węzeł routera odczytuje aktualny stan i wybiera ścieżkę. Może to być zwykłe
if/elselub wywołanie modelu językowego, które klasyfikuje żądanie. - Trzy specjalistyczne węzły – agent badawczy, agent kodowy i agent recenzujący – są każdy samodzielny: odczytują stan, wykonywają swoje zadanie i zapisują wyniki z powrotem.
- Węzeł agregujący lub łączący łączy wszystko, co wygenerowała zrealizowana gałąź, w jeden spójny obiekt stanu.
- Krawędź przetwarzająca ponowne próby radzi sobie z niepowodzeniami recenzji. Gdy walidacja przeprowadzona przez agenta recenzującego się nie powiedzie, specjalna krawędź kieruje sygnał z powrotem do routera, a ten sam model nie jest po prostu ponownie proszony o działanie. Ścieżka jest widoczna na grafie i nie jest ukryta w linii instrukcji typu „jeśli to się nie uda, spróbuj ponownie.”
- Stan osiąga punkt END po przejściu walidacji.
Oto uproszczony pseudokod w stylu, który najczęściej przyjmuje większość frameworki grafowych.
from graph_engine import StateGraph, START, END
def router(state: dict) -> str:
return state["task_type"] # "research" | "code" | "review"
def research_agent(state: dict) -> dict:
state["results"]["research"] = do_research(state["query"])
return state
def code_agent(state: dict) -> dict:
state["results"]["code"] = write_code(state["query"])
return state
def review_agent(state: dict) -> dict:
state["valid"] = validate(state["results"])
return state
def aggregator(state: dict) -> dict:
state["final_output"] = merge(state["results"])
return state
graph = StateGraph(schema=AgentState)
graph.add_node("router", router)
graph.add_node("research_agent", research_agent)
graph.add_node("code_agent", code_agent)
graph.add_node("review_agent", review_agent)
graph.add_node("aggregator", aggregator)
graph.add_conditional_edges("router", {
"research": "research_agent",
"code": "code_agent",
"review": "review_agent",
})
graph.add_edge(["research_agent", "code_agent", "review_agent"], "aggregator")
graph.add_conditional_edges("aggregator", {
"valid": END,
"invalid": "router", # explicit retry edge
})
app = graph.compile()
app.invoke({"query": "...", "results": {}, "task_type": "code"})
Umieszczenie obu wzorców obok siebie ułatwia dostrzeżenie kontrastu.
Dlaczego branża przechodzi od pętli do grafów
Ta zmiana nie nastąpiła nagle. Pętle napotkały prawdziwe ograniczenia, gdy ludzie próbowali budować bardziej ambitne systemy, z kilku powodów.
Prawdziwa praca nie przebiega w linii prostej. Badania, obsługa klienta, analiza finansowa oraz procesy tworzenia treści wszystkie się rozgałęziają. Jeśli chodzi o faktury, trzeba podjąć jedną drogę, a jeśli to problem techniczny – inną. Pętla spycha to wszystko w jedną długą łańcuch warunków, co szybko staje się chaotyczne.
Systemy wieloagentowe wymagały lepszej struktury. Gdy system miał kilku agentów, na przykład badacza, podsumowującego i sprawdzającego fakty, jedna pętla nie mogła określić, że dwa agenci powinni pracować jednocześnie lub że jeden powinien działać tylko wtedy, gdy sprawdzenie się nie powiedzie. Graf naturalnie to uwzględnia.
Z upływem czasu ważniejsza staje się widoczność i zaufanie. Kiedy agenci zajmowali się zadaniami o wysokim stopniu ryzyka, zespoły potrzebowały szczegółowego przeglądu tego, co się wydarzyło. Można narysować wykres, który wskazuje dokładnie, gdzie proces przebiegł pomyślnie, a gdzie nieudolnie, podczas gdy pętla to nieprzezroczysty blok, który wykonywał identyczny kod dwadzieścia razy.
Koszt i szybkość. Każda zmarnowana iteracja zużywa czas, a często także prawdziwe pieniądze, ponieważ każdy krok rozumowania to wywołanie modelu językowego. Wykonywanie niezależnych kroków równolegle oraz powrót tylko do tej części, która wymaga ponownego przetworzenia, jest po prostu bardziej efektywne.
Testowanie i konserwacja stają się prostsze. Można budować, testować i modyfikować węzeł wykresu krok po kroku. Łącznie skonstruowana pętla to zazwyczaj logika typu wszystko albo nic, więc bezpieczna modyfikacja po uruchomieniu jest trudniejsza.
Wybór między nimi
Poniżej przedstawiono przybliżoną ramę decyzyjną.
Wybierz pętlę, gdy:
- zadanie ma jeden cel: jeden agent, jeden cel oraz jeden zestaw narzędzi
- wcześniejszy prototyp musi zostać sprawdzony, zanim wydano jakiekolwiek pieniądze na architekturę
- liczba kroków jest niska i dość przewidywalna
- jedna osoba odpowiada za całość i nic nie musi być przekazywane innemu zespołowi
Należy użyć grafu wtedy, gdy:
- angażowane są dwa lub więcej specjalistycznych agentów lub ról
- konieczne jest sprawdzalne rejestrowanie prób ponownych, alternatyw lub zatwierdzeń przez ludzi
- części procesu mogą działać równolegle, a później muszą zostać połączone
- konieczne jest śledzenie wykonywania, tworzenie punktów kontrolnych lub wznowienie z określonego momentu, czego nie może zapewnić ponowne odtworzenie transkrypcji
- oddzielne osoby lub zespoły odpowiadają za oddzielne segmenty, przy czym graf służy jako umowa między nimi
Oto przydatna weryfikacja. Jeśli kod pętli zawiera komentarz w stylu „w tym momencie powinniśmy już spróbować X”, to oznaka, że źle modelujesz graf wewnątrz pętli, i prawdopodobnie nadszedł czas, aby narysować ten graf.
To nie jest tak naprawdę wybór typu „albo to, albo tamto”. Chodzi o dostosowanie narzędzia do zadania. Prosty chatbot odpowiadający na pytania po jednym lub mały skrypt powtarzający jedną konkretne czynność aż do zakończenia pasują do pętli. Zadanie z kilkoma rozgałęzieniami, wieloma współpracującymi specjalistycznymi agentami, pracą możliwą do równoległego wykonywania lub potrzebą jasnej widoczności tego, co się stało i dlaczego, pasuje do grafu. Rozsądnym standardem jest rozpoczęcie od pętli i przejście na graf w momencie, gdy logika typu „jeśli to, to tamto” staje się trudna do zrozumienia.
Lista kontrolna przed wdrożeniem
Zanim wdrożysz którykolwiek z tych wzorów, te nawyki przyniosą korzyści:
- Ustal granice kroków. Oba wzory wymagają mechanizmu awaryjnego wyłączania, ponieważ agent bez ograniczeń nie ma górnej granicy kosztów.
- Uczynij test „zakończenia” możliwym do sprawdzenia. Warunek zakończenia powinien być czymś, co można sprawdzić za pomocą testu, a nie domysłem tworzonym przez model.
- Zinstrumentuj każdy krok. Każde wezwanie LLM oraz każde wezwanie narzędzia powinno mieć własny obszar pomiarowy OpenTelemetry lub podobny; unikaj jednego obszaru pomiarowego dla całego procesu.
- Zastosuj wersjonowanie grafu. Przechowuj definicje w systemie kontroli wersji, tak jak każdy kod, ponieważ nawet niewielka zmiana w łączach może cicho wpłynąć na zachowanie systemu.
- Waliduj stan na granicach węzłów. Sprawdzaj schematy typowe dla stanu przy wchodzeniu i wychodzeniu z każdego węzła, aby usunąć dane nieprawidłowe na wczesnym etapie.
Co jest najważniejsze
Pętla to najprostszy projekt – składa się z jednego kontekstu, jednego cyklu, a model steruje przepływem danych. Nadaje się do zastosowań ograniczonych, o jednoznacznym celu. Graf natomiast opisuje proces poprzez węzły, określone stany oraz krawędzie, które można rysować, rozgałęziać, wykonywać równolegle oraz celowo ponawiać.
Głębsza zmiana polega nie na tym, że wykresy są lepsze. Chodzi o przejście od myślenia proceduralnego, polegającego na pytaniu o to, co nastąpi dalej, do myślenia deklaratywnego, polegającego na pytaniu o to, jaka jest forma systemu. Wykresy dobrze współpracują z mechanizmami śledzenia i obserwowalności, których potrzebują systemy produkcyjne, natomiast pętle dobrze pasują do szybkiej iteracji.
Większość systemów produkcyjnych ostatecznie przybiera postać wykresów zbudowanych z pętli, czyli w zasadzie maszyn stanowych, których węzłami są małe cykle w stylu ReAct. To sprawia, że te dwa wzorce stanowią różne poziomy szczegółowości tej samej architektury, a nie konkurencję. W przypadku każdego obecnego projektu opartego na agentach słusznym pytaniem jest to, czy wszystko nadal działa jako jedna długa pętla, czy nadszedł czas, by przedstawić to w formie wykresu.
Literatura pokrewna
- Od pętli agentów do grafów przepływów pracy: typowane stany, bramy dowodowe i ograniczona odzyskiwalność — Dlaczego agenci działające przez długi czas przekraczają możliwości pojedynczej pętli oraz jak wyraźne węzły, krawędzie, typowane artefakty, zweryfikowane przejścia i uprawnienia dla poszczególnych węzłów sprawiają, że są one niezawodne.
- Inżynieria Agent Harness: stan, weryfikacja i kontrola wokół modelu — Perspektywa runtime na agenty produkcyjne: dlaczego prompty i kontekst nie wystarczają oraz jak trwały stan, egzekwowanie zasad, weryfikacja i możliwości obserwacji zamierzają tę luki.