Inżynieria narzędzi dla agentów: stan, weryfikacja i kontrola wokół modelu
Widok w czasie rzeczywistym agentów produkcyjnych: dlaczego prośby i kontekst nie wystarczają, oraz jak trwały stan, egzekwowanie, weryfikacja i obserwowalność zamierzają tę lukę.
Źródła: Agent Harness Engineering: The Runtime Architecture Behind Reliable AI Agents
Gdy silny model nadal zawodzi
Załóżmy agenta wyposażonego w najlepszy model na rynku, starannie dostrojony prompt systemowy, dziesiątki narzędzi oraz okno kontekstowe wystarczająco duże na całą bazę kodu. Mimo to może ponieść porażkę przy zadaniu, które każdy kompetentny inżynier uznałby za rutynowe. Wybiera właściwą akcję, ale wykonuje ją błędnie. Znajduje kluczowy fakt, a następnie traci go po ponownym ustawieniu kontekstu. Edytuje dziesięć plików poprawnie, ale wprowadza cichą regresję w jedenastym. Spędza godzinę na debugowaniu problemu, który sam stworzył. Może nawet napisać przekonujący raport, w którym stwierdzi, że praca została zakończona, mimo że nic nie zostało sprawdzone.
Zwykłą reakcją jest praca nad instrukcją: kolejne polecenie, kolejny przykład, więcej kontekstu, prośba o ostrożność. To pomaga przez jakiś czas, a potem przestaje być skuteczne. Głębszy błąd leży w modelu mentalnym, który traktuje model jako agenta, a wszystko wokół niego jako ustawienia. Taki pogląd rozpada się, gdy agent musi działać nieprzerwanie w rzeczywistym środowisku.
Agenat produkcyjny to nie tylko model otoczony instrukcjami. Jest to system działający w czasie rzeczywistym: przechowuje stan, wykonywa czynności, komunikuje się z zewnętrznymi systemami, radzi sobie z awariami, przyjmuje informacje zwrotne i wymaga sposobów na odzyskanie funkcjonalności, weryfikację oraz kontrolę. Dyscyplina rozwijająca się wokół takiego systemu nazywana jest inżynierią narzędzi dla agentów. Porównaj ją z pracą nad instrukcjami. Inżynieria instrukcji pyta, jak skierować model do określonego zachowania, natomiast inżynieria narzędzi pyta, jak stworzyć środowisko, w którym model może niezawodnie osiągnąć cel. To nie jest ulepszona instrukcja – to inna abstrakcja, obejmująca zarówno to, co model pisze, jak i to, co system może robić, co przetrwa awarię, co jest dozwolone oraz co uznaje się za zakończone.
System działający w czasie rzeczywistym dla modelu probabilistycznego
Najprostszym obrazem agenta jest model zawierający instrukcję oraz kilka narzędzi. To wystarcza do zrozumienia pojedynczej inferencji, ale nie nadaje się dla agenta produkcyjnego, który lepiej można postrzegać jako system działający w czasie rzeczywistym oparty na modelu probabilistycznym.
Model wykonuje rozumowanie. Narzędzie sterujące określa warunki, w których to rozumowanie przechodzi w realizację: co model widzi, do czego może dotrzeć, jakie działania są dozwolone, jaki stan pozostaje nienaruszony oraz jakie dowody są potrzebne, zanim można ogłosić sukces.
Weźmy agenta do programowania, którego instrukcja mówi o najpierw sprawdzeniu architektury, uruchomieniu testów i pozostawieniu niespowiązanych komponentów w spokoju. Te zdania określają intencję, ale nic nie narzucają. Narzędzie pomocnicze może uczynić określone pliki dostępnymi do zapisu, a inne nie, wykonywać weryfikację po każdej zmianie, blokować zabronione operacje, przechowywać postępy i odmawiać zamknięcia zadania bez dowodów. Zatem instrukcja określa, co agent powinien robić, podczas gdy narzędzie pomocnicze decyduje o tym, co system pozwoli oraz co uznaje się za zakończone. Model dostarcza inteligencję, a narzędzie pomocnicze przekształca ją w coś, z czym można pracować.
Trzy warstwy inżynierii
Inżynieria agentów przechodziła przez trzy coraz szersze poziomy abstrakcji: instrukcje, następnie kontekst, a potem narzędzie pomocnicze.
Inżynieria promptów polega na określaniu, co model powinien zrobić. Poprawia instrukcje, przykłady, opisy narzędzi oraz ograniczenia behawioralne i w prostych zadaniach działa niezwykle skutecznie. Jednak prompt to jedynie instrukcja i nie ma mocy przymusowej. Agentowi, któremu polecono przeprowadzić testy, nadal można twierdzić, że odniósł sukces, nie wykonując ich. Polecenie, by nie dotykał plików produkcyjnych, niewiele znaczy, jeśli środowisko wykonawcze zapewnia mu nieograniczony dostęp. Prośba o zapamiętanie decyzji na sześć godzin stoi w sprzeczności ze wszystkim innym, co trafia do kontekstu.
Inżynieria kontekstu zajmuje się kolejnym problemem, a mianowicie tym, co model powinien znać w momencie podejmowania decyzji. Proces wydobywania informacji, umiejętności, pamięć, wyniki narzędzi, ustrukturyzowany stan, stopniowe ujawnianie informacji oraz kompresja – to wszystko tworzy lepszy kontekst decyzyjny, a cel zmienia się z posiadania większej ilości kontekstu na posiadanie lepszego kontekstu. Mimo to model może wybrać niewłaściwą akcję, uszkodzić stan, pominąć weryfikację, utknąć w pętli lub zbyt wcześnie ogłosić sukces.
W tym momencie zaczyna się inżynieria zarządzania systemem – pojawia się pytanie, jaki system powinien otaczać model, aby zadanie mogło zostać wykonyane w sposób niezawodny. Zapewnia ona to, czego same prompty i kontekst nie mogą dostarczyć: trwały stan, ograniczone narzędzia, uprawnienia, izolację, weryfikację, możliwość odzyskania stanu, ocenę oraz możliwość obserwacji. Zmienia ona również cykl inżynieryjny – awaria nie wymaga już tylko przepisania promptu; pojawia się pytanie, który element kontroli brakuje, a odpowiedzią może być walidator, bardziej rygorystyczny kontrakt narzędziowy, granica polityki, punkt kontrolny, strategia odzyskania lub lepsza widoczność. Każda awaria kończy się zmianą w systemie.
Rezultatem jest zębatka pasa bezpieczeństwa: awaria, następnie brak kontroli, potem ulepszenie pasa bezpieczeństwa, następnie weryfikacja i w końcu silniejszy punkt odniesienia. Inżynieria promptów poprawia to, co jest mówione modelowi, a inżynieria kontekstu poprawia to, co on wie. Inżynieria pasa bezpieczeństwa poprawia warunki, w których model pracuje, i sprawia, że system staje się coraz trudniejszy do awarii w taki sam sposób dwukrotnie.
Odpowiedzialność środowiska wykonawczego
Jeśli pas bezpieczeństwa to środowisko wykonawcze, co ono zawiera? Zamiast wymieniać prompty, narzędzia, pamięć i kod orkiestracji, bardziej przydatne jest określenie obowiązków środowiska wykonawczego.
- Kontekst decyduje o tym, co model musi wiedzieć, aby podjąć następną decyzję: instrukcje, pobrane materiały, umiejętności, wyniki użytych narzędzi oraz aktualne obserwacje.
To nie są siedem niezależnych funkcji, ani nie muszą to być siedem usług. Razem tworzą pętlę sterującą wokół modelu probabilistycznego. Gdy ta pętla działa godzinami zamiast minut, przetrwując ograniczenia kontekstu, awarie, próby ponowne oraz zmiany pracowników, architektura zaczyna przypominać coś, co inżynierowie już dobrze znają – system rozproszony.
Okno kontekstowe to nie magazyn stanu
Jednym z najprostszych błędów w projektowaniu agentów jest traktowanie okna kontekstowego jako pamięci.
To kuszący nawyk. Model może widzieć całą rozmowę, wcześniejsze wywołania narzędzi, decyzje oraz wyniki pośrednie, więc dodawanie kolejnych informacji wydaje się nieszkodliwe. Jednak ten obszar to zbiór roboczy, a nie baza danych. Nic w nim nie jest trwałe: restart, skrócenie lub proces kompresji może go zmniejszyć lub całkowicie zastąpić. Powiększanie tego obszaru dodaje pojemność, ale nie zmienia jego trwałości.
Dla agenta działającego przez długi czas stan zadań musi znajdować się gdzie indziej: cel, ukończone i w toku zadania, decyzje, pliki wynikowe, punkty kontrolne, wyniki weryfikacji oraz odnośniki do zasobów zewnętrznych. Kontekst jest następnie odbudowywany na podstawie tego stanu, zgodnie z tym, czego model potrzebuje w danym momencie. Różnica jest prosta: kontekstem jest to, co widzi model, a stanem to, co wie system.
Kompresja sprawia to oczywistym. Agent, który spędził trzy godziny na modyfikacji repozytorium, może zgromadzić setki wywołań narzędzi, porzuconych podejść oraz zapisanych obserwacji. Skondensowanie tej historii może uczynić kolejny kontekst użytecznym, ale podsumowanie pozostaje interpretacją tego, co się wydarzyło, więc krytyczny stan nie powinien zależeć od tego, co zachował kompresor. Zamiast tego narzędzie może stworzyć nowy kontekst na podstawie trwałego stanu, w następującej kolejności: stan zadania, istotne artefakty, aktualne obserwacje, umiejętności oraz wreszcie kontekst modelu.
Checkpointy stosują tę samą zasadę w przypadku awarii procesów, a zorganizowane przekazywanie informacji stosuje ją pomiędzy agentami lub pracownikami. Następca potrzebuje stanu niezbędnego do prawidłowego kontynuowania pracy, a nie całej rozmowy swojego poprzednika. Pytanie architektoniczne brzmi, jakie informacje muszą przetrwać niezależnie od kontekstu, a gdy zostanie to postawione, zarządzanie kontekstem staje się problemem zarządzania stanem.
Agenty działające przez długi czas to systemy rozproszone
Gdy agent działa godzinami lub dniami, tradycyjny model żądanie-odpowiedź przestaje funkcjonować. Proces może się zakończyć, narzędzie może osiągnąć limit czasu, a pracownik może zniknąć po zakończeniu operacji, zanim ją zgłosi. Dwóch pracowników może przejąć to samo zadanie. Kontekst modelu może zniknąć w połowie procesu. Nic z tego nie jest egzotyczne, ponieważ są to klasyczne problemy systemów rozproszonych, a długo działający mechanizm wymaga wyraźnych semantyk wykonania, aby sobie z nimi poradzić.
Jeśli praca może przetrwać pracownika, konieczne są ograniczenia dotyczące prawa własności. Umowa dzierżawy pozwala pracownikowi przejąć zadanie na określony czas, a sygnały aktywności dostarczają zewnętrznemu obserwatorowi informacji o jego istnieniu. Gdy pracownik zniknie, umowa dzierżawy wygasa i inny może przejąć pracę na podstawie trwałego stanu.
Ponawiane próby wymagają równego podejścia. Wyobraźmy sobie agenta, który wysyła zlecenie implementacji, a połączenie wygasa zanim pojawi się jakikolwiek wynik. Słupa ponawiania prób mógłby uruchomić tę implementację dwukrotnie. Dlatego narzędzia agentów potrzebują gwarancji obecnych w innych systemach rozproszonych: identyfikatorów operacji, właściwości idempotentności, wyraźnych stanów błędu oraz jasno określonego odpowiedzialnego za zachowanie przy ponawianiu prób.
Następnie jest kontynuacja. Długa zadanie powinno być reprezentowane jako trwały postęp, a nie jako rozmowa w pamięci tymczasowej, zgodnie z cyklem sprawdzania stanu, wykonywania, obserwacji, przechowywania i kontynuowania. Jeśli wykonywanie zostanie przerwane w połowie, system musi określić, czy bieżący krok można bezpiecznie powtórzyć, czy został już zapisany, czy jest częściowo ukończony, czy wymaga korekty. Kontynuacja nie oznacza odtwarzania wszystkiego – oznacza odbudowę minimalnego stanu niezbędnego do bezpiecznego kontynuowania. Przekazywanie obowiązków odbywa się według tego samego wzoru: nowy pracownik otrzymuje cel, decyzje, wyniki pracy, stan weryfikacji oraz nierozwiązane zadania, a nie żadne informacje z historii rozmów poprzedniego pracownika.
To określa centralną granicę niezawodności. Gdy agent może przetrwać dłużej niż jego proces, to proces nie jest już jednostką niezawodności – jednostką taką jest trwałe zadanie.
Weryfikacja to druga połowa agencji
Agent może pisać kod, uruchamiać procesy wdrożeniowe, tworzyć zapytania do bazy danych lub modyfikować infrastrukturę. Stworzenie czegoś to nie to samo, co jego prawidłowe wykonanie, a ryzykownym podejściem jest pozwalanie agentowi decydować o tym, czy jego praca się udała, na przykład poprzez komunikat informujący o zakończeniu procesu autoryzacji i pomyślnym przejściu wszystkich testów. System nie powinien przyjmować tego jako dowodu – powinien uruchomić testy. Podobnie, stwierdzenie, że usługa jest sprawna, powinno uruchomić kontrole stanu, a nie zakończyć zadanie; migracja danych powinna być oceniana na podstawie schematu i niezmienników danych, a nie na podstawie interpretacji modelu dotyczącej własnych wywołań narzędzi. Przekonanie agenta o swoim sukcesie nie stanowi wiarygodnego sygnału zakończenia pracy.
Dlatego w procesie produkcji wykorzystuje się trzy odrębne role. Planista decyduje, co musi się wydarzyć. Wykonawca wykonuje określone zadania. Oceniający decyduje, czy wynikowy stan systemu spełnia wymagania. Jeden model może pełnić wszystkie trzy role, ale ich obowiązki pozostają odrębne.
Weryfikacja powinna opierać się na rzeczach, które można zaobserwować, a deterministyczne dowody są pierwszym wyborem tam, gdzie są dostępne: kompilatory, narzędzia do wykonywania testów, walidatory schematów, sprawdzanie stanu systemu, status wdrażania, weryfikacja zasad lub proste stwierdzenia. Ocena oparta na modelu jest przydatna, gdy poprawność ma charakter semantyczny, ale wymaga konkretnych kryteriów, a nie niejasnego pytania o to, czy wynik wygląda dobrze. Wtedy ukończenie zadania staje się właściwością systemu, a nie czymś, co mówi model: wymagania spełnione, walidacja przeprowadzona, niezbędne pliki obecne, weryfikacja zasad zakończona pomyślnie – dopiero wtedy zadanie jest ukończone. Innymi słowy, weryfikacja dostarcza dowodów, a osoba oceniająca je analizuje, aby zdecydować, czy można kontynuować wykonywanie zadania; w ten sposób osoba oceniająca pełni rolę czujnika w pętli sprzężenia zwrotnego. Agent napędza postęp, podczas gdy system tworzy odpowiednie dowody.
Od instrukcji do egzekwowania
Agent może otrzymać polecenie, by czegoś nie robić, bez utraty możliwości tego zrobienia. Zdania takie jak „nie modyfikuj produkcji”, „pisz tylko w przestrzeni roboczej” oraz „nigdy nie ujawniaj danych uwierzytelniających” są przydatne, ale żadne z nich nie stanowi granicy bezpieczeństwa, jeśli środowisko wykonawcze nadal pozwala na tę operację. Instrukcje komunikują intencję, natomiast egzekwowanie zapewnia niezmienniki.
Projekt narzędzia wyraźnie pokazuje tę różnicę. Gdy agent otrzymuje ogólne funkcje typu execute_sql(), jego możliwości działania znacznie różnią się od tych agenta, który ma dostęp do ograniczonej, tylko do odczytu interfejsu zapytań. Interfejs ograniczony daje możliwość sprawdzenia uprawnień, walidacji parametrów, audytu operacji oraz zmniejszenia zasięgu ich wpływu. Narzędzia MCP, API, systemy plikowe, wiersze poleceń oraz zewnętrzne usługi działają w ten sam sposób: model proponuje działanie, a mechanizm decyduje, czy może ono zostać wykonane oraz pod jaką tożsamością, z jakimi uprawnieniami, w jakim środowisku i zgodnie z jaką polityką.
Praktyczna zasada pomocnicza polega na sortowaniu ograniczeń według kosztu ich naruszenia:
- Jeśli złamanie ograniczenia jest do przyjęcia, może wystarczyć pojedyncza instrukcja.
- Jeśli jego złamanie jest kosztowne, należy dodać weryfikację.
- Jeśli jego złamanie jest niebezpieczne, należy je egzekwować na granicy.
Sandboxing wprowadza drugi wymiar. Autoryzacja decyduje o tym, czy dana akcja jest dozwolona. Sandbox określa natomiast, co się stanie, gdy agent zachowuje się niewłaściwie. Granice w systemie plików i sieci, ograniczenia zasobów oraz ściśle określone uprawnienia pomagają ograniczyć skutki nieoczekiwanego zachowania. Bardziej zaawansowane rozwiązania kontrolują również przejścia pomiędzy etapami pracy, a nie tylko pojedyncze wywołania narzędzi. Wdrożenie w środowisku produkcyjnym może pozostać niedostępne, dopóki testy nie przejdą, środowisko testowe będzie sprawne i ktoś je nie zatwierdzi. Model może zasugerować takie przejście, ale to reguły działania decydują o jego zgodności z przepisami. To bardziej przypomina maszynę stanową niż poleganie na zdaniu w języku naturalnym. Celem nie jest ograniczanie inteligencji, lecz ograniczanie możliwości i zasięgu jej oddziaływania.
Nie można zarządzać tym, czego nie można obserwować
Zwykła obserwowalność dotyczy sprawdzania, czy usługa funkcjonuje prawidłowo, gdzie rośnie opóźnienie i która zależność zawodzi. Systemy agentowe wymagają dodatkowej warstwy. Gdy agent zawodzi, pojawia się pytanie o to, co się stało oraz dlaczego jego rozwój doprowadził do tego stanu. Czego próbował osiągnąć? Jaki miał kontekst? Jakie narzędzia wykorzystał? Które zasady umożliwiły lub zabroniły tych wywołań? Jakie zmiany nastąpiły w stanie systemu? Jakie dowody przekonały go, że zadanie zostało wykonane? To właśnie jest obserwowalność trajektorii.
Standardowe metryki LLM, takie jak liczba tokenów, opóźnienie, koszt, wersja modelu oraz dane wejściowe i wyjściowe, są konieczne, ale niewystarczające, ponieważ jedna próba uruchomienia modelu to pojedynczy element w szerszym łańcuchu: intencja, kontekst, decyzja, działanie, obserwacja, stan, weryfikacja i wynik. Załóżmy, że agent spędza czterdzieści minut na migracji usługi, a następnie ponosi porażkę. Informacja o zużyciu 80 tysięcy tokenów niewiele mówi. Przydatna analiza mogłaby pokazać, że narzędzie użyte do migracji pobrało przestarzałe instrukcje, agent wybrał nieaktualną API, implementacja technicznie się udała, ale testy integracji zawiodły, a procedury naprawcze ponownie zastosowały tę samą strategię. To jest rzeczywista diagnoza.
To oznacza, że kontekst wymaga źródła: sposobu na określenie, jakie umiejętności, dokumenty, stan i wyniki narzędzi wpłynęły na dane decyzje. Wywołania narzędzi również potrzebują kontekstu przyczynowego, obejmującego krok zadania, który je uruchomił, tożsamość użytego narzędzia, politykę, która została oceniona, oraz konsekwencje. Decyzje polityki i przejścia pomiędzy stanami powinny być równie widoczne, podobnie jak działania, które zakończyły się sukcesem. Najbardziej informacyjne wskaźniki okazują się być behawioralne: stopa sukcesu w wykonywaniu zadań, błędy w weryfikacji, skuteczność przywracania stanu, przedwczesne zakończenie, odrzucenia ze względu na politykę, powtarzające się wzorce błędów, interwencje ludzi oraz liczba kroków na jedno zadanie zakończone pomyślnie.
Obserwowalność to element, który dopełnia całości systemu. Awaria powinna pozostawić coś więcej niż tylko wpis w dzienniku. Jej przebieg powinien umożliwić sklasyfikowanie tego, co poszło nie tak, oraz określenie brakującego elementu sterującego – czy to źródła kontekstu, narzędzia oceny, zasady działania, granic narzędzia, punktu kontrolnego czy strategii odzyskiwania. Celem jest system, który nie może zawieść w ten sam sposób dwa razy.
Nowa dyscyplina systemowa
Gdy pyta się, jak sprawić, by agenci lepiej wykonywali swoje zadania, odpowiedź staje się coraz szersza wraz ze wzrostem autonomii. Inżynieria poleceń dostosowuje instrukcje, inżynieria kontekstu dostosowuje informacje dostępne w momencie podejmowania decyzji, a inżynieria całego procesu wykonania dostosowuje cały jego przebieg: stan systemu, działania, granice, informacje zwrotne, mechanizmy odzyskiwania, weryfikację oraz obserwowalność. Nie zastępują one się wzajemnie, lecz stanowią coraz szersze zakresy działania.
Korzystny podział obowiązków stanowi fundament całego rozwiązania: model zajmuje się rozumowaniem w warunkach niepewności, natomiast środowisko wykonawcze odpowiada za zachowanie niezmienników. Pliki, które nigdy nie powinny ulec zmianie, są chronione granicami systemu plików. Systemy produkcyjne, których nie wolno modyfikować, podlegają weryfikacji uprawnień. Procesy migracyjne muszą zostać sprawdzone pod kątem ostatecznego stanu, a stan zadań, które muszą przetrwać restart, jest przechowywany trwale. Gwarancje dotyczące bardziej niezawodnego działania środowiska wykonawczego nie powinny być wymagane od modelu.
Agenty produkcyjne będą zawodzić, a o dojrzałości systemu świadczy to, co robi on dalej. Każde zawodzenie wpływa na bieżącą eksploatację. Jeśli ten sam błąd się powtarza, powstaje specjalny mechanizm jego oceny. Jeśli dana akcja okazuje się ryzykowna, możliwości związane z nią stają się ograniczone. Jeśli doszło do utraty postępów, pojawia się punkt kontrolny w miejscu, gdzie go brakowało, a jeśli próby przywrócenia nadal się nie udają, wchodzi w grę polityka eskalacji. Wykonanie generuje dowody, które ujawniają brakujące mechanizmy kontroli, a te z kolei sprawiają, że kolejne uruchomienie jest bardziej odporne.
Zmienia to również sposób oceny agentów. Pytanie przestaje dotyczyć tego, jak dobry jest model, a staje się pytaniem o to, na ile niezawodnie cały system potrafi wykonać tego typu zadania. Inżynieria Harness to nie kolejna platforma do orkiestracji – to dyscyplina systemowa służąca do zapewnienia niezawodności inteligencji probabilistycznej. Demo pokazuje, że agent potrafi coś zrobić raz; system produkcyjny musi robić to niezawodnie, w sposób sprawdzalny, z możliwością odzyskania stanu i wielokrotnie, przy czym każda awaria powinna poprawić wynik kolejnej próby. Większość najtrudniejszych zadań znajduje się teraz poza samym promptem, w architekturze stanów, pętli sprzężeń zwrotnych, weryfikacji, odzyskiwania i sterowania, które przekształcają rozumowanie agenta w trwałe zachowanie systemu.
Literatura pokrewna
- Agent AI to model AI plus ramię: co robi ramię i dlaczego — Agent to model w połączeniu z ramieniem. Dowiedz się, jak ramiona dodają narzędzia, pamięć, pętle i zasady bezpieczeństwa, w czym różnią się agenci o otwartych wagach i o otwartym kodzie źródłowym oraz dlaczego ważne są oceny.
- Sandboxing agenta programistycznego i utrzymywanie lekkiego okna kontekstowego — Dodaj sandbox typu Seatbelt lub Bubblewrap do agenta i zarządzaj kontekstem za pomocą plików pomocniczych, szablonów, skompresowania oraz późnej iniekcji przyjaznej do cache’u prefiksów.