Eskaluj węzły, a nie zadania: sześciostopniowa drabina do kontrolowania kosztów procesu pracy LLM

Many teams building LLM-powered pipelines start with a single architectural question for every new feature: should this run as a fixed DAG or as an autonomous agent? It sounds like a sensible design review, but answering it at the level of a whole task quietly locks in the cost of the most uncertain step for every other step. This article walks through how that happens, then presents a six-level escalation ladder in which each node starts at the cheapest viable level and climbs only when an explicit contract fails. By the end you should be able to decompose your own "agent" tasks, see how much of them is actually deterministic, and put hard bounds on what the rest may spend.

Przyjętym w całym tekście scenariuszem jest produkt, który wykonywa dwa zadania: konwertuje codzienne formaty plików oraz uruchamia procesy typu „pliki wejściowe – pliki wyjściowe”, zarówno w formie jedno-klikowych pipeline’ów, jak i za pomocą narzędzia generującego takie pipeline’y na podstawie żądania napisanego w języku potocznym. Część związana z konwersją działa niezawodnie. To natomiast w części dotyczącej procesów workflow pojawiał się ciągle problem związany z wyborem między DAG a agentem, i dopiero po prawie roku udało się stwierdzić, że sam ten problem stanowił przyczynę trudności.

Punkt wyjścia: klasyfikacja każdego zadań z góry

Początkowy proces tworzenia każdego jedno-klikowego workflow był metodyczny – najpierw przeprowadzano badania przypadku użycia, pisano specyfikację, a następnie osoba odpowiedzialna decydowała, czy pipeline ma być zaimplementowany jako DAG, czy jako agent.

Zadania otwarte trafiały do agenta

Zadania uznane za prawdziwie otwarte zostały zaimplementowane jako pojedynczy agent ReAct na LangGraph. Przykładem referencyjnym była poszukiwana praca oparta na CV. Użytkownik przesyła swoje CV, a system musi znaleźć odpowiednie stanowiska do aplikowania oraz przygotować dostosowane CV dla każdego z nich. Obejmuje to CV napisane w kilku językach, dopasowywanie kandydatów do stanowisk na podstawie wymiarów, których nie da się uchwycić za pomocą słów kluczowych (czas dojazdu z domu, skład zespołu, codzienne obowiązki na stanowisku, przedział wynagrodzeń) oraz ostatecznie tworzenie spersonalizowanego dokumentu. Nikt nie może z góry powiedzieć, ile kroków to zajmie, więc wyglądało to jak typowy przykład z podręcznika dla agenta.

Zadania przewidywalne trafiły do statycznego DAG

Praca sekwencyjna, przewidywalna stała się ustalonym grafem. Przykładem była konwersja filmu na napisy: wyodrębnienie ścieżki dźwiękowej, zastosowanie rozpoznawania mowy, podział transkrypcji na segmenty z określonym czasem trwania oraz utworzenie pliku z napisami. Nawet dodatkowe elementy mogły być wymienione z góry, takie jak uporządkowanie dosłownej transkrypcji dla lepszej czytelności lub sprawdzenie, czy stwierdzenia faktyczne w prezentacji są prawdziwe. Ponieważ każda decyzja może zostać podjęta przed rozpoczęciem wykonywania, cały graf może zostać narysowany jeszcze przed jego rozpoczęciem.

Rozdzielenie zadań wydawało się racjonalne i zostało wdrożone. Problem polegał na tym, że koszty nigdy nie spadały.

Dlaczego podatek od agentów nigdy nie znika

Mechanizm stojący za liniowym wykresem kosztów jest zwyczajny, co właśnie sprawia, że łatwo o nim zapomnieć.

Gdy zadanie jest oznaczone jako „agent”, każdy krok w jego obrębie wykonywany jest w ramach pętli agenta i generuje za niego koszt. Pętla ReAct może wybrać akcję tylko wtedy, gdy schematy jej narzędzi znajdują się w oknie kontekstowym. Można skompresować rozmowę, streszczać stan pośredni oraz uprościć uzyskane dokumenty – zespół robił wszystko to, ale minimalny koszt na jeden ruch pozostaje niezmienny, ponieważ stanowi on blok schematów narzędzi i jest przesyłany na każdym ruchu. Nie można też po prostu dać agentowi mniej narzędzi, jeśli chce się zachować jego elastyczność: powodem, dla którego jest to agent, jest fakt, że nikt z góry nie wie, jakie narzędzia będą potrzebne podczas danej sesji.

