Inżynieria kontekstu ważniejsza niż prompty. Jak projektować skutecznych agentów AI

W świecie agentów AI coraz mniej chodzi o kunszt pojedynczego promptu, a coraz bardziej o projekt całego środowiska informacyjnego, w którym model podejmuje decyzje. Najnowszy przewodnik Anthropic przesuwa akcent z „prompt engineering” na inżynierię kontekstu — dyscyplinę, która zakłada, że kontekst jest zasobem jednocześnie najcenniejszym i najbardziej ograniczonym. Nawet świetny model nie nadrobi złej selekcji i złej organizacji danych wejściowych, za to skromniejszy LLM potrafi zabłysnąć, jeśli ma pod ręką właściwe fakty, narzędzia i pamięć.

To przesunięcie myślenia ma praktyczne konsekwencje dla zespołów: zamiast dopisywać coraz dłuższe instrukcje, warto budować spójny ekosystem — od przemyślanych system prompts, przez zestaw narzędzi i pamięć, po mechanizmy dynamicznego pobierania informacji.

Czym inżynieria kontekstu różni się od pracy nad promptami

Klasyczne „prompt engineering” to sztuka formułowania instrukcji i formatów odpowiedzi. Inżynieria kontekstu wykracza dalej: obejmuje wszystko, co model widzi podczas wnioskowania — komunikaty systemowe, wyniki z narzędzi, wiedzę domenową, historię rozmowy, a nawet streszczenia wcześniejszych sesji. Wraz z przejściem agentów w tryb wieloturowy i długotrwałe zadania, kluczowe staje się kuratorowanie treści w ograniczonym oknie uwagi, a nie tylko dopieszczanie pojedynczej wiadomości startowej.

Dlaczego to ma znaczenie: uwaga modeli jest skończona

Transformery mają kosztowny mechanizm uwagi — każdy token „przygląda się” innym, a im dłuższy kontekst, tym większy szum i większe ryzyko utraty precyzji. Przewodnik trafnie opisuje efekt rozmywania się istotnych szczegółów w długich wątkach („context rot”). Zwiększanie okna kontekstu pomaga tylko do pewnego punktu: bez selekcji i struktury model traci z oczu to, co naprawdę ważne, a rozumowanie na długim dystansie słabnie.

Co składa się na skuteczny kontekst

Dobra inżynieria kontekstu nie polega na dorzucaniu większej liczby akapitów, tylko na maksymalizowaniu sygnału i minimalizowaniu szumu. Kluczowe komponenty:

System prompts. Zwięzłe, konkretne i odporne na błędy. Unikaj dwóch skrajności: twardo zakodowanej, nadmiernie szczegółowej logiki (krucha i nieelastyczna) oraz mglistych, ogólnikowych zaleceń (zbyt szerokie). Pomagają czytelne sekcje instrukcji i formatów wyjścia oraz iteracyjne testy zamiast rozbudowy „na sucho”.

Narzędzia. To interfejs agenta ze światem. Lepsze są małe, dobrze zdefiniowane funkcje o niepokrywających się rolach niż „kombajn”, który robi wszystko. Jasne parametry wejściowe zmniejszają niejednoznaczność i poprawiają powtarzalność zachowań.

Przykłady (few-shot). Zamiast listy wyjątków — reprezentatywny przekrój wzorców. Dobrze jest pokazać zarówno poprawne, jak i błędne przypadki, by narysować granice oczekiwań.

Wiedza domenowa. Opisy API, schematy danych, procedury — wszystko, co przenosi model z trybu „przewidywania tekstu” w tryb podejmowania decyzji opartych na realiach domeny.

Pamięć. Krótkoterminowa (kroki wnioskowania, ostatnie wymiany) i długoterminowa (preferencje użytkownika, fakty firmowe). Daje ciągłość i kontekst działań, ale wymaga dyscypliny, by nie zamieniać się w śmietnik rozproszonej treści.

Wyniki narzędzi. Włączane z powrotem do strumienia kontekstu umożliwiają autokorektę i dynamiczne planowanie.

Kontekst na żądanie: od statycznego RAG do JIT

Praktyczny kierunek rozwoju to przejście z preładowanego kontekstu (klasyczne RAG) do pobierania „just-in-time”. Agent uczy się korzystać z narzędzi — ścieżek plików, zapytań, API — by ściągnąć tylko to, co chwilowo potrzebne do kolejnego kroku rozumowania. Zyskujemy oszczędność pamięci i elastyczność, a wzorzec przypomina ludzką pracę z katalogami, zakładkami czy notatkami.

W bardziej złożonych systemach sprawdza się hybryda: część danych pozostaje statycznie dostępna dla szybkości, a reszta jest dociągana JIT. Warunkiem powodzenia jest jednak staranny projekt narzędzi i kontrola strategii wyszukiwania — bez tego agent może błądzić, marnować okno kontekstu i gonić ślepe zaułki.

Jak utrzymać spójność przy długich zadaniach

Gdy zadanie rozciąga się na wiele iteracji i przekracza ograniczenia okna, potrzebne są techniki utrzymania toru jazdy:

Kompakcja (destylacja). Kiedy bufor pęka w szwach, starsze fragmenty historii warto streszczać, zostawiając przepływ rozmowy i kluczowe fakty, a porzucając surowe, zbędne wyniki narzędzi.

Strukturalne notatki. Zewnętrzny, trwały rejestr (np. NOTES.md lub dedykowane „memory tool”), w którym agent zapisuje postępy, zależności i plan. Koszt kontekstu pozostaje niski, a ciągłość — wysoka.

Sub‑agenci. W głębokich eksploracjach lepiej odseparować „pracę w tle” w wyspecjalizowanych, izolowanych oknach kontekstowych. Do głównego koordynatora wraca tylko skondensowany wyciąg — tyle, by podjąć decyzję, bez zalewania go szczegółami.

Implikacje dla zespołów: gdzie szukać przewagi

Najważniejsza lekcja jest przyziemna: częściej wygrywa lepsza inżynieria kontekstu niż większy model. Zamiast pompować okno albo dopisywać akapity reguł, lepiej:

• uprościć i ustrukturyzować komunikaty systemowe,
• zredukować i doprecyzować narzędzia,
• dodać kilka dobrych, zróżnicowanych przykładów,
• dołączyć niezbędną wiedzę domenową,
• wprowadzić JIT‑retrieval i mechanizmy destylacji pamięci,
• testować scenariusze długohoryzontalne, mierząc precyzję i stabilność, a nie tylko „pierwszą odpowiedź”.

Krytyczny punkt to obserwowalność: bez logów kontekstu, śledzenia odwołań do narzędzi i jasnych metryk, trudno odróżnić prawdziwe ulepszenia od pozornych. Warto też uważać na nadmierną sztywność — „twarde” prompty często pękają w nieprzewidzianych sytuacjach — oraz na rozrost pamięci bez kurateli, który wprowadza szum szybciej, niż daje korzyści.

Przewodnik Anthropic porządkuje dobre praktyki, ale nie zwalnia z inżynierskiej dyscypliny: iteracyjnych testów, kontroli jakości narzędzi i świadomego kompromisu między bogactwem kontekstu a obciążeniem uwagi modelu. To właśnie w tych decyzjach kryje się różnica między imponującym demem a stabilnym systemem produkcyjnym.