Co to jest context engineering i czym różni się od prompt engineering?

Context engineering to projektowanie i zarządzanie informacjami, które model AI otrzymuje w konkretnym momencie wykonywania zadania. Obejmuje nie tylko prompt, ale również historię rozmowy, pamięć, dokumenty, dane pobrane przez RAG, dostępne narzędzia oraz wyniki wcześniejszych działań. Celem jest przekazanie modelowi takiego zestawu informacji, który pozwoli mu poprawnie wykonać następny krok.

Jeśli korzystasz z prostego chatbota, różnica między prompt engineering a context engineering nie zawsze będzie od razu widoczna. Staje się znacznie ważniejsza przy agentach AI, które pracują przez wiele etapów, korzystają z plików i aplikacji oraz muszą pamiętać wcześniejsze ustalenia. W takim systemie jakość odpowiedzi zależy nie tylko od możliwości samego modelu, ale również od tego, jakie informacje są w danej chwili dostępne w jego kontekście.

• Co to jest context engineering?
• Context engineering a prompt engineering – czym się różnią?
• Z czego składa się kontekst modelu AI?
• Dlaczego więcej kontekstu nie zawsze oznacza lepszy wynik?
• Jak context engineering wygląda w praktyce?
• Jak łączą się RAG, pamięć AI i narzędzia?
• Czy context engineering zastąpi prompt engineering?

Znaczenie tego zagadnienia dobrze widać przy systemach agentowych. Przykładem jest Google Genkit Agents API, gdzie model nie tylko odpowiada na pytanie, ale wykonuje kolejne działania i korzysta z narzędzi. Podobny problem zarządzania informacjami pojawia się w rozwiązaniach wykonujących dłuższe zadania, takich jak ChatGPT Work.

Co to jest context engineering?

Context engineering odpowiada na pytanie: co model powinien wiedzieć w danym momencie, aby prawidłowo wykonać zadanie? Samo polecenie użytkownika jest tylko jednym z elementów. Model może potrzebować wcześniejszych ustaleń, danych klienta, dokumentacji, aktualnego stanu zadania, informacji zwróconej przez API albo opisu narzędzi, z których może skorzystać.

W praktyce context engineering polega na dobieraniu, porządkowaniu, aktualizowaniu i ograniczaniu informacji przekazywanych modelowi podczas inferencji. Nie chodzi więc o zgromadzenie największej możliwej ilości danych. Istotne jest dostarczenie informacji potrzebnych do aktualnego kroku i pominięcie tych, które zwiększają objętość kontekstu, ale nie pomagają w rozwiązaniu problemu.

Przy pojedynczym pytaniu cały kontekst może składać się z instrukcji systemowej i promptu użytkownika. Agent wykonujący zadanie przez kilkadziesiąt minut tworzy natomiast kolejne wyniki, podejmuje decyzje i korzysta z różnych źródeł. Jego kontekst zmienia się wraz z postępem pracy, dlatego trzeba nim zarządzać przez cały czas trwania procesu.

Context engineering a prompt engineering – czym się różnią?

Prompt engineering skupia się przede wszystkim na sposobie formułowania instrukcji dla modelu. Określamy rolę AI, opisujemy zadanie, dodajemy ograniczenia, przykłady albo oczekiwany format odpowiedzi. Dobrze napisany prompt zmniejsza niejednoznaczność i jasno komunikuje, czego oczekujemy.

Context engineering obejmuje prompt, ale nie kończy się na nim. Uwzględnia również wszystkie informacje, które model otrzymuje razem z instrukcją lub w kolejnych etapach pracy. Dlatego różnica staje się szczególnie wyraźna przy agentach AI, systemach korzystających z RAG oraz aplikacjach pracujących z pamięcią i zewnętrznymi narzędziami.

Załóżmy, że prosisz agenta o przygotowanie raportu konkurencji. Prompt może określić liczbę firm, zakres analizy i format tabeli. Do wykonania zadania agent potrzebuje jednak również informacji o analizowanej firmie, rynku, wcześniejszych ustaleniach, dostępnych źródłach i danych, które zostały już sprawdzone. Prompt opisuje zadanie, a context engineering zapewnia informacje potrzebne do jego wykonania.

Z czego składa się kontekst modelu AI?

Kontekst modelu nie musi być jednym dużym blokiem tekstu. W bardziej rozbudowanych aplikacjach składa się z kilku źródeł, z których system wybiera informacje potrzebne do aktualnego zadania. Jeśli budujesz lub konfigurujesz agenta, warto patrzeć na kontekst właśnie jak na zestaw elementów, a nie wyłącznie historię czatu.

• instrukcje systemowe – określają rolę modelu, zasady działania i ograniczenia;
• polecenie użytkownika – opisuje aktualne zadanie lub cel;
• historia rozmowy – zawiera wcześniejsze pytania, odpowiedzi i ustalenia;
• pamięć AI – przechowuje informacje, które można przywołać również poza bieżącą rozmową;
• dane z RAG – dostarczają fragmenty dokumentów, baz wiedzy lub innych źródeł;
• narzędzia – informują model, z jakich funkcji, API lub serwerów MCP może skorzystać;
• wyniki narzędzi – wprowadzają do kontekstu dane uzyskane podczas wykonywania zadania;
• stan zadania – określa, co zostało już zrobione, jakie decyzje podjęto i co pozostało do wykonania.

