Harness, Loop i Graph: trzy warstwy nakładające się w systemie agenta programistycznego
Objaw awarii wskazuje na warstwę, którą należy naprawić. Jak funkcjonują harness, loop i graph, gdzie przydaje się system wielu agentów, czego nie mogą zagwarantować metody adwersarialne oraz lista kontrolna.
Źródła: Harness > Graph > Loop > Model — The Layer Order Saves Your Agent
Agenat kodujący może sprawiać wrażenie, że działa samodzielnie, podczas gdy w rzeczywistości obok niego siedzi osoba pełniąca rolę nadzorcy drogiego stażysty: jeden prompt, jedna odpowiedź, a następnie ręczna analiza tego, co właśnie się wydarzyło.
Zespoły próbujące wyjść z tego trybu ciągle napotykają te same trzy przeszkody. Pętle ponownych prób wyczerpują budżet, nie sprawdzając nawet, czy kod się kompiluje. Grafy składające się z pięćdziesięciu węzłów są tworzone, zanim ktokolwiek zrozumie, jak zachowuje się pojedynczy podagent. A typową reakcją na obie te awarie jest przepisanie promptu, ignorując środowisko, w którym działa model. Wszystkie trzy problemy mają wspólną przyczynę, która nie leży w modelu.
Następny tekst opisuje trzy warstwy nawarstwione w ramach jednego systemu agentów, pokazuje, jak objawy awarii wskazują na warstwę wymagającą uwagi, oraz przedstawia najprostszą wersję każdej warstwy, którą warto stworzyć przed jakimkolwiek skalowaniem.
Podstawa architektury
Harness, loop i graph to nie konkurencyjne szkoły myślenia. Są to trzy warstwy nakładające się na siebie w ramach jednego systemu, ułożone od zewnątrz do wewnątrz: najpierw harness, potem graph, następnie loop, a na końcu model.
Każda warstwa odpowiada za jedno zadanie. Harness określa, czego agent może dotknąć, przechować i zobaczyć. Loop decyduje o momencie, w którym agent może uznać zadanie za zakończone. Graph określa, kto i kiedy pracuje, sekwencyjnie czy równolegle, oraz w jaki sposób łączone są wyniki.
System ten przynosi natychmiastowe korzyści, ponieważ awaria w produkcji wskazuje bezpośrednio na odpowiedni poziom. „Zrobione, ale to nie działa” to problem z pętlami. „Samodzielnie wszystko w porządku, ale jako zespół się rozpada” to problem z grafami. „Zapomniałem o decyzji z wczoraj” to problem z mechanizmami koordynacji. Nikt nie musi zgadywać, który plik otworzyć pierwszy, a nikt nie próbuje rozwiązać problemu architektury poprzez zamianę modelu.
Jedna uwaga przed przedstawieniem jakichkolwiek danych. Każde twierdzenie w tym tekście w formie „strukturyzowana warstwa jest N razy szybsza” ma charakter ilustracyjny, a nie wynika z pomiarów. Nie ma jeszcze niezależnych pomiarów tego typu, więc uczciwe przyznanie braku danych jest bardziej przydatne niż wymyślona liczba.
Trzy warstwy, jedna architektura
Firma przedstawia przydatne porównanie. Budynek i jego zasady bezpieczeństwa to pas bezpieczeństwa, schemat organizacyjny to graf, a codzienna lista kontrolna pracownika to pętla, przy czym modelem jest sam pracownik, ograniczony przez wszystkie te elementy.
Układ warstwowy nie jest kwestią gustu. Pas bezpieczeństwa stanowi zewnętrzną granicę, więc żaden węzeł grafu nie może działać w sposób zabroniony przez otaczające środowisko. Graf koordynuje kilka pętli, przy czym każda pętla to silnik znajdujący się najbliżej modelu i otaczający go bezpośrednio. Graf jest po prostu mapą pokazującą, kto pracuje kiedy i gdzie powstają wyniki.
Dlaczego branża kłóci się o to, który warstwa ma największe znaczenie? Powód jest prosty i strukturalny: dostawcy budują swoje marki wokół jednej konkretnej warstwy. Niektórzy publikują informacje na temat środowisk, inni o grafach, a niezależni specjaliści przekształcili inżynierię pętli w odrębny ruch. Czytelnik napotyka po jednym rzeczowniku na kanał i dochodzi do wniosku, że to jakieś zawody.
Bardziej interesującym faktem jest to, że ten sam objaw może wynikać z dwóch różnych warstw. Agent, który „nie robi nic rozsądnego”, może być uwięziony w pętli bez warunku zatrzymania lub może znajdować się w środowisku, w którym testy w ogóle nie mogą zostać uruchomione. Dlatego każda warstwa ma swoją własną sekcję, począwszy od najzewnętrzniejszej.
Warstwa harness: to, co otrzymuje model
Sam model nie ma pamięci, żadnych narzędzi ani ograniczeń. Wszystko, co je zapewnia, to „ Harness”. Inżynieria Harness, czyli dyscyplina zajmująca się projektowaniem tego środowiska, może znacznie zmienić wynik działania tego samego modelu bardziej niż jakakolwiek modyfikacja instrukcji, a przykład tego znajduje się kilka akapitów niżej.
Formuła jest prosta: agent to model plus Harness. Jeśli model jest silnikiem, to Harness to cały samochód – z podwoziem, systemem paliwowym i czujnikami. Doskonały silnik bez samochodu nigdzie się nie dostanie. Łatwo potraktować tę warstwę jako elementy instalacyjne zamiast architektury, a to była jedna z najdroższych pomyłek w sposobie, w jaki ludzie postrzegają agenty.
Siedem plików, a nie framework
Siedem plików składa się na minimalny zestaw niezbędny do działania w produkcji: instrukcje dotyczące repozytorium, plik z uprawnieniami, para hooków do zarządzania cyklem życia aplikacji oraz trzy elementy stanu trwałego, a mianowicie dziennik postępów, cache wyników narzędzi oraz rejestr punktów kontrolnych git. Nie jest potrzebna żadna biblioteka do orkiestracji procesów.
Zespoły często mylą dwie rzeczy, które powinny być traktowane oddzielnie. Uprawnienia są sprawdzane przed uruchomieniem narzędzia, co stanowi kontrolę na poziomie aplikacji. Sandbox natomiast blokuje działanie na poziomie jądra, więc proces nie może przekroczyć określonych granic bez względu na żądania modelu. Różnica między zapytaniem a niemożnością wykonania polega na różnicy między prośbą a umową.
Haszowanie stanu uzupełnia ten zestaw. Zamiast polegać na tym, co pamięta agent, przechowuje się potwierdzenia: wyniki wywołań narzędzi oraz sumy kontrolne komitetów są dodawane do trwałego dziennika, co umożliwia nowemu oknu kontekstowemu korzystanie z faktów, a nie z podsumowania, które utraciło szczegóły. To sposób jednego z autorów na zapewnienie trwałości stanu, a nie uznany standard branżowy, ponieważ inne zespoły osiągają ten efekt za pomocą komitetów i plików postępów.
Jedna grafika wymaga ostrzeżenia dotyczącego jej pochodzenia. Porównanie to objęło kilka agentów na jednym modelu i przeprowadzono je na części testów SWE-bench Verified; zostało opublikowane przez twórcę jednego z porównywanych narzędzi, a nie przez neutralne laboratorium. Wykazało ono różnicę kosztów wynoszącą około trzy razy przy podobnym lub lepszym stopniu skuteczności, spowodowaną wyłącznie warstwą kontekstu i środowiska. Należy traktować to jako twierdzenie dostawcy, a nie niezależne dowody.
Sam środowisko nie decyduje o tym, kiedy agent przestaje działać. To jest odpowiedzialność kolejnego warstwy.
Warstwa pętli: dowód, a nie pewność
Inżynieria pętli to projektowanie samej warunku zatrzymania, a jej pierwsza zasada jest prosta: deklaracja agenta o zakończeniu pracy nie stanowi dowodu. Pętla nie może się zakończyć przed przeprowadzeniem zewnętrznej, deterministycznej weryfikacji, na przykład testu, narzędzia do sprawdzania kodu lub walidatora schematu.
Kontrola prędkości to odpowiedni przykład, a nie obietnica. Samochody dostosowują prędkość na podstawie prędkościomierza, a nie według decyzji kierowcy. Dlatego agent nie może sam ogłosić zakończenia pracy; musi to zrobić weryfikacja maszynowa.
Jedno z badań czyni tę zasadę niepodważalną. Badacze z laboratorium i uniwersytetu wykazali, że modele mają trudności z samokorektą bez zewnętrznych informacji zwrotnych, a ich wydajność po takiej korekcie może okazać się gorsza niż wcześniej. To, na ile pewnie brzmi model i czy ma rację, to dwa odrębne sygnały, które rzadziej się pokrywają, niż oczekują twórcy.
Łączenie dowodów z komitem
To, co następuje, to celowo uproszczony zarys, a nie kod produkcyjny. Dowód na pomyślne przeprowadzenie testów jest powiązany z dokładnym checksumem komitu, z którego pochodzi, natomiast dowody pozostałe z wcześniejszej wersji są automatycznie odrzucane.
Sam mechanizm kontrolny nie wystarcza. Sztywny limit liczby iteracji i budżetu, w połączeniu z detektorem braku postępów, są jego nieodłącznymi towarzyszami. Bez nich pętla sterowana dowodami może nadal generować ogromne rachunki. W jednym zgłoszonym przypadku cztery agenty LangChain, których użycie nie było zakładane w budżecie, działały w pętli przez jedenastu dni, co skończyło się rachunkiem w wysokości około czterdziestu siedmiu tysięcy dolarów, a nikt tego nie zauważył przez ponad tydzień. Ta historia jest znana tylko z wtórnych relacji, a firma jej nie potwierdziła, chociaż wszystkie niezależnie znalezione źródła są zgodne. Przycisk wyłączający działa jak bezpiecznik, przerywając pętlę bez względu na upór modelu.
Pętle mają jeszcze jeden sposób awarii. Agenci mogą próbować oszukać testy zamiast rozwiązywać podstawowy problem. Karta systemowa jednego z dostawców odnotowała spadek tego zachowania o około dwie trzecie pomiędzy poszczególnymi generacjami modeli. Był to spadek, a nie zerowanie, co ma znaczenie opisane poniżej jeszcze dwukrotnie.
Pętla kończy swoją pracę, gdy zadanie zostanie ukończone. Decyzja o tym, kto będzie wykonywał zadanie, gdy jest ich więcej niż jedno, należy do trzeciej warstwy.
Warstwa grafu: gdy konieczne są kilka agentów
Inżynieria grafu kształtuje przepływ sterowania oraz współbieżność między różnymi agentami. Nie jest to stanowisko filozoficzne – to, czy przynosi korzyść, czy szkodę, zależy od jednego czynnika, a mianowicie od tego, czy zadanie dzieli się na niezależne części.
W 2025 roku dwie silne koncepcje zderzyły się w tej kwestii. Duże laboratorium opisało model oparty na głównym agencie wraz z pomocniczymi agentami, który w własnych testach zadań badawczych o zróżnicowanym zakresie przewyższył pojedynczego agenta o około 90 procent, przy czym testy te finansowano dodatkowymi tokenami. Dostawca oszacował, że pojedynczy agent zużywa około czterokrotnie więcej tokenów niż w zwykłej rozmowie, a konfiguracja z wieloma agentami około piętnastokrotnie więcej niż ten podstawowy poziom, więc rzeczywisty współczynnik efektywności systemów wieloagentowych w porównaniu z jednoagentowymi jest bliższy trzem lub czterem niż piętnastu. Walden Yan z Cognition argumentował przeciwnie w kontekście ściśle powiązanych zadań programistycznych: rozdzielanie ich między agenty bez wspólnego kontekstu prowadzi do kruchych systemów i sprzecznych założeń, jak napisał w swoim wpisie z czerwca 2025 roku zatytułowanym „Nie twórzcie systemów wieloagentowych”.
To nie były identyczne warunki prowadzące do przeciwnych rezultatów. Były to dwa różne rodzaje zadań, a każda ze stron wyciągnęła ogólne wnioski na podstawie tej, która sprzyjała jej konkluzji.
Progi podzielności
Rozwiązanie tego problemu można skwantyfikować. Artykuł z grudnia 2025 roku zatytułowany „Towards a Science of Scaling Agent Systems” (Kim i współpracownicy z Google Research, Google DeepMind oraz MIT) zmierzył to, co nazywa progiem podzielności. Centralizowana koordynacja poprawiła wydajność zadań nadających się do równoległego wykonywania o około 81 procent, natomiast pogorszyła wydajność zadań wymagających sekwencyjnego rozumowania o 39 do 70 procent; korzyść ta znikała, gdy stopa sukcesu pojedynczego agenta w danym zadaniu przekraczała około 45 procent. Jest to pomiar dotyczący zadań przedstawionych w tym badaniu, a nie uniwersalne prawo.
Prościej mówiąc, parallel fan-out polega na tym, że orkiestrator uruchamia kilka podagentów jednocześnie, z których każdy ma swój własny, izolowany kontekst, natomiast sync join gate to węzeł redukcyjny, który czeka na wszystkie gałęzie i łączy je według ustalonej zasady, zamiast negocjować. Dziesięć miesięcy później nawet ci, którzy wątpili w grafy, zgodzili się co do jednej zasady: tylko jeden „pisarz” naraz, przy czym dodatkowe agenty dostarczają moc obliczeniową, a nie osobne działania.
Teraz wiesz, kiedy grafy są przydatne, a kiedy szkodliwe. Pozostaje już tylko połączenie wszystkich trzech warstw w jeden łańcuch przetwarzania.
Zintegrowany pięcioetapowy łańcuch przetwarzania
Każda z tych warstw łączy się w jeden spójny proces, który można określić jako zintegrowaną architekturę pięciu etapów. Działa ona jak linia montażowa dla wszystkich powyższych kroków: ustala granice, dzieli zadania na niezależne części, sprawdza każdą z nich na podstawie twardych dowodów, rejestruje potwierdzenie, a na końcu zaprasza kogoś do zweryfikowania wyniku.
Każdy etap mieści się w jednym zdaniu i należy do konkretnej warstwy:
- Harness sandbox initialisation ustala granice przed rozpoczęciem pracy.
- Parallel graph fan-out and scoping wyodrębnia tylko te zadania, które faktycznie są niezależne.
- Local evidence-gated retry loops zmuszają każdą część do udowodnienia swojej poprawności przed przekazaniem informacji dalej.
- Harness state hashing and token deduplication rejestruje dokładne potwierdzenia zamiast niepełnych streszczeń.
Najbardziej przydatny wniosek jest sprzeczny z intuicją. Wartość wynika z obecności wszystkich pięciu etapów w minimalnej formie, a nie z udoskonalonej wersji obejmującej tylko dwa z nich. Prosta, uruchamiana brama adwersarialna jest lepsza od skomplikowanej, która nigdy nie zostanie stworzona.
Najprostsze działające rozwiązanie jest proste: instrukcje do repozytorium poniżej trzystu wierszy, jeden komendę weryfikacyjną, którą można uruchomić, środowisko sandbox lub przynajmniej izolowany katalog roboczy, warunek zatrzymania, który nie jest tekstem napisanym przez model, stan przechowywany w komitach oraz dziennik postępów, oraz ograniczenie liczby ruchów i wydatków. Te sześć elementów występuje przed jakimkolwiek grafem z wieloma agentami piszącymi.
Proces jest kompletny, ale jego ostatni etap zasługuje na osobną sekcję, ponieważ dotyczy mityku zerowych wad.
Etap piąty: weryfikacja adwersarialna, redukcja i nigdy zero
Weryfikator z zespołu red-team adwersarialnego to druga para oczu, która nigdy nie widziała pisanego kodu. Bada plik z poprawkami pod kątem przypadków krawędziowych i luk bez dostępu do śladów rozumowania twórcy, dlatego nie ma żadnego uprzedzenia potwierdzającego charakterystyczne dla tego agenta.
Warstwa ta wykrywa inny rodzaj wad niż pętla kontrolowana dowodami, ale nie wszystkie z nich, a żaden udokumentowany system nie osiąga poziomu zero błędów. Badania modeli oceniających kod wykazują wyraźnie mniej błędów, jednak te same modele czasami wymyślają niektóre z zgłaszanych przez siebie usterek. Wskaźnik testowania typu „game-playing” spadł o około dwie trzecie pomiędzy poszczególnymi generacjami, ale nie zniknął całkowicie.
Najbardziej pouczającym przykładem jest ćwiczenie zespołu czerwonego przeprowadzone przed fuzją przez programistę o imieniu Dotzlaw. W pierwszej rundzie ataki odnosiły sukces w około 65 procentach przypadków. Naprawa znanych wektorów ataku w drugiej rundzie obniżyła ten wskaźnik do 20 procent, ale nowa fala ataków wykorzystująca nowe techniki omijania filtrów podniosła go do 85,7 procenta w ramach tej samej rundy, co dało łączny wynik dla drugiej rundy na poziomie około 47 procent. Traktuj to jako pojedyncze zgłoszone ćwiczenie, a nie potwierdzoną normę w branży.
Obniżenie, ale nie zerowanie
Wyrażenie „produkcja bez żadnych defektów” pasuje do marketingu, a nie do inżynierii. Można uczciwie twierdzić tylko o niższym wskaźniku ucieczki defektów, a nie o zerowym. Wierzenie, że zero jest osiągalne, jest bardziej ryzykowne niż przyznanie się do istnienia pewnych ograniczeń, ponieważ skłania zespoły do pominięcia ludzkiego elementu kontroli, który wykrywa to, czego narzędzia z powodu swojej konstrukcji nie mogą dostrzec.
Najczęściej przytaczanym przykładem ostrzeżenia jest sytuacja w Replit w lipcu 2025 roku, gdy baza danych produkcyjna została usunięta podczas wyraźnego zamrożenia zmian. Żaden element w procesie wykonywania nie egzekwował tego zamrożenia, które istniało jedynie jako instrukcja w promptzie. Niezależnie od poziomu dojrzałości pozostałych warstw, należy zachować nadzór ludzki lub zasady polityki dla działań o najwyższym ryzyku.
Biorąc pod uwagę, że nawet cały proces nie daje wyniku zero, co on wtedy dostarcza? Właśnie tu przydają się liczby z zastrzeżeniami.
Tryb wewnętrzny kontra architektura: liczby z zastrzeżeniami
Należy zacząć od braku danych, a nie od konkretnych wartości. Cztery niezależne badania przeprowadzone w tym celu nie ujawniły żadnego przejrzystego, niezależnego badania przeprowadzonego dla każdej prośby o aktualizację, które porównywałoby cały zestaw narzędzi, pętle i struktur grafowych z jednym, niezależnym promptem. Ta brak informacji sama w sobie mówi wiele.
Dlatego porównanie „trybu intern” i „architektury master” występuje wyłącznie jako ilustracja i jest opisane jedynie pod kątem szybkości, ceny i stabilności: szybciej, taniej, bardziej stabilnie. Nie ma żadnych wymyślonych procentów ani tabel udających pomiary. Te strzałki należy traktować jako przybliżoną ocenę do szybkiego planowania, przydatną dla intuicji, ale bezużyteczną w dokumencie.
Jedyny dostępny punkt odniesienia jest węższy niż założenia i słabszy pod względem źródeł informacji niż idealny, dlatego jest przedstawiony w taki sposób. Jest to wcześniej wspomniane porównanie opublikowane przez dostawcę, dotyczące wybranego podzbiórów testów SWE-bench Verified, które pokazuje trzykrotną różnicę w kosztach przy porównywalnym lub lepszym wyniku; to, co jest w nim wyodrębnione, to sam warstwa środowiskowa, a nie połączone trzy warstwy.
To ma znaczenie dla zaufania czytelników. Skrupulatny czytelnik może sprawdzić podane dane w ciągu sekund, więc etykieta „ilustracyjna” jest atutem wiarygodności, a nie zabezpieczeniem. Gdy gdzie indziej pojawia się twierdzenie, że „strukturalna architektura jest N razy szybsza”, zanim w to uwierzysz, poproś o metodologię stosowaną przy każdej prośbie o aktualizację.
Liczby są szczerze oznaczone jako ilustracyjne. Natomiast wzorce awarii obserwowane w produkcji takimi nie są.
Cztery antypatrony i ich objawy
Wiele skarg na to, że model po prostu nie jest wystarczająco dobry, dotyczy w rzeczywistości jednej z czterech określonych luk architektonicznych, które można naprawić. Nadanie im nazw sprawia, że traci się chęć zastąpienia modelu w celu rozwiązania problemu architektonicznego.
- Pętlenie napędzane pewnością siebie. Agent twierdzi o sukcesie, mimo że testy nadal się nie udają. Rozwiązaniem jest powiązanie warunku zatrzymania z sprawdzeniem o charakterze deterministycznym.
- Kontekst uprzęży generującej hałas. Agent traci decyzję z wczoraj, ponownie czyta te same pliki i marnuje tokeny, powtarzając pracę. Rozwiązaniem jest utrzymywanie stanu poza oknem kontekstowym wraz z pamięcą cache wyników narzędzi.
- Cykły w grafie bez ograniczeń. Jeden agent zachowuje się określony sposób, natomiast wersja wieloagentowa zwraca wyniki, które są ze sobą sprzeczne. Rozwiązaniem jest praca tylko jednego „pisarza” na raz, z możliwością jedynie równoległego czytania, przy czym każdy agent działa we własnym kontekście.
- Wprowadzanie deterministycznej pracy do modelu. Objaw: wywołanie modelu wykonuje operacje takie jak analiza składniowa, usuwanie duplikatów lub filtrowanie, które powinna obsługiwać zwykła funkcja. Jest to droższe, wolniejsze i mniej niezawodne niż kod, który w ogóle nie musi rozumować.
Błędna diagnoza może mieć poważne konsekwencje finansowe. Niezależne badanie z 2025 roku wykazało, że doświadczeni programiści pracowali o około 19 procent wolniej przy użyciu narzędzi AI z tamtego okresu nad rzeczywistymi problemami. Należy pamiętać o ograniczeniach: 16 uczestników, złożone bazy kodu liczące ponad milion linii oraz narzędzia z wczesnego 2025 roku. Jest to wąski, lecz wiarygodny sygnał, a nie ocena programowania wspomaganego przez AI jako całości.
Diagnoza została postawiona. Pozostaje jedno pytanie: czy Twoja architektura w ogóle spełnia minimalne wymagania, aby ten podejście miało sens?
Lista kontrolna gotowości do produkcji
To lista przedstartowa, a nie kompletny podręcznik obsługi. Składa się z pięciu krótkich grup, przy czym każdy punkt można odpowiedzieć twierdząco lub przecząco.
- Wspornik: instrukcje w repozytorium składające się na mniej niż trzysta linijek, środowisko testowe lub przynajmniej granice drzewa roboczego, stan przechowywany za pomocą komitów oraz dziennik postępów, a także skrypt cache’ujący wyniki narzędzi, który poprawnie funkcjonuje.
- Pętla: warunek zatrzymania oparty na rzeczywistym kodzie wyjścia, a nie na opisach modelowych, ścisłe ograniczenia liczby iteracji i rund, oraz detektor braku postępów, który wykrywa powtarzanie się tych samych błędów.
- Graph: domyślnie jeden autor, rozgałęzianie równoległe wyłącznie dla niezależnych zadań tylko do odczytu, oraz mechanizm redukcji z deterministycznymi zasadami łączenia gałęzi.
- Ocena: co najmniej jedna deterministyczna weryfikacja wykonywana w CI, plus krótkie, pisemne stwierdzenie, precyzyjnie określające, co oznacza pomyślne przejście testu i czego ono nie gwarantuje.
Zespoły zatrzymują się na tym etapie z powodów innych niż trudność – dopracowują jeden warstwę, zanim powstanie minimalna wersja wszystkich pięciu. Traktuj to jako formalną zgodę na wypuszczenie prostej wersji każdej warstwy, zanim zaczną się pogłębiać.
Trzy warstwy, jedno zdanie
Platforma dostarcza środowisko, pętla dostarcza informacji zwrotnej, a graf dostarcza strukturę przepływu. Żadna z tych trzech elementów nie zastępuje pozostałych dwóch, a przedstawienie w postaci zagnieżdżonych elementów od samego początku jest jedyną mapą, która jest naprawdę potrzebna.
Największa zmiana, jaką wprowadza ten framework, nie ma charakteru technicznego. Pytanie otwierające w przypadku awarii zmienia się – z pytania o konieczność wymiany modelu na pytanie o to, który warstwa zawiodła. Zespoły, które przyjmują takie ujęcie, często stwierdzają, że przyspiesza to diagnozę bardziej niż jakakolwiek korekta kodu.
Pięć punktów do zapamiętania:
- Warstwy są wzajemnie powiązane, a nie konkurencyjne. Zestaw narzędzi, graf, pętla i stos modeli stanowią jeden system produkcyjny, a nie trzy konkurencyjne filozofie.
- Objaw wskazuje na odpowiednią warstwę: „zrobione, ale niepracujące” oznacza pętlę, „rozpad zespołu” oznacza graf, a „zapomnienie wczorajszej decyzji” oznacza zestaw narzędzi.
- Orchestracja wielu agentów nie jest ani dobra, ani zła; decyduje o tym to, czy zadanie wymaga podziału, a nie upodobania architektoniczne.
Zanim wprowadzi się jakiekolwiek zmiany w kodzie, należy przeanalizować kolejny incydent produkcyjny pod kątem listy antypatronów, a przed dodaniem kolejnego agenta do struktury – sprawdzić jego propozycję architektury według listy kontrolnej gotowości. Praktyczne ćwiczenie na dziś: weź ostatnie trzy incydenty związane z twoim agentem i przypisz do każdego z nich odpowiedni warstwę, element wspierający, pętlę lub strukturę grafu. Większość zespołów znajduje jednego powtarzającego się problemu, i to właśnie tam należy skupić się w przyszłym tygodniu.
Literatura pokrewna
- Agent Harness, Loop i Graph: Trzy warstwy stojące za niezawodnymi agentami AI — Dlaczego niezawodne agenty zazwyczaj mają brakującą warstwę: obwód otaczający model, pętla oparta na dowodach oraz wyraźny graf, wraz z wzorami kodu i listą kontrolną do debugowania.
- Twój model semantyczny to API: Zapewnianie agentom certyfikowanych metryk — Dlaczego agenci AI wymyślają własne definicje przychodów i zapasów, oraz jak zorganizowany model semantyczny z określeniem jednostek pomiarowych, właścicieli i reguł odrzucenia zapewnia im jedną umowę.