Prompt, Kontekst, Mechanizm wykorzystania, Pętla: Cztery warstwy leżące u podstaw agenta AI

Częste pytanie początkowe: jeśli model do rozmów to po prostu słowa wpadające do środka i słowa wychodzące na zewnątrz, to jak agenci AI rezerwują loty lub piszą kod? Odpowiedź ma cztery warstwy, a każda z nich istnieje dlatego, że warstwa poniżej nie może sama w sobie wyjaśnić funkcjonowania agenta. Krótkie ujęcie łączące je wszystkie: doskonały prompt bez kontekstu to piękne zdanie wypowiedziane w pustym pomieszczeniu. Doskonały kontekst bez ram jest idealnym planem bez rąk. Kompletny zestaw ram bez pętli to wykwalifikowany pracownik, który nadal czeka, aż ktoś będzie powtarzał „teraz następne zadanie”.

Warstwa pierwsza: prompt

Jednostką pracy tutaj jest pojedynczy wpis. Model nie pamięta nic z okresu przed wywołaniem, więc prompt musi zawierać wszystko, czego potrzebuje: rolę, kontekst, instrukcje, przykłady oraz format wyjścia, wszystko to spakowane w jednej wiadomości. Gdy wyniki są niezadowalające, kluczem jest ustalenie, który element zawodzi, a nie przepisywanie całego tekstu.

Narzędzia dostępne do pracy są liczne:

• Zero-shot prompting polega na bezpośrednim zadaniu pytania bez przykładów, w nadziei, że model to zrozumie.
• Few-shot prompting dostarcza dwa lub trzy przykłady wejścia-wyjścia, a model szuka wzorców w nich.
• Chain-of-thought polega na prośbie o rozumowanie krok po kroku, co może znacząco pomóc w zadaniach matematycznych, logicznych oraz wieloetapowych.
• Role prompting, np. „jesteś starszym redaktorem” lub „jesteś sceptycznym recenzentem”, zmienia ton i poziom ścisłości odpowiedzi.
• Meta-promptowanie i samokonsystencja opierają się na tych elementach przy rozwiązywaniu trudniejszych problemów.

Wszystko to sprowadza się do dobrych instrukcji, podobnych do jasnego e-maila, które odpowiadają na jedno konkretne pytanie: jakie słowa należy teraz użyć w związku z tą konkretną prośbą? Starannie napisany prompt dotyczący streszczenia badawczego może dać precyzyjny wynik o czystej strukturze, bez zbędnych informacji.

Słabość ta pojawia się przy dalszych pytaniami. Jeśli w tym samym czacie zada się pytanie odnoszące się do treści z trzech wiadomości wcześniej, model może je całkowicie przeoczyć i pewnie odpowiedzieć na nieco inne pytanie. Nie pamięta kontekstu, w którym się znajduje. Okazuje się, że dobra fraza jest konieczna, ale niewystarczająca – brakuje czegoś na wyższym poziomie w strukturze promptu.

Dlaczego po prostu nie kontynuować tworzenia lepszych promptów? Ponieważ inżynieria promptów została stworzona do zadań jednorazowych: zapytanie, odpowiedź, koniec. Gdy celem jest coś, co działa w kilku krokach, pamięta wydarzenia, korzysta z narzędzi lub funkcjonuje bez konieczności, by osoba wpisywała każdą instrukcję, sprytny zapis przestaje być wąskim gardłem. Wąskim gardłem staje się wszystko wokół niego. Prompting nadal ma znaczenie – po prostu przestaje być całą historią.

Warstwa druga: kontekst

Tutaj jednostką pracy jest to, co pozostaje w oknie modelu na każdym kroku. Okno jest skończone, podczas gdy dostępne informacje nie, dlatego kuratorstwo staje się niezbędne. Bez niego ważne szczegóły giną pod starymi wynikami narzędzi i dawnymi fragmentami rozmowy, a uwaga modelu się pogarsza. Kurator decyduje, co pozostawić, kompresuje to, co przydatne, ale objętościowe, i wyrzuca resztę. Umiejętność polega na wiedzy, co wyrzucić, a nie na umieszczaniu większej ilości informacji.

Pokój, w którym znajduje się model, ma nazwę: kontekst. Oznacza to wszystko, co model widzi podczas danej rozmowy, a nie tylko prompt: instrukcje systemowe, pobraane dokumenty, definicje narzędzi, historię rozmów, pamięć długoterminową oraz wcześniejsze wyniki narzędzi. Inżynieria kontekstu polega na dobieraniu tego, co model widzi, aby uzyskać lepszy rezultat. Prompting dotyczy wyboru słów do użycia, natomiast inżynieria kontekstu dotyczy tego, co model wie w tym dokładnym momencie.