Jednym z rozwiązań jest przewidywanie odpowiedniego podzestawu narzędzi dla każdego zadania. To uzasadniony kierunek badań, ale wymaga własnych inwestycji oraz modelu, który dobrze radzi sobie z przewidywaniami. Zespół natomiast szukał czegoś, co można było by jasno określić: architektury, której koszt jest ograniczony sposobem jej budowy, a nie dokładnością predyktora. Jeśli interesuje cię ta droga rozwiązania, temat postępowego odkrywania narzędzi dla agentów w skali przemysłowej omawia go szczegółowo.

Ponowne przeczytanie literatury naukowej w połączeniu z miesiącami записów z działania systemu doprowadziło do niemal żenująco prostego wniosku:

Niepewność dotyczy poszczególnych węzłów, a nie całych zadań.

Decyzja dotycząca użycia DAG czy agenta była podejmowana dla każdego zadań osobno. Jednak zadanie to po prostu zbiór kroków, a w niemal każdym zadaniu sklasyfikowanym jako „agent” większość kroków była całkowicie deterministyczna. Podejmowanie decyzji na poziomie zadania oznacza, że każdy węzeł płaci cenę najbardziej niepewnego węzła w grafie.

Gdy rozłożymy na czynniki pierwsze proces poszukiwania pracy, wzorzec staje się oczywisty:

• Wyciąganie ustrukturyzowanych danych z CV w formacie PDF nie wymaga żadnego rozumowania opartego na modelu.
• Identyfikacja języka użytego w CV jest równie mechaniczna.
• Znalezienie adresu zamieszkania i obliczenie czasu dojazdu to jedna tylko interakcja z narzędziem.
• Pobieranie dostępnych ofert pracy oznacza korzystanie z API do prac.
• Ocena tego, jak dobrze dana pozycja pasuje do danego kandydata, wymaga jednego żądania od modelu, ustalonego promptu i żadnych narzędzi.

Tylko coś w rodzaju „dowiedz się, co ta konkretna zespół dostarcza ostatnio” nie ma przewidywalnej liczby kroków.

Ostatni punkt to jeden węzeł. Cały graf musiał płacić ceny agenta, aby go obsłużyć.

Skrzynka eskalacji

Rozwiązaniem było zaprzestanie podejmowania decyzji z góry. Zgodnie z nową zasadą każdy proces rozpoczyna się od najtańszego poziomu, który może funkcjonować, a tylko te pojedyncze węzły, które zawodzą, przechodzą na wyższy poziom. Istnieje sześć poziomów.

• L0: tylko wywołania narzędzi, bez LLM. Jeśli żądanie można w pełni zrealizować za pomocą operacji deterministycznych, żaden model nie jest uruchamiany. W produkcie jest to istniejąca szybka ścieżka i pozostaje odrębną opcją. Koszt to po prostu wywołania narzędzi.
• L1: statyczny DAG mechanicznych węzłów. Prawdziwy graf z rozgałęzieniami i rozprzestrzenianiem się, ale każdy węzeł to zwykły kod. Nadal nie ma wywołań modeli.
• L2: statyczna DAG z węzłami LLM typu single-shot. Kształt grafu pozostaje niezmieniony, ale niektóre węzły teraz wywołują model raz, przy bardzo ograniczonym kontekście. W praktyce węzeł otrzymuje tylko swoje bezpośrednie dane wejściowe – żadnej historii rozmowy, żadnego stanu globalnego oraz, co kluczowe, żadnych schematów narzędzi. Na tym poziomie model zachowuje się jak funkcja czysta, a nie jako agent. Koszt wynosi O(n) wywołań, przy czym wartość n jest znana przed rozpoczęciem wykonywania.
• L3: pętle udoskonalania z ograniczeniem. Węzeł L2 może próbować ponownie zgodnie z umową maksymalnie N razy. To umowa, a nie model, decyduje o tym, czy wynik jest akceptowalny. Koszt wynosi O(n·N), co również jest znane przed rozpoczęciem wykonywania.
• L4: nieprzezroczysty węzeł staje się podagentem. Węzeł, którego nie można określić z góry, otrzymuje rzeczywisty pętlę ReAct, ale jego narzędzia są ograniczone do tego węzła i ma ustalony budżet kroków. Nikt nie może przewidzieć, ile go to kosztować, a ta nieprzewidywalność jest powodem, dla którego musi istnieć wyraźny limit.
• L5: całkowite przeplanowanie. Sam plan był błędny, więc gra jest odbudowywana. Jest to najdroższa możliwa opcja i powinna występować rzadko.

Umowy, zakres i budżety

Sama taksonomia byłaby jedynie lepszą terminologią. To trzy mechanizmy sprawiają, że ta struktura faktycznie funkcjonuje:

• Umowy uruchamiają eskalację. Każdy węzeł określa kształt akceptowalnego wyniku, a jedynie nieudana weryfikacja tego wymogu uzasadnia przejście na wyższy poziom.
• Zakres utrzymuje koszty poziomu L4 na przystępnych poziomach. Schematy narzędzi podagenta znajdują się w kontekście tego jednego węzła i nie pojawiają się nigdzie indziej podczas wykonywania, dzięki czemu opłata za schematy jest płatna lokalnie.
• Budżety ustalają górny limit. Każdy poziom powyżej L2 ma maksymalną liczbę prób lub kroków, po których węzeł albo rezygnuje, albo przechodzi do kolejnego poziomu.

Praktyczne podejście do tego tematu: kontrakt odpowiada na pytanie „czy to wystarczająco dobre?”, zakres na pytanie „co ten węzeł może zobaczyć i wywołać?”, a budżet na pytanie „ile może on wydać na próby?”. Jeśli brakuje któregokolwiek z tych trzech elementów, odpowiedni poziom traci możliwość przewidywania. Aby dowiedzieć się więcej na temat kontrolowania pętli takich jak L3 i L4 w kodzie, zapoznaj się z ograniczonymi pętlami agentowymi w TypeScript.

Krok po kroku w procesie tworzenia napisów

Większość przetworzeń nigdy nie opuszcza poziomu L1. Proces ten wyodrębnia dźwięk, przeprowadza rozpoznawanie mowy, dzieli materiał według danych czasowych i tworzy plik SRT, wszystko to bez żadnego wywołania modelu. Wynik jest następnie sprawdzany pod kątem określonych zasad: napisy nie mogą się nakładać, żadny wiersz nie może przekroczyć limitu znaków, a szybkość odczytu musi pozostać poniżej ustalonego progu. Typowe wideo z głową mówiącą i czystym dźwiękiem przechodzi sprawdzenie, a koszt przetworzenia nie przekracza wartości odpowiadającej użyciu ffmpeg plus jednego przejścia przez proces rozpoznawania mowy.

Gdy dany napis narusza zasady dotyczące długości wiersza lub czytelności, tylko ten napis przechodzi na poziom L2. Wtedy następuje jedno wywołanie modelu, którego kontekstem są ten napis oraz jego bezpośrednie sąsiedzi. Pełny transkrypt, metadane wideo oraz schematy wszystkich narzędzi nie są uwzględniane w instrukcjach, a reszta struktury pozostaje nietknięta.

L3 jest uzasadniony terminologią. W prezentacji technicznej, która zawiera glosariusz, sprawdzanie terminologii może nadal zawodzić po pojedynczej korekcie, więc dany węzeł może udoskonalić swój wynik dokładnie dwa razy, przy czym to sprawdzenie z glosariuszem decyduje o tym, czy wynik jest akceptowalny.

L4 występuje tylko w jednym miejscu: przy weryfikacji poprawności twierdzeń przedstawionych w prezentacji. Wymaga to przeszukiwania, a nikt nie może określić, ile takich przeszukań będzie potrzebnych. Dlatego ten pojedynczy węzeł staje się podagentem, którego narzędzia ograniczają się do wyszukiwania i pobierania danych, a liczba jego kroków jest ograniczona. Otaczający go proces przetwarzania pozostaje mechaniczny.

L5 zajmuje się przypadkiem, gdy plan był błędny od samego początku. Załóżmy, że plik okazuje się być nagraniem ekranu, w którym znaczenie znajduje się w tekście na ekranie, a dźwięk ma jedynie charakter dodatkowy. Żadne udoskonalanie poszczególnych węzłów nie uratuje planu opartego na rozpoznawaniu mowy, dlatego graf jest odbudowywany wokół OCR.

Krok po kroku w poszukiwaniu pracy

To właśnie ten przykład zmienił sposób myślenia zespołu, ponieważ wyraźnie przypominał agenta.

L1 obejmuje więcej funkcji, niż się spodziewano: analizę CV, wykrywanie języka, geokodowanie i obliczanie czasu dojazdu oraz pobieranie ofert pracy. Wszystko to stanowi zwykły kod.

L2 zajmuje się dopasowywaniem. Dla każdej kandydującej oferty istnieje jedna wywołanie modelu, które zwraca ustrukturyzowaną ocenę w odniesieniu do odpowiednich wymiarów, przy czym całym kontekstem są streszczenie CV oraz opis tej konkretnej oferty. Jest to O(n) wywołań taniego modelu bez żadnych schematów narzędzi, a zastąpiło to agenta, który rozważał tę samą listę przy każdym ruchu, ładowając pełny zestaw narzędzi za każdym razem.

L3 zajmuje się przepisywaniem CV, a w tym przypadku umowy zmieniają swój charakter z narzędzia kontroli kosztów na narzędzie kontroli bezpieczeństwa. Umowa wymaga, aby każde stwierdzenie w przepisanym CV było powiązane z oryginałem, zabrania wymyślania pracodawcy lub daty oraz określa maksymalną długość CV. Jeśli projekt narusza te zasady, jest udoskonalany maksymalnie dwa razy, a następnie proces się kończy. To przydatny wzorzec wykraczający poza kwestie kosztów: umowa sprawdzająca pochodzenie danych stanowi tani, deterministyczny mechanizm ochrony przed fałszowaniem historii kariery kogoś przez model.

L4 to pojedynczy węzeł: badanie zespołu konkretnej firmy oraz jej najnowszych kierunków rozwoju. Z natury jest otwarty, ale ma określone granice ze względu na swoją strukturę.

L5 zostaje aktywowany, gdy same kategorie nie pasują. Wyobraźmy sobie fizyka aplikującego o stanowiska w finansach ilościowych: przetworzone kategorie stanowisk słabo odpowiadają rzeczywistemu doświadczeniu kandydata, więc plan dopasowania musi zostać całkowicie przeprojektowany, a nie tylko dostosowany.

Głównym rezultatem jest to, że zadanie, które wcześniej klasyfikowano jako praca wykonywana przez agenta, okazało się w przybliżeniu 80% pracą typu L1 i L2. Nie chodzi tu o dostosowanie instrukcji; to całkowicie zmienia krzywą kosztów procesu pracy.

Co oferuje produkt typu plik-do-pliku

Procesy przetwarzania plików wejściowych i wyjściowych w dużej mierze się pokrywają. Pierwsze 80% niemal każdego z tych procesów wygląda prawie tak samo. Jednak jakość, którą zauważają użytkownicy, znajduje się wyłącznie w pozostałych 20%, a ta część zmienia się za każdym razem. To właśnie jest pułapka personalizacji: albo inżynierowie ręcznie projektują szczegóły każdego z zadań, przez co produkt nigdy nie rozwija się skalowo, albo te szczegóły są pomijane, co skutkuje przeciętnym wynikiem.

„Drabina” to sposób na wydostanie się z tej pułapki. Personalizacja nadal ma miejsce, ale odbywa się poprzez decyzje dotyczące eskalacji zadań, kierowane umowami, a nie godzinami pracy inżynierów. Rezultatem jest dostosowanie do poszczególnych zadań bez konieczności angażowania ludzkich zasobów przy każdym z nich.

Oczywistym porównaniem są agenty wielozadaniowe oferowane przez Anthropic i OpenAI, które prawdopodobnie realizują coś podobnego pod względem struktury. Te systemy są zamknięte, więc chodzi tu o wnioskowanie, a nie o wiedzę, ale można przypuszczać, że duża część ich wysiłków jest skupiona na tworzeniu spójnej struktury w różnych zadaniach, przy czym dysponują znacznie większą ilością danych do tego celu. Ladder osiąga porównywalną strukturę dzięki sposobowi organizacji procesu pracy, a nie dzięki ogromnym zbiórkom danych, co czyni go bardziej dostępną wersją tej samej koncepcji.

Kiedy Ladder nie jest opłacalny

Podejście to zakłada, że można tworzyć sensowne umowy. Jeśli jakość wyniku działania węzła może być oceniona jedynie przez człowieka, nie ma wiarygodnego mechanizmu eskalacji, a cała struktura przeradza się w domysły. Dodatkowo wymaga to specjalistycznego sprzętu do orkiestracji; w przypadku procesu składającego się z dwóch lub trzech kroków o niskim obrocie, pojedyncze dobrze skonfigurowane wywołanie modelu może być prostsze i wystarczająco tanie.

Najpierw najniższy szczebel

Gdy każdy proces przechowuje pliki i zwraca pliki, warstwa obsługi plików znajduje się u podstaw wszystkiego innego. Każdy z opisanych powyżej szczebli ostatecznie sprowadza się do czegoś mechanicznego: otwarcie kontenera, wydobycie tekstu, zachowanie tabel w niezmienionej formie. W tej warstwie nic nie jest niepewne, więc płacenie za przetwarzanie tam byłoby czystą stratą, a jej przewidywalność sprawia, że jest to oczywisty pierwszy element do wdrożenia.

Zostało opublikowane jako otwarte oprogramowanie SDK dla Pythona, dostępne na PyPI pod licencją Apache-2.0 i mogące być używane jako serwer MCP wewnątrz Claude Code. Instalacja odbywa się za pomocą jednego polecenia z użyciem uv lub pip.

uv add convilyn          # or: pip install convilyn

SDK konwertuje dokumenty na Markdown, przekształca obrazy między 26 formatami oraz przestawia strony PDF, wszystko lokalnie, bez konieczności posiadania konta ani dostępu do sieci. Gdy zadanie faktycznie wymaga użycia modelu do przeczytania czegoś, takiego jak zeskanowana strona, zdjęcie lub plik audio, jest ono przekazywane do usługi chmurowej, a wtedy zaczyna się naliczanie opłat za korzystanie.

To rozdzielenie stanowi drabinę wyrażoną poprzez projekt produktu, a nie architekturę wewnętrzną. Wolna ścieżka lokalna to L0: gdy zwykły, deterministyczny kod może ukończyć zadanie, żaden model nie jest ładowany, a praca trafia na płatną ścieżkę tylko wtedy, gdy ta tania droga wyraźnie zawiedzie. Zgodnie z projektem, konwerter offline nie wymaga konta, klucza ani kwoty i nie wysyła żadnych danych telemetrycznych; sprawdź aktualny plik README w repozytorium, aby uzyskać szczegóły dotyczące instalacji oraz dokładny zestaw funkcji, ponieważ oba te elementy mogą ulegać zmianom.

Bieżący stan silnika przepływów pracy

W momencie pisania ten tekst, funkcje związane z przepływem pracy oraz narzędziem do budowania wciąż były w fazie stabilizacji, podczas gdy opisany tutaj proces odbudowy trwał w tle; zespół spodziewa się go ukończenia w ciągu mniej więcej miesiąca. Uzasadnienie jest godne przytoczenia: lepiej wstrzymać działanie silnika przepływu pracy, o którym wiadomo, że jest w fazie wycofywania, niż promować go i migrować użytkowników dwa razy.

Dawniejsze rozwiązania i powiązane prace

Żaden z poszczególnych elementów nie jest nowy, a każdy z nich został już wcześniej opisany. Wydaje się jednak, że niepublikowana jest ta konkretna kombinacja: eskalacja na poziomie każdego węzła wyzwalana przez umowy, zakres narzędzia wykorzystywany jako czynnik wpływający na koszty, możliwość rekurencyjnego rozszerzania, ale z ograniczeniami budżetowymi, stosowana w przypadku obciążeń typu plik do pliku. Poniższe prace obejmują te elementy.

Zacznij od prostoty i dodawaj złożoność tylko wtedy, gdy jest to konieczne

• Tworzenie skutecznych agentów, opublikowane przez Anthropic w grudniu 2024 roku, odróżnia przepływy pracy od agentów i zaleca najprostsze rozwiązanie praktyczne, dodając złożoność tylko wtedy, gdy jest to konieczne. Metoda ta różni się tym, że stosuje ten zasadę podczas wykonywania procesu, krok po kroku, zamiast raz na zadanie podczas projektowania.

Eskaluj tylko ten komponent, który zawiodł

• Artykuł ADaPT, którego nazwa oznacza dekompozycję i planowanie według potrzeb (Findings of NAACL 2024), zaczyna się od planu ogólnego i dalej dekomponuje podzadanie w sposób rekurencyjny, dopiero po tym, jak jego wykonanie się nie powiedzie, pozostawiając te udane bez zmian. Jest to najbliższy opis mechanizmu wyzwalania L4, jaki został opublikowany, chociaż nie jest sformułowany w kategoriach kosztów.

Umowy, ograniczone zasady odzyskiwania i eskalacji

• Ramy teoretyczne dotyczące planerowania wykonywania agentów LLM jako strukturalnych grafów, opublikowane na arXiv w kwietniu 2026 roku, wykorzystują statyczny DAG z umowami wyjściowymi dla każdego węzła oraz trójetapowy protokół odzyskiwania składający się z ponownej próby, lokalnej korekty i całkowitego przeplanowania, z wyraźnie określonymi niezmiennikami eskalacji. Autorzy argumentują, że węzły oparte na modelach powinny być weryfikowane pod kątem tych umów, ponieważ samych sprawdzeń typów jest niewystarczająco, a ponawianie nieidempotentnych działań wymaga ograniczonych budżetów. Celowo pomijają rozszerzanie rekurencyjne podgrafów, w którym mieści się podejście L4.

Planowanie niezależne od zadań (TDP), omówione w tym samym artykule, dzieli pracę na graf podceli, z których każda ma swój własny wąski kontekst, i ogranicza ponowne planowanie do tego konkretnego podzadania, które jest obecnie aktywne. Pokazuje ono redukcję liczby tokenów o aż 82%, co stanowi najbliższe opublikowane dane potwierdzające argument dotyczący zastosowania poziomu L2.

Zakres narzędzia jako główny czynnik kosztowy

• Skillflow definiuje strukturę typu DAG w formacie YAML, którą przetwarza silnik, a nie model. Jego operacje wejścia/wyjścia są kontrolowane przez możliwości danego narzędzia: krok otrzymuje tylko ten kontekst, o który prosi, a każde narzędzie nieobjęte jego umową po prostu nie pojawia się w jego schemacie. Jego wniosek, że mały kontekst specyficzny dla danej roli sprawia, iż tanie modele wystarczają, jest zgodny z argumentem poziomu L2.

Lodowiska etapowe już w użyciu

• PraisonAI wprowadza w swoim SDK dla agentów funkcję eskalacji, która definiuje cztery stopnie postępu: bezpośrednia odpowiedź bez użycia narzędzi ani planowania, wykorzystanie heurystyk bez dodatkowego wezwania modelu, jedno ograniczone wezwanie modelu oraz wreszcie całkowicie autonomiczny proces z wykorzystaniem narzędzi, podagentów i weryfikacji. To w przybliżeniu poziomy od L0 do L4 skompresowane w cztery kroki.
• Router eskalacji w NVIDIA NeMo Switchyard stosuje tę samą strukturę do wyboru modelu zamiast architektury: zaczyna się od słabszego modelu, a gdy system wykryje trwałe problemy, przechodzi na silniejszy.

Ta sama struktura gdzie indziej

• Agentic Design Patterns (systemdesign.one, kwiecień 2026) używa wyrażenia „drabina eskalacji” na określenie wyboru między przepływem pracy a agentem i zaleca stosowanie najprostszego rozwiązania, które pozwala wykonać zadanie.
• Przewodnik Vercel dotyczący ramowań oceny agentów AI do użycia w produkcji (lipiec 2026) stosuje zasadę najtańszego pierwszego rozwiązania przy ocenie: należy wykonać najmniej kosztowną weryfikację zdolną do wykrycia danego błędu, a eskalować sytuację tylko wtedy, gdy ta weryfikacja strukturalnie nie jest w stanie zidentyfikować problemu.

Główne wnioski

• Decyzja o wyborze „DAG czy agent” dla każdego zadań sprawia, że każdy krok służy pokryciu kosztów najbardziej niepewnego etapu.

Niezmienną kosztem pętli agenta jest blok schematu narzędzia wysyłany przy każdej turze, którego kompresja historii nie może usunąć.

Rozpocznij każdy węzeł na najtańszym poziomie i podnieś go tylko w przypadku nieudanego, wyraźnego kontraktu.

Ogranicz schematy narzędzi do węzła, który ich potrzebuje, i przydziel każdemu poziomowi powyżej L2 sztywny budżet.

Oczekuj, że większość obciążeń „agentów” będzie w dużej mierze deterministyczna po dekompozycji; w przypadku wyszukiwania pracy około 80% należało do poziomów L1 i L2.

Literatura pokrewna

• Projektowanie systemów wieloagentowych na węzłach A2A: pamięć i zarządzanie — architektura referencyjna dla systemów wieloagentowych opartych na protokole A2A, obejmująca moduły agentów, typy pamięci, orkiestrację, zagrożenia bezpieczeństwa oraz listę kontrolną projektu.
• LangGraph w praktyce: stany, węzły, krawędzie i pięć wzorców agentów — Dowiedz się, jak definiować stan LangGraph za pomocą adnotacji i reduktorów, łączyć węzły krawędziami oraz implementować wszystkie pięć podstawowych wzorców pracy agentów w JavaScript.