Dlaczego wiele systemów agentowych zawodzi w produkcji i jak projektować niezawodne agenty z użyciem maszyn stanów, jasnych kontraktów narzędzi, polityk ponawiania i głębokiej obserwowalności.
Systemy agentowe to aplikacje, w których LLM nie tylko odpowiada na prompt, ale decyduje, co zrobić dalej: które narzędzia wywołać, jakie dane pobrać, jakie kroki uruchomić i kiedy uznać zadanie za „zrobione”. Łączą model, zestaw narzędzi (API, bazy danych, serwisy), pętlę planowania/wykonania oraz infrastrukturę, która skleja wszystko razem.
W demie wygląda to magicznie: agent tworzy plan, wywołuje kilka narzędzi i zwraca idealny wynik. Ścieżka szczęścia jest krótka, opóźnienia małe, a nic się nie psuje równocześnie.
W rzeczywistych obciążeniach ten sam agent jest naciskany w sposób, którego demo nigdy nie widziało:
W efekcie: niestabilne zachowanie trudne do odtworzenia, cicha korupcja danych i przepływy użytkownika, które od czasu do czasu wiszą lub chodzą w kółko.
Niestabilne agenty nie tylko psują „doznanie użytkownika”. One:
Ten artykuł dotyczy wzorców inżynieryjnych, nie „lepszych promptów”. Omówimy maszyny stanów, jawne kontrakty narzędzi, strategie ponawiania i obsługi błędów, kontrolę pamięci i współbieżności oraz wzorce obserwowalności, które sprawiają, że systemy agentowe są przewidywalne pod obciążeniem — nie tylko efektowne na scenie.
Większość systemów agentowych wygląda dobrze w pojedynczym demie z happy path. Zawodzi, gdy przychodzi ruch, narzędzia i przypadki brzegowe razem.
Naiwna orkiestracja zakłada, że model zrobi „właściwą rzecz” w jednej lub dwóch wywołaniach. W praktyce pojawiają się powtarzające się wzorce:
Bez jawnych stanów i warunków zakończenia te zachowania są nieuniknione.
Losowość LLM, zmienność latencji i timing narzędzi tworzą ukrytą niedeterministyczność. To samo wejście może pójść różnymi ścieżkami, wywołać różne narzędzia lub różnie zinterpretować wyniki.
W skali dominują problemy z narzędziami:
Każdy z tych problemów zamienia się w fałszywe pętle, powtórzenia lub niepoprawne odpowiedzi końcowe.
To, co psuje się rzadko przy 10 RPS, będzie zawodzić stale przy 1000 RPS. Współbieżność ujawnia:
Zespoły produktowe często oczekują deterministycznych workflowów, jasnych SLA i audytowalności. Agenci, zostawieni bez ograniczeń, oferują probabilistyczne, best‑effort zachowanie ze słabymi gwarancjami.
Gdy architektury ignorują to niedopasowanie — traktując agentów jak tradycyjne serwisy zamiast stochastycznych planerów — systemy zachowują się nieprzewidywalnie wtedy, gdy niezawodność jest kluczowa.
Agenci gotowi do produkcji to mniej „mądre prompty”, a więcej zdyscyplinowanego projektowania systemów. Dobrym sposobem myślenia o nich jest traktowanie ich jako małych, przewidywalnych maszyn, które od czasu do czasu wywołują LLM, a nie jako tajemniczych monolitów LLM, które od czasu do czasu dotykają twoich systemów.
Cztery cechy mają największe znaczenie:
Te cechy nie wynikają z samych promptów. Wynikają ze struktury.
Domyślny wzorzec, od którego wiele zespołów zaczyna, to: „while not done, call the model, let it think, maybe call a tool, repeat”. To łatwe do prototypowania i trudne w eksploatacji.
Bezpieczniejszy wzorzec to reprezentowanie agenta jako jawnego workflowu:
COLLECTING_INPUT, PLANNING, EXECUTING_STEP, WAITING_ON_HUMAN, DONE).To zamienia agenta w maszynę stanów, gdzie każdy krok jest inspekcjonowalny, testowalny i odtwarzalny. Pętle wolnej formy wydają się elastyczne, ale to jawne workflowy czynią incydenty debugowalnymi, a zachowania audytowalnymi.
Monolityczne agenty, które „robią wszystko”, kuszą, ale tworzą silne sprzężenia między niepowiązanymi odpowiedzialnościami: planowanie, retrieval, logika biznesowa, orkiestracja UI i inne.
Zamiast tego komponuj małe, dobrze zdefiniowane agentki/umiejętności:
Każda umiejętność może mieć własną maszynę stanów, narzędzia i zasady bezpieczeństwa. Logika komponująca staje się wtedy workflowem wyższego poziomu, a nie rosnącym promptem w jednym agencie.
Ta modularność utrzymuje każdy komponent na tyle prostym, by nad nim panować, i pozwala ewoluować jedną zdolność bez destabilizacji reszty.
Przydatny model mentalny to podział agenta na trzy warstwy:
Polityka decyzyjna (prompt + model)
Określa jak agent wybiera następne akcje, interpretowaną pod ścisłymi ograniczeniami. Powinieneś móc podmienić model, zmienić temperaturę lub dopracować prompt bez ruszania okablowania systemowego.
Maszyna stanów / silnik workflowu
Zarządza gdzie jesteś w procesie, które przejścia są możliwe i jak persistować postęp. Polityka sugeruje ruch; maszyna stanów go waliduje i stosuje.
Warstwa narzędzi
Realizuje co może się zdarzyć w świecie: API, bazy, kolejki, zewnętrzne serwisy. Narzędzia wystawiają wąskie, dobrze typowane kontrakty i egzekwują autoryzację, limity i walidację wejścia.
Wymuszając to rozdzielenie, unikasz pułapki ukrywania logiki biznesowej w promptach czy opisach narzędzi. LLM staje się komponentem decyzyjnym wewnątrz jasnej, deterministycznej powłoki, a nie powłoką samą w sobie.
Najbardziej niezawodne systemy agentowe nie są najbardziej imponującymi demami — to te, których zachowanie potrafisz wyjaśnić na tablicy.
Konkretnie:
To nastawienie na małe, komponowalne i dobrze ustrukturyzowane agenty pozwala systemom rosnąć bez zapadania się pod własną złożonością.
Większość implementacji agentów zaczyna się od pętli „think, act, observe” opakowanej wokół wywołania LLM. To działa w demie, ale szybko staje się nieprzejrzyste i kruche. Lepsze podejście to traktować agenta jako jawną maszynę stanów: skończony zbiór stanów z dobrze zdefiniowanymi przejściami wywoływanymi zdarzeniami.
Zamiast pozwalać modelowi niejawnie decydować, co zrobić dalej, zdefiniuj mały diagram stanów:
Przejścia między stanami wyzwalane są typowanymi zdarzeniami takimi jak UserRequestReceived, ToolCallSucceeded, ToolValidationFailed, TimeoutExceeded lub HumanOverride. Każde zdarzenie plus bieżący stan decyduje o następnym stanie i akcjach.
To ułatwia polityki ponawiania i timeoutów: przylegasz je do konkretnych stanów (np. CALL_TOOL może robić 3 ponowienia z wykładniczym backoffem, PLAN może nie być ponawiany wcale) zamiast rozsiewać logikę ponowień po całej bazie kodu.
Persistuj bieżący stan i minimalny kontekst w zewnętrznym magazynie (baza danych, kolejka lub silnik workflowu). Agent staje się wtedy funkcją czystą:
next_state, actions = transition(current_state, event, context)
To umożliwia:
Z maszyną stanów każdy krok zachowania agenta jest jawny: w jakim stanie się znajdował, jakie zdarzenie wystąpiło, które przejście zostało uruchomione i jakie efekty uboczne wygenerowano. Ta przejrzystość przyspiesza debugowanie, upraszcza dochodzenia incydentów i tworzy naturalny ślad audytowy dla zgodności. Możesz udowodnić z logów i historii stanu, że pewne ryzykowne akcje są podejmowane jedynie z określonych stanów i pod zdefiniowanymi warunkami.
Agenci zachowują się dużo przewidywalniej, gdy narzędzia przypominają „API” zamiast „API ukryte w prozie”.
Każde narzędzie powinno mieć kontrakt obejmujący:
InvalidInput, NotFound, RateLimited, TransientFailure) z jasną semantyką.Udostępnij ten kontrakt modelowi jako ustrukturyzowaną dokumentację, nie jako ścianę tekstu. Planner agenta powinien wiedzieć, które błędy są ponawialne, które wymagają interwencji użytkownika, a które powinny zatrzymać workflow.
Traktuj I/O narzędzi jak każde inne produkcyjne API:
To upraszcza prompty: zamiast rozbudowanych instrukcji polegaj na wskazówkach prowadzonych przez schemat. Jasne ograniczenia zmniejszają halucynacje argumentów i nielogiczne sekwencje wywołań narzędzi.
Narzędzia ewoluują; agenty nie powinny się psuć przy każdej zmianie.
v1, v1.1, v2) i przypinaj agentów do wersji.Dzięki temu logika planowania może bezpiecznie mieszać agentów i narzędzia o różnym stopniu dojrzałości.
Projektuj kontrakty z myślą o częściowej awarii:
Agent może wtedy adaptować się: kontynuować workflow z ograniczoną funkcjonalnością, zapytać użytkownika o potwierdzenie lub przełączyć się na narzędzie zapasowe.
Kontrakty narzędzi to naturalne miejsce na kodowanie limitów bezpieczeństwa:
confirm: true).Połącz to z kontrolami po stronie serwera; nigdy nie polegaj wyłącznie na tym, że model „będzie się dobrze zachowywał”.
Gdy narzędzia mają jasne, walidowane i wersjonowane kontrakty, prompty mogą być krótsze, logika orkiestracji prostsza, a debugowanie znacznie łatwiejsze. Przenosisz złożoność z kruchej, naturalnej mowy do deterministycznych schematów i polityk, ograniczając halucynacje wywołań narzędzi i nieoczekiwane efekty uboczne.
Niezawodne systemy agentowe zakładają, że wszystko kiedyś zawiedzie: modele, narzędzia, sieci, nawet twoja własna warstwa koordynacji. Celem nie jest unikanie błędów, lecz uczynienie ich tanimi i bezpiecznymi.
Idempotencja oznacza: powtórzenie tego samego żądania ma ten sam widoczny efekt zewnętrzny, co wykonanie go raz. To kluczowe dla agentów LLM, które często ponawiają wywołania narzędzi po częściowych błędach lub niejednoznacznych odpowiedziach.
Uczyń narzędzia idempotentnymi przez design:
request_id. Narzędzie przechowuje to i zwraca ten sam wynik, jeśli widzi ten sam ID ponownie.Używaj ustrukturyzowanych ponowień dla błędów przejściowych (timeouty, limity, 5xx): wykładniczy backoff, jitter, i surowy max attempts. Loguj każdą próbę z identyfikatorami korelacji, aby móc śledzić zachowanie agenta.
Dla błędów trwałych (4xx, błędy walidacji, naruszenia reguł biznesowych) nie powtarzaj. Wystaw strukturalny błąd polityce agenta, aby mogła zrewidować plan, zapytać użytkownika lub wybrać inne narzędzie.
Wdrażaj circuit breakers na warstwach agenta i narzędzi: po powtarzających się błędach tymczasowo zablokuj wywołania tego narzędzia i fail fast. Sparuj to z dobrze zdefiniowanymi fallbackami: trybem degradacji, cache'owanymi danymi lub alternatywnymi narzędziami.
Unikaj ślepych ponowień w pętli agenta. Bez idempotentnych narzędzi i jasnych klas błędów jedynie pomnożysz efekty uboczne, latencję i koszty.
Niezawodne agenty zaczynają się od jasnego rozróżnienia, czym jest stan i gdzie on żyje.
Traktuj agenta jak serwis obsługujący żądanie:
Mieszanie tych dwóch prowadzi do zamieszania i błędów. Na przykład umieszczanie efemerycznych wyników narzędzi w „pamięci” sprawia, że agenci używają przestarzałego kontekstu w przyszłych rozmowach.
Masz trzy główne opcje:
Dobra zasada: LLM jest funkcją bezstanową nad jawnym obiektem stanu. Persistuj ten obiekt poza modelem i regeneruj prompty z jego zawartości.
Częsty błąd to używanie logów konwersacji, śladów lub surowych promptów jako pamięci.
Problemy:
Zamiast tego zdefiniuj ustrukturyzowane schematy pamięci: user_profile, project, task_history itd. Logi powinny być pochodną stanu, a nie na odwrót.
Gdy wiele narzędzi lub agentów aktualizuje te same encje (np. rekord CRM lub status zadania), potrzebujesz podstawowych kontroli spójności:
Dla operacji wysokiej wartości prowadź osobny log decyzji niezależny od konwersacyjnego: co zmieniono, dlaczego i na podstawie jakich wejść.
Aby przetrwać crash, deployy i limity, workflowy powinny być możliwe do wznowienia:
To także umożliwia debugowanie w czasie: możesz obejrzeć i odtworzyć dokładny stan, który doprowadził do złej decyzji.
Pamięć to ryzyko tak samo jak zasób. W produkcyjnych agentach:
Traktuj pamięć jako produkt: projektowaną, wersjonowaną i zarządzaną — a nie jako rosnący dump tekstu przyczepiony do agenta.
Agenci na tablicy wyglądają sekwencyjnie, ale pod obciążeniem zachowują się jak systemy rozproszone. Gdy masz wielu współbieżnych użytkowników, narzędzia i zadania w tle, zaczynasz walczyć z warunkami wyścigu, duplikowaną pracą i problemami z kolejnością.
Typowe tryby awarii:
Minimalizujesz to przez idempotentne kontrakty narzędzi, explicit workflow state i optymistyczne/pesymistyczne blokowanie w warstwie danych.
Synchroniczny request–response jest prosty, ale kruchy: każda zależność musi być dostępna, mieszcząca się w limicie i szybka. Gdy agenci rozchodzą się na wiele narzędzi lub równoległych podzadań, przenieś długotrwałe lub efektowe kroki za kolejkę.
Orkiestracja oparta na kolejkach pozwala:
Agenci zwykle trafiają w trzy klasy limitów:
Potrzebujesz wyraźnej warstwy limitów z throttle'ami per‑user, per‑tenant i globalnymi. Użyj kubełków tokenów lub lejących kubełków, by egzekwować polityki, i wystawaj jasne typy błędów (np. RATE_LIMIT_SOFT, RATE_LIMIT_HARD), aby agenty mogły się łagodnie cofać.
Backpressure chroni system pod obciążeniem. Strategie obejmują:
Monitoruj sygnały saturacji: głębokość kolejek, wykorzystanie workerów, wskaźniki błędów i percentyle latencji. Rosnące kolejki wraz z rosnącą latencją lub błędami 429/503 to wczesne ostrzeżenie, że agenci przeładowują środowisko.
Nie uczynisz agenta niezawodnym, jeśli nie potrafisz szybko odpowiedzieć na dwa pytania: co zrobił? i dlaczego to zrobił? Observability dla systemów agentowych polega na uczynieniu tych odpowiedzi tanimi i precyzyjnymi.
Projektuj obserwowalność tak, aby pojedyncze zadanie miało trace, który przewija się przez:
Do śladu dołączaj ustrukturyzowane logi dla kluczowych decyzji (wybór routingu, rewizje planu, wyzwolenia garde‑rail) i metryki dla wolumenu i zdrowia.
Przydatny trace zwykle zawiera:
Loguj prompty, wejścia narzędzi i ich wyjścia w formie strukturalnej, ale przepuść je przez warstwę redakcji najpierw:
Przechowuj surową zawartość za feature flagami w środowiskach niższych; produkcja powinna domyślnie pokazywać widoki zredagowane.
Przynajmniej mierz:
Gdy wystąpią incydenty, dobre trace'y i metryki pozwalają przejść od „agent jest niestabilny” do precyzyjnego stwierdzenia: „P95 zadań kończy się w ToolSelection po 2 ponowieniach z powodu nowego schematu w billing_service”, skracając diagnozę z godzin do minut i dając konkretne dźwignie do strojenia zachowania.
Testowanie agentów to testowanie zarówno narzędzi, które wywołują, jak i flowów, które to wszystko spina. Traktuj to jak testowanie systemów rozproszonych, a nie tylko strojenie promptów.
Zacznij od testów jednostkowych na granicy narzędzi:
Te testy nie zależą od LLM. Wywołujesz narzędzie bezpośrednio z syntetycznymi danymi i asercją na konkretny output lub kontrakt błędu.
Testy integracyjne ćwiczą workflow agenta end‑to‑end: LLM + narzędzia + orkiestracja.
Modeluj je jako testy scenariuszowe:
Te testy asserwują przejścia stanów i wywołania narzędzi, nie każde słowo w odpowiedzi LLM. Sprawdzaj: jakie narzędzia zostały wywołane, z jakimi argumentami, w jakiej kolejności i jaki stan / rezultat końcowy osiągnięto.
Aby testy były powtarzalne, fixuj odpowiedzi LLM i wyniki narzędzi.
Typowy wzorzec:
with mocked_llm(fixtures_dir="fixtures/llm"), mocked_tools():
result = run_agent_scenario(input_case)
assert result.state == "COMPLETED"
Każda zmiana promptu lub schematu powinna uruchamiać obowiązkowy przebieg regresyjny:
Ewolucja schematów (dodawanie pól, zaostrzenie typów) ma własne przypadki regresyjne, by wychwycić agentów lub narzędzia zakładające stary kontrakt.
Nigdy nie wrzucaj nowego modelu, polityki lub strategii routingu bezpośrednio na ruch produkcyjny.
Zamiast tego:
Dopiero po przejściu bramek offline nowy wariant powinien trafić do produkcji, najlepiej za feature flagami i z stopniowym rolloutem.
Logi agentów często zawierają wrażliwe dane użytkowników. Testowanie musi to respektować.
Skodyfikuj te reguły w pipeline CI, aby żaden artefakt testowy nie mógł powstać lub być przechowywany bez kontroli anonimizacji.
Obsługa agentów w produkcji przypomina bardziej uruchamianie systemu rozproszonego niż wypuszczanie statycznego modelu. Potrzebujesz kontroli rolloutu, jasnych celów niezawodności i dyscypliny w zarządzaniu zmianami.
Wprowadzaj nowe agenty lub zachowania stopniowo:
Wspieraj to feature flagami i politykami konfiguracyjnymi: reguły routingu, włączone narzędzia, temperatura, ustawienia bezpieczeństwa. Zmiany powinny być deployowalne przez konfigurację, nie kod, i natychmiast odwracalne.
Zdefiniuj SLO odzwierciedlające zarówno zdrowie systemu, jak i wartość dla użytkownika:
Podłącz to do alertów i obsługuj incydenty jak każde produkcyjne usługi: jasna odpowiedzialność, runbooki do triage i standardowe kroki łagodzenia (rollback flagi, odprowadzanie ruchu, tryb bezpieczny).
Korzystaj z logów, śladów i transkrypcji konwersacji, by dopracowywać prompty, narzędzia i polityki. Traktuj każdą zmianę jako wersjonowany artefakt z przeglądem, zatwierdzeniem i możliwością rollbacku.
Unikaj cichych zmian w promptach lub narzędziach. Bez kontroli zmian nie skorelujesz regresji z konkretnymi edycjami, a reakcja na incydenty zmienia się w zgadywanie zamiast inżynierię.
System produkcyjny z agentami zyskuje na jasnym podziale obowiązków. Celem jest, by agent był „mądry w decyzjach”, ale „głupi w infrastrukturze”.
1. Gateway / API edge
Pojedynczy punkt wejścia dla klientów (aplikacje, serwisy, UI). Obsługuje:
2. Orkiestrator
Orkiestrator to „pień mózgu”, nie mózg. Koordynuje:
LLM(i) stoją za orkiestratorem, używane przez planner i przez konkretne narzędzia wymagające rozumienia języka.
3. Warstwa narzędzi i storage
Logika biznesowa pozostaje w istniejących mikrousługach, kolejkach i systemach danych. Narzędzia są cienkimi wrapperami wokół:
Orkiestrator wywołuje narzędzia przez ścisłe kontrakty, a systemy storage pozostają źródłem prawdy.
Egzekwuj auth i kwoty na gatewayu; egzekwuj bezpieczeństwo, dostęp do danych i politykę w orkiestratorze. Wszystkie wywołania (LLM i narzędzi) emitują ustrukturyzowaną telemetrię do pipeline'u, który zasila:
Prostsza architektura (gateway → pojedynczy orkiestrator → narzędzia) jest łatwiejsza w obsłudze; dodanie odrębnych plannerów, silników polityk i gatewayów modeli zwiększa elastyczność, kosztem większej koordynacji, latencji i złożoności operacyjnej.
Masz już podstawowe składniki agentów, które zachowują się przewidywalnie pod realnym obciążeniem: jawne maszyny stanów, jasne kontrakty narzędzi, zdyscyplinowane ponawiania i głęboka obserwowalność. Ostatnim krokiem jest przekształcenie tych pomysłów w powtarzalną praktykę dla twojego zespołu.
Pomyśl o każdym agencie jako o workflowie ze stanem:
Gdy te elementy się zgrają, otrzymujesz systemy, które degradują się łagodnie zamiast rozpadać się przy przypadkach brzegowych.
Zanim wystawisz prototyp agenta na realnych użytkowników, potwierdź:
Jeśli czegoś brakuje, jesteś nadal w trybie prototypu.
Trwałe rozwiązanie zwykle rozdziela obowiązki:
To pozwala zespołom produktowym szybko się poruszać, a platformowym wymuszać niezawodność, bezpieczeństwo i kontrolę kosztów.
Gdy masz stabilne fundamenty, możesz eksplorować:
Postęp powinien być przyrostowy: wprowadzaj komponenty uczące za feature flagami, z offline'ową ewaluacją i silnymi zabezpieczeniami.
Przewodnia myśl pozostaje taka sama: projektuj na porażkę, faworyzuj przejrzystość nad sprytem i iteruj tam, gdzie możesz obserwować i szybko cofać zmiany. Z tymi ograniczeniami systemy agentowe przestają być strasznymi prototypami i stają się infrastrukturą, na której organizacja może polegać.
System agentowy to aplikacja, w której LLM nie tylko odpowiada na pojedyncze zapytanie, lecz decyduje, co zrobić dalej: które narzędzia wywołać, jakie dane pobrać, jaki krok w przepływie wykonać i kiedy zakończyć działanie.
W odróżnieniu od prostego uzupełnienia czatu, system agentowy składa się z:
W produkcji LLM staje się komponentem decyzyjnym wewnątrz większej, deterministycznej powłoki — nie jest całym systemem.
Dema zwykle pokazują jedną ścieżkę sukcesu: jednego użytkownika, idealne działanie narzędzi, brak timeoutów, brak dryfu schematów i krótkie rozmowy. W produkcji agenci mierzą się z:
Bez jawnych workflowów, kontraktów i obsługi błędów te czynniki prowadzą do pętli, zastoju, częściowej pracy i cichych błędów, które nie występują w środowiskach demo.
Spraw, by LLM działał wewnątrz jasnej struktury, zamiast w pętli wolnej formy:
Zamodeluj agenta jako workflow z nazwanymi stanami i typowanymi zdarzeniami zamiast while not done: call LLM.
Typowe stany to między innymi:
Projektuj narzędzia jak prawdziwe API produkcyjne, a nie opis wpleciony w prompt. Każde narzędzie powinno mieć:
Zakładaj, że każde zewnętrzne wywołanie kiedyś zawiedzie, i projektuj pod to.
Kluczowe wzorce:
Oddziel krótkotrwały stan od pamięci długoterminowej, a sam LLM traktuj jako bezstanową funkcję.
Myśl o systemie agenta jak o systemie rozproszonym pod obciążeniem, nawet jeśli na schemacie każdy flow wygląda sekwencyjnie.
Aby pozostać niezawodnym:
Musisz umieć odpowiedzieć „co agent zrobił?” i „dlaczego to zrobił?” dla dowolnego zadania.
Praktyczne wymagania:
Traktuj agentów jak ewoluujące usługi i zarządzaj nimi z tą samą dyscypliną, co innymi systemami produkcyjnymi.
Zalecane praktyki:
Dzięki temu możesz krok po kroku tłumaczyć, testować i debugować zachowanie, zamiast ścigać nieprzejrzyste „myśli agenta”.
PLAN – zinterpretuj żądanie i wygeneruj plan krok po krokuCALL_TOOL – wywołaj konkretne narzędzie lub batch narzędziVERIFY – sprawdź wyniki narzędzi względem prostych reguł lub dodatkowych kontroli modeluRECOVER – obsłuż błędy przez ponowienia, fallback lub eskalacjęDONE / FAILED – stany końcoweZdarzenia (np. ToolCallSucceeded, TimeoutExceeded) wraz z bieżącym stanem decydują o kolejnym stanie. To sprawia, że ponawianie, timeouty i obsługa błędów są jawne, zamiast być ukryte w promptach czy kodzie spajającym.
InvalidInput, NotFound, RateLimited, TransientFailureWaliduj wejścia przed wywołaniem narzędzia i wyniki po nim. Wersjonuj kontrakty narzędzi i przypinaj agentów do konkretnej wersji, by zmiany schematów nie łamały przepływów.
request_id lub klucz biznesowy i zwracają ten sam rezultat przy ponownym wywołaniu.To utrzymuje wysoką niezawodność bez pętli runaway, podwójnych efektów ubocznych czy niekontrolowanych kosztów.
Unikaj używania surowych logów lub historii rozmów jako pamięci; zamiast tego twórz zwarte, strukturalne rekordy z jasnymi zasadami retencji i prywatności.
Monitoruj głębokość kolejek, percentyle latencji i wskaźniki 429/503, aby wykryć przeciążenie zanim stanie się awarią.
Dzięki temu triage incydentów zmieni się z „agent jest niestabilny” na wskazanie konkretnego stanu, narzędzia i zmiany, które spowodowały regresję.
Dzięki temu możesz ciągle ulepszać agentów, zachowując równocześnie możliwość ograniczenia, zdiagnozowania i wycofania zmian.