Analogia z budownictwem może pomóc. Zatrudniając wykonawcę na jeden dzień, można przekazać mu doskonale sformułowany zamówienie robocze, ale bez planu budynku, historii pozwoleń oraz notatek z wczorajszego inspektoratu, takie sformułowanie nie pomoże. Wykonawca z pewnością wykona złą czynność. To odzwierciedla powyższy błąd w dalszym procesie: model nie był głupi, po prostu miał niewystarczające informacje. Większość błędów agentów wynika z braku kontekstu, a nie z wad modelu. Model funkcjonuje prawidłowo, ale nikt nie dostarczył planu budynku.

Oczywistym rozwiązaniem jest dostarczenie mu wszystkiego: całej rozmowy, każdego dokumentu, każdej wcześniejszej interakcji. Im więcej informacji, tym lepsza odpowiedź. Praktycy odkryli coś przeciwnego i nadali temu nazwę – zepsucie kontekstu. Nawet modele z dużymi oknami jakościowo się pogarszają, gdy wypełniają się materiałem jedynie częściowo istotnym. Model nie ma problemu z brakiem miejsca. Sygnał tonie w szumie, a nieistotne szczegóły zaczynają być traktowane jako ważne. Lepszą instrukcją jest podanie właściwej folderu, a nie całej szafki na akta. Zasada w jednym zdaniu brzmi: selekcja zamiast gromadzenia – decydowanie o tym, co powinno znaleźć się w „pomieszczeniu”, a co, co równie ważne, powinno pozostać na zewnątrz.

Nawet w przypadku idealnie przygotowanej przestrzeni szybko pojawia się kolejna bariera. Doskonały kontekst daje piękny plan działań na dalszy krok, a potem model po prostu się zatrzymuje. Nie może otworzyć pliku, uruchomić kodu ani sprawdzić, czy plan zadziałał. To jakby mieć doskonały plan budowy, ale brakować rąk do jego realizacji.

Warstwa trzecia: zestaw narzędziowy

Teraz jednostką pracy jest sama maszyna. Sam model generuje jedynie tekst. Zestaw narzędziowy przekształca go w coś, co może działać, sprawdzać swoje działania i odbudowywać się po awarii, poprzez trzy fazy:

• Zbieranie: zebranie wszystkiego, co jest potrzebne.
• Działanie: uruchomienie modelu, wywołanie narzędzi lub podagentów.
• Weryfikacja: sprawdzenie wyników za pomocą testów lub osoby oceniającej.

W przypadku awarii cały cykl jest ponawiany z zaktualizowanym kontekstem. To właśnie ta różnica odróżnia wywołanie API od uruchamiania agenta.

Praktyczne równanie: agent = model + uprząż. Wszystko, co otacza model, stanowi uprząż – czy to kod, konfiguracja, czy logika wykonywania. Obejmuje to narzędzia dostępne do wywołania, pamięć czytalną i zapisywalną, ograniczenia dotyczące dozwolonych działań, mechanizm koordynacji wybierający kolejny krok oraz stan trwający dłużej niż sesja.

Samo to określenie jest trafne. Koń jest potężny, ale bez uprzążi nie może pracować na roli, ponieważ pasy i wodze kierują jego surową siłę na użyteczną pracę. Zastąpmy konia modelem: ma on inteligencję, ale bez narzędzi, pamięci, ograniczeń i mechanizmów koordynacji ta inteligencja nie ma dokąd się skierować.

Jedno spostrzeżenie zmienia cały obraz sytuacji. Pas nie sprawia, że model staje się inteligentniejszy. Jeśli zastąpimy model lepszym, pas pozostanie taki sam, ponieważ jest to element podłączany od dołu, a nie element kluczowy. Jego rolą jest zapewnienie struktury: sprytny model, który sam w sobie nie posiada żadnego stanu, staje się jednym z komponentów zamkniętego systemu, który podejmuje działania, sprawdza wyniki i kontynuuje pracę dokładnie tam, gdzie skończył się dzień wcześniej.

To również wyjaśnia, co oznacza, gdy sztuczna inteligencja zdaje się pamiętać coś pomiędzy sesjami. Model tak naprawdę nie pamięta – narzędzie zapisuje to gdzieś i przekazuje później. Każde wezwanie modelu zaczyna się od zera, a narzędzie symuluje ciągłość, wykorzystując wczorajsze notatki, dzisiejszą listę zadań oraz stan systemu plików, przekazując to wszystko jako kontekst przed tym, jak model zacznie myśleć. Inżynieria kontekstu i inżynieria narzędzi są więc ściśle powiązane, ponieważ to narzędzie decyduje, jaki kontekst zostanie przygotowany przy każdym wezwaniu.

Warstwa czwarta: pętla

Model wyposażony w narzędzia i pamięć wydaje się szczytem możliwości. Czego jeszcze mógłby potrzebować agent? Rytm pracy. Inżynieria pętli to najnowsza warstwa, której nazwa jest jeszcze ustalana w miarę jej tworzenia.

Oto ta luka. Nawet przy użyciu pełnego zestawu bezpieczeństwa ktoś nadal musi siedzieć przy klawiaturze i decydować, co agent ma robić dalej: wpisać polecenie, przeczytać wynik, wybrać kolejne polecenie i tak dalej. To człowiek bierący udział w tym procesie, krok po kroku, zawsze.

Inżynieria pętli zastępuje ręczną wymianę informacji systemem, który sam steruje tym cyklem: myśli, działa, sprawdza, co się stało, wybiera następny krok i robi to ponownie, bez konieczności ponownego wpisywania instrukcji przez człowieka. Przypomina to różnicę między prowadzeniem samochodu a budową systemu kontroli prędkości. Człowiek już nie naciska pedału gazu co sekundę, ale określił, co oznaczają prędkość jazdy i zatrzymanie się.

Konkretne przykład sprawia, że wszystko staje się jasne. Agent przydzielony do naprawy błędu czyta komunikat o błędzie, opracowuje plan, edytuje kod i uruchamia zestaw testów. Testy nadal zawodzą, więc dostosowuje swój podejście, ponownie edytuje kod i uruchamia testy. Dopiero gdy testy przynoszą pozytywne wyniki lub gdy spróbuje wystarczająco wiele razy i doszednie do wniosku, że utknął, zwraca się do człowieka. Każdy z tych cykli stanowi pętlę, a nikt nie wpisywał w międzyczasie „spróbuj ponownie”.

Co może pójść nie tak? Pętla działająca bez nadzoru może również powtarzać ten sam błąd, tym szybciej, a przez jakiś czas nikt tego nie zauważy. Dlatego staranne projekty włączają do pętli mechanizm oceny: punkt kontrolny, czasami drugi model pełniący rolę sędziego, który ocenia wynik według określonych kryteriów. Dopiero po przejściu tych kryteriów pętla może uznać zadanie za zakończone. Gdy nikt nie obserwuje każdego kroku, weryfikacja przestaje być opcjonalna i staje się częścią opisu zadań pętli.

Wszystkie cztery razem

Podawanie instrukcji to powiedzenie komuś, co ma zrobić, raz. Kontekst to upewnienie się, że właściwa folder znajduje się na ich biurku przed rozpoczęciem pracy. Uzbrojenie dostarcza im rąk, narzędzi oraz pamięci, która przetrwa weekend. Pętla oznacza koniec sytuacji, gdy ktoś musi patrzeć im przez ramię: pracują, sprawdzają własne wyniki, próbują ponownie, jeśli coś jest nie tak, i przychodzą do ciebie dopiero wtedy, gdy praca jest naprawdę zakończona.

Cztery pytania ułożone jedno na drugim, z których żadne nie jest odpowiadane przez poprzednie. Razem tworzą to, co ludzie obecnie nazywają po prostu agentem, jakby to było oczywiste i zawsze tak proste. Tak nie było. Każda warstwa stała się jasna tylko dlatego, że ktoś ciągle pytał dlaczego, aż ujawniły się ograniczenia poprzedniej warstwy.

Literatura pokrewna

• Prompt, Context, Harness, Loop: Cztery warstwy inżynierii agenta AI — Cztery warstwy wzajemnie powiązane decydują o zachowaniu agenta. Dowiedz się, co kontroluje każda z nich, zobacz przykład z GitHuba oraz uzasadnienie, dlaczego najpierw należy stworzyć komponenty harness i loop.
• Praktyczne notatki: Twój agent programistyczny nie potrzebuje lepszego prompta — Szczegółowy przewodnik po praktycznych notatkach dotyczących tego tematu: umowy, sprawdzania oraz gotowe elementy kodu przeznaczone dla zespołów wdrażających ten model.