Nie wszystkie te elementy powinny być przekazywane modelowi przy każdym wywołaniu. Jeśli agent analizuje pojedynczą fakturę, pełna historia wcześniejszych dokumentów prawdopodobnie nie jest mu potrzebna. Przy tworzeniu zestawienia miesięcznego część tych danych może już mieć znaczenie. Context engineering decyduje więc zarówno o tym, co trafi do kontekstu, jak i kiedy dana informacja zostanie do niego wprowadzona.

Dlaczego więcej kontekstu nie zawsze oznacza lepszy wynik?

Duże okno kontekstowe pozwala przekazać modelowi więcej tokenów, ale nie gwarantuje, że wszystkie informacje zostaną wykorzystane równie skutecznie. Przy bardzo długiej rozmowie istotne ustalenia zaczynają konkurować ze starymi wiadomościami, rozbudowanymi wynikami narzędzi i danymi, które były ważne kilka etapów wcześniej. Model nadal może mieć do nich techniczny dostęp, ale odnalezienie najważniejszego sygnału staje się trudniejsze.

Dlatego w długich procesach stosuje się m.in. trimming, summarization i context compaction. Starsze lub niepotrzebne elementy można usunąć, natomiast rozbudowaną historię zastąpić krótszym podsumowaniem zawierającym najważniejsze decyzje i aktualny stan pracy. Przy agentach działających przez wiele etapów pozwala to ograniczyć zjawisko określane jako context rot, czyli spadek użyteczności nadmiernie rozbudowanego kontekstu.

Nie oznacza to, że dobry kontekst musi być krótki. Powinien być wystarczająco kompletny, aby model nie musiał zgadywać, a jednocześnie pozbawiony danych, które nie pomagają w wykonaniu aktualnego zadania. Jeśli projektujesz taki system, ważniejsza od maksymalnego rozmiaru okna kontekstowego jest jakość informacji, które faktycznie w nim umieszczasz.

Jak context engineering wygląda w praktyce?

Załóżmy, że agent pomaga przenieść sklep WooCommerce na nowy serwer. Na początku ustalasz, że nie wolno zmienić adresów URL produktów, stary hosting ma pozostać aktywny przez siedem dni, a priorytetem jest zachowanie SEO. W trakcie pracy agent analizuje DNS, bazę danych, konfigurację SSL i logi z testów. Po kilkudziesięciu operacjach musi przygotować ostateczną kolejność przełączenia domeny.

Źle zaprojektowany system może przekazać mu całą historię sesji razem z setkami komunikatów i wyników technicznych. Informacja o zachowaniu adresów URL nadal znajduje się w kontekście, ale ginie wśród mniej istotnych danych. Lepiej przygotowany system przed kolejnym krokiem buduje aktualny kontekst z informacji naprawdę potrzebnych do podjęcia decyzji.

Pełne logi, wcześniejsze warianty i nieaktualne propozycje mogą pozostać poza aktywnym kontekstem i zostać pobrane ponownie, jeśli okażą się potrzebne. W tym właśnie tkwi sens context engineering: model nie musi mieć przed sobą wszystkich dostępnych informacji, lecz właściwy stan wiedzy dla konkretnego etapu pracy.

Jak context engineering łączy RAG, pamięć AI i narzędzia?

RAG jest jednym ze sposobów dostarczania kontekstu. System wyszukuje odpowiednie fragmenty dokumentów lub bazy wiedzy i przekazuje je modelowi razem z aktualnym zadaniem. Jeśli wyszukiwanie zwróci dużo nieistotnych fragmentów, technicznie kontekst został dostarczony, ale jego jakość będzie niska. Dlatego context engineering łączy się również z retrievalem, filtrowaniem, chunkingiem i rerankingiem.

Pamięć pełni inną funkcję. Pozwala przechowywać informacje poza aktualnym wywołaniem i przywoływać je wtedy, gdy są potrzebne. Dobrym przykładem rozwoju takich mechanizmów jest nowa pamięć Claude. Informacja przechowywana w pamięci nie musi znajdować się w każdym kontekście – powinna trafić do niego wtedy, gdy ma znaczenie dla bieżącego zadania.

Podobnie wygląda sytuacja z narzędziami. Agent korzystający z API, wyszukiwarki, CRM-u czy serwera MCP musi znać ich przeznaczenie i parametry, a wyniki działania tych narzędzi również zajmują miejsce w kontekście. Jeśli system zwróci cały rekord klienta, mimo że agent potrzebuje jedynie pięciu ostatnich zamówień, zwiększamy ilość danych bez poprawy jakości decyzji. Mechanizmy MCP rozwijają właśnie tę warstwę połączenia modeli z narzędziami i danymi, czego przykładem jest opisana przez nas aktualizacja Model Context Protocol.

Czy context engineering zastąpi prompt engineering?

Context engineering nie zastępuje prompt engineering, lecz rozszerza sposób projektowania systemów wykorzystujących modele AI. Nadal trzeba jasno sformułować polecenie, określić rolę modelu i opisać oczekiwany rezultat. W przypadku bardziej złożonych agentów sam dobry prompt nie wystarczy jednak, jeśli system dostarczy nieaktualne dokumenty, niepotrzebną historię albo pominie ważny wynik wcześniejszego działania.

Jeśli pracujesz z prostym chatbotem, dobrze przygotowany prompt nadal może być najważniejszym elementem. Gdy budujesz agenta korzystającego z pamięci, RAG, API i wielu narzędzi, musisz myśleć o całym przepływie informacji. W takim zastosowaniu jakość modelu i jakość promptu pozostają ważne, ale równie istotne jest to, co model wie w chwili podejmowania kolejnej decyzji.