Prompt Engineering vs. Context Engineering: to nie rebranding, to zmiana tego, co optymalizujesz

Prompt engineering to dobre sformułowanie polecenia. Context engineering to decyzja, co model w ogóle zobaczy. Termin spopularyzował w czerwcu 2025 roku Tobi Lutke z Shopify, a wzmocnił go Andrej Karpathy, który opisał go jako sztukę wypełniania okna kontekstowego dokładnie tą informacją, która jest potrzebna do kolejnego kroku. Najczystsze rozróżnienie pochodzi od Philippa Schmida: kontekst to wszystko, co model widzi, zanim wygeneruje odpowiedź, a to jest system, nie ciąg znaków.

Te dwa podejścia nie są rywalami; prompt engineering jest podzbiorem. Gdy piszą Państwo dobry systemowy prompt, to jest prompt engineering. Gdy decydują Państwo, które trzy dokumenty zostaną pobrane, jakie narzędzia zostaną udostępnione, ile historii zachować, co odrzucić i jakiego schematu wyjściowego wymagać, wszystko w ramach budżetu tokenów, to jest context engineering. Własne wytyczne Anthropic ujmują to jako zarządzanie całym stanem kontekstu na przestrzeni kolejnych ruchów, a ich najostrzejsze zdanie warto zapamiętać: kontekst to skończony zasób o malejącej użyteczności krańcowej.

Powodem, dla którego context engineering stał się nazwaną dyscypliną, jest to, że wygodne założenie rozpadło się pod wpływem pomiarów. Założenie brzmiało: modele z długim kontekstem pozwalają wypełnić okno po brzegi i przestać myśleć. Badanie Context Rot od Chroma przetestowało w lipcu 2025 roku 18 wiodących modeli i wykazało, że każdy z nich degraduje się wraz ze wzrostem danych wejściowych, często w niejednolity sposób: model nie traktuje dziesięciotysięcznego tokenu tak samo wiarygodnie jak setnego. Wcześniejsze odkrycie Lost in the Middle wskazywało w tym samym kierunku.

Dwie siły sprawiły, że to ładunek, nie prompt, stał się tym, co należy inżynierować. Po pierwsze: agenci, użycie narzędzi, retrieval i pamięć oznaczają, że kontekst jest składany przez system na przestrzeni wielu ruchów, a nie pisany raz ręcznie. Po drugie ekonomia: w produkcji u Manus stosunek tokenów wejściowych do wyjściowych wynosi około 100 do 1, a ponowne wykorzystanie key-value cache napędza duże różnice w kosztach, więc to, co trafia do okna, jest w równym stopniu decyzją kosztową, co decyzją jakościową. Więcej kontekstu nie jest lepsze; lepszy jest kontekst zbudżetowany i istotny. To empiryczny fundament stojący za naszym wcześniejszym omówieniem context engineering i tego, dlaczego ma znaczenie.

Uwolniony od etykiety, context engineering to zestaw testowalnych praktyk, a nie szeptanie do promptu. Nazwane techniki powtarzają się u Anthropic, w LangChain i w raporcie produkcyjnym Manus:

• Retrieval. Pobierają Państwo kilka istotnych dokumentów dokładnie w momencie, gdy są potrzebne, zamiast wklejać wszystko naraz. To dyscyplina stojąca za Retrieval-Augmented Generation.
• Kondensacja i podsumowanie. Kompresują Państwo dawne ruchy w bieżące podsumowanie, aby budżet był wydawany na to, co żywe, a nie na transkrypt.
• Pamięć i notatki. Wyprowadzają Państwo stan do zewnętrznych notatek lub plików, które agent może odczytać ponownie, zamiast dźwigać go w oknie.
• Kuratorstwo narzędzi. Utrzymują Państwo załadowanych od trzech do pięciu kluczowych narzędzi, a resztę pobierają dokładnie na czas. Załadowanie każdego narzędzia rozcieńcza sygnał i przerywa cache.
• Ustrukturyzowane wyjścia. Wymagają Państwo schematu, aby model wydawał tokeny na odpowiedź, a nie na formatującą prozę.
• Izolacja. Dzielą Państwo pracę między subagentów, aby każdy widział tylko kontekst, którego potrzebuje.

LangChain ujmuje ten sam zestaw jako pisanie, wybieranie, kompresowanie i izolowanie. Rzecz w tym, że każdy z tych elementów jest mierzalny: mogą Państwo przetestować A/B retriever, próg kondensacji czy wyposażenie w narzędzia, co dokładnie sprawia, że to inżynieria, a nie formułowanie.

Częściowo, i to jest w porządku. Tak, dobrzy inżynierowie już wcześniej dbali o to, co widzi model; wartość tej nazwy polega na tym, że kieruje optymalizację na ładunek i system, a nie na zdanie, tam gdzie faktycznie mieszka niezawodność i koszty. Trwająca debata jest bardziej użyteczna niż spór o terminologię. W czerwcu 2025 roku Cognition argumentowało przeciwko systemom wieloagentowym, twierdząc, że trudno jest czysto dzielić kontekst między agentami, i zalecało utrzymywanie pracy pojedynczo oraz dzielenie się pełnymi śladami (trace). W tym samym tygodniu Anthropic opisał wieloagentowy system badawczy, który zależy od zdyscyplinowanej izolacji kontekstu. Ta sama dyscyplina, przeciwny wniosek architektoniczny.

Dla zespołu budującego z LLM-ami wnioski są proste. Budżetują Państwo tokeny tak, jak budżetuje się moc obliczeniową, ponieważ więcej nie jest za darmo i nie zawsze jest lepsze. Traktują Państwo tę pracę jako inżynierię przepływu (jakość retrievalu, kondensacja, pamięć, kuratorstwo narzędzi, ustrukturyzowane wyjścia), a nie jako formułowanie. I wybierają Państwo architekturę na podstawie tego, jak niezawodnie mogą Państwo dzielić kontekst, a nie na podstawie tego, które podejście brzmi bardziej zaawansowanie. Nazwa będzie dalej mutować, niektórzy już nazywają kolejną warstwę harness engineering, ale obiekt pozostaje stabilny: system, który decyduje, co dostanie do zobaczenia model.