Context Engineering: zaawansowane zarządzanie oknem kontekstu

Czego się nauczysz

• Czym context engineering różni się od zwykłego prompt engineeringu
• Jak projektować warstwy kontekstu: always-on, plan, task-specific i sesyjne
• Jak unikać context dumpingu, szumu i mieszania niezwiązanych tematów

Context engineering nie polega na wrzuceniu wszystkiego do promptu

Wręcz przeciwnie.

To sztuka selekcji i układania informacji tak, żeby agent podejmował lepsze decyzje przy mniejszej liczbie korekt.

Prompt engineering pyta: jak sformułować polecenie.

Context engineering pyta: jakie informacje, w jakiej formie i w którym momencie mają trafić do modelu.

Oficjalny workflow jest trzystopniowy

Guide kontekstowy w VS Code pokazuje trzy główne kroki:

1. Curate project-wide context
2. Create implementation plan
3. Generate implementation code

To bardzo dojrzały model.

Nie próbujesz od razu implementować wszystkiego z jednego, gigantycznego promptu. Najpierw budujesz wspólną podstawę wiedzy, potem plan, a dopiero na końcu wykonanie.

Warstwa pierwsza: project-wide context

To wszystko, co agent powinien wiedzieć stale o projekcie, ale czego nie wywnioskuje łatwo z kodu.

Najczęściej będą to:

• architektura
• zasady domenowe
• proces pracy zespołu
• istotne ograniczenia środowiska

W docsach widać dobry wzorzec: krótkie dokumenty typu PRODUCT.md, ARCHITECTURE.md, CONTRIBUTING.md plus odwołania do nich z .github/copilot-instructions.md.

To jest lepsze niż wrzucanie ściany tekstu do jednej instrukcji always-on.

Warstwa druga: plan

Plan jest osobnym artefaktem, a nie dodatkiem do promptu implementacyjnego.

To ma ogromny sens, bo plan zbiera:

• zakres zadania
• decyzje architektoniczne
• podział na kroki
• otwarte pytania
• sposób weryfikacji

W momencie implementacji agent nie musi już zgadywać struktury pracy. Ma ją pod ręką.

Warstwa trzecia: task-specific context

To wszystko, co dotyczy konkretnej sesji i konkretnego problemu:

• pliki dodane przez #
• #codebase
• problemy z panelu Problems
• output z terminala
• wyniki testów
• zasoby z browsera albo MCP

To jest właśnie warstwa, która ma być dynamiczna i oszczędna. Nie próbuj przenosić jej do always-on instructions.

Kontekst trzeba też odchudzać

VS Code pokazuje kontekstowe usage w pasku wejścia czatu i obsługuje automatyczną oraz ręczną kompaktację.

To ważne, bo kontekst nie psuje się tylko przez brak informacji. Psuje się też przez nadmiar informacji i historię, która przestała być istotna.

/compact jest praktycznym narzędziem do resetowania szumu bez tracenia najważniejszych decyzji.

Najbardziej niedoceniona technika: nowe sesje

Guide i best practices mówią to dość jasno: nie trzymaj wszystkiego w jednym wątku.

Jeśli zmieniasz temat, typ pracy albo obszar problemu, nowa sesja często daje lepsze efekty niż ratowanie starej coraz dłuższym promptem.

To jest prosty sposób na izolację kontekstu bez budowania wielkiej infrastruktury.

Subagenci i plan agent to narzędzia porządkowania kontekstu

To ważne, bo context engineering nie kończy się na plikach instructions.

Subagent pozwala zrobić research w izolowanym kontekście.

Plan agent pozwala utrzymać osobną fazę myślenia przed wykonaniem.

Oba mechanizmy robią tę samą dobrą rzecz: nie mieszają wszystkiego w jednej głównej nitce rozmowy.

Antywzorzec: context dumping

Guide nazywa to wprost i bardzo dobrze.

Context dumping to sytuacja, w której dodajesz zbyt dużo nieukierunkowanych informacji, licząc, że model “sam sobie wybierze” to, co ważne.

W praktyce zwykle dzieje się odwrotnie:

• rośnie koszt poznawczy
• spada trafność decyzji
• pojawiają się sprzeczne sygnały

Lepsza zasada brzmi: mniej, ale bardziej decyzyjnie.

Dokumenty kontekstowe też są kodem

To świetna myśl z guide’a: custom instructions, custom agents i plan templates powinny być traktowane jak living documents.

Jeśli agent regularnie popełnia ten sam błąd, poprawiasz dokument kontekstowy. Jeśli dokument zaczyna rozmijać się z rzeczywistością projektu, aktualizujesz go tak samo jak kod.

Ćwiczenie praktyczne

Rozpisz własny mini workflow context engineering dla jednego projektu:

• co trafia do .github/copilot-instructions.md
• jaki dokument planistyczny tworzysz dla większych zadań
• kiedy używasz #mentions
• kiedy otwierasz nową sesję
• kiedy odpalasz /compact

Na końcu sprawdź, czy któraś warstwa nie jest przeciążona informacjami, które powinny żyć gdzie indziej.

Kluczowe wnioski

• Context engineering to projektowanie przepływu informacji, nie tylko formułowanie lepszego promptu.
• Najlepiej działa model warstwowy: project-wide context, plan, task-specific context.
• Nadmiar kontekstu szkodzi tak samo jak jego brak.
• Nowe sesje, /compact, subagenci i plan agent są narzędziami porządkowania kontekstu, nie dodatkami dla zaawansowanych.

Co dalej

Masz już model kontekstu. Teraz pora przełożyć go na bardzo praktyczny workflow inżynierski: red-green-refactor z Copilotem, czyli TDD wspierane przez AI.