Inżynieria kontekstu dla agentów AI: pamięć i narzędzia

Viacheslav Dubrov

2025-10-05 · Zaktualizowano 2026-08-16 · 14 min · Agenci AI

Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

Inżynieria kontekstu to pipeline, który przed każdą decyzją wybiera to, co model zobaczy: instrukcje, przykłady, wiedzę, pamięć, definicje narzędzi, obserwacje i guardrails. Agent nie działa na podstawie całej wiedzy systemu. Działa na podstawie working setu zebranego na potrzeby następnego wywołania modelu.

To właśnie na tym etapie zaczyna się wiele awarii. Nieaktualna preferencja wygląda na bieżącą. Wyszukany tekst zawiera instrukcję. Długi wynik narzędzia ukrywa niespełniony warunek wstępny. Podsumowanie zachowuje decyzję, ale gubi informację o tym, który plik został zmieniony.

W przypadku inżynierów budujących lub utrzymujących agentów AI, systemy wyszukiwania i aplikacje korzystające z narzędzi praktyczne zadanie polega na zebraniu najmniejszego wystarczającego working setu dla każdej decyzji agenta, przy zachowaniu zakresu, proweniencji i uprawnień. Ten artykuł pokazuje, jak zaprojektować pipeline kontekstu dla każdej decyzji, znaleźć jego granice zaufania, sprawdzić, czy working set wspiera dane zadanie, oraz sprawić, by awarie były możliwe do przeanalizowania — zamiast obwiniać model, który widzi wyłącznie zebrane wejście.

TL;DR. Traktuj kontekst jako typowany artefakt runtime’u przenoszący proweniencję. Wybieraj go dla każdego kroku, egzekwuj zakres tenantów i uprawnień przed wyszukiwaniem oraz oddzielaj zaufane instrukcje od niezaufanych danych. Ustalaj budżet na podstawie użyteczności, waliduj działania poza modelem i oceniaj wyniki zadań, a nie samą długość kontekstu.

Kontekst jest wejściem decyzji, a nie pamięcią

Okno kontekstu to bieżące wejście modelu wraz z wygenerowanymi tokenami. Może zawierać tury rozmowy, ale nie jest trwałym systemem pamięci. Pamięć długoterminowa, indeksy dokumentów, bazy danych i magazyny artefaktów znajdują się poza oknem. Pipeline kontekstu wybiera, co zostanie do niego skopiowane.

Rozmiar okna to limit pojemności, a nie gwarancja jakości. Lost in the Middle i RULER pokazują, że wyszukiwanie i rozumowanie mogą zależeć od pozycji, zadania, modelu i długości sekwencji. Wniosek operacyjny nie brzmi: tokeny ze środka są zawsze ignorowane. Chodzi o to, że dodanie tokenów wyglądających na istotne może mimo wszystko obniżyć jakość wykonania zadania.

Diagram przedstawia jakościowy wynik badania, a nie uniwersalną krzywą uwagi. Liu i in. testowali odpowiadanie na pytania na podstawie wielu dokumentów oraz wyszukiwanie par klucz–wartość. Często obserwowali lepsze wyniki, gdy istotny element znajdował się blisko początku lub końca. Rozmiar i kształt efektu zmieniały się zależnie od modelu, zadania i długości kontekstu. Traktuj pozycję jako zmienną w swoim zbiorze ewaluacyjnym, zamiast zakładać stałą karę za umieszczenie informacji w środku.

Poniższy schemat Pydantic jest przykładowy i nie stanowi przetestowanej implementacji repozytorium. Waliduje wyłącznie typy pól i wartości literalne. Nie autoryzuje tenanta, nie zapewnia spójności total_input_tokens z items, nie utrwala manifestu ani nie egzekwuje zachowania modelu.

from datetime import datetime
from typing import Literal

from pydantic import BaseModel

class ContextItem(BaseModel):
    item_id: str
    kind: Literal["instruction", "task_state", "evidence", "memory", "tool"]
    source: str
    trust: Literal["trusted", "untrusted"]
    retrieved_at: datetime | None = None
    version: str | None = None
    token_count: int

class ContextManifest(BaseModel):
    request_id: str
    tenant_id: str
    items: list[ContextItem]
    total_input_tokens: int

Manifest sprawia, że awaria jest odtwarzalna. Zdanie „model halucynował” zmienia się w testowalne pytanie: jakie dowody, wersję, zakres uprawnień i schemat narzędzia faktycznie otrzymał?

Cykl składania kontekstu

Niezawodny pipeline wykonuje te operacje w następującej kolejności:

1. Rozwiąż zaufany kontekst żądania. Uwierzytelnij aktora, tenanta, lokalizację, czas i bieżący stan zadania poza modelem.
2. Wybierz następną decyzję. Krok planowania, wyszukanie dowodów, wybór narzędzia i odpowiedź końcowa wymagają różnego kontekstu.
3. Wyszukuj w określonym zakresie. Zastosuj filtry autoryzacji i tenanta przed rankingiem semantycznym, a nie dopiero po dodaniu dokumentów do zbioru kandydatów.
4. Uszereguj i ustal budżet. Wybieraj elementy na podstawie użyteczności, świeżości, wiarygodności i różnorodności, mieszcząc się w budżecie wejścia.
5. Złóż kontekst z zachowaniem granic zaufania. Przechowuj politykę w kanałach instrukcji, a wyszukany tekst przedstawiaj jako dane. Wyszukane instrukcje nie stają się polityką systemową.
6. Wygeneruj typowaną propozycję. Ograniczone generowanie może wymusić obsługiwaną składnię i strukturę. Nie gwarantuje poprawności wartości.
7. Zweryfikuj i wykonaj. Kod aplikacji sprawdza autoryzację, reguły biznesowe, argumenty narzędzi i warunki końcowe.
8. Zapisz proweniencję i wynik. Zachowaj manifest, identyfikatory wybranych źródeł, referencje do wyników narzędzi, rezultat walidacji i wynik zadania.

Cykl dotyczy każdej decyzji. Ponowne używanie jednego dużego kontekstu podczas całego uruchomienia agenta prowadzi do nieaktualnych dowodów i daje każdemu krokowi dostęp do materiałów, których nie potrzebuje.

Nadaj każdemu źródłu kontekstu jedno zadanie

Instrukcje definiują trwałe zachowanie

Instrukcje określają rolę, politykę, kontrakt danych wyjściowych i sposób eskalacji. Zachowuj stabilną treść bez zmian, aby poprawić prefix caching, ale nie zamrażaj wartości zmieniających się w runtime. Próg zwrotu należy przechowywać w serwisie polityk lub wersjonowanym rekordzie danych, a nie kopiować bezterminowo do promptu.

Hierarchia instrukcji jest granicą kontroli, a nie piaskownicą bezpieczeństwa. Model nadal może wykonać złośliwy tekst znajdujący się w wyszukanym dokumencie. Oznaczaj niezaufaną treść separatorami, zaznaczaj, że jest dowodem, a nie instrukcją, niezależnie ograniczaj narzędzia i testuj przypadki prompt injection.

Nie przenoś nazw ról jednego dostawcy do uniwersalnej hierarchii. OpenAI Model Spec definiuje poziomy autorytetu dla instrukcji platformy lub systemu, dewelopera i użytkownika. Anthropic Messages API używa parametru najwyższego poziomu system oraz komunikatów user i assistant. To API nie udostępnia równoważnej roli developer. Inne runtime’y podejmują inne decyzje. Zmapuj swoją politykę na udokumentowane kanały dostawcy, a następnie egzekwuj uprawnienia i skutki uboczne w kodzie aplikacji.

Stan zadania rejestruje zobowiązania

Proza rozmowy jest słabym źródłem prawdy w pracy wieloetapowej. Przechowuj jawny stan obejmujący cel, bieżącą fazę, wykonane działania, oczekujące akceptacje, referencje do artefaktów i status testów. Model może podsumować ten stan w narracji. Wersję kanoniczną posiada kod aplikacji.

Przykłady pokazują decyzje brzegowe

Przykłady few-shot są przydatne, gdy wyjaśniają trudną granicę, a nie tylko powtarzają schemat. Wybieraj przykłady pasujące do bieżącej decyzji i uwzględniające konsekwentne przypadki brzegowe. Oceniaj wyszukiwanie przykładów tak samo jak wyszukiwanie dokumentów: pozornie podobny, ale niezgodny z polityką przykład może być gorszy niż jego brak.

Wiedza dostarcza dowodów

Retrieval jest odpowiedni dla świeżych, prywatnych lub możliwych do zacytowania faktów. Nie istnieje uniwersalnie najlepszy top_k, rozmiar chunka, waga hybrydowa ani próg rerankingu. Dostrajaj całą ścieżkę na podstawie pytań ze znanymi dowodami źródłowymi.

Przydatny element dowodowy zawiera:

• źródło i stabilny identyfikator dokumentu
• wersję lub datę wejścia w życie
• zakres uprawnień
• cytowany fragment i jego lokalizację
• wyniki wyszukiwania i rerankingu do celów debugowania

Nie proś modelu o cytowanie URL-a, którego nie otrzymał. Nie loguj całych prywatnych dokumentów wyłącznie po to, by debugować wybór.

Pamięć zapewnia ciągłość w określonym zakresie

Pamięć to wyszukane dane obciążone dodatkowym ryzykiem związanym z cyklem życia. W metadanych projektowych śledź podmiot, proweniencję, cel, właściwą decyzję dotyczącą zgody lub podstawy prawnej, czas utworzenia, politykę wygaśnięcia lub przeglądu oraz ścieżkę usunięcia. Obowiązujące przepisy o ochronie prywatności i doradztwo prawne dla produktu określają podstawę prawną produktu i jego danych — nie ta lista kontrolna.

Sztywne reguły, takie jak „preferencje są przechowywane przez 365 dni”, nie są uniwersalną polityką. Retencja wynika z potrzeb produktu, oczekiwań użytkownika i prawa. Przed załadowaniem pamięci sprawdź:

1. Czy dotyczy tego uwierzytelnionego podmiotu i tenanta?
2. Czy jej cel jest istotny dla tej decyzji?
3. Czy jest wystarczająco aktualna, by jej użyć?
4. Czy jej źródło jest wiarygodne, czy jedynie wywnioskowane przez model?

Traktuj pamięci wywnioskowane jako hipotezy. Nie zamieniaj po cichu jednej odpowiedzi modelu w trwały fakt o użytkowniku.

Kontrakty narzędzi ujawniają możliwości

Opisy narzędzi powinny wyjaśniać warunki wstępne, skutki, zakres autoryzacji, schemat wejścia, schemat wyjścia, idempotencję i istotne błędy. Wywołanie zgodne ze schematem nadal może być nieautoryzowane lub niebezpieczne.

Po wykonaniu zastąp obszerny surowy wynik typowaną obserwacją, która zachowuje wynik istotny dla decyzji oraz referencję do pełnego artefaktu:

{
    "tool": "check_api_key_status",
    "status": "revoked",
    "checked_at": "2026-07-15T09:30:00Z",
    "account_id": "A-123",
    "artifact_ref": "toolrun://req-42/step-3"
}

Specyfikacja MCP standaryzuje sposób, w jaki klienci komunikują się z narzędziami, zasobami i promptami. Nie autoryzuje ich użycia ani nie sprawia, że zwracana treść jest godna zaufania. Kontrole bramy, poświadczeń i polityk utrzymuj poza modelem i opisem protokołu.

Ładuj szczegóły, gdy wymaga ich decyzja

Progressive disclosure to wzorzec składania kontekstu: utrzymuj dostępne identyfikatory i zaufany stan zadania, a szczegóły pobieraj na potrzeby bieżącej decyzji. Nie jest to obietnica, że konkretny budżet tokenów zadziała dla każdego modelu.

Router musi zastosować autoryzację i zakres tenanta przed wyszukiwaniem. Powinien zwracać fragmenty dowodów, rekordy pamięci i schematy narzędzi obsługujące bieżącą decyzję. Następnie model proponuje działanie. Kod aplikacji waliduje tę propozycję przed wykonaniem. Wytyczne Anthropic dotyczące kontekstu narzędzi stosują tę samą zasadę selektywności do dużych zbiorów narzędzi. Tool search utrzymuje definicje poza oknem kontekstu, dopóki model o nie nie poprosi. Zmierz, czy dodatkowy krok routingu poprawia skuteczność zadań, opóźnienie i liczbę tokenów na skuteczne zadanie w twoim systemie.

Jak kontekst ulega degradacji

Słaby kontekst nie zawodzi tylko w jeden sposób. Poniższy pięcioczynnikowy model degradacji jest moją syntezą na potrzeby debugowania, opartą na opisanych wyżej ewaluacjach długiego kontekstu i badaniach nad prompt injection:

• Utrata informacji zależna od pozycji: wymagany dowód znajduje się w kontekście, ale model wykorzystuje go niespójnie ze względu na jego pozycję i otaczającą sekwencję. Ewaluacje długiego kontekstu pokazują, że efekt zależy od modelu i zadania. Nie istnieje uniwersalny „zły zakres środka”.
• Zatrucie: nieprawidłowa pamięć, nieaktualny dokument, złośliwa instrukcja lub błędna obserwacja narzędzia trafia do working setu i wpływa na kolejne decyzje.
• Rozproszenie: istotne dowody konkurują z materiałami, które są świeże lub semantycznie podobne, ale niepotrzebne dla bieżącego kroku.
• Konfuzja: nakładające się instrukcje, przykłady lub opisy narzędzi pozostawiają modelowi kilka prawdopodobnych interpretacji zadania.
• Konflikt: dwa elementy wyglądające na autorytatywne nie zgadzają się co do wartości, polityki lub następnego działania, a assembler nie ujawnia ich wersji ani pierwszeństwa.

Te awarie wymagają różnych poprawek. Lepszy ranking może pomóc w przypadku rozproszenia, ale nie naprawi nieaktualnego źródła. Separatory mogą pomóc oddzielić dane od instrukcji, ale nie autoryzują narzędzia. Większe okno kontekstu może zachować więcej sprzecznych materiałów, nie rozwiązując konfliktu.

Gdy uruchomienie zakończy się niepowodzeniem, przeanalizuj manifest i najpierw ustal, który wzorzec wystąpił, zanim zmienisz prompt lub dodasz kolejny etap wyszukiwania.

Ustalaj budżet na podstawie użyteczności, nie limitów komponentów

Budżet kontekstu rezerwuje miejsce na wyjście, a następnie przydziela wejście do bieżącej decyzji. Zacznij od obsługiwanego przez model okna, odejmij maksymalny rozmiar wyjścia i narzut protokołu, a pozostałą przestrzeń wypełnij kandydatami.

Oceniaj kandydatów na podstawie cech, które twoje ewaluacje mogą zakwestionować:

utility = relevance × authority × freshness × scope_match
          − redundancy_penalty − injection_risk

Traktuj ten wzór jako punkt wyjścia do projektu. W odpowiedzi dotyczącej polityki wiarygodność źródła może mieć większe znaczenie niż podobieństwo semantyczne. W debugowaniu świeży log nieudanego działania może być ważniejszy niż ogólna dokumentacja.

Kolejność również ma znaczenie. Utrzymuj stabilne zaufane instrukcje na początku, gdy semantyka cache dostawcy korzysta ze wspólnego prefiksu. Umieść bieżące zadanie i decyzję blisko dowodów, do których się odnoszą. Unikaj znaczników czasu i identyfikatorów żądań w stabilnych prefiksach, jeśli nie są tam potrzebne.

Kompresuj bez utraty stanu

Kompresja jest stratna, chyba że oryginał pozostaje dostępny pod adresem. Ewaluacja Factory Research dotycząca trzech metod kompresji w długotrwałych sesjach agentów przedstawia cel jako liczbę tokenów na zadanie, a nie na żądanie. Adaptuję to do rekomendacji inżynieryjnej: optymalizuj liczbę tokenów na skuteczne zadanie, a nie liczbę tokenów na żądanie, przy porównywalnych warunkach zadań — nie traktuj tego jako uniwersalnego prawa. Ewaluacja Factory Research

Stosuj oddzielne mechanizmy dla różnych materiałów:

• Rozmowa: podsumowuj decyzje, nierozstrzygnięte pytania i zobowiązania.
• Obserwacje narzędzi: zachowuj typowane ustalenia i referencje do artefaktów. Usuwaj boilerplate i powtarzające się payloady.
• Wyszukane dowody: zachowuj identyfikatory źródeł, wspierające fragmenty i daty wejścia w życie, aby system mógł ponownie je pobrać.
• Stan zadania: przechowuj kanonicznie poza podsumowaniem.
• Ślad plików lub artefaktów: utrzymuj jawny indeks odczytów, zapisów, hashy i wyników testów.

Uruchamiaj kompakcję na podstawie zmierzonej degradacji lub progu budżetowego dobranego do modelu i zadania. Nie publikuj ogólnej reguły „kompresuj przy 70%”, jakby wszystkie modele zawodziły w tym samym punkcie.

Oceniaj kompresję za pomocą sond wymagających kontynuacji, a nie podobieństwa leksykalnego:

• Jaki jest bieżący cel i następne działanie?
• Które pliki lub rekordy uległy zmianie?
• Która decyzja została odrzucona i dlaczego?
• Które źródło wspiera bieżące twierdzenie?
• Na jaką akceptację nadal czekamy?

Uruchom to samo zadanie z kompresją i bez niej. Porównaj skuteczność, nieprawidłowe działania, ponowne pobrania, opóźnienie i całkowitą liczbę tokenów.

Optymalizuj ścieżkę kontekstu

Optymalizacja powinna zachowywać kontrakt decyzji. Po zidentyfikowaniu zmierzonego wąskiego gardła przydatne są cztery techniki:

Techniki te rozwiązują różne problemy. Kompakcja i edycja kontekstu mogą zmniejszyć ilość treści wysyłanej do modelu. Selektywne ładowanie narzędzi pozwala uniknąć wysyłania nieużywanych schematów. Prompt caching może obniżyć koszt powtarzających się prefiksów, ale nie zmniejsza liczby tokenów w oknie kontekstu. Partycjonowanie zmienia zestaw możliwości i dowodów otrzymywanych przez każdą decyzję. Przewodnik Anthropic dotyczący kontekstu narzędzi wyraźnie rozróżnia te kwestie, a jego dokumentacja edycji kontekstu udostępnia konfigurowalne wyzwalacze zamiast uniwersalnego progu.

Kompaktuj ukończoną historię

Zastąp stare tury rozmowy strukturalnym przekazaniem zawierającym decyzje, nierozstrzygnięte pytania, zmienione artefakty i stan testów. Zachowaj dostęp do oryginalnego transkryptu lub artefaktów, gdy wymagają tego przegląd lub odzyskiwanie.

Maskuj obszerne obserwacje

Narzędzie może zwrócić całe strony logów, podczas gdy kolejny krok potrzebuje tylko statusu, kodu błędu i referencji do artefaktu. Po walidacji surowego wyniku przekształć go w typowaną obserwację, a pełny payload pozostaw poza promptem. Nie pozwól modelowi podsumować w sposób, który usunie jedyny dowód awarii.

Zachowuj prefiksy możliwe do zcache’owania

Dostawcy i runtime’y mogą ponownie wykorzystać wykonaną pracę, gdy początek żądania pozostaje stabilny. Utrzymuj trwałe instrukcje i schematy narzędzi w stałej kolejności, a znaczniki czasu, identyfikatory żądań, wyszukane dowody i bieżący stan przenieś do dynamicznego sufiksu. Przed zaprojektowaniem rozwiązania na tej podstawie potwierdź semantykę cache dostawcy.

Partycjonuj według decyzji

Planista, retriever, wywołujący narzędzia i etap generowania odpowiedzi końcowej nie potrzebują tych samych materiałów. Każdemu krokowi przekaż minimalny zestaw zaufanych instrukcji, stanu, dowodów i narzędzi. Partycjonowanie jednocześnie zmniejsza zużycie tokenów i ekspozycję możliwości, ale tylko ewaluacje na poziomie zadania pokażą, czy nie usunięto niezbędnych informacji.

Zabezpiecz łańcuch dostaw kontekstu

Badania nad prompt injection traktują niezaufaną treść zewnętrzną jako powierzchnię ataku (artykuł). W operacyjnym modelu tego artykułu zatrucie kontekstu może nastąpić przez dokumenty, pamięci, wyniki narzędzi, umiejętności lub wcześniejsze wiadomości asystenta. Oznaczenie tekstu jako „niezaufanego” pomaga modelowi, ale egzekwowanie musi być architektoniczne.

Poniższa lista kontrolna łańcucha dostaw jest moją rekomendacją inżynieryjną. Przekształca granice protokołu i modelu zagrożeń w mechanizmy kontroli aplikacji. Ani specyfikacja MCP, ani artykuł o prompt injection nie egzekwuje całej tej listy.

Stosuj następujące granice:

1. Autoryzuj przed wyszukiwaniem i wykonaniem narzędzia.
2. Oddzielaj dane od kanałów instrukcji i ograniczaj zewnętrzny tekst separatorami.
3. Stosuj allowlistę narzędzi dla każdego kroku i aktora. Domyślnie nie udostępniaj możliwości wywołujących skutki uboczne.
4. Waliduj identyfikatory zasobów, zamiast pozwalać modelowi wymyślać klucze tenantów lub ścieżki plików.
5. W przypadku operacji o dużym wpływie wymagaj potwierdzenia opartego na polityce, a nie na pewności modelu.
6. Skanuj i przeglądaj wykonywalne umiejętności lub konektory przed instalacją.
7. Nie dopuszczaj do umieszczania sekretów i surowego wrażliwego kontekstu w logach ani w pamięci długoterminowej.

Automatyczna „naprawa” jest odpowiednia wyłącznie dla zmian zachowujących znaczenie, takich jak parsowanie znanego formatu daty. Uzupełnienie brakujących argumentów narzędzia „sensownymi wartościami domyślnymi” może zmienić operację. Gdy znaczenie jest niepewne, poproś o wyjaśnienie lub odrzuć żądanie.

Przykład: zgłoszenie dotyczące klucza API

W przypadku pytania „Dlaczego mój klucz API nie działa?” następną decyzją jest zebranie dowodów diagnostycznych, a nie wygenerowanie odpowiedzi końcowej. Assembler może uwzględnić:

• zaufaną politykę wsparcia i kontrakt odpowiedzi
• uwierzytelniony identyfikator konta i plan z warstwy stanu aplikacji
• bieżący cel zgłoszenia i wykonane już działania
• dwa aktualne fragmenty runbooka wybrane w zakresie produktu i wersji
• pamięć w określonym zakresie, że klucz został utworzony trzy dni temu, wraz z proweniencją
• check_api_key_status i search_incidents, ale nie narzędzia usuwania ani rotacji klucza

Model proponuje kontrolę statusu tylko do odczytu. Kod aplikacji autoryzuje konto, wywołuje narzędzie i zapisuje typowaną obserwację. Drugie wywołanie modelu otrzymuje odpowiednie fragmenty runbooka oraz tę obserwację. Odpowiedź końcowa cytuje wersję runbooka, nigdy nie wyświetla klucza i oferuje rotację wyłącznie jako oddzielnie autoryzowane działanie.

Zwróć uwagę, co pozostaje poza kontekstem: niezwiązana historia zgłoszenia, wszystkie przykłady wsparcia, surowe zrzuty konta, narzędzia mutujące stan i pamięci innych tenantów.

Antywzorce, które należy testować jawnie

• Wypełnienie okna: załadowanie wszystkich wyszukanych dokumentów, historii, pamięci i narzędzi tylko dlatego, że pozostało wolne miejsce.
• RAG wszędzie: używanie wyszukiwania semantycznego dla wartości, które powinny znajdować się w bazie danych, serwisie polityk lub uwierzytelnionym stanie aplikacji.
• Nieograniczona pamięć: przechowywanie wywnioskowanych faktów bez zakresu, wygaśnięcia, mechanizmu korekty lub semantyki usuwania.
• Jedno wywołanie dla każdego etapu: proszenie jednego promptu o wyszukanie, rozumowanie, autoryzację, modyfikację i wyjaśnienie bez obserwowalnych granic.
• Schemat równa się poprawność: traktowanie poprawnego JSON jako dowodu, że wartości, uprawnienia lub decyzje biznesowe są prawidłowe.
• Brak ewaluacji komponentów: ocenianie wyłącznie końcowej prozy i pomijanie awarii wyszukiwania, wyboru kontekstu lub narzędzi.

Przekształć każdy antywzorzec w kontrprzykład w zbiorze ewaluacyjnym. Wytyczną, której nie sprawdza żadne zadanie ani trace, łatwo naruszyć bez zauważenia.

Oceniaj assembler, nie tylko odpowiedź

Utwórz stały zbiór zadań z etykietami dowodów, granicami uprawnień, wymaganymi wywołaniami narzędzi i działaniami zabronionymi. Przy każdej zmianie polityki kontekstu mierz:

Stosuj ablacjami, aby znaleźć wartość przyczynową: usuwaj pamięć, reranking, przykłady lub kompresję pojedynczo. Komponent, który dodaje tokeny bez poprawy wyników na odpowiednim wycinku, nie powinien być ładowany domyślnie.

Podsumowanie

Dobra inżynieria kontekstu jest selektywna i rozliczalna. Nie zapełnia dużego okna tylko dlatego, że dostępna jest wolna pojemność. Buduje working set dla konkretnego kroku z zaufanych instrukcji, kanonicznego stanu zadania, dowodów w określonym zakresie, zweryfikowanej pamięci i dozwolonych narzędzi.

Pętla jest krótka: złożyć, utworzyć manifest, zaproponować, zweryfikować, wykonać i ocenić. Gdy decyzja się nie powiedzie, pętla pokazuje, czy brakowało dowodów, świeżości, wiarygodności, stanu czy polityki. Daje też test dla następnej zmiany.

Materiały źródłowe

• Lost in the Middle — zależne od pozycji wykorzystanie długiego kontekstu
• RULER — wielozadaniowa ewaluacja efektywnej długości kontekstu
• OpenAI Model Spec — specyficzne dla dostawcy poziomy autorytetu instrukcji
• Anthropic Messages API — parametr systemowy i struktura ról komunikatów
• Manage tool context — selektywne ładowanie narzędzi, caching i edycja kontekstu
• Anthropic context editing — konfigurowalne czyszczenie wyników narzędzi i kompakcja
• Model Context Protocol specification — pojęcia protokołu i bieżąca specyfikacja
• Evaluating Context Compression for AI Agents — ujęcie liczby tokenów na zadanie i ewaluacja oparta na sondach
• Formalizing and Benchmarking Prompt Injection Attacks and Defenses — taksonomia zagrożeń i mechanizmy obronne