W prezentacji udostępnionej przez InfoQ Patrick Debois przedstawił podejście, w którym kontekst dla agentów programistycznych staje się zarządzanym artefaktem. Zespoły mają go tworzyć, testować, dystrybuować i obserwować podobnie jak kod. Ma to ułatwić skalowanie pracy z agentami AI oraz ograniczyć ryzyko wynikające z ich niedeterministycznych rezultatów.
Kontekst otrzymuje własny cykl życia
Debois jest Product DevRel lead w Tessl i zajmuje się wzorcami AI-native development, inżynierią kontekstu oraz obiegiem wiedzy w organizacjach. Swoją propozycję opiera na analogii do DevOps. Skoro praktyki programistyczne pomogły uporządkować operacje, podobne mechanizmy mogą objąć materiały przekazywane agentom.
Kontekst obejmuje instrukcje, reguły, dokumentację, specyfikacje, informacje o zależnościach oraz wiedzę zebraną podczas wcześniejszych zadań. Może też stanowić część produktu. Debois podał przykład procesu wdrażania użytkowników, w którym rozbudowaną logikę obsługującą przypadki brzegowe zastąpiła umiejętność opisana językiem naturalnym i wykonywana przez agenta.
- Generowanie - tworzenie i aktualizowanie materiałów dla agentów.
- Ocena - sprawdzanie składni, jakości i skuteczności kontekstu.
- Dystrybucja - wersjonowanie, pakowanie i udostępnianie kontekstu.
- Obserwacja - zbieranie informacji o działaniu agentów i poprawianie instrukcji.
Debois określa ten obieg jako Context Development Life Cycle. Odróżnia go od dobierania treści do okna kontekstowego modelu. W tym podejściu zespół zarządza całym zasobem wiedzy, z którego agent może korzystać.
Jak tworzyć i porządkować kontekst dla agentów
Ręczne poprawianie poleceń podczas każdej sesji nie skaluje się na większą liczbę projektów i użytkowników. Zespół powinien działać jako kurator kontekstu, który pilnuje aktualności, poprawności i dostępności instrukcji. Agent nadal może wybierać potrzebne materiały, ale musi mieć dostęp do kontrolowanego źródła wiedzy.
Jednym z rozwijających się sposobów zapisu instrukcji jest plik AGENTS.md. Ma on umożliwiać ponowne wykorzystanie reguł przez różne narzędzia, choć Claude nadal korzysta z CLAUDE.md. Kontekst może też pochodzić z dokumentacji bibliotek. Context7 i Ref dobierają materiały na podstawie zależności projektu oraz używanej wersji biblioteki.
Podobny model może działać wewnątrz organizacji. Zespół utrzymujący mikrousługę publikuje instrukcje jej użycia, a inne zespoły pobierają je do swoich projektów. Złącza oparte na Model Context Protocol mogą wyszukiwać informacje w źródłach takich jak Slack. Kiro i SpecKit traktują natomiast specyfikacje produktu lub zadania jako trwalszą formę kontekstu niż pojedynczy prompt.
Jak testować kontekst i oceniać ryzyko zmian
Debois wskazuje SWE-bench jako przykład myślenia o testach dla agentów. Większość zespołów nie buduje własnych modeli, może jednak tworzyć zestawy zadań sprawdzające dostarczany kontekst. Test uruchamia agenta, przekazuje zadanie i ocenia rezultat. Pozwala porównać pracę bez instrukcji, ze starszą wersją kontekstu i po jego aktualizacji.
Najprostszy poziom kontroli przypomina linting kodu. Narzędzie może sprawdzić składnię pliku, obecność wymaganych pól YAML albo długość opisu. Model językowy może dodatkowo ocenić jasność, spójność i przydatność treści. Debois porównuje taki mechanizm do narzędzia redakcyjnego analizującego styl instrukcji.
Test funkcjonalny powinien sprawdzać, czy umiejętność agenta rzeczywiście prowadzi do wykonania zadania. Test end-to-end może rozpoczynać się od konkretnego commitu, przekazywać ustalony prompt i weryfikować zmiany w repozytorium. Przypadki, w których agent podczas codziennej pracy wykonał zadanie niepoprawnie, mogą zasilać bibliotekę testów regresji.
Takie oceny można uruchamiać w CI/CD, ale wynik pozostaje niedeterministyczny. Debois podaje przykład pięciokrotnego wykonania tego samego testu i zaakceptowania rezultatu, który działa w większości prób. Przy wyniku na poziomie 98 proc. sam zielony lub czerwony status nie wystarcza. Zespół musi określić, które przypadki zawsze muszą przejść, a dla których dopuszcza margines błędu podobny do budżetu błędów. Decyzja o wdrożeniu może wówczas należeć do właściciela produktu.
Jak pakować, wersjonować i zabezpieczać kontekst
Przechowywanie plików z instrukcjami w Git ułatwia ich współdzielenie, ale nie rozwiązuje problemu użycia w wielu projektach. Debois proponuje model znany z bibliotek oprogramowania. Zespół pakuje kontekst, publikuje go w rejestrze i instaluje wskazaną wersję tam, gdzie jest potrzebna. Może do tego wykorzystać mechanizmy podobne do pakietów npm.
Umiejętności agentów zaczynają pełnić rolę przenośnego formatu kontekstu obsługiwanego przez różnych dostawców narzędzi programistycznych. Sam rejestr nie gwarantuje jednak jakości. Umiejętność udostępniona w marketplace może nie mieć testów, dokumentacji ani potwierdzenia, że działa poza repozytorium autora.
Pakiety kontekstu wymagają także skanowania bezpieczeństwa, ponieważ mogą zawierać wykonywalny kod. Snyk przygotował skaner kontekstu, a Debois wskazuje również potrzebę rejestrowania pochodzenia materiałów. AI Bill of Materials może opisywać, kto, kiedy i w jaki sposób utworzył dany element. Adnotacje w GitHub oraz mechanizmy podobne do git blame mogą odróżniać wkład człowieka od treści wygenerowanej przez AI. Pełniejszy dziennik zmian daje agentowi także historię decyzji projektowych.
Jak obserwować agentów i aktualizować ich wiedzę
Ostatnim etapem jest obserwacja rzeczywistej pracy agenta. System może analizować błędy zapisane w logach, przygotowywać retrospektywę i proponować lepszą wersję instrukcji. Hugging Face stosował podejście, w którym agent oceniał wykonane działania, a wnioski wracały do jego kontekstu. Zaktualizowany pakiet może następnie trafić do rejestru i kolejnych agentów.
Informacje zwrotne nie muszą pochodzić wyłącznie z logów technicznych. Recenzje commitów i rozmowy na Slacku również pokazują, czy kontekst zadziałał. Hud instrumentuje kod wdrożony na produkcji i wiąże zdarzenia z konkretnymi liniami. Agent może wykorzystać dane o awarii jako lekcję, którą należy dołączyć do kontekstu przed następną zmianą.
Obserwowalność musi obejmować także zachowania niepożądane, takie jak połączenia z nieznanymi punktami końcowymi, odczyt zmiennych środowiskowych, dostęp do pamięci lub próby wyprowadzenia danych przez DNS. Dlatego Debois łączy monitoring z izolowanym środowiskiem uruchomieniowym i kontrolą operacji sieciowych.
Dla firm w Polsce oznacza to potrzebę objęcia instrukcji dla agentów tym samym nadzorem, który stosują wobec kodu i zależności. Przed szerszym wdrożeniem warto wskazać właściciela kontekstu, prowadzić wersje w repozytorium, budować testy na własnych projektach i zbierać dane z produkcji. Materiał nie podaje kosztu takiego procesu ani gotowego zestawu narzędzi dla całego cyklu.
