Prompt engineering dla agentów AI

Czym jest prompt engineering dla agentów AI?

Prompt engineering dla agentów to dyscyplina inżynierska, dzięki której agent AI konsekwentnie wykazuje pożądane zachowanie w wielu turach inferencji. O ile klasyczny prompt engineering (2022–2023) oznaczał napisanie jednego, sprytnego ciągu instrukcji, o tyle w przypadku agenta okno kontekstowe nie jest już statycznym tekstem, lecz dynamicznie komponowanym stanem systemu: prompt systemowy, definicje narzędzi, wyniki narzędzi, historia rozmowy, pobrane chunki RAG, notatki w scratchpadzie i ustrukturyzowany stan.

Andrej Karpathy opisał to przesunięcie 25 czerwca 2025 roku jako context engineering, „the delicate art and science of filling the context window with just the right information for the next step”, niespełna tydzień po tym, jak CEO Shopify Tobi Lütke spopularyzował ten termin. Anthropic sformalizował go 29 września 2025 roku w tekście „Effective context engineering for AI agents” jako „naturalną ewolucję prompt engineeringu”. Ważne dla właściwego zrozumienia: context engineering obejmuje prompt engineering, a nie go zastępuje. Dobry prompt systemowy pozostaje warunkiem koniecznym; po prostu nie jest już wystarczający.

Ta strona zbiorcza daje przegląd pięciu kluczowych elementów: promptów systemowych, opisów narzędzi, pętli planowania (ReAct), zarządzania oknem kontekstowym i ewaluacji.

Architektura promptu systemowego

Prompt systemowy to jedyny fragment kontekstu, który agent widzi w każdej turze; to kod: wersjonowany, poddawany przeglądom, porównywalny przez diff. Produkcyjne prompty systemowe mają w 2026 roku konsekwentnie strukturę czterech warstw:

Anthropic zaleca oddzielanie tych sekcji tagami XML lub nagłówkami Markdown; model niezawodniej parsuje ustrukturyzowane prompty. Właściwą długość Anthropic nazywa „the right altitude”: raporty praktyków zbiegają się na poziomie 500–3000 tokenów dla rdzenia (bez schematów narzędzi). Obie skrajności szkodzą: przy zbyt długich promptach z 47 ponumerowanymi regułami model rzadziej stosuje reguły z końca listy (Lost-in-the-Middle we własnym prompcie systemowym); zbyt ogólnikowe prompty („Jesteś pomocnym asystentem”) zostawiają zbyt wiele inferencji modelu.

Kluczowa zmiana dotyczy reguł absolutnych: wytyczne OpenAI dla GPT-5 (2026) wyraźnie zalecają, by ALWAYS/NEVER stosować tylko do prawdziwych niezmienników; „for judgment calls, such as when to search, ask for clarification, use a tool, or keep iterating, prefer decision rules instead”. Zespoły z regionu DACH (Niemcy, Austria, Szwajcaria) powinny dodatkowo zawsze jawnie ustawiać język odpowiedzi (w przeciwnym razie modele frontier przy treściach technicznych domyślnie przechodzą na angielski) i jawnie przypinać formę grzecznościową (Sie/Du), aby uniknąć dryfu stylu w pętli.

Opisy narzędzi: tu agenci naprawdę zawodzą

Gdy agent produkcyjny działa błędnie, przyczyna według inżynierskiego doświadczenia samego Anthropic „w większości przypadków” nie leży w modelu, lecz w definicji narzędzia. Pytanie przewodnie brzmi: „If a human engineer can't definitively say which tool should be used in a given situation, an AI agent can't be expected to do better.”

Kluczowe jest to, że opisy narzędzi są częścią budżetu promptu. Każde narzędzie dodaje 100–300 tokenów „always-on”; katalog 10 narzędzi kosztuje 1000–3000 tokenów na wywołanie. Najskuteczniejszym, a zarazem najczęściej pomijanym elementem jest klauzula „kiedy nie używać”: jeśli równolegle istnieją search_web i query_internal_db, to właśnie ta klauzula decyduje o wyborze narzędzia. Nakładanie się narzędzi, czyli sytuacja, w której dwa narzędzia mogą wiarygodnie odpowiedzieć na to samo zapytanie, to jedyny problem, którego nie rozwiąże nawet najlepszy prompt.

Dowody empiryczne są jednoznaczne. Dzięki narzędziu tool_search od Anthropic i ustawieniu defer_loading: true dla rzadko używanych narzędzi trafność wyboru narzędzi w wewnętrznych ewaluacjach MCP wzrosła w Opus 4 z 49% do 74%, a w Opus 4.5 z 79,5% do 88,1% (Anthropic, listopad 2025), przy oszczędności tokenów na poziomie ok. 85%. Od mniej więcej 10 aktywnych narzędzi zaczyna się mierzalna degradacja. Dlatego wzorzec produkcyjny to 3–7 zawsze ładowanych narzędzi plus Tool Search dla pozostałych. Inną drogą idzie wykonywanie kodu z MCP: agent komunikuje się z serwerami MCP przez kod i ładuje definicje narzędzi dopiero wtedy, gdy są potrzebne.

Inne sprawdzone konwencje: nazwy w formie czasownik-rzeczownik (get_user, send_email), opisy na poziomie pól z semantyką, udokumentowane formaty zwrotne i tryby awarii, narzędzia nastawione na wyszukiwanie zamiast takich, które listują wszystko, a także twarde limity tokenów w odpowiedzi (wartość orientacyjna Anthropic: ~25 000 tokenów na zwrot narzędzia). Sprawdzona praktyka: nazwy narzędzi i parametry po angielsku (interoperacyjność), opisy w języku, w którym agent działa w czasie wykonania.

Pętle planowania: ReAct i jego następcy

Planowanie to struktura pętli decyzyjnej agenta. W 2026 roku dominują cztery wzorce, z wyraźnymi kompromisami:

ReAct przeplata rozumowanie i działanie (Thought → Action → Observation) i jest niezawodnym wyborem domyślnym dla modeli bez rozumowania. W przypadku modeli rozumujących obraz się zmienia: Interleaved Thinking (Anthropic Claude z Extended Thinking, seria o od OpenAI/GPT-5) pozwala modelowi planować na nowo między wywołaniami narzędzi i tym samym sprowadza wiele klasycznych implementacji „ReAct-in-a-loop” do jednego wywołania API. W praktyce agenci produkcyjni korzystają z rozwiązań hybrydowych: pętli ReAct z jawnym krokiem planowania na początku i weryfikacją przed nieodwracalnymi działaniami.

Zdyscyplinowane kończenie pętli to najważniejsze zabezpieczenie; nieskończone pętle były w latach 2025–2026 najczęstszą klasą błędów produkcyjnych. Solidne pętle łączą maksymalną liczbę iteracji (twardy limit, zwykle 10–30 ogólnie, 50–100 przy kodowaniu), kryterium sukcesu (np. narzędzie submit_final_answer), limity kosztów, wykrywanie powtarzających się stanów przeciw tool thrashingowi oraz ścieżkę eskalacji do człowieka.

Zarządzanie oknem kontekstowym

Długie okna kontekstowe są w 2026 roku dostępne (Claude Opus i Gemini, każdy do 1M tokenów), ale nie da się ich wykorzystać równomiernie. Badanie „Context Rot” firmy Chroma (lipiec 2025, 18 modeli frontier) pokazuje, że wszystkie modele tracą na jakości wraz ze wzrostem długości wejścia. Wzajemnie wzmacniają się trzy mechanizmy: Lost-in-the-Middle (Liu et al., Stanford/TACL 2024; modele skupiają uwagę na początku i na końcu, a słabo na środku), rozmycie uwagi i interferencja dystraktorów. Heurystycznie efektywna pojemność wynosi 30–50% nominalnej przy zadaniach opartych na rozumowaniu i 60–80% przy zadaniach opartych na wyszukiwaniu. Jeśli w pełni zapełniasz okno 1M, marnujesz tokeny i pogarszasz jakość.

Lance Martin (LangChain) ukuł do tego kanoniczną taksonomię czterech filarów, którą przejęły Anthropic i Manus:

• Write: utrwalanie informacji poza oknem (scratchpady, todo.md, magazyn pamięci)
• Select: pobieranie właściwych tokenów na każdym kroku (RAG, filtrowanie narzędzi, delegowanie do subagentów)
• Compress: zachowywanie tylko tokenów istotnych dla zadania (streszczanie, Context Editing od Anthropic)
• Isolate: rozdzielanie kontekstu między subagentów i pola schematu

W ekonomii dominują trzy dźwignie. Prompt Caching jest najważniejszą z nich: odczyty z cache w Anthropic kosztują 10% standardowej stawki za input, a w przypadku niektórych aktualnych modeli mniej (stan na październik 2026: 5% w Opus 5.5 i Sonnet 5.5, 2,5% w Fable 5.1 i Mythos 5.1). OpenAI nalicza w rodzinie GPT-5 również 10%, w GPT-4.1 25%, a w GPT-4o 50%. Badanie z arXiv (luty 2026, „Don't Break the Cache”) mierzy przy obciążeniach agentowych o 41–80% niższe koszty API i o 13–31% krótszy time-to-first-token dzięki strategicznej kontroli bloków cache. Pruning usuwa stare tury i nieaktualne wyniki narzędzi. Compaction kompresuje kontekst przy 70–85% pojemności, w Claude Code np. przez /compact. Według Anthropic zachowuje to „architectural decisions, unresolved bugs, and implementation details” i odrzuca zbędne outputy narzędzi. Delegowanie do subagentów działa jako prymityw kompakcji: subagent eksploruje we własnym oknie i zwraca tylko podsumowanie o długości 1000–2000 tokenów.

Ewaluacja: jeśli nie mierzysz, to nic nie zrobiłeś

Najbardziej brutalny wniosek dla tech leadów brzmi: zmiany w context engineeringu weryfikuje się ewaluacjami, a nie intuicją. Najczęściej cytowana rada Hamela Husaina, „Look at your data”, oznacza w praktyce: przeczytać 50–100 prawdziwych trace’ów z produkcji, swobodnie oznaczyć błędy, pogrupować je w taksonomię, dla każdego częstego trybu napisać ewaluację w kodzie lub ewaluację LLM-as-Judge i zintegrować je z CI i monitoringiem.

Husain ostrzega przy tym przed czystym podejściem eval-first: „Write evaluators for errors you discover, not errors you imagine.” Praktyczny złoty środek zaczyna się od małej ewaluacji end-to-end (10–50 reprezentatywnych zadań), iteruje i buduje konkretne subewaluacje dla rzeczywistych trybów awarii. Otrzeźwiający, empirycznie potwierdzony wniosek: wiele popularnych porad promptowych („Jesteś ekspertem”, „Think step by step”, „I'll tip you $200”) daje w rygorystycznych ewaluacjach minimalną poprawę albo żadną; w modelach rozumujących „think step by step” jest już zachowaniem domyślnym, a dodawane ręcznie często przynosi efekt odwrotny do zamierzonego.

Gotowość produkcyjna oznacza: ewaluacje uruchamiają się automatycznie przy każdej zmianie kontekstu, narzędzi lub retrievalu; ewaluacja PR (20–50 zadań) blokuje merge, ewaluacja przed wdrożeniem (200–2000 zadań) blokuje wdrożenie, a ewaluacja po wdrożeniu na trace’ach produkcyjnych służy do wykrywania dryfu. Wymuszanie ustrukturyzowanych outputów domyka całość: OpenAI Structured Outputs w trybie strict (ogólnie dostępne od sierpnia 2024) i Structured Outputs od Anthropic ze ścisłym użyciem narzędzi (od listopada 2025) wymuszają zgodność ze schematem przez constrained decoding i zastępują dawne „parsuj JSON i miej nadzieję”. Dokumentacja Anthropic wprost wymienia wyjątki: odmowy, przerwania na limicie tokenów i sporadycznie odmienną wielkość liter w wartościach enum i const.

Region DACH i zgodność z przepisami

Dla zespołów z regionu DACH dochodzą trzy twarde ograniczenia inżynierskie. Po pierwsze tokenizacja języka niemieckiego: rzeczowniki złożone i fleksja generują o 30–50% więcej tokenów na równoważną treść niż angielski. Okno 200K mieści więc tylko tyle niemieckiej treści, ile po angielsku zmieściłoby się w ok. 130–150K tokenów. Oznacza to wyższe koszty, ale też wyższy ROI z cachowania, bo rabat za cache działa na większą liczbę tokenów.

Po drugie dyscyplina RODO w oknie kontekstowym: dane osobowe nie powinny trafiać do niego bez filtrowania. Sprawdzone wzorce to pseudonimizacja przed wstrzyknięciem do kontekstu (prawdziwe nazwiska rozwiązywać dopiero w warstwie narzędzi), warstwa redakcji PII przed wstrzyknięciem RAG oraz audytowalny reset stanu sesji. Po trzecie logowanie zgodne z art. 12 AI Act dla systemów wysokiego ryzyka: na mocy AI Omnibus (rozporządzenie (UE) 2026/1744) obowiązuje ono dla systemów z załącznika III od 2 grudnia 2027 r., a dla produktów z załącznika I od 2 sierpnia 2028 r. Zespołów ze Szwajcarii RODO i AI Act dotyczą tylko w razie powiązania z UE. RODO ma zastosowanie zgodnie z art. 3 ust. 2, jeśli zespół oferuje towary lub usługi osobom w UE albo monitoruje ich zachowanie. AI Act ma zastosowanie zgodnie z art. 2, jeśli zespół wprowadza systemy AI do obrotu w UE albo ich wyniki są wykorzystywane w UE. Na poziomie krajowym od 1 września 2023 r. obowiązuje znowelizowana ustawa o ochronie danych (revDSG). Ta klasyfikacja ma charakter informacyjny i nie stanowi porady prawnej. Od strony inżynierskiej obowiązek logowania oznacza, że wersja promptu systemowego, wersja katalogu narzędzi, pobrane dokumenty (lub ich ID + hashe), input użytkownika, wywołania narzędzi, wyniki narzędzi i końcowy output muszą być zapisywane w sposób audytowalny, a zarazem usuwalny zgodnie z RODO, najlepiej dla każdego wywołania narzędzia z identyfikatorem korelacji przebiegu.

Perspektywy i wskazówka praktyczna

Prompt engineering dla agentów nie jest w 2026 roku ani folklorem, ani zwykłą zmianą nazwy, lecz odpowiedzią na przejście od pojedynczych wywołań one-shot do wieloetapowych pętli agentowych. Jeśli budujesz agenta produkcyjnego, uprawiasz tę dyscyplinę; pytanie brzmi tylko, czy robisz to świadomie i powtarzalnie, czy nieświadomie i zawodnie. Kilka obszarów wciąż się zmienia i należy je traktować jako „aktualny snapshot”: konwencje dla modeli rozumujących, heurystyka multi-agent vs. single-agent (równoległa praca z przewagą odczytu działa, z przewagą zapisu nie) oraz frameworki optymalizacji promptów, takie jak DSPy, które sprawdzają się w wąsko zdefiniowanych podzadaniach, ale nie stanowią jeszcze standardu produkcyjnego dla pełnych pętli agentów.

Praktyczny start jest mało spektakularny i dobrze udokumentowany: wyciągnij prompt systemowy z playgroundu dostawcy i wersjonuj go w Git, waliduj schemat każdego outputu, włącz Prompt Caching dla stabilnych części, ustaw twarde limity kosztów i co tydzień czytaj 20 prawdziwych trace’ów. Zasada przewodnia Anthropic opisuje cały cel trafniej niż jakakolwiek dyskusja o narzędziach: „Find the smallest set of high-signal tokens that maximize the likelihood of your desired outcome.” To jest inżynieria. A potem: look at your